Web Services Security (WS-Security)

[アーティクル]
11/20/2008

Version 1.0

April 5, 2002

          日本語版編者 (あいうえお順):
          加藤健二 (マイクロソフト株式会社)
          高橋伸和 (日本ベリサイン株式会社)
          野村一行 (マイクロソフト株式会社)
          羽田知史 (日本アイ・ビー・エム株式会社)
          丸山宏 (日本アイ・ビー・エム株式会社)

執筆者

          Bob Atkinson (Microsoft)
          Giovanni Della-Libera (Microsoft)
          羽田知史(IBM)
          Maryann Hondo (IBM)
          Phillip Hallam-Baker (VeriSign)
          Chris Kaler (編集者) (Microsoft)
          Johannes Klein (Microsoft)
          Brian LaMacchia (Microsoft)
          Paul Leach (Microsoft)
          John Manferdelli (Microsoft)
          丸山宏 (IBM)
          Anthony Nadalin (IBM)
          Nataraj Nagaratnam (IBM)
          Hemma Prafullchandra (VeriSign)
          John Shewchuk (Microsoft)
          Dan Simon (Microsoft)

著作権について

The presentation, distribution or other dissemination of the information contained in this specification is not a license, either expressly or impliedly, to any intellectual property owned or controlled by IBM or Microsoft or VeriSign and\or any other third party. IBM, Microsoft, VeriSign and\or any other third party may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to IBM's or Microsoft's or VeriSign's or any other third party's patents, trademarks, copyrights, or other intellectual property. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, places, or events is intended or should be inferred.

This specification and the information contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, IBM and Microsoft and VeriSign provides the document AS IS AND WITH ALL FAULTS, and hereby disclaims all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the document. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE DOCUMENT.

IN NO EVENT WILL IBM OR MICROSOFT OR VERISIGN BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

この翻訳文書の元になったオリジナルの英語版がこの仕様の正式版です。内容に隔たりがある場合、英語版が正しいものです。また、日本語版の著作権は、日本アイ・ビー・エム株式会社、日本ベリサイン株式会社、マイクロソフト株式会社が所有します。

概要

WS-Security は、メッセージの完全性、メッセージの秘匿性、および単一メッセージの認証による "保護品質" を提供するための SOAP メッセージングに対する機能強化について記述しています。これらのメカニズムを、幅広いセキュリティモデルと暗号化テクノロジに対応するために使用できます。

また、WS-Security はセキュリティトークンとメッセージを関連付けるための汎用メカニズムも提供しています。 WS-Security は、特定の種類のセキュリティトークンを必要としません。 WS-Security は、拡張可能であるようにデザインされています (たとえば、複数のセキュリティトークン形式をサポートします)。クライアントが ID の証明や特定のビジネス上の許可証、免許証を持っていることの証明を提供することなどが考えられます。

さらに、WS-Security はバイナリセキュリティトークンをエンコードする方法を記述しています。この仕様では特に、構造の不明な暗号化された鍵を含める方法のみならず、 X.509 証明書や Kerberos チケットをエンコードする方法も記述しています。また、この仕様には、メッセージに含まれるクレデンシャルの特性をさらに詳しく記述するために使用できる拡張性メカニズムも含んでいます。

組み合わせ可能なアーキテクチャ

SOAP ベースの仕様は、 SOAP 拡張性モデルを使用することにより、互いに組み合わせることで豊富なメッセージング環境を提供できるようにデザインされています。このため、WS-Security は単独でセキュリティを保証するものでもなく、完全なセキュリティソリューションを提供するものでもありません。 WS-Security は、他の Web サービスとアプリケーション固有のプロトコルと組み合わせて、幅広いセキュリティモデルと暗号化テクノロジに対応するための基本要素です。 WS-Security を実装することが、アプリケーションが攻撃を受けないとか、セキュリティが危殆化されないことを意味するわけではありません。

ステータス

WS-Security と関連仕様は、現状有姿のまま、レビューと評価の目的のみに提供されています。 IBM、Microsoft、および VeriSign は近い将来に、読者からの寄稿と提案を募る予定です。 IBM、Microsoft、および VeriSign は、これらの仕様に関して、いかなる形の保証や表明も行いません。

1. はじめに
    1.1. 目標と要件
       1.1.1. 要件
       1.1.2. この仕様が目標としない事項
    1.2. 例
2. 表記と用語
    2.1. 表記規則
    2.2. 名前空間
    2.3. 専門用語
3. 保護品質
    3.1. メッセージセキュリティモデル
    3.2. メッセージの保護
    3.3. 申告がないか、不適切な申告
4. Security 要素
    4.1. UsernameToken 要素
    4.2. バイナリセキュリティトークンのエンコード
    4.3. SecurityTokenReference 要素
    4.4. ds:KeyInfo
    4.5. ds:Signature
       4.5.1. アルゴリズム
       4.5.2. メッセージの署名
       4.5.3. 完全性の検証
       4.5.4. 例
    4.6. Encryption サブ要素
       4.6.1. xenc:ReferenceList
       4.6.2. xenc:EncryptedKey
       4.6.3. xenc:EncryptedData
       4.6.4. 処理規則
5. 拡張例
6. エラー処理
7. セキュリティの考慮事項
8. 謝辞
9. 参考文献

1. はじめに

本仕様は、完全性と秘匿性を実装するようなセキュアな Web サービスの構築に使用できる SOAP 拡張機能の標準セットを提案しています。これらの拡張機能のセットを "Web Services Security Language" または "WS-Security" と呼びます。

WS-Security は柔軟性があり、 PKI、Kerberos、および SSL などの幅広いセキュリティモデルを構築するための基礎として使用するようにデザインされています。 WS-Security は特に、複数のセキュリティトークン、複数の信頼ドメイン、複数の署名形式、および複数の暗号化テクノロジのサポートを提供します。

本仕様は、セキュリティトークンの受け渡し、メッセージの完全性、およびメッセージの秘匿性の 3 つの主要なメカニズムを提供します。これらのメカニズムは、それ自体で完全なセキュリティソリューションを提供するわけではありません。むしろ、WS-Security は、他の Web サービス拡張機能や高レベルのアプリケーション固有のプロトコルと組み合わせて、幅広いセキュリティモデルや暗号化テクノロジに対応するために使用できる基本要素です。

これらのメカニズムは、単独で使用することも (セキュリティトークンに渡すなど)、緊密に統合した手法で使用することもできます (メッセージの署名と暗号化を行い、署名と暗号化で使用される鍵に関連付けられたセキュリティトークン階層を提供するなど)。

このドキュメントは、SOAP-SECを含むIBMおよびMicrosoftによる既存のWebサービスセキュリティの仕様、つまり、Microsoft の WS-Security と WS-License、および IBM のセキュリティトークンと暗号化ドキュメントを置き換えます。

セクション 1 が標準ではないことに注意してください。

1.1. 目標と要件

WS-Security の目標は、アプリケーションがセキュアな SOAP メッセージ交換を行えるようにすることです。

本仕様は、ある範囲のセキュリティプロトコルの構築に使用できる柔軟なメカニズムのセットを提供することを目的としています。つまり、本仕様は明示的な固定されたセキュリティプロトコルについて記述しているわけではありません。

あらゆるセキュリティプロトコルがそうであるように、 WS-Security を使用して構築されるセキュリティプロトコルに幅広い攻撃への耐性を持たせるには、多大な労力を投じる必要があります。

要約すると、本仕様は、確立されたセッション、セキュリティコンテキスト、および (または) ポリシーの合意を前提として、メッセージのセキュリティを提供する単一のメッセージセキュリティ言語を記述することを中心としています。

セキュアなメッセージ交換をサポートする要件を以下に示します。

1.1.1. 要件

Web サービスセキュリティ言語は、幅広いセキュリティモデルをサポートする必要があります。以下のリストは、本仕様の主要な要件を示しています。

認証または認可のための複数のセキュリティトークン
複数の信頼ドメイン
複数の暗号化テクノロジ
単なるトランスポートレベルのセキュリティではない、エンドツーエンドのメッセージレベルのセキュリティ

1.1.2. この仕様が目標としない事項

以下のトピックは、本ドキュメントの対象範囲ではありません。

複数の交換を必要とするセキュリティコンテキストの確立または認証メカニズム
鍵交換と派生鍵
信頼が確立または決定される方法

1.2. 例

以下の例は、ユーザ名セキュリティトークンを持つメッセージを例示しています。

(001) <?xml version="1.0" encoding="utf-8"?>
(002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
(003)   <S:Header>
(004)      <m:path xmlns:m="https://schemas.xmlsoap.org/rp/">
(005)         <m:action>http://fabrikam123.com/getQuote</m:action>
(006)         <m:to>http://fabrikam123.com/stocks</m:to>
(007)         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
(008)      </m:path>
(009)      <wsse:Security
             xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext">
(010)         <wsse:UsernameToken Id="MyID">
(011)             <wsse:Username>Zoe</wsse:Username> 
(012)         </wsse:UsernameToken>
(013)         <ds:Signature>
(014)            <ds:SignedInfo>
(015)               <ds:CanonicalizationMethod
                   Algorithm=
                          "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(016)               <ds:SignatureMethod 
                        Algorithm=
                        "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(017)               <ds:Reference URI="#MsgBody">
(018)                  <ds:DigestMethod 
                          Algorithm=
                        "http://www.w3.org/2000/09/xmldsig#sha1"/>
(019)                  <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
(020)               </ds:Reference>
(021)            </ds:SignedInfo>
(022)            <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
(023)            <ds:KeyInfo>
(024)                <wsse:SecurityTokenReference>
(025)                 <wsse:Reference URI="#MyID"/>
(026)                </wsse:SecurityTokenReference>
(027)            </ds:KeyInfo>
(028)         </ds:Signature>
(029)      </wsse:Security>
(030)   </S:Header>
(031)   <S:Body Id="MsgBody">
(032)     <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">
              QQQ
          </tru:StockSymbol>
(033)   </S:Body>
(034) </S:Envelope>

最初の 2 行は、SOAP エンベロープの始まりです。行 (003) は、この SOAP メッセージに関連付けられているヘッダーの始まりです。行 (004) から (008) までは、 (WS-Routing で定義されているように) このメッセージをルーティングする方法を指定しています。

行 (009) は、この仕様で定義する <Security> ヘッダーの始まりです。このヘッダは、想定される受信者のセキュリティ情報を保持します。この要素は、行 (029) まで続いています。

行 (010) から (012) までは、メッセージに関連付けられるセキュリティトークンを指定しています。この場合は、 <UsernameToken> を使用して、クライアントの "username" を定義しています。ここでは、サービスがパスワードを知っていることを前提としていることに注意してください。つまり、秘密を共有しています。

行 (013) から (028) までは、デジタル署名を指定しています。この署名は、署名付き要素の完全性を保証しています (つまり、これらの要素が変更されていないことを保証しています)。署名は、XML 署名仕様を使用します。この例では、署名はユーザのパスワードから生成される鍵に基づいています。通常はより強固な署名メカニズムが使用されるでしょう (後述の「拡張例」を参照してください)。

行 (014) から (021) までは、そのデジタル署名を記述しています。行 (015) は、署名されているデータを正規化する方法を指定しています。

行 (017) から (020) までは、署名されている要素を選択しています。行 (017) は特に、<S:Body> 要素が署名されていることを示しています。この例では、メッセージ本文のみに署名が行われています。通常は、ルーティングヘッダの一部などのメッセージの付加的な要素が、その署名に含められます (後述の「拡張例」を参照してください)。

行 (022) は、XML 署名仕様で定義されているように、署名されているデータの正規化形式の署名値を指定しています。

行 (023) から (027) までは、この署名に関連付けられたセキュリティトークンを見つけるための場所に関する "ヒント" を提供しています。 (024) から (025) までは特に、セキュリティトークンを指定した URL で見つけられる (から取り出せる) ことを示しています。

行 (031) から (033) までは、SOAP メッセージの "本文" (ペイロード) を含んでいます。

2. 表記と用語

このセクションでは、本仕様で使用される表記、名前空間、および用語を示します。

2.1. 表記規則

このドキュメントのキーワード "MUST"、"MUST NOT"、 "REQUIRED"、"SHALL"、"SHALL NOT"、 "SHOULD"（する必要がある）、"SHOULD NOT"（しないほうがいい）、"RECOMMENDED"（推奨される）、 "MAY"（してもよい）、および "OPTIONAL" は、RFC2119 の記述に従って解釈されるものとします。

（"some-URI" という一般的な形式の)名前空間 URI は、 RFC2396 で定義されている何らかのアプリケーション依存またはコンテキスト依存の URI を表します。

WS-Security は、一般的な SOAP メッセージ構造とメッセージ処理モデルを使って機能するようにデザインされているので、 WS-Security は任意のバージョンの SOAP に適用できます。本仕様では詳しい例を示すために現在の SOAP 1.2 名前空間 URI を使用していますが、本仕様の適用範囲を SOAP の 1 つのバージョンに制限する意図はありません。

このドキュメントは、読者が Internet Security Glossary に収録されている用語についての知識があることを前提にしています。

2.2. 名前空間

本仕様の実装が使用しなければならない (MUST) XML 名前空間 URI は、次の URI です。


https://schemas.xmlsoap.org/ws/2002/04/secext

このドキュメントでは、以下の名前空間を使用しています。

プレフィックス	名前空間
S	http://www.w3.org/2001/12/soap-envelope
ds	http://www.w3.org/2000/09/xmldsig#
xenc	http://www.w3.org/2001/04/xmlenc#
m	https://schemas.xmlsoap.org/rp
wsse	https://schemas.xmlsoap.org/ws/2002/04/secext

2.3. 専門用語

本仕様で使用するセキュリティの専門用語の基本的な定義を提供します。

申告 (Claim) "申告" は、クライアントが行う声明です (例えば、名前、ID、鍵、グループ、特権、権限など)。

セキュリティトークン "セキュリティトークン" は、申告のコレクションを表します。

署名付きセキュリティトークン "署名付きセキュリティトークン" は、特定の機関によってアサート(assert)され、また暗号的に保証されたセキュリティトークンです(例えば、X.509 証明書または Kerberos チケットなど)。

所有の証明（proof-of-possession） "所有の証明" 情報は、セキュリティトークンを申告している送信者だけが知る必要がある(他人に知られてはならない) (SHOULD)情報の送信者の知識を示すための証明プロセスで使用されるデータです。

完全性 "完全性" は、情報が転送中に変更されないことを保証するプロセスです。

秘匿性 "秘匿性" は、認可されたアクタまたはセキュリティトークンの所有者だけがデータを参照できるように、データを保護するプロセスです。

ダイジェスト "ダイジェスト" は、オクテットストリームの暗号的なチェックサムです。

署名 "署名" は、所有の証明とダイジェストとの暗号的なバインディングです。これは、対称鍵ベースの署名と公開鍵ベースの署名の両方をカバーします。その結果、否認不可性が常に満たされるわけではありません。

添付データ "添付データ" は、 SOAP メッセージと共に移動する付加データを表す一般的な用語ですが、 SOAP エンベロープの一部ではありません。

3. 保護品質

SOAP メッセージを保護するために、次の 2 種類の脅威を考慮する必要があります： 1) メッセージが悪意のある人よって変更または読み取られる可能性があります。 2) 悪意のある人間が、整形式であっても、処理を保証するための適切なセキュリティの申告が不足しているメッセージをサービスに対して送信できる可能性があります。

これらの脅威を理解するために、メッセージセキュリティモデルを定義します。

3.1. メッセージセキュリティモデル

本ドキュメントでは、セキュリティトークン (鍵) の所有の証明として、デジタル署名と組み合わせたセキュリティトークンの点から、抽象的な"メッセージセキュリティモデル"を示します。

セキュリティトークンが申告アサートし、署名が送信者の鍵の知識を証明するためのメカニズムを提供します。また、署名とセキュリティトークン (トークンが信頼されていると仮定して) 内の申告とを "バインドする" または "関連付ける" ために署名を使用できます。このようなバインディングは署名がカバーする要素に限定されることに注意してください。さらに、このドキュメントは認証のための特定の手法を示していないことに注意してください。仕様では、セキュリティトークンをメッセージにバインドしてもよい (MAY) ことを示しているだけです。

申告は、信頼される機関によって保証されているかされていないかのいずれかになります。保証された申告のセットは通常、機関によってデジタル署名または暗号化が行われる署名付きセキュリティトークンとして表されます。 ID と公開鍵とのバインディングを申告する X.509 証明書は、署名付きセキュリティトークンの例です。保証された申告を、ある機関への参照として表すこともできます。この結果、受信者が参照されている機関から申告を "取り出す" ことができます。

保証されていない申告は、送信者と受信者の間に信頼関係がある場合は信頼されます。たとえば、送信者 Bob の保証されていない申告は、送信者と受信者が信頼関係接続を使用していて、送信者と受信者の間に帯域間外の信頼関係があれば、特定の受信者にとっては送信者が本当に Bob であるということを十分確信できます。

保証されていない申告の 1 つの特別な種類が、所有の証明です。このような申告は、送信者が適切なアクタによって申告可能な特定部分の知識を持っていることを証明します。たとえば、ユーザー名とパスワードは、この種の申告を持つセキュリティトークンです。所有の証明の申告が、別のセキュリティトークンと組み合わされ、送信者の申告を証明する場合もあります。メッセージの完全性に使用されるデジタル署名は所有の証明の申告としても使用できますが、本仕様では、このようなデジタル署名をセキュリティトークンの一種とは考えていません。

このセキュリティモデルは、それ自体が複数のセキュリティ攻撃を受けやすいということに注意する必要があります。詳細については、「セキュリティの考慮事項」セクションを参照してください。

3.2. メッセージの保護

メッセージコンテンツを盗聴されたり (秘匿性)、不正に変更されたり (完全性) することから保護することが、セキュリティの主要な考慮事項です。本仕様は、本文、ヘッダ、添付データ、またはそれら(またはそれらの一部)の任意の組み合わせを暗号化およびデジタル署名、またはそのいずれかを行うことによって、メッセージを保護する方法を提供します。

メッセージの完全性は、セキュリティトークンと XML 署名を組み合わせて利用して、メッセージが変更されずに転送されることを保証します。完全性メカニズムは、複数のアクタによって行われる可能性のある複数の署名をサポートし、追加の署名形式をサポートするために拡張できるようにデザインされています。

メッセージの秘匿性は、セキュリティトークンと XML 暗号化を組み合わせて利用し、 SOAP メッセージの機密の部分を保持します。暗号化メカニズムは、複数のアクタによる追加の暗号化処理と操作をサポートするようにデザインされています。

3.3. 申告がないか、不適切な申告

メッセージの受信者は、無効な署名を持つメッセージ、申告を持たないメッセージ、または不適切な申告を持つメッセージを、認可されていない (または適切な形式ではない) メッセージとして拒否すべきです (SHOULD)。本仕様は、メッセージの送信者が 0 (ゼロ) 個以上のセキュリティトークンをメッセージに関連付けることによって、セキュリティのプロパティを申告するための柔軟性のある方法を提供します。セキュリティの申告の一例が送信者の ID です。送信者がある企業の従業員とわかっている Bob であり、そのため Bob がメッセージを送信する権限を持っていることを申告できます。

4. Security 要素

<Security> ヘッダーブロックは、特定の受信者 (SOAP アクタ) を対象とするセキュリティ関連の情報を添付するためのメカニズムを提供します。特定の受信者は、メッセージの最終的な受信者または中間ノードのいずれかにしてもよい (MAY)。その結果、このヘッダブロックは SOAP メッセージ内に複数回、現れてもよい(MAY)。メッセージの経路上の中間ノードは、同じ SOAP ノードを対象にしている場合、 1 つ以上の新しいサブ要素を既存の <Security> ヘッダブロックに追加してもよい (MAY)。また、メッセージの経路上の中間ノードは、追加の対象用に 1 つ以上の新たなヘッダを追加してもよい (MAY)。

上記のように、１つのメッセージは別々の受信者を対象にしている場合、複数の <Security> ヘッダーブロックを持ってもよい (MAY)。ただし、1 つの <Security> ヘッダブロックだけが S:actor 属性を省略でき、 2 つの <Security> ヘッダブロックが S:actor に同じ値を持つことはできません。異なる受信者を対象とするメッセージのセキュリティ情報は、異なる <Security> ヘッダブロックで示さなければならない (MUST)。誰もが S:actor が指定されていない <Security> ヘッダブロックを使用することができるが、 WS-Routing によって決定されている最終的な送信先に到達する前に削除してはならない (MUST NOT)。

要素が <Security> ヘッダブロックに追加されるときは、新たな要素は既存の要素の前に追加されます。このため、 <Security> ヘッダブロックは、メッセージの送信者がメッセージの作成に使用した署名と暗号化の手順を表します。この「前に追加する」という規則により、サブ要素間に前方向の依存関係がないので、受信側のアプリケーションが <Security> ヘッダブロックにサブ要素が示される順番にサブ要素を処理してもよい (MAY)。本仕様がサブ要素を処理するために何か特定の順番を強いているわけではないことに注意してください。受信側のアプリケーションは、必要なポリシーは何でも使用できます。

サブ要素が別のサブ要素 (たとえば、署名に使用される X.509 証明書を含むバイナリセキュリティトークンのサブ要素を参照する署名サブ要素) で搬送される鍵を参照するときは、鍵が埋め込まれたセキュリティトークンは、後に追加される、その鍵を使用するサブ要素の前に追加する必要があります (SHOULD)。これは、鍵データが、その鍵を使用するサブ要素の前に示されるようにするためです。

以下に、このヘッダーの構文を示します。

<S:Envelope>
    <S:Header>
            ...
        <Security S:actor="..." S:mustUnderstand="...">
            ...
        </Security>
            ...
    </S:Header>
    ...
</S:Envelope>

以下で、上記の例で示した属性と要素を説明します。

/Security

これは、セキュリティ関連のメッセージ情報を受信者に渡すためのヘッダブロックです。

/Security/@S:actor

この属性を使用して、特定の SOAP アクタを識別できます。この属性は必須ではありません。ただし、ヘッダブロックのインスタンスが2つ以上ある場合、アクタは1つしか省略できず、また同じ値のアクタ属性は指定できません。。

/Security/{any}

これは、異なる (拡張可能な) 種類のセキュリティ情報をスキーマに基づいて渡すことを可能にする拡張性メカニズムです。

/Security/@{any}

これは、付加的な属性をスキーマに基づいてヘッダに追加することを可能にする拡張性メカニズムです。

以下のセクションでは、 <Security> ヘッダ内で使用することが予測される新しい要素と既存の要素を概説します。

4.1. UsernameToken 要素

ユーザ名と省略可能なパスワード情報を証明する方法として、 <UsernameToken> を導入します。

以下に、この要素の構文を例示します。

<UsernameToken Id="...">
    <Username>...</Username>
    <Password Type="...">...</Password>
</UsernameToken>

以下で、上記の例で示した属性と要素を説明します。

/UsernameToken
この要素は、基本認証情報の送信に使用します。
/UsernameToken/@Id
このセキュリティトークンの文字列ラベル。
/UsernameToken/Username
この必須の要素は、認証する団体のユーザー名を指定します。
/UsernameToken/Username/@{any}
これは、付加的な属性をスキーマに基づいてヘッダに追加することを可能にする拡張性メカニズムです。
/UsernameToken/Password
この要素は省略可能で、パスワード情報を提供します。セキュアなトランスポートが使用されているときのみ、この要素を渡すことが推奨されます (RECOMMENDED)。

/UsernameToken/Password/@Type
この属性は省略可能で、提供するパスワードの種類を指定します。以下の表は、定義済みの種類を示しています。

値	説明
wsse:PasswordText (デフォルト)	そのユーザ名の実際のパスワード。
wsse:PasswordDigest	そのユーザ名のパスワードのダイジェスト。値は、UTF8 エンコードされたパスワードのSHA1ハッシュ値を取り、それをbase64 エンコードしたものです。

/UsernameToken/Password/@{any}
これは、付加的な属性をスキーマに基づいてヘッダに追加することを可能にする拡張性メカニズムです。
/UsernameToken/{any}
これは、異なる (拡張可能な) 種類のセキュリティ情報をスキーマに基づいて渡すことを可能にする拡張性メカニズムです。
/UsernameToken/@{any}
これは、付加的な属性をスキーマに基づいてヘッダに追加することを可能にする拡張性メカニズムです。

以下に、この要素の使用例を示します。

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext">
    <S:Header>
            ...
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>Zoe</wsse:Username>
                <wsse:Password>ILoveDogs</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
            ...
    </S:Header>
    ...
</S:Envelope>

4.2. バイナリセキュリティトークンのエンコード

任意の XML ベースのセキュリティトークンを、 <Security> ヘッダーに指定できます。ただし、バイナリ (X.509 証明書や Kerberos チケットなど) またはその他の XML 以外の形式は、それを包含するための特別なエンコード形式を必要とします。

バイナリセキュリティトークンには、その解釈に使用される 2 つの属性があります。 ValueType 属性は、セキュリティトークンが何であるかを示します。たとえば、Kerberos チケットです。 EncodingType は、セキュリティトークンをエンコードする方法を指示します。たとえば、Base64Binary です。

BinarySecurityToken 要素は、バイナリエンコードするセキュリティトークンを定義します。エンコードは EncodingType 属性を使用して指定され、値の種類や空間は ValueType 属性を使用して指定されます。

以下は、構文の概要です。

   <BinarySecurityToken Id=... 
                        EncodingType=... 
                        ValueType=.../>

以下で、上記の例で示した属性と要素を説明します。

/BinarySecurityToken
この要素は、バイナリエンコードされるセキュリティトークンを含めるために使用します。
/BinarySecurityToken/@Id
このセキュリティトークンの省略可能な文字列ラベル。
/BinarySecurityToken/@ValueType
ValueType 属性は、エンコードされるバイナリデータ (X.509 証明書など) の "値空間" を示すために使用します。 ValueType 属性は、エンコードされるバイナリデータの値の種類と空間を定義する修飾名を許可します。この属性は、XML 名前空間を使用して拡張できます。
/BinarySecurityToken/@EncodingType
EncodingType 属性は、 QName を使用して、バイナリデータのエンコード形式 (wsse:Base64Binary など) を示すために使用します。 XML スキーマ内では単純な型と複雑な型が混在する派生を行うのが扱いにくい、という現行の問題があるので、この新しい属性を導入します。 EncodingType 属性は、要素のエンコード形式を示すために解釈されます。以下は定義済みのエンコード形式です。

QName 説明

wsse:Base64Binary XML スキーマ Base 64 エンコード

wsse:HexBinary XML スキーマ 16 進エンコード
/BinarySecurityToken/@{any}
これは、付加的な属性をスキーマに基づいて追加することを可能にする拡張性メカニズムです。

QName	説明
wsse:Base64Binary	XML スキーマ Base 64 エンコード
wsse:HexBinary	XML スキーマ 16 進エンコード

以下の値空間が、@ValueType 用に定義されています。

QName	説明
wsse:X509v3	X.509 v3 証明書
wsse:Kerberosv5TGT	Kerberos のセクション 5.3.1 で定義されている Kerberos v5 チケット。この `ValueType` は、チケットがチケットを許可するチケット (TGT) である場合に使用されます。
wsse:Kerberosv5ST	Kerberos のセクション 5.3.1 で定義されている Kerberos v5 チケット。この `ValueType` は、チケットがサービスチケット (ST) である場合に使用されます。

XML 署名が X.509 証明書をエンコードするためのメカニズムを提供していることにも注意してください。 ValueType="wsse:X509v3" を持つ BinarySecurityToken は、は、エンコードの目的として柔軟性が必要な場合に使用してもよい (MAY)。それに対して、 ds:KeyInfo を使用することにより、使用するシナリオの中に付加的な柔軟性を提供することがあります。

以下の例は、BinarySecurityToken: の使用例を示しています。

         <wsse:BinarySecurityToken
             xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
             Id="myToken"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgAwIBAgIQEmtJZc0...
          </wsse:BinarySecurityToken>

<BinarySecurityToken> を署名に使用する場合、つまりそれが <ds:Signature> 要素から参照される場合、正規化アルゴリズム (例、Exclusive XML Canonicalization) が属性または要素の値で使用される QName の名前空間プレフィックスの認可できない置き換えを許可しないように注意する必要があります。特に、このトークンが署名する鍵を搬送しない場合 (かつ、その結果署名に暗号的にバインドされない場合)、これらの名前空間プレフィックスを <BinarySecurityToken> 要素内で宣言することが推奨されます (RECOMMENDED)。たとえば、上記の例に署名を行いたい場合、使用される名前空間定義を含める必要があります。以下の例では、カスタム ValueType を使用しています。その結果、この ValueType の名前空間の定義が <BinarySecurityToken> 要素に含められます。 wsse の定義も、エンコードの種類と要素に使用されるので、含められることにも注意してください。

         <wsse:BinarySecurityToken 
             xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
             Id="myToken"
             ValueType="x:MyType" xmlns:x="http://fabrikam123.com/x"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgAwIBAgIQEmtJZc0...
          </wsse:BinarySecurityToken>

Kerberos チケットが署名鍵として参照されるときは、署名アルゴリズムはハッシュされたメッセージ認証コードにする必要があります (SHOULD)。特に、、チケット内のセッション鍵を共有秘密鍵として用いて、HMAC-SHA1 (XML 署名によって必要とされる) を使用することが推奨されます (RECOMMENDED)。

4.3. SecurityTokenReference 要素

セキュリティトークンは、申告のセットを搬送します。場合によっては、これらの申告がどこか別の場所に存在し、受信側のアプリケーションにより、「取り出される」必要があります。 <SecurityTokenReference> 要素は、セキュリティトークンを参照するための拡張可能なメカニズムを提供します。

以下に、この要素の構文を例示します。

<SecurityTokenReference Id="...">
    <Reference URI="..."/>
</SecurityTokenReference>

以下で、上記で定義された要素を説明します。

/SecurityTokenReference
この要素は、セキュリティトークンへの参照を提供します。
/SecurityTokenReference/@Id
このセキュリティトークンの参照の文字列ラベル。
/SecurityTokenReference/Reference
この要素は、セキュリティトークンを探すための URI の場所の識別に使用します。
/SecurityTokenReference/Reference/@URI
この属性は、セキュリティトークンを探す場所の URI を指定します。
/SecurityTokenReference/{any}
これは、異なる (拡張可能な) 種類のセキュリティ情報をスキーマに基づいて渡すことを可能にする拡張性メカニズムです。
/SecurityTokenReference/@{any}
これは、付加的な属性をスキーマに基づいてヘッダに追加することを可能にする拡張性メカニズムです。

以下に、この要素の使用例を示します。

<wsse:SecurityTokenReference               
          xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext"> 
   <wsse:Reference 
             URI="http://www.fabrikam123.com/tokens/Zoe#X509token"/>
</wsse:SecurityTokenReference>

また、この要素はどこか別の場所に格納されているセキュリティトークンから鍵情報を取得するためのヒントを示すために、 <ds:KeyInfo> の直接の子要素としても使用できます。特に、XML 署名と XML 暗号化を使用しているときに、署名や暗号化に使用されるセキュリティトークンを参照するために、 <SecurityTokenReference> 要素を <ds:KeyInfo> の内部に配置することが推奨されます (RECOMMEND)。

4.4. ds:KeyInfo

X.509 証明書などの特定の種類のキーの場合、 (XML 署名からの) <ds:KeyInfo> 要素と <BinarySecurityToken> 要素の両方を鍵情報の搬送に使用できます。 <ds:KeyInfo> 要素は、異なる種類の鍵と将来の拡張性を可能にしています。ただし、鍵の種類がセクション 4.2 で適切に定義されている場合、本仕様では、鍵データの搬送方法として <BinarySecurityToken> を使用することが推奨されます (RECOMMENDED)。

以下の例は、名前付き鍵を取り出すためにこの要素を使用する方法を例示しています。

<ds:KeyInfo Id="..." xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
</ds:KeyInfo>

4.5. ds:Signature

メッセージの送信者は、メッセージの受信者に転送時にメッセージが変更されたかどうかを判定させたい可能性があり、これを検証するためにメッセージは特定のセキュリティトークンのプロセッサによって送信されます。

XML 署名と <SecurityTokenReference> 要素とを組み合わせて使用する場合、メッセージ署名者のセキュリティトークンが相互に関連付けられ、セキュリティトークンの申告とメッセージ間のマッピングがアプリケーションにより評価されることがあります。

一部の SOAP ヘッダの可変性により、送信者は XML 署名で定義されている Enveloped Signature Transform を使用しないほうがよい (SHOULD NOT)。代わりに、メッセージには署名する必要がある要素を明示的に含める必要があります (SHOULD)。同様に、送信者は XML 署名で定義されている Enveloping Signature を使用しないほうがよい (SHOULD NOT)。

本仕様では、1 つのメッセージに、メッセージの異なる部分、ときには重なり合う部分に関連付けられる複数の署名を添付することが許可されています。このことは、メッセージが複数の処理段階を経て流れる多くの分散型アプリケーションでは重要になります。たとえば、送信者が orderID ヘッダを含む注文を送信したとします。送信者は、リクエストの orderID ヘッダと本文 (注文内容) に署名を行います。このメッセージを受注処理サブシステムが受信したときに、ヘッダに shippingID を挿入できます。その後、注文サブシステムは、少なくとも orderID と shippingID に、またおそらく本文にも署名を行います。この注文は配送部門で処理され、配送時に、shippedInfo ヘッダが付加されます。配送部門は、少なくとも shippedInfo と shippingID に、またおそらく本文にも署名を行い、メッセージを処理のために請求部門に転送します。請求部門は署名を検証し、その注文の有効な信頼のチェーンと、誰がどのような処理を行ったかを決定できます。

仕様に準拠するすべての実装は、 <ds:Signature> 要素を処理できなければならない (MUST)。

4.5.1. アルゴリズム

WS-Security の仕様は、 XML 署名上に構築されており、そのために XML 署名の仕様で指定されているのと同等のアルゴリズムに対する要件を有しています。

以下の表は、WS-Security が推奨 (RECOMMENDS) している追加のアルゴリズムを概説しています。

アルゴリズムの種類	アルゴリズム	アルゴリズムの URI
Canonicalization	Exclusive XML Canonicalization	http://www.w3.org/2001/10/xml-exc-c14n#
Transformations	XML Decryption Transformation	http://www.w3.org/2001/04/decrypt#

Exclusive XML Canonicalization アルゴリズムは、すでに存在する署名とリンクした "不備な" 名前空間から生じる、一般的な正規化の危険性に対処しています。

最後に、暗号化する前にメッセージに署名したいと考える送信者は、 Decryption Transformation for XML Signature を使用する必要があります。

4.5.2. メッセージの署名

<Security> ヘッダブロックは、 SOAP エンベロープ内の 1 つ以上の要素に署名する目的で、 SOAP エンベロープ内の XML 署名仕様に準拠する署名を搬送するために使用されます。 <Security> ヘッダブロック内の 1 つの SOAP エンベロープに、複数の署名エントリを追加してもよい (MAY)。送信者は、メッセージのすべての重要な要素に署名を行う必要がありますが、伝送中に正当な変更がされる可能性のあるメッセージ部分に署名を行わない、というポリシーを作成するときは、注意を払う必要があります。

SOAP アプリケーションは、以下の条件を満たさなければならない (MUST)。

アプリケーションは、 XML 署名仕様で定義されている必要な要素を処理できなければならない (MUST)。
<Security> ヘッダブロックに署名を追加するには、 XML 署名仕様に従って、 <ds:Signature> 要素が <Security> ヘッダブロックの既存のコンテンツの前に追加される必要があります (SHOULD)。つまり、新しい情報が古い情報の前に (追加され) 存在することになります。署名に含まれるすべての <ds:Reference> 要素は、それを囲む SOAP エンベロープ内、または添付データ内でリソースを参照する必要があります (SHOULD)。

XML 署名仕様に記述されているように、 XPath フィルタリングを使用して、署名対象のオブジェクトを指定できます。ただし、SOAP メッセージ交換モデルでは仲介アプリケーションによるエンベロープの変更 (ヘッダーブロックの追加や削除など) が許可されているので、 XPath フィルタリングはメッセージの配信後に、必ずしも同じオブジェクトを生成しません。 XPath フィルタリングを使用するときには、このような変更によりその後の検証が失敗しないように注意する必要があります。

中間ノードによる変更の問題は、XPath 処理だけにとどまりません。デジタル署名は、正規化とダイジェストによって、この種の関係の特に脆弱な例になっています。全体的なメッセージ処理の堅牢性を損なわないために、中間ノードは、それらのトランスフォーメーションがデジタル署名されたコンポーネントのスコープ内で変更を行わないよう注意しなければならない。

名前空間に伴うセキュリティ上の配慮により、本仕様は "Exclusive XML Canonicalization" アルゴリズムか、これと同等以上の保護を提供するその他の正規化アルゴリズムを使用することを強く推奨しています (RECOMMENDS)。

4.5.3. 完全性の検証

<Security> ヘッダーブロック内の <ds:Signature> エントリの検証は、以下のいずれかの場合に失敗します。

エントリのコンテンツの構文が本仕様に従っていない場合、あるいは、
XML 署名仕様の中核となる検証（core validation）に従って、エントリに含まれる署名の検証が失敗する場合、あるいは、
独自の信頼ポリシーを適用しているアプリケーションが、何らかの理由でメッセージを拒否する場合 (たとえば、署名が信頼されていない鍵によって作成されます。つまり、上の 2 つの手順の検証は、署名の暗号的な検証を実行するだけです)。

アプリケーションは、署名エントリの検証が失敗した場合、セクション 6 で定義されているフォールトコード（fault code）を使用して、その失敗を送信者に報告してもよい (MAY)。

4.5.4. 例

以下のサンプルメッセージは、完全性とセキュリティトークンの使用例を示しています。この例には、メッセージ本文と一緒に不変のルーティングヘッダを選択する架空の "RoutingTransform" を使用しています。

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
            xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
   <S:Header>
      <m:path xmlns:m="https://schemas.xmlsoap.org/rp">
         <m:action>http://fabrikam123.com/getQuote</m:action>
         <m:to>http://fabrikam123.com/stocks</m:to>
         <m:from>mailto:johnsmith@fabrikam123.com</m:from>
         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
      </m:path>
      <wsse:Security> 
         <wsse:BinarySecurityToken 
                     ValueType="wsse:X509v3"
                     EncodingType="wsse:Base64Binary"  
                     Id="X509Token">
                  MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
         </wsse:BinarySecurityToken>
         <ds:Signature>
            <ds:SignedInfo>
               <ds:CanonicalizationMethod Algorithm=
                     "http://www.w3.org/2001/10/xml-exc-c14n#"/>
               <ds:SignatureMethod Algorithm=
                     "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
               <ds:Reference>
                  <ds:Transforms>
                     <ds:Transform Algorithm=
                           "http://...#RoutingTransform"/>
                     <ds:Transform Algorithm=
                           "http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </ds:Transforms>
                  <ds:DigestMethod Algorithm=
                       "http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <ds:DigestValue>EULddytSo1...</ds:DigestValue>
               </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
              BL8jdfToEb1l/vXcMZNNjPOV...
            </ds:SignatureValue>
            <ds:KeyInfo>
                <wsse:SecurityTokenReference>
                    <wsse:Reference URI="#X509Token"/>
                </wsse:SecurityTokenReference>
            </ds:KeyInfo>
         </ds:Signature>
      </wsse:Security>
   </S:Header>
   <S:Body>
      <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">
        QQQ
      </tru:StockSymbol>
   </S:Body>
</S:Envelope>

4.6. Encryption サブ要素

本仕様は、送信者と受信者によって共有される共通の対称鍵、または暗号化された形式でメッセージ内で搬送される鍵のいずれかによる、本文ブロック、ヘッダブロック、それらの任意のサブ構造、および添付データの任意の組み合わせの暗号化を許可します。

この柔軟性を可能にするために、 XML 暗号化標準を利用します。特に、(以下に示され、 XML 暗号化で定義されている) 3 つの要素を <Security> ヘッダブロック内で使用する方法について説明します。送信者または中間ノードは、 XML 暗号化を使用して SOAP メッセージを部分的に暗号化するときに、サブ要素を <Security> ヘッダーブロックに追加するでしょう。さらに、暗号化する団体は暗号化された部分の暗号化を解除することを期待する対象の受信者向けに、 <Security> ヘッダブロックにサブ要素を前に追加しなければならない (MUST)。メッセージの部分を暗号化する処理と、暗号化された部分を参照するそれらのサブ要素のいずれかを追加する処理を組み合わせた処理は、これ以降 "暗号化手順" と呼ばれます。サブ要素は、メッセージのどの部分が受信者によって復号化されるべきなのかを識別するために、十分な情報を保持する必要があります。

4.6.1. xenc:ReferenceList

SOAP エンベロープ内の要素または要素のコンテンツを暗号化する際には、エンベロープ内で <xenc:EncryptedData> 要素として表される、暗号化された部分のマニフェストの作成のために、 XML 暗号化からの <xenc:ReferenceList> 要素が使用されてもよい(MAY)。この暗号化手順によって暗号化される要素または要素のコンテンツは、 XML 暗号化に従い、対応する <xenc:EncryptedData> によって置き換えられなければならない (MUST)。この暗号化手順によって作成されたすべての <xenc:EncryptedData> 要素は、 <xenc:ReferenceList> 要素内部の <xenc:DataReference> 要素に一覧されるべきです (SHOULD)。

XML 暗号化では、 <xenc:ReferenceList> は本来 <xenc:EncryptedKey> 要素内で使用するようにデザインされています (これは、参照されるすべての <xenc:EncryptedData> 要素が同一の鍵で暗号化されることを意味します) が、本仕様では同一の <xenc:ReferenceList> によって参照される <xenc:EncryptedData> 要素が異なる鍵で暗号化されていてもよい (MAY) 。各暗号鍵は、個々の <xenc:EncryptedData> 内の <ds:KeyInfo> で指定できます。

<xenc:ReferenceList> サブ要素が役に立つ典型的な状況は、送信者と受信者が共有の秘密鍵を使用することです。以下に、このサブ要素の使用例を示します。

<S:Envelope
   xmlns:S="http://www.w3.org/2001/12/soap-envelope"    
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
   xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <S:Header>
        <wsse:Security>
            <xenc:ReferenceList>
                <xenc:DataReference URI="#bodyID"/>
            </xenc:ReferenceList>
        </wsse:Security>
    </S:Header>
    <S:Body>
        <xenc:EncryptedData Id="bodyID"> 
          <ds:KeyInfo>
            <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
          </ds:KeyInfo>
          <xenc:CipherData>
            <xenc:CipherValue>...</xenc:CipherValue>
          </xenc:CipherData>
        </xenc:EncryptedData>
    </S:Body>
</S:Envelope>

4.6.2. xenc:EncryptedKey

暗号化手順が、ある鍵で SOAP エンベロープ内の要素または要素のコンテンツの暗号化を行い、その鍵が受信者の鍵によってさらに暗号化され、メッセージに埋め込まれる場合は、 <xenc:EncryptedKey> がその暗号化された鍵などを搬送するために使用されてもよい (MAY)。この鍵 (存在する場合) を使って復号化される部分を受信者が識別するために、このサブ要素は、マニフェスト、つまり <xenc:ReferenceList> 要素を持つ必要があります (SHOULD)。この暗号化手順によって暗号化される要素または要素のコンテンツは、 XML 暗号化に従い、対応する <xenc:EncryptedData> によって置き換えられなければならない (MUST)。この暗号化手順によって作成されるすべての <xenc:EncryptedData> 要素は、このサブ要素の内部の <xenc:ReferenceList> 要素に一覧される必要があります (SHOULD)。

この構成は、受信者の公開鍵によって順次暗号化される、ランダム生成される対称鍵によって暗号化が行われるときに役立ちます。以下に、この要素の使用例を示します。

<S:Envelope
   xmlns:S="http://www.w3.org/2001/12/soap-envelope"    
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
   xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <S:Header>
        <wsse:Security>
            <xenc:EncryptedKey>
               <xenc:EncryptionMethod Algorithm="..."/>
               <ds:KeyInfo>
                   <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
               </ds:KeyInfo>
               <xenc:CipherData>
                   <xenc:CipherValue>...</xenc:CipherValue>
               </xenc:CipherData>
               <xenc:ReferenceList>
                  <xenc:DataReference URI="#bodyID"/>
               </xenc:ReferenceList>
            </xenc:EncryptedKey>
        </wsse:Security>
    </S:Header>
    <S:Body>
        <xenc:EncryptedData Id="bodyID"> 
            <ds:KeyInfo>
              <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
            </ds:KeyInfo>
            <xenc:CipherData>
              <xenc:CipherValue>...</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </S:Body>
</S:Envelope>

4.6.3. xenc:EncryptedData

場合によっては、セキュリティ関連の情報が純粋に暗号化された形式で提供されるか、 XML 以外の添付データが暗号化されてもよい (MAY)。 XML 暗号化からの <xenc:EncryptedData> 要素は、このようなシナリオに使用できます。暗号化される添付データの部分ごとに、1 つの暗号化手順が必要になります。つまり、各添付データが暗号化されるには、 1 つの <xenc:EncryptedData> サブ要素が以下の規則に従って追加されなければならない (MUST) (手順 2 から 4 までは MIME タイプが添付データに使用されている場合のみに当てはまることに注意してください)。

添付データのコンテンツは、暗号化されたオクテット列によって置き換えられなければならない (MUST)。
置き換えられる MIME 部分は、メディア形式 application/octet-stream を持たなければならない (MUST)。
添付データの元のメディア形式は、 <xenc:EncryptedData> 要素の MimeType 属性で宣言しなければならない (MUST)。
暗号化される MIME 部分は、 <xenc:CipherReference> 要素によって、 URI のスキームコンポーネントとして cid: を含む MIME 部分を指す URI を使って参照しなければならない (MUST)。

以下に、この要素の使用法を例示し、暗号化された添付データを示します。

<S:Envelope
   xmlns:S="http://www.w3.org/2001/12/soap-envelope"    
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
   xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <S:Header>
        <wsse:Security>
            <xenc:EncryptedData MimeType="image/png">
               <xenc:EncryptionMethod Algorithm="foo:bar"/>
               <ds:KeyInfo>
                 <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
               </ds:KeyInfo>
               <xenc:CipherData>
                   <xenc:CipherReference URI="cid:image"/>
               </xenc:CipherData>
            </xenc:EncryptedData>
        </wsse:Security>
    </S:Header>
    <S:Body> </S:Body>
</S:Envelope>

4.6.4. 処理規則

上記で定義されたサブ要素のいずれかを使用した SOAP メッセージの暗号化された部分または添付データは、 XML 暗号化仕様に従わなければならない (MUST)。暗号化された SOAP エンベロープは、依然として有効な SOAP エンベロープでなければならない (MUST)。メッセージの作成者は、<S:Envelope>、 <S:Header>、または <S:Body> 要素を暗号化してはいけません (MUST NOT) が、 <S:Header> と <S:Body> 要素の子要素は暗号化してもよい (MAY)。複数の暗号化手順は、それらが同一の受信者を対象にしている場合、 1 つの <Security> ヘッダブロックに追加してもよい (MAY)。

SOAP エンベロープ内の要素または要素のコンテンツ (たとえば、<S:Body> のコンテンツ) を暗号化する必要があるときは、 XML 暗号化に従って <xenc:EncryptedData> によって置き換えられなければならない (MUST)、そして、この暗号化手順によって作成される <xenc:ReferenceList> 要素から参照される必要があります (SHOULD)。本仕様は、添付データに暗号化されたオクテットストリームを格納することを許可しています。たとえば、<S:Body> 要素の内部に現れる <xenc:EncryptedData> が、添付ファイルを参照する <xenc:CipherReference> を持っている場合、暗号化を解除されたオクテットストリームは <xenc:EncryptedData> を置き換えます。ただし、<enc:EncryptedData> 要素が <Security> ヘッダーブロックに格納されていて、それが添付ファイルを参照する場合、復号化されたオクテットストリームは添付データ内の暗号化されたオクテットストリームを置き換えなければならない (MUST)。

暗号化

本仕様に従って暗号化される SOAP メッセージを作成するための一般的な手順 (標準ではない) を以下に示します (<xenc:ReferenceList> を使用することを推奨している (RECOMMENDED) ことに注意してください)。

新しい SOAP エンベロープを作成します。
暗号化の種類によって異なりますが、 <xenc:ReferenceList> サブ要素、 <xenc:EncryptedKey> サブ要素、または <xenc:EncryptedData> サブ要素を <Security> ヘッダーブロックに作成します (SOAP "アクタ" と "mustUnderstand" 属性が異なる場合は、新しいヘッダーブロックが必要になる場合があることに注意してください)。
暗号化するデータ項目、すなわち、対象の SOAP エンベロープ内のXML要素、XML要素のコンテンツ、および、添付データを見つけます。
次のようにデータ項目を暗号化します。各対象の SOAP エンベロープ内の XML 要素または要素のコンテンツごとに、XML 暗号化仕様の処理規則に従って暗号化します。それぞれ選択された元の要素または要素のコンテンツは削除され、暗号化された結果の <xenc:EncryptedData> 要素によって置き換えられなければならない (MUST)。添付データについては、セクション 4.6.3 で説明したように、そのコンテンツが暗号化された暗号データによって置き換えられなければならない (MUST)。
<xenc:EncryptedData> 要素内の省略可能な <ds:KeyInfo> 要素は、別の <ds:KeyInfo> 要素を参照してもよい (MAY)。暗号化が添付されたセキュリティトークンに基づいている場合は、それを容易に見つけ出せるようにするために、 <SecurityTokenReference> 要素が <ds:KeyInfo> 要素に追加される必要がある(SHOULD) ことに注意してください。
生成された <xenc:EncryptedData> 要素を参照する <xenc:DataReference> 要素を作成します。作成した <xenc:DataReference> 要素を <xenc:ReferenceList> に追加します。

復号化

暗号化ヘッダーエントリを含む SOAP エンベロープを受け取ったときに、暗号化ヘッダエントリごとに、以下の一般的な手順が処理される必要があります (標準ではありません)。

(おそらく、<xenc:ReferenceList> を使用して) 復号化するべき <xenc:EncryptedData> 項目を見つけます。
次のようにそれらを復号化します。対象の SOAP エンベロープ内の要素ごとに、XML 暗号化仕様の処理規則と上記に示した処理規則に従って、復号化します。
復号化されたデータが添付データの一部で、 MIME タイプが使用されている場合、添付データの MIME タイプを元の MIME タイプに変更します (存在する場合)。

復号化が何らかの理由で失敗した場合、アプリケーションはセクション 6 で定義しているフォールトコードを使用して、失敗を送信者に報告してもよい (MAY)。

5. 拡張例

以下のサンプルメッセージは、セキュリティトークン、署名、および暗号化の使用例を示しています。この例では、メッセージ本文と一緒に不変のルーティングヘッダを選択する架空の "RoutingTransform" を使用しています。

(001) <?xml version="1.0" encoding="utf-8"?>
(002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
            xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext" 
            xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
(003)   <S:Header>
(004)      <m:path xmlns:m="https://schemas.xmlsoap.org/rp/">
(005)         <m:action>http://fabrikam123.com/getQuote</m:action>
(006)         <m:to>http://fabrikam123.com/stocks</m:to>
(007)         <m:from>mailto:johnsmith@fabrikam123.com</m:from>
(008)         <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
(009)      </m:path>
(010)      <wsse:Security>
(011)         <wsse:BinarySecurityToken 
                     ValueType="wsse:X509v3"
                     Id="X509Token"  
                     EncodingType="wsse:Base64Binary">
(012)         MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
(013)         </wsse:BinarySecurityToken>
(014)         <xenc:EncryptedKey>
(015)             <xenc:EncryptionMethod Algorithm=
                        "http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
(016)             <ds:KeyInfo>
(017)               <ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName>
(018)             </ds:KeyInfo>
(019)             <xenc:CipherData>
(020)                <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(021)                </xenc:CipherValue>
(022)             </xenc:CipherData>
(023)             <xenc:ReferenceList>
(024)                 <xenc:DataReference URI="#enc1"/>
(025)             </xenc:ReferenceList>
(026)         </xenc:EncryptedKey>
(027)         <ds:Signature>
(028)            <ds:SignedInfo>
(029)               <ds:CanonicalizationMethod
                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(030)               <ds:SignatureMethod 
               Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(031)               <ds:Reference>
(032)                  <ds:Transforms>
(033)                     <ds:Transform 
                             Algorithm="http://...#RoutingTransform"/>
(034)                     <ds:Transform 
                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(035)                  </ds:Transforms>
(036)                  <ds:DigestMethod 
                   Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(037)                  <ds:DigestValue>LyLsF094hPi4wPU...
(038)                   </ds:DigestValue>
(039)               </ds:Reference>
(040)            </ds:SignedInfo>
(041)            <ds:SignatureValue>
(042)                     Hp1ZkmFZ/2kQLXDJbchm5gK...
(043)            </ds:SignatureValue>
(044)            <ds:KeyInfo>
(045)                <wsse:SecurityTokenReference>
(046)                    <wsse:Reference URI="#X509Token"/>
(047)                </wsse:SecurityTokenReference>
(048)            </ds:KeyInfo>
(049)         </ds:Signature>
(050)      </wsse:Security>
(051)   </S:Header>
(052)   <S:Body>
(053)      <xenc:EncryptedData 
                  Type="http://www.w3.org/2001/04/xmlenc#Element"
                  Id="enc1">
(054)         <xenc:EncryptionMethod         
              Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/>
(055)         <xenc:CipherData>
(056)            <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...
(057)            </xenc:CipherValue>
(058)         </xenc:CipherData>
(059)      </xenc:EncryptedData>
(060)   </S:Body>
(061) </S:Envelope>

この例の主なセクションの一部を調べてみましょう。

行 (003) から (051) までは、SOAP メッセージヘッダを保持しています。

行 (004) から (009) までは、 (WS-Routing で定義されている) メッセージルーティング情報を指定しています。この場合は "getQuote" 操作を要求して、メッセージを http://fabrikam123.com/stocks サービスに送信しています。

行 (010) から (050) までは、 <Security> ヘッダブロックを表しています。これは、このメッセージに関するセキュリティ関連の情報を保持しています。

行 (011) から (013) までは、メッセージに関連付けられているセキュリティトークンを指定しています。この場合は、 Base64 でエンコードされる X.509 証明書を指定しています。行 (012) は、証明書の実際の Base64 エンコードを指定しています。

行 (014) から (026) までは、メッセージ本文の暗号化に使用する鍵を指定しています。これは対称鍵なので、暗号化された形式で渡されます。行 (015) は、鍵の暗号化に使用するアルゴリズムを定義しています。行 (016) から (018) までは、対称鍵の暗号化に使用された鍵の名前を指定しています。行 (019) から (022) までは、対称鍵の実際の暗号化された形式を指定しています。行 (023) から (025) までは、この対称鍵を使用するメッセージ内の暗号化ブロックを識別しています。この場合、それは本文の暗号化のみに使用します (Id="enc1")。

行 (027) から (049) までは、デジタル署名を指定しています。この例では、署名は X.509 証明書に基づいています。行 (028) から (040) までは、署名されている部分を示しています。特に行 (029) は、正規化アルゴリズムを (この例では排他的) 示しています。行 (030) は、署名アルゴリズム (この場合は、sha1 上の rsa) を示しています。

行 (031) から (039) までは、メッセージの署名されている部分を識別します。特に行 (033) は、 "Transform" を識別します。この架空の変換は、ルーティングヘッダとメッセージ本文の不変の部分を選択します。行 (034) は、正規化アルゴリズムを指定して、行 (033) から選択したメッセージ部分で使用します。行 (036) は、正規化データに対するダイジェストアルゴリズムの使用を示しています。行 (037) は、正規化データに対する指定したアルゴリズムから生じるダイジェスト値を指定しています。

行 (041) から (043) までは、行 (042) で指定した実際の署名値を示しています。

行 (044) から (048) までは、署名に使用された鍵を示しています。この場合は、メッセージに含まれる X.509 証明書です。行 (046) は、行 (011) から (013) までへの URI リンクを提供しています。

メッセージ本文は、行 (052) から (060) までで表されています。

行 (053) から (059) までは、 XML 暗号化を使用している本文の暗号化されるメタデータと形式を表しています。行 (053) は、"要素値" が置き換えられ、この暗号化を識別することを示しています。行 (054) は、暗号化アルゴリズム、この場合は Triple-DES を指定しています。行 (055) から (058) までは、実際の暗号テキスト (暗号化の結果など) を含んでいます。行 (024) については、鍵がこの暗号化を参照するので、鍵への参照を含まないことに注意してください。

6. エラー処理

セキュリティ情報を処理中に "エラー" が発生する状況は数多くあります。その例を以下に示します。

無効な、またはサポートされていない種類のセキュリティトークン、署名、または暗号化
無効な、または認証されていないか、認証できないセキュリティトークン
無効な署名
復号化エラー
参照されているセキュリティトークンが見つからない

これらは、サポートされていないエラーと処理の失敗を示すエラーの 2 種類に分類できます。サポートされていないエラーの場合は、受信者がサポートされている形式などを送信者に伝える応答を提供してもよい (MAY)。失敗を示すエラーの場合は、これがサービス拒否 (DOS) 攻撃または暗号化攻撃の形式である可能性があるので、受信者は応答しないことも選択してもよい (MAY)。署名と暗号化の失敗を組み合わせて、特定の種類の攻撃を軽減します。

失敗を送信者に返す場合、その失敗を SOAP のフォールトメカニズムを使用して報告しなければならない (MUST)。以下の表は、定義済みのセキュリティフォールトコードを概説しています。 "サポートされない" クラスのエラーは次のとおりです。

発生したエラー	フォールトコード
サポートされないトークンが指定されました	wsse:UnsupportedSecurityToken
サポートされない署名または暗号化アルゴリズムが使用されました	wsse:UnsupportedAlgorithm

"失敗を示す" クラスのエラーは次のとおりです。

発生したエラー	フォールトコード
`<Security>` ヘッダの処理中にエラーが見つかりました	wsse:InvalidSecurity
無効なセキュリティトークンが指定されました	wsse:InvalidSecurityToken
セキュリティトークンを認証または認可できませんでした	wsse:FailedAuthentication
署名または復号化が無効です	wsse:FailedCheck
参照しているセキュリティトークンを取得できませんでした	wsse:SecurityTokenUnavailable

7. セキュリティの考慮事項

メッセージがオープンネットワークを経由して交換されるときに、メッセージの受信者がメッセージの再送を検出できるようにするために、メッセージデジタル署名された要素を含めることが強く推奨されます (RECOMMENDED)。これは、他の SOAP 拡張で定義されたメッセージまたはヘッダの一部であってもかまいません。代表的なアプローチとして、以下の 4 つがあります。

タイムスタンプ
シーケンス番号
有効期限
メッセージの相関関係

この仕様は、 SOAP ヘッダー内での XML 署名と XML 暗号化の使用方法を定義しています。 SOAP メッセージの安全性を確保するための基本要素の 1 つとして、この仕様を他のセキュリティ技法と組み合わせて使用することを意図しています。デジタル署名は、他のセキュリティメカニズムのコンテキストや、エンティティへの考えられる脅威について理解される必要があります。

デジタル署名は、単独でメッセージの認証を行うことはできません。他人が署名付きのメッセージを記録し、それを再送できます (リプレイ攻撃)。この種の攻撃を防ぐには、デジタル署名を、タイムスタンプやシーケンス番号といった、メッセージの一意性を保証する適切な手段と組み合わせなければなりません (詳細については、前半のセクションを参照してください)。

デジタル署名を送信者の ID を検証するために使用する場合、送信者は秘密鍵を所有していることを証明しなければなりません。これを行う方法の 1 つは、チャレンジ/レスポンス形式のプロトコルを使用することです。この種のプロトコルは、本ドキュメントの対象範囲を超えています。

この目的を実現するために、開発者はタイプスタンプ、有効期限、およびメッセージへのシーケンス番号をメッセージに添付できます。

また、実装者は、デジタル署名一般、また具体的には XML 署名の使用から生じるセキュリティ上の含意をすべて認識しておく必要があります。デジタル署名をベースにした信頼をアプリケーションに組み込む際には、証明書の評価などの他のテクノロジも組み込まなければならないが、これらは本ドキュメントの対象範囲を超えています。

要求側は、伝送中に変更されていないことを確実にするために、デジタル署名を使用して署名 (または他の保護メカニズム) を含んでいないセキュリティトークンに署名を行う必要があります。

また、 XML 暗号化に記述されているように、共通のデータ項目に対する署名と暗号化の組み合わせが、ある種の暗号化の脆弱性を導く可能性があることに注意してください。たとえば、デジタル署名が行われたデータを暗号化するときに、デジタル署名を平文で残していると、この平文のテキストを推測する攻撃を許す可能性があります。アプリケーションの設計者は、そのような脆弱性を組み込まないように注意を払う必要があります。

8. 謝辞

本仕様は、以下を含めた多くの個人およびチームとの合同作業の結果として開発されました。

9. 参考文献

[DIGSIG]
Informational RFC 2828, "Internet Security Glossary," May 2000.
[Kerberos]
J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC 1510, September 1993, http://www.ietf.org/rfc/rfc1510.txt .
[KEYWORDS]
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997
[SHA-1]
FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce / National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt
[SOAP]
W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.
[SOAP-SEC]
W3C Note, "SOAP Security Extensions: Digital Signature," 06 February 2001.
[URI]
T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.
[XML-C14N]
W3C Recommendation, "Canonical XML Version 1.0," 15 March 2001
[XML-Encrypt]
W3C Working Draft, "XML Encryption Syntax and Processing," 04 March 2002.
[XML-ns]
W3C Recommendation, "Namespaces in XML," 14 January 1999.
[XML-Schema1]
W3C Recommendation, "XML Schema Part 1: Structures,"2 May 2001.
[XML-Schema2]
W3C Recommendation, "XML Schema Part 2: Datatypes," 2 May 2001.
[XML Signature]
W3C Recommendation, "XML Signature Syntax and Processing," 12 February 2002.
[WS-Routing]
H. Nielsen, S. Thatte, "Web Services Routing Protocol", Microsoft, October 2001
[X509]
S. Santesson, et al,"Internet X.509 Public Key Infrastructure Qualified Certificates Profile," http://www.itu.int/rec/T-REC-X.509-200003-I
[XPath]
W3C Recommendation, "XML Path Language", 16 November 1999

Web Services Security (WS-Security)

Version 1.0

執筆者

著作権について

概要

組み合わせ可能なアーキテクチャ

ステータス

目次

1. はじめに

1.1. 目標と要件

1.1.1. 要件

1.1.2. この仕様が目標としない事項

1.2. 例

2. 表記と用語

2.1. 表記規則

2.2. 名前空間

2.3. 専門用語

3. 保護品質

3.1. メッセージ セキュリティ モデル

3.2. メッセージの保護

3.3. 申告がないか、不適切な申告

4. Security 要素

4.1. UsernameToken 要素

4.2. バイナリ セキュリティ トークンのエンコード

4.3. SecurityTokenReference 要素

4.4. ds:KeyInfo

4.5. ds:Signature

4.5.1. アルゴリズム

4.5.2. メッセージの署名

4.5.3. 完全性の検証

4.5.4. 例

4.6. Encryption サブ要素

4.6.1. xenc:ReferenceList

4.6.2. xenc:EncryptedKey

4.6.3. xenc:EncryptedData

4.6.4. 処理規則

5. 拡張例

6. エラー処理

7. セキュリティの考慮事項

8. 謝辞

9. 参考文献

その他のリソース

3.1. メッセージセキュリティモデル

4.2. バイナリセキュリティトークンのエンコード