XMLマスターポイントレッスン
～ プロフェッショナル(アプリケーション開発)編 ～
第6回 XMLデータの交換／XMLセキュリティ
インフォテリア株式会社 教育部 木村 達哉
今回は、「XMLマスター：プロフェッショナル(アプリケーション開発)」認定試験のセクション5で出題される、XMLデータの交換や、その際に用いられるセキュリティ技術に関連する問題のポイントについて解説します。標準仕様を正しく理解するとともに、各仕様の相互の関連性についてもしっかりと押さえておきましょう。
セクション5の出題範囲
XMLは、データの保存形式としてだけでなく、ネットワーク経由でデータ交換を行う際など、さまざまな場面で利用されています。特に、インターネット上でデータ交換を行う場合には、XML形式のファイルをやり取りすることも多いでしょう。そして、その際には、何らかの通信プロトコルやセキュリティ技術が必要となります。
セクション5で問われるのは、こうした通信プロトコル／セキュリティ技術に関連する知識です。具体的には、次の6つの仕様を出題範囲としています。
●SOAP 1.1
SOAP 1.1は、XML文書をネットワーク経由で伝送する際のメッセージ仕様を定めた、XMLベースの標準プロトコルです。そのメッセージ仕様は、特定のプログラミング言語やOSに依存しないため、使用する言語／OSが異なるシステム間でも、データ交換を行うことができます。
●WSDL 1.1
WSDL 1.1は、ネットワーク・サービスに関連する情報（アクセス・ポイントやインタフェース仕様など）をXMLで記述するための仕様をまとめたものです。ただし、WSDLでは、メッセージを受信／送信する際のプロトコルは定めていません。メッセージを送受信する際のプロトコルには、上述したSOAPを使用するのが一般的です。
●XML-Signature Syntax and Processing
XML-Signature Syntax and Processing（以下、XML-Signature）は、XML文書に付加する電子署名に関する仕様です。インターネット経由でビジネスに用いるデータを交換する場合、「データが改竄されていないこと」および「送信者本人から送られてきたものであること」を証明できる仕組みが必要になります。そこで、XML文書に電子署名を付加するための仕様をまとめて標準化したものが、XML-Signatureというわけです。
●XML Encryption Syntax and Processing
XML Encryption Syntax and Processing（以下、XML Encryption）は、XML文書の暗号化に関する仕様です。同仕様では、インターネット経由でデータを交換する際に使用する暗号化の仕組みが定められています。
●Canonical XML Version 1.0
Canonical XML Version 1.0（以下、Canonical XML）は、XML文書を正規化形式にシリアライズする方法をまとめた仕様です。同仕様に基づいて2つのXML文書をそれぞれ正規化形式にシリアライズした結果が同一であれば、「元の2つのXML文書は、論理的に等価である」ということになります。
●Exclusive XML Canonicalization Version 1.0
Canonical XMLがXML文書全体を対象とした正規化形式を規定しているのに対し、Exclusive XML Canonicalization Version 1.0（以下、Exclusive XML Canonicalization）は、XML文書の一部分を対象にした正規化の方法をまとめた仕様です。Canonical XMLをベースとし、名前空間の扱いに関する部分に変更を加えています。
電子署名の付加とXML文書の正規化
前節では、セクション5の出題範囲となる6つの標準仕様を挙げ、その概要を説明しました。例題とその解説に入る前に、各仕様の関連について補足しておきましょう。
XML-Signatureに基づいて電子署名の付加を行う場合、Canonical XMLやExclusive XML CanonicalizationによるXML文書の正規化が不可欠です。まずは、その理由について、説明しましょう。
XMLによる記述形式には、比較的、柔軟性があります。例えば、要素phoneに内容がない場合、「<phone></phone>」と記述することもできれば、「<phone/>」と記述することも可能です。両者は、記述は異なっていても論理的には等価であるため、もし、送信前後のXML文書を比較した結果、こうした差異があっても、XML文書が改竄されたことにはなりません。
ところが、電子署名を付加した場合には、送信前後のXML文書にこのような記述の差異があると、データが改竄されたと判断されてしまうのです。そこで、Canonical XMLでは、記述に差異があっても論理的に等価なXML文書を同一のXML文書と見なすための統一的な表現方法を定めているのです。
また、Exclusive XML Canonicalizationは、先にも述べたように、XML文書の一部分を対象とし、名前空間の問題を解決して正規化する方法をまとめた仕様です。と言っても、いまひとつ用途がわかりづらいかもしれません。そこで、1つ具体的な例をご覧いただきましょう。SOAPを使用したデータ交換では、送信前のXMLデータをSOAPメッセージ内に記述します。このとき、SOAPメッセージの名前空間宣言が、内部に記述されたXMLデータに影響を与える可能性があるのです。例えば、送信前のXML文書が以下のようなものであるとします。
| <ns:Order xmlns:ns="http://example.com/order">
<ns:product>table</ns:product> <ns:quantity>2</ns:quantity> </ns:Order> |
このXML文書をSOAPメッセージ内に記述すると、次のようになります。
| <SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <ns:Order xmlns:ns="http://example.com/order"> <ns:product>table</ns:product> <ns:quantity>2</ns:quantity> </ns:Order> </SOAP-ENV:Body> </SOAP-ENV:Envelope> |
このSOAPメッセージを受信した側は、その内部に記述されたXMLデータを取り出すわけですが、その際、処理の仕方によっては、次のようなXMLデータが取り出される可能性があります。
| <ns:Order xmlns:ns="http://example.com/order"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <ns:product>table</ns:product> <ns:quantity>2</ns:quantity> </ns:Order> |
ご覧のとおり、取り出したXMLデータには、元のXMLデータにはなかった名前空間宣言xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"が追加されています。これは、SOAPメッセージで宣言している名前空間宣言が、その内部に記述されていたXMLデータに影響を与えたためです。この名前空間宣言は、「SOAP-ENV」という名前空間接頭辞の宣言なので、XMLデータ内でその接頭辞を使用していなければ、xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"という名前空間宣言の記述の有無は、XML文書の内容に影響を与えません。したがって、2つのXML文書は論理的には等価なのですが、電子署名を用いていた場合には、改竄されたと見なされてしまいます。
こうした場合に、Exclusive XML Canonicalizationを利用すれば、SOAPメッセージの名前空間宣言の影響が考慮され、論理的に等価なXMLデータは同一のXMLデータとして扱うことができるのです。
SOAPメッセージのセキュリティ
前節で説明したXML-SignatureやXML Encryptionは、電子署名や暗号化のルールを定めたものにすぎません。したがって、実際にそれらを使う場合には、署名／暗号化を施した後のSOAPメッセージの形式をどうするか、あるいは電子署名の検証方法はどうするのかといった具体的な事柄もあらかじめ決めておく必要があります。そうした事柄を定めたものが、標準化団体OASISが策定した「Web Services Security v1.0（以下、WS-Security）」です※1。
※1 WS-Securityは、XMLマスター：プロフェッショナル(アプリケーション開発)の試験範囲には含まれない。
WS-Securityは、「SOAP Message Security 1.0」を中心として、合計5つの仕様で構成されています。
SOAP Message Security 1.0は、電子署名の付加／暗号化後のSOAPメッセージの形式や、電子署名の付加およびその電子署名の検証を行う際の手順、暗号化／復号化の手順などを定めたものです。同仕様では、XML-SignatureとXML Encryptionの実装を必須としているほか、XML文書の正規化にはExclusive XML Canonicalizationの実装を用いることを強く推奨しています。
このように、SOAPやXML-Signature、Exclusive XML Canonicalizationなどの各仕様は、相互に連携しつつ、交換するXMLデータのセキュリティを確保するのです。
なお、セクション5では、ここまでに説明した各仕様についての理解度を問う問題のほか、“XMLとシステムの連携”に関する設問も出題されます。以下に、それに関するポイントをまとめておきましょう。
●アプリケーションとデータベースとの連携やアプリケーション同士の連携などに、XMLを使用する際の注意点／考慮点
●XMLのメディア・タイプを定めるRFC 3023に対する理解
●XMLデータの構造とデータ型をプログラミング言語にマッピングする、データ・バインディングに対する理解
これらを踏まえ、次節からの例題に挑戦してみてください。
●セクション5の出題例――（1）
次に示すWSDL定義（WSDL 1.1を使用）は、あるWebサービスの仕様を定義しています。これについて説明している選択肢のうち、正しいものを1つ選択してください。
《WSDL定義》
| <definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/1999/XMLSchema"> <complexType name="inputType"> <sequence> <element name="tickerSymbol" type="string"/> </sequence> </complexType> </schema> </types> <message name="GetLastTradePriceInput"> <part name="input" type="xsd1:inputType"/> </message> <message name="GetLastTradePriceOutput"> <part name="output" type="xsd:long"/> </message> <portType name="StockQuotePortType"> <operation name="getLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> </definitions> |
●選択肢
A.
Webサービス側にメッセージを送信するためのプロトコルは、HTTPである
B.
Webサービス側に送信するメッセージは、SOAPメッセージである
C.
Webサービスが提供する機能は、要求／応答（Request-response）型である
D.
2つ目の要素messageの子要素partの属性typeに記述しているxsd:long型が、要素types内に定義されていないため、WSDL定義の記述形式として誤っている
●解答
C
●解説
WSDL定義では、設問で使用している要素types、message、portTypeのほか、要素binding、serviceを使うことが可能です。問題の解説に入る前に、これらの各要素について簡単に説明しておきましょう。
まず、要素types、message、portTypeは、Webサービスが提供する機能（オペレーション）を定義するためのものです。また、要素bindingではメッセージの送信に使用する具体的なプロトコルを定義し、要素serviceによってアクセス・ポイントを記述します。このように、WSDL定義では、オペレーション定義と、プロトコルやアクセス・ポイントの定義を分離して記述することが可能です。これにより、1つのオペレーションを複数のプロトコルやアクセス・ポイントを利用して提供できるというわけです。
以上を踏まえ、例題を見てみましょう。例示されている《WSDL定義》では、プロトコルを定義するための要素bindingが記述されていないので、選択肢AとBは誤りです。
また、《WSDL定義》において、要素portTypeの子要素input/outputは、提供する機能が要求／応答型であることを示しています※2。したがって、選択肢Cが正解です。
※2 このほかに、要素inputのみで記述する一方向（One-way）型の機能などがある。
なお、選択肢Dにある「xsd:long型」というのは、「XML Schema Part 2: Datatypes」で定義されているデータ型です。この場合、要素typesによる型定義は必要ないため、選択肢Dは誤りとなります。
●セクション5の出題例――（2）
Canonical XMLを用いて、各選択肢に示すXML文書の正規化を行った場合、正規化後の形式が次の《XML文書》の形式と同一にならないものを2つ選択してください。
《XML文書》
| <parent>
<child1>DATA1</child1> <child2>DATA2</child2> </parent> |
●選択肢
A.
| <parent>
<child1>DATA1</child1> <child2>DATA2</child2> </parent> |
B.
| <parent>
<child1> DATA1 </child1> <child2>DATA2</child2> </parent> |
C.
| <parent>
<child1 >DATA1</child1> <child2 >DATA2</child2> </parent> |
D.
| <?xml version="1.0"?>
<parent> <child1>DATA1</child1> <child2>DATA2</child2> </parent> |
●解答
A、B
●解説
Canonical XMLは、先にも説明したように、XML文書の正規化を行う際のルールを定めたものです。この例題の場合、Canonical XMLに基づいて正規化を行うとすると、以下のようなルールに従うことになります。
（1）文字エンコーディング方式は、UTF-8とする
（2）XML宣言と文書型宣言を出力しない
（3）空要素を記述する際は、空要素タグではなく、開始タグと終了タグを組み合わせて使う
（4）開始タグ内、終了タグ内にある余分な空白は、削除される
選択肢A、B、Cは、提示されている《XML文書》と比較してみると、それぞれ異なる個所に改行を含む空白文字が追加されています。このうち、選択肢Cでは、開始タグ内に空白文字が追加されているので、上記の（4）に基づき、その空白文字は正規化の対象となります（結果として、空白文字は削除されることになります）。
他方、選択肢A、Bでは、開始タグや終了タグの外側に空白文字が追加されており、これらは削除の対象にはなりません。
また、選択肢DのXML文書は、提示されている《XML文書》とほぼ同じ記述ではあるものの、唯一異なる点として、XML宣言「<?xml version="1.0"?>」が追加されています。ただし、このXML宣言は、ルールの（2）に基づき、正規化後の形式には含まれません。
以上のことから、正解は選択肢A、Bとなります。
なお、以下に、設問で提示したXML文書を正規化した結果を示しておくので、参考にしてください（選択肢C、Dに関しては《XML文書》と同様の結果となります）。
《XML文書》
| <parent>
<child1>DATA1</child1> <child2>DATA2</child2> </parent> |
A.
| <parent>
<child1>DATA1</child1> <child2>DATA2</child2> </parent> |
B.
| <parent>
<child1> DATA1 </child1> <child2>DATA2</child2> </parent> |
XMLマスターポイントレッスン ～ プロフェッショナル(アプリケーション開発)編 ～ 記事一覧へ戻る
