Web Services Trust Language (WS-Trust)

  • [アーティクル]

Version 1.0

December 18, 2002

日本語版編者 (あいうえお順):
田口 慶二 (日本ベリサイン株式会社)
中村 祐一 (日本アイ・ビー・エム株式会社)
野村 一行 (マイクロソフト株式会社)
米持 幸寿 (日本アイ・ビー・エム株式会社)

執筆者

Giovanni Della-Libera (Microsoft)
Brendan Dixon (Microsoft)
Praerit Garg (Microsoft)
Phillip Hallam-Baker (VeriSign)
Maryann Hondo (IBM)
Chris Kaler (Editor) (Microsoft)
丸山 宏 (IBM)
Anthony Nadalin (Editor) (IBM)
Nataraj Nagaratnam (IBM)
Andrew Nash (RSA Security)
Rob Philpott (RSA Security)
Hemma Prafullchandra (VeriSign)
John Shewchuk (Microsoft)
Dan Simon (Microsoft)
Elliot Waingold (Microsoft)
Riaz Zolfonoon (RSA Security)

著作権について

(c) 2001, 2002 International Business Machines Corporation, Microsoft Corporation, RSA Security Inc., VeriSign Inc. All rights reserved.

IBM, Microsoft, RSA Security Inc., and VeriSign (collectively, the "Authors") hereby grant you permission to copy and display the WS-Trust Specification, in any medium without fee or royalty, provided that you include the following on ALL copies of the WS-Trust Specification, or portions thereof, that you make:

  1. A link or URL to the Specification at this location
  2. The copyright notice as shown in the WS-Trust Specification.

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

THE WS-Trust SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE WS-Trust SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE WS-Trust SPECIFICATION.

The WS-Trust Specification may change before final release and you are cautioned against relying on the content of this specification.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the WS-Trust Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

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

概要

本仕様は、セキュリティ トークンの要求と発行、および信頼関係の管理のために、WS-Security 上に構築された拡張機能を定義します。

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

Web サービス仕様 (WS*) は、XML、SOAP、および WSDL の拡張性モデルを使用することにより、互いに組み合わせることで豊富な Web サービス環境を提供できるようにデザインされています。WS-Trust は、それ自体では Web サービスの完全なセキュリティ ソリューションを提供するものではありません。WS-Trust は、他の Web サービスとアプリケーション固有のプロトコルとを組み合わせて、幅広いセキュリティ モデルに対応するための基本要素です。

ステータス

本 WS-Trust 仕様は、最初に公開される草案としてのリリースで、レビューと評価の目的のみに提供されています。IBM、Microsoft、RSA、および VeriSign は近い将来に、読者からの寄稿と提案を募る予定です。IBM、Microsoft、RSA、および VeriSign は、本仕様に関して、いかなる形の保証や表明も行いません。

目次

1. 概要

   1.1. 本仕様の目標と本仕様が目標としない事項

   1.2. 要件

2. 表記と用語

   2.1 表記規則

   2.2 名前空間

   2.3. スキーマと WSDL ファイル

   2.4. 専門用語

3. Web サービス信頼モデル

4. セキュリティ トークンの発行、検証、および交換

   4.1. セキュリティ トークンの要求

   4.2. セキュリティ トークンの返却

   4.3. スコープ要件

   4.4. 鍵と暗号の要件

   4.5. デリゲーション、フォワーディング、およびプロキシの要件

   4.6. 存続期間と更改の要件

   4.7. ポリシー

   4.8. チャレンジ

      4.8.1. 構文

      4.8.2. 例

5. 信頼の管理

6. 信頼評価のモデル

   6.1. イン・バンド

   6.2. アウト・オブ・バンド

7. パスワード ベースの鍵の派生

8. エラー処理

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

10. 謝辞

11. 参考文献

付録 I

1. 概要

WS-Security は、セキュリティで保護されたメッセージングを提供する基本メカニズムを定義します。本仕様はこのような基本メカニズムを使用し、異なる信頼ドメイン内のクレデンシャルの発行と伝達を可能にするために、セキュリティ トークン交換の新たな基本機能と拡張機能を定義します。

2 者間の通信を保護するには、その両当事者がセキュリティ クレデンシャルを (直接または間接的に) 交換する必要があります。ただし、一方の当事者は、他方の当事者から表明されたクレデンシャルを "信頼" できるかどうかを判断する必要があります。

本仕様では、以下の項目を提供する WS-Security の拡張機能を定義します。

  • セキュリティ トークンを発行および交換するためのメソッド。
  • 信頼関係の存在を確立し、アクセスする方法。

アプリケーションは、これらの仕様を使って、WSDL サービス記述、UDDI businessServices と bindingTemplates、および SOAP メッセージなど、一般的な Web サービス フレームワークで機能するようにデザインされたセキュリティで保護された通信に参加します。

本仕様は、このことを実現するために、セキュリティ トークンの要求と信頼関係の管理に使用する数多くのヘッダや要素を導入します。

本仕様は多数の拡張機能を定義します。本仕様に準拠するサービスは、本仕様で定義するすべての機能を実装する必要はない (NOT REQUIRED)。ただし、サービスが本仕様のある側面を実装する場合は、指定された要件に準拠しなければならない (MUST)。(例、関連する "MUST" を含む文。)

1.1. 本仕様の目標と本仕様が目標としない事項

WS-Trust の目標は、アプリケーションが信頼性のある SOAP メッセージ交換を行えるようにすることです。

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

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

以下のトピックは、本書の対象範囲ではありません。

  • セキュリティ コンテキスト トークンの確立。
  • 鍵の派生と交換。

1.2. 要件

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

  • セキュリティ トークンの要求と取得。
  • 信頼の管理と信頼関係の確立。
  • 信頼関係の確立と評価。
  • パスワード認証。

2. 表記と用語

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

2.1. 表記規則

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

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

2.2. 名前空間

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

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

本書では、以下の名前空間を使用します。

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

2.3. スキーマと WSDL ファイル

本仕様のスキーマは、次の名前空間に配置できます。

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

本仕様の WSDL は、本書の付録 I と次の名前空間にあります。

        https://schemas.xmlsoap.org/ws/2002/12/ws-trust.wsdl

本書では、ユーティリティ スキーマ (https://schemas.xmlsoap.org/ws/2002/07/utility) の wsu:Id 属性、wsu:Created 属性、および wsu:Expires 属性への参照が設定されています。ID やタイムスタンプなどを必要とする他の仕様がユーティリティ スキーマを (本仕様と同様に) 参照できるようにするために、wsu:Id 属性、wsu:Created 属性、および wsu:Expires 属性がユーティリティ スキーマに追加されました。

2.4. 専門用語

本仕様で使用するセキュリティの専門用語の基本的な定義を提供します。読者は、WS-Security 仕様に精通している必要があることに注意してください。

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

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

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

Cc465478.ws-trust01(ja-jp,MSDN.10).gif

所有の証明 (Proof-of-Possession) – "所有の証明" 情報は、送信者がクライアントだけが知っておくべき情報の知識に基づいて、(申告済みの) クライアントの代理として操作していることを示すために、証明処理で使用するデータです。所有の証明は、セキュリティ トークン内でクライアントとクライアントの代理として操作している送信者を結び付けるために使用します。

所有の証明トークン – "所有の証明トークン" は、送信側の当事者が所有の証明を示すために使用できるデータを保持するセキュリティ トークンです。一般的には、所有の証明情報は、送信側の当事者と受信側の当事者だけが知っている鍵を使って暗号化されますが、必ずしも暗号化されるとは限りません。

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

署名 – "署名" は、ある情報の鍵とダイジェストとの暗号化バインディングです。これは、対称鍵ベースの署名と公開鍵ベースの署名の両方をカバーします。署名できる情報の例には、メッセージ、トークン、および所有の証明などがあります。

信頼エンジン – Web サービスの "信頼エンジン" は、以下の セクション 3 で説明するように、メッセージのセキュリティに関連する側面を評価する概念的なコンポーネントです。

セキュリティ トークン サービス – "セキュリティ トークン サービス" は、セキュリティ トークンを発行する Web サービスです (WS-Security 参照)。つまり、セキュリティ トークン サービスは、セキュリティ トークン サービスが信頼する証拠に基づいて、セキュリティ トークン サービスを信頼するすべての相手に表明を行います。サービスは、信頼を伝達するために、セキュリティ トークンまたはセキュリティ トークンのセットなどの証明を要求し、独自の信頼ステートメントを持つセキュリティ トークンを発行します (セキュリティ トークンの形式によっては、これが単なる再発行または共同署名になり得ることに注意してください)。これは、信頼の仲介の基礎を形成します。

信頼 - "信頼" は、あるエンティティが動作のセットを実行して、主体およびスコープ、またはいずれか一方について一連の表明を行うとき、あるいはいずれか一方を実行するとき、第 2 の当事者に積極的に依存する特性のことです。

直接信頼 – "直接信頼" は、依存している当事者が要求者が送信したトークン内のすべての (またはあるサブセットの) 申告を全面的に受け入れるときを指します。

直接仲介された信頼 – "直接仲介された信頼" は、ある当事者が第 2 の当事者が順次信頼または保証する第 3 の当事者を信頼するときを指します。

間接的に仲介された信頼 – "間接的に仲介された信頼" は、第 3 の当事者、 また第 4 以上の当事者の信頼性を評価するために、 第 2 の当事者が第 3 の当事者と交渉するような、直接仲介された信頼の変形です。

メッセージ認証 – "メッセージ認証" は、受け取ったメッセージが送信されたメッセージと同じであることを確認する処理です。

送信元認証 – "送信元認証" は、メッセージの送信者を確認する処理です。

新鮮度 – "新鮮度" は、メッセージがリプレイされておらず、現在有効であることを確認する処理です。

3. Web サービス信頼モデル

WS-Trust で定義される Web サービス セキュリティ モデルは、以下のプロセスに基づいています。

Web サービスは、着信するメッセージが申告のセット (例、名前、鍵、許可、権限など) を証明することを要求できます。必要な申告の証明を持たずにメッセージが着信した場合は、サービスはこのメッセージを無視するか、拒否する必要がある (SHOULD)。WS-Policy 仕様と WS-PolicyAttachment 仕様で説明したように、サービスはサービスが要求する申告と関連情報をサービスのポリシーに示すことができます。

要求者は、メッセージとセキュリティ トークンを関連付け、そのトークンの (コンテンツの) 所有の証明を示すメッセージの署名を含めることによって、要求された申告のセットを証明する能力を示すメッセージを送信できます。

  • 要求者が申告の証明に必要なトークンを所有していない場合は、要求者は適切な機関に連絡し、トークンを入手します。このような "機関" を "セキュリティ トークン サービス" と呼び、これは申告の独自のセットを順次要求することがあります。セキュリティ トークン サービスは、異なる信頼ドメイン間で信頼関係を仲介するために使用できるセキュリティ トークンを発行することによって、信頼の基礎を形成します。
  • また、本仕様はチャレンジ/レスポンス プロトコルを定義します。Web サービスはこのプロトコルを使用して、要求者が提供した新鮮度や所有の証明について、その要求者に新たなチャレンジを行います。

以下の図はこのモデルを説明していて、任意の要求者はサービスであることもあり、セキュリティ トークン サービスがポリシーの表記やセキュリティ トークンの要求を含む Web サービスであることを示しています。

Cc465478.ws-trust02(ja-jp,MSDN.10).gif

申告、ポリシー、およびセキュリティ トークンを使用するこの一般的なメッセージング モデルは、ID ベースのセキュリティ、アクセス制御リスト、権限ベースのセキュリティなど、多くの特定モデルをいくつか包含し、サポートします。このモデルは、X.509 公開鍵証明書、 XML ベースのトークン、Kerberos 共有秘密チケット、パスワード ダイジェストなどの既存のテクノロジの使用を許可します。WS-Security の基本機能と WS-Policy の基本機能を組み合わせた一般的なモデルを使って、高度な鍵交換、認証、ポリシーに基づくアクセス決定、監査、および複雑な信頼関係を十分構築できます。

要約すると、Web サービスはその Web サービスに適用されるポリシーを持ち、要求者からセキュリティ トークンを含む可能性のあるメッセージを受け取り、さらに、WS-Security メカニズムを使用して Web サービスに適用される何らかの保護機能を備えることもあります。Web サービスの信頼エンジンによって以下の主要な手順が実行されます (処理の順序に基準はないことに注意してください)。

トークン内の申告がポリシーに十分準拠していることを確認し、メッセージがポリシーに従っていることを確認します。

申告者の属性が署名によって証明されていることを確認します (必要な属性に関連付けられた鍵で行われます)。仲介された信頼モデルでは、申告者の ID を確認しないこともあります。単純に申告者の ID を表明する中間ノードの ID を確認することもあります。申告は、証明されるか、ポリシーに基づいていないかのいずれかになります。

セキュリティ トークン (すべての関連するセキュリティ トークンや受け継いだセキュリティ トークンを含みます) の発行者が、申告を発行することを信頼されている発行者であることを確認します。信頼エンジンは、評価に直接使用できる他のセキュリティ トークンとトークンを交換するために、セキュリティ トークン サービスにそのトークンを送信する必要がある場合があります。

これらの条件を満たし、要求者が操作の実行を承認される場合に、サービスは上記に示した信頼モデル内でサービス要求を処理できます。

本仕様では、セキュリティ トークン サービスにセキュリティ トークンを要求し、取得する方法と、サービスが手順 3 を実行できるようにセキュリティ トークン サービスが信頼と信頼ポリシーを仲介する方法を定義します。

4. セキュリティ トークンの発行、検証、および交換

上記で説明したように、セキュリティ トークン サービスは、セキュリティ トークンを発行、検証、および交換します。要求者が要求を送信した際に、もしポリシーがその要求を許可し、 かつその要求が受信者の要件を満たす場合は、 要求者はセキュリティトークン応答を受け取ります。

このために、<RequestSecurityToken> 要素と <RequestSecurityTokenResponse> 要素をそれぞれ定義します。これらの要素は、セキュリティ トークン サービスによって実装される特定の WSDL ポート (セクション 2.3 で説明しています) にペイロードとして渡されます。

ポートでのセキュリティ トークン要求の SOAP 動作は、次のように定義されます。

    https://schemas.xmlsoap.org/security/RequestSecurityToken

ポートでのセキュリティ トークン応答の SOAP 動作は、次のように定義されます。

    https://schemas.xmlsoap.org/security/RequestSecurityTokenResponse

4.1. セキュリティ トークンの要求

セキュリティ トークンの要求には <RequestSecurityToken> 要素を使用します。要求者は、その要求に含まれるか、その要求で参照される、その要求に関連するトークンを使用して、この要素に署名する必要がある (SHOULD)。署名付き要求を使用している場合、要求者はセキュリティ トークン サービスの要件を満たすのに必要な申告を証明しなければならない (MUST)。

この要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <TokenType>...</TokenType>
        <RequestType>...</RequestType>
        <Base>...</Base>
        <Supporting>...</Supporting>
    </RequestSecurityToken>

以下で、上記のスキーマ概要で示した属性と要素を説明します。

  • /RequestSecurityToken
    この要素は、発行されたセキュリティ トークンを持つ要求です。

  • /RequestSecurityToken/TokenType
    この要素は省略可能で、要求されたセキュリティ トークンの型を説明します。セキュリティ トークンの型は QName として示されます。これは、<RequestSecurityTokenResponse> メッセージで返されるトークンの型です。この要素が要求において定義されていない場合は、省略可能な要素 <AppliesTo> (以下で定義します) を使用することが推奨される (RECOMMENDED)。つまり、要求においては <TokenType> 要素または <AppliesTo> 要素のいずれかを定義する必要がある (SHOULD)。<TokenType> 要素と <AppliesTo> 要素の両方を定義すると、対象のスコープが特定の型のトークンを必要とする場合に (現在の要求のみに対して) <AppliesTo> 要素が優先されます。

  • /RequestSecurityToken/RequestType
    QName を使用して、要求される動作 (例、 wsse:Issue) を示すために、RequestType 要素を使用します。 以下は定義済みの符号化形式です。

    QName 説明
    wsse:ReqIssue セキュリティ トークンを発行します。
    wsse:ReqValidate セキュリティ トークンを検証します。
    wsse:ReqExchange セキュリティ トークンを交換します。

  • /RequestSecurityToken/Base
    この要素は省略可能で、<SecurityTokenReference> (WS-Security 参照) 要素と同じ型を持ち、要求の信頼性を検証するために使用する基本 (プライマリ) トークンを参照します。要求には、要求を行う権利を証明する署名が提供されるので、一般的にはこの要素を使用しません。要求において複数の署名が存在し、そのすべてが要求の承認をサポートするわけではないような場合、またはサポートしているトークンが署名を提供できない場合 (例、埋め込みパスワードを持つ <UsernameToken> トークン)、この要素を指定します。

  • /RequestSecurityToken/Supporting
    この要素は省略可能で、<SecurityTokenReference> 要素と同じ型を持ち、この要求を承認するために使用する、サポートしているトークンを参照します。一般的には、認証機関でトークンを識別するために、この要素を使用します。任意のまたはすべてのサポートしているトークンを指定する必要はありません。受信者サービスに対する単なるヒントまたは手掛かりです。

  • /RequestSecurityToken/{any}
    これは、付加的な要素を追加できるようにする拡張メカニズムです。これにより、クライアントはトークン要求の処理に使用できる任意の要素を含めることができます。

  • /RequestSecurityToken/@{any}
    これは、付加的な属性をスキーマに基づいて追加することを可能にする拡張メカニズムです。

以下に要求例を示します。この例では、ID "myToken" を持つ <Security> ヘッダ内に配置されるセキュリティ トークンに基づいて、X509 セキュリティ トークンが要求されます。このトークンはユーザー名を指定し、パスワード (またはパスワードに相当するもの)、ノンス、およびタイムスタンプから派生される鍵を使用して、要求上に署名が行われます。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility>
    <S:Header>
       ...
       <Security>
           <UsernameToken wsu:Id="myToken">
               <Username>NNK</Username>
               <Nonce>FKJh...</Nonce>
               <wsu:Created>2001-10-13T09:00:00Z </wsu:Created>
           </UsernameToken>
           <ds:Signature xmlns:ds="...">
               ...
           </ds:Signature>
       </Security>
       ...
    </S:Header>
    <S:Body wsu:Id="req">
       <RequestSecurityToken>
           <TokenType>wsse:X509v3</TokenType>
           <RequestType>wsse:ReqIssue</RequestType>
           <Base>
               <Reference URI="#myToken"/>
           </Base>
       </RequestSecurityToken>
    </S:Body>
</S:Envelope>

4.2. セキュリティ トークンの返却

<RequestSecurityTokenResponse> 要素を使用して、セキュリティ トークンを返します。

この要素の構文は、以下のとおりです。

    <RequestSecurityTokenResponse> 
        <TokenType>...</TokenType>
        <KeyType>...</KeyType>
        <KeySize>...</KeySize>
        <wsp:AppliesTo>...</wsp:AppliesTo>
        <RequestedSecurityToken>...</RequestedSecurityToken>
        <RequestedProofToken>...</RequestedProofToken>
    </RequestSecurityTokenResponse>

以下で、上記のスキーマ概要で示した属性と要素を説明します。

  • /RequestSecurityTokenResponse
    この要素は、セキュリティ トークン要求に対する応答です。
  • /RequestSecurityTokenResponse/TokenType
    この要素は省略可能で、返されるセキュリティ トークンの型を指定します。省略可能な <TokenType> 要素または省略可能な <AppliesTo> 要素のいずれかを指定する必要がある (SHOULD) ことに注意してください。要求された型以外のトークン型を返す場合は、これを指定しなければならない (MUST)。
  • /RequestSecurityTokenResponse/KeyType
    この要素は省略可能で、トークンで使用される鍵の型を指定します (以下の要求の説明内の <RequestKeyType> を参照してください)。
  • /RequestSecurityTokenResponse/KeySize
    この要素は省略可能で、返される鍵のサイズを指定します (以下の要求の説明内の <RequestKeySize> を参照してください)。
  • /RequestSecurityTokenResponse/wsp:AppliesTo
    この要素は省略可能で、このセキュリティ トークンが適用されるスコープを指定します。詳細については、WS-PolicyAttachment を参照してください。
  • /RequestSecurityTokenResponse/RequestedSecurityToken
    この要素は省略可能で、要求されたセキュリティ トークンを返すために使用します。通常は、要求されたセキュリティ トークンがこの要素のコンテンツになりますが、代わりにセキュリティ トークン参照を使用してもよい (MAY)。たとえば、要求されたセキュリティ トークンをメッセージのセキュリティ保護の一部として使用する場合は、(WS-Security で説明しているように) セキュリティ トークンが <Security> ヘッダ内部に格納され、<Security> ヘッダ内のトークンを参照するために、<SecurityTokenReference> 要素が <RequestedSecurityToken> 要素の内部に格納されます。この要素は省略可能ですが、エラーが 1 つも存在しない限りは、<RequestedSecurityToken> または <RequestedProofToken> の少なくとも 1 つを返す必要がある (REQUIRED)。
  • /RequestSecurityTokenResponse/RequestedProofToken
    この要素は省略可能で、要求されたセキュリティ トークンに関連付けられた所有の証明トークンを返すために使用します。通常は、所有の証明トークンがこの要素のコンテンツになりますが、代わりにセキュリティ トークン参照を使用してもよい (MAY)。トークン (または参照) は、この要素のコンテンツとして指定されます。たとえば、証明トークンをメッセージのセキュリティ保護の一部として使用する場合は、このトークンが <Security> ヘッダに格納され、<Security> ヘッダ内でトークンを参照するために <SecurityTokenReference> 要素が <RequestedProofToken> 要素内部で使用されます。この要素は省略可能ですが、エラーが 1 つも存在しない限りは、<RequestedSecurityToken> または <RequestedProofToken> の少なくとも 1 つを返す必要がある (REQUIRED)。
  • /RequestSecurityTokenResponse/{any}
    これは、付加的な要素を追加できるようにする拡張メカニズムです。
  • /RequestSecurityTokenResponse/@{any}
    これは、付加的な属性をスキーマに基づいて追加することを可能にする拡張メカニズムです。

以下に応答例を示します。この例では、事前に存在する X.509v3 (ディレクトリ内を照合し、その後セキュリティ トークンに符号化します) セキュリティ トークンが返されます。この例では、クライアントが使用する公開鍵を提供した (および対応する秘密鍵を使用して認証した) ので、所有の証明は返しません。

    ...
    <RequestSecurityTokenResponse>
        <RequestedSecurityToken>
            <BinarySecurityToken ValueType="wsse:X509v3" 
                                 EncodingType="wsse:Base64Binary">
                 MIIEZzCCA9CgAwIBAgIQEmtJZc0...
            </BinarySecurityToken>
        </RequestedSecurityToken>
    </RequestSecurityTokenResponse>
    ...

以下に別の応答例を示します。この例では、所有の証明の暗号化された対称鍵と共に、カスタム セキュリティ トークンが返されます。

    ...
    <RequestSecurityTokenResponse>
        <RequestedSecurityToken>
            <BinarySecurityToken ValueType="x:MyToken" 
                                 EncodingType="wsse:Base64Binary"
                                 xmlns:x="...">
                 MIIEZzCCA9CgAwIBAgIQEmtJZc0...
            </BinarySecurityToken>
        </RequestedSecurityToken>
        <RequestedProofToken>
            <xenc:EncryptedKey Id="newProof">
                ...
            </xenc:EncryptedKey>
        </RequestedProofToken>
    </RequestSecurityTokenResponse>
    ...

4.3. スコープ要件

このセクションは、返されるセキュリティ トークンでのスコープ要件のための、<RequestSecurityToken> 要素に対する拡張機能を定義します。

この拡張要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <wsp:AppliesTo>...</wsp:AppliesTo>
        <Claims>...</Claims>
    </RequestSecurityToken>

以下で、上記のスキーマ概要で示した属性と要素を説明します。

/RequestSecurityToken/wsp:AppliesTo

この要素は省略可能で、このセキュリティ トークンを希望するスコープを指定します。詳細については、WS-PolicyAttachment を参照してください。<RequestSecurityToken> メッセージ内でこの要素または <TokenType> 要素を定義する必要がある (SHOULD) ことに注意してください。両方 (BOTH) のフィールドが値を持つ場合は、<AppliesTo> フィールドが優先されます。

/RequestSecurityToken/Claims

この要素は省略可能で、申告の特定のセットを要求します。大部分の場合、この要素はサービスのポリシー内で要求されたとおりに識別された申告を保持します。サービスが申告の要件を指定するポリシーを使用する方法の例については、WS-Policy を参照してください。

4.4. 鍵と暗号の要件

このセクションは、特定の種類の鍵またはアルゴリズム、あるいは返されるトークン内で指定されたポリシーによって指定された鍵およびアルゴリズムを要求するための、<RequestSecurityToken> 要素の拡張機能を定義します。

この拡張要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <RequestKeyType>...</RequestKeyType>
        <RequestKeySize>...</RequestKeySize>
        <RequestSignatureAlgorithm>...</RequestSignatureAlgorithm>
        <RequestEncryption>...</RequestEncryption>
        <RequestProofEncryption>...</RequestProofEncryption>
        <UsePublicKey Sig=...>
            <ds:KeyInfo>...</ds:KeyInfo>
        </UsePublicKey>
        <UseKeyRef Sig=...>...</UseKeyRef>
    </RequestSecurityToken>

以下で、上記のスキーマ概要で示した属性と要素を説明します。

  • /RequestSecurityToken/RequestKeyType
    この要素は省略可能で、セキュリティ トークンに希望する鍵の種類を示します。定義済みの値は wsse:PublicKey および wsse:SymmetricKey です。一部のセキュリティ トークン形式は固定的な鍵の種類を持つことに注意してください。
  • /RequestSecurityToken/RequestKeySize
    この要素は省略可能で、必要な鍵のサイズを示します。値のセマンティクスは、KeyType によって異なります。これはあくまでも要求で、要求されたセキュリティ トークンが要求された鍵のサイズを使用する義務はありません。希望するセキュリティの長さを示すときに、この情報を提供します。
  • /RequestSecurityToken/RequestSignatureAlgorithm
    この要素は省略可能で、返されるトークンに希望する署名アルゴリズムを示します。アルゴリズムを示す URI としてこれを指定します (代表的な署名アルゴリズムについては、XML Signature を参照してください)。
  • /RequestSecurityToken/RequestEncryption
    この要素は省略可能で、要求者が指定したトークンを暗号化するために、発行されるセキュリティ トークン内に任意の機密情報が返されるのを希望していることを示します。つまり、指定したトークンの所有者が機密情報を復号化できるようにします。この要素は <SecurityTokenReference> 要素と同じ型を持ち、そのコンテンツが希望するトークンを参照します。この要素が指定されない場合は、鍵を暗号化する方法を判断するために、基本トークン (または特定の知識) を使用します。
  • /RequestSecurityToken/RequestProofEncryption
    この要素は省略可能で、要求者が指定したトークンを暗号化するために、所有の証明トークン内に任意の機密情報が返されるのを希望していることを示します。つまり、指定したトークンの所有者が機密情報を復号化できるようにします。この要素は <SecurityTokenReference> 要素と同じ型を持ち、そのコンテンツが希望するトークンを参照します。この要素が指定されない場合は、鍵を暗号化する方法を判断するために、基本トークン (または特定の知識) を使用します。
  • /RequestSecurityToken/UsePublicKey
    この要素は省略可能で、要求したセキュリティ トークンまたは発行したセキュリティ トークン内で要求者の公開鍵を使用する必要があることを示します。鍵は、XML Signature からの <ds:KeyInfo> 要素を使用して指定されます。
  • /RequestSecurityToken/UsePublicKey/@Sig
    指定された公開鍵を "認証" するために、この要求の署名に対応する秘密鍵を使用してもよい (MAY)。この省略可能な属性が指定された場合、この属性は (URI 参照による) 対応する署名の ID を示します。
  • /RequestSecurityToken/UseKeyRef
    この要素は <SecurityTokenReference> 要素と同じ型を持ち、そのコンテンツは要求したトークンで使用する必要がある鍵を保持するセキュリティ トークンを参照します。サービスが鍵の種類を暗黙的に認識していない場合に、<RequestKeyType> を定義しないと、この要素に意味はなく、無視されます。
  • /RequestSecurityToken/UseKeyRef/@Sig
    参照される公開鍵を "認証" するために、この要求の署名に対応する秘密鍵を使用してもよい (MAY)。この省略可能な属性が指定された場合、この属性は (URI 参照による) 対応する署名の ID を示します。

以下の例は、要求者が "SomeTokenType" 型のトークンを要求しています。この型のトークンは、暗号化の必要性に対して 1024 ビット公開鍵テクノロジ (大抵の場合、対称鍵でも可) を使用する必要があります。

要求者は、デジタル署名とトークン サービスに RSA を使用して、提供するトークンを使用する情報を暗号化することを希望しています。さらに、返されるトークンは "http://somekey" からの公開鍵を持つ必要があります。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility"
            xmlns:ds="...>
    <S:Header>
       ...
       <Security>
           <UsernameToken wsu:Id="myToken">
               <Username>NNK</wsse:Username>
               <Nonce>FKJh...</wsse:Nonce>
               <Created>2001-10-13T09:00:00Z </wsu:Created>
           </UsernameToken>
           <BinarySecurityToken wsu:Id="requestEncryptionToken" 
                             ValueType="x:SomeTokenType" 
                             EncodingType="wsse:Base64Binary"
                             xmlns:x="...">
                 MIIEZzCCA9CgAwIBAgIQEmtJZc0...
           </BinarySecurityToken>
           <BinarySecurityToken wsu:Id="requestProofEncryptionToken" 
                             ValueType="x:SomeTokenType" 
                             EncodingType="wsse:Base64Binary"
                             xmlns:x="...">
                 MIIEZzCCA9CgAwIBAgIQEmtJZc0...
           </BinarySecurityToken>
           <ds:Signature>
               ... 要求上の署名 ...
           </ds:Signature>
           <ds:Signature Id="proofSignature">
               ... 要求した鍵を提供する署名 ...
           </ds:Signature>
       </Security>
       ...
    </S:Header>
    <S:Body wsu:Id="req">
        <RequestSecurityToken>
            <TokenType>x:SomeTokenType</TokenType>
            <RequestType>wsse:ReqIssue</RequestType>
            <Base>
                <Reference URI="#myToken"/>
            </Base>
            <RequestKeyType>wsse:PublicKey</RequestKeyType>
            <RequestKeySize>1024</RequestKeySize>
            <RequestSignatureAlgorithm>
                http://www.w3.org/2000/09/xmldsig#rsa-sha1
            </RequestSignatureAlgorithm>
            <RequestEncryption>
                <Reference URI="#requestEncryptionToken">
            </RequestEncryption>
            <RequestProofEncryption>
                <Reference URI="#requestProofEncryptionToken">
            </RequestProofEncryption>
            <UsePublicKey Sig="#proofSignature">
                <ds:KeyInfo>
                    <SecurityTokenReference>
                        <Reference URI="http://somekey"/>
                    </SecurityTokenReference>
                </ds:KeyInfo>
            </UsePublicKey>
        </RequestSecurityToken>
    </S:Body>
</S:Envelope>

4.5. デリゲーション、フォワーディング、およびプロキシの要件

このセクションは、要求されたセキュリティ トークンでのデリゲーション、フォワーディング、およびプロキシの要件のための、<RequestSecurityToken> 要素に対する拡張機能を定義します。

この拡張要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <OnBehalfOf>...</OnBehalfOf>
        <DelegateTo>...</DelegateTo>
        <Forwardable/>
        <Delegatable/>
        <Proxiable/>
    </RequestSecurityToken>
  • /RequestSecurityToken/OnBehalfOf
    この要素は省略可能で、要求者が他人の代理で要求を行っていることを示します。要求を代理で行っている元の要求者の ID は、<OnBehalfOf> 要素内部にセキュリティ トークンまたは <SecurityTokenReference> 要素を格納することによって指定します。
  • /RequestSecurityToken/DelegateTo
    この要素は省略可能で、要求されるトークンまたは発行されるトークンを他の ID に委任することを示します。委任を受ける ID は、<DelegateTo> 要素内部にセキュリティ トークンまたは <SecurityTokenReference> 要素を格納することによって指定します。
  • /RequestSecurityToken/Forwardable
    この要素は省略可能で、セキュリティ トークンを "Forwardable" としてマークすることを要求します。これは、種類固有のトークン プロセッサに特殊な動作を許可します。一般的には、この要素を使用して返されるトークンにマークを付けることにより、返されるトークンを使用して、他の当事者または指定されたポリシーに基づくアドレス用にトークンを取得できます。転送の用途に使用するときに、この要素の省略可能なコンテンツがトークンの種類固有の規則や制限事項を保持してもよい (MAY)。トークン固有の規則の例には、Kerberos チケットの要求に適用されるようなものがあります。
  • /RequestSecurityToken/Delegatable
    この要素は省略可能で、セキュリティ トークンを "Delegatable" としてマークすることを要求します。これは、種類固有のトークン プロセッサに特殊な動作を許可します。一般的には、この要素を使用して返されるトークンにマークを付けることにより、返されるトークンを使用して、他の当事者に委任できます。委任の用途に使用するときに、この要素の省略可能なコンテンツがトークンの種類固有の規則や制限事項を保持してもよい (MAY)。トークン固有の規則の例には、Kerberos チケットの要求に適用されるようなものがあります。
  • /RequestSecurityToken/Proxiable
    この要素は省略可能で、セキュリティ トークンを "Proxiable" としてマークすることを要求します。これは、種類固有のトークン プロセッサに特殊な動作を許可します。一般的には、この要素を使用して返されるトークンにマークを付けることにより、返されるトークンを転送でき、本来対象としていない他の当事者やアドレス (プロキシなど) が返されるトークンを使用できます。プロキシの用途に使用するときに、この要素の省略可能なコンテンツがトークンの種類固有の規則や制限事項を保持してもよい (MAY)。トークン固有の規則の例には、Kerberos チケットの要求に適用されるようなものがあります。

4.6. 存続期間と更改の要件

このセクションは、要求されたトークンでの存続期間と更改の要件のための、<RequestSecurityToken> 要素に対する拡張機能を定義します。

WS-Security 仕様では、XML スキーマで定義される dateTime 型に関連して、時間参照を定義および説明します。すべての時間参照がこの型を使用することが推奨される (RECOMMENDED)。さらに、すべての参照を UTC 時刻で表現することが推奨される (RECOMMENDED)。要求者と受信者は、ミリ秒単位よりも細かい単位で時間をサポートする他のアプリケーションに依存しないほうがよい (SHOULD NOT)。実装は、うるう秒を指定する時刻を生成してはならない (MUST NOT)。

この拡張要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <AllowPostdating/>
        <Renewing Allow=... OK=.../>
        <Lifetime>
            <wsu:Created>...</wsu:Created>
            <wsu:Expires>...</wsu:Expires>
        </Lifetime>
    </RequestSecurityToken>
  • /RequestSecurityToken/AllowPostdating
    この要素は、返されるトークンが実際の日付よりも後の日付が指定されたトークンの要求を許可する必要があることを示します。
  • /RequestSecurityToken/Renewing
    この要素は省略可能で、この操作をサポートする種類の更改のセマンティクスを指定するために使用します。
  • /RequestSecurityToken/Renewing/@Allow
    この省略可能なブール値の属性を使用して、更改可能なトークンを要求します。
  • /RequestSecurityToken/Renewing/@OK
    この省略可能なブール値の属性を使用して、要求した期間が発行サービスの制限値を超えても、更改可能なトークンを受け取ることができることを示します。
  • /RequestSecurityToken/Lifetime
    この要素は省略可能で、返されるセキュリティ トークンに対して希望する有効な時間範囲を指定するために使用します。
  • /RequestSecurityToken/Lifetime/@wsu:Created
    この属性は省略可能で、トークンの初期有効時間を表す絶対時刻を指定します。この時刻が将来の時刻を表す場合は、実際の日付よりも後の日付が指定されたトークンに対する要求になります。この属性を指定しない場合は、初期期間として現在時刻を使用します。
  • /RequestSecurityToken/Lifetime/@wsu:Expires
    この属性は省略可能で、要求したトークンの有効時間の上限を表す絶対時刻を指定します。この属性を指定しない場合は、サービスはセキュリティ トークンの存続期間を選択します。

4.7. ポリシー

このセクションは、ポリシーの受け渡しのための、<RequestSecurityToken> 要素の拡張機能を定義します。

この拡張要素の構文は、以下のとおりです。

    <RequestSecurityToken>
        <wsp:Policy>...</wsp:Policy>
        <wsp:PolicyReference>...</wsp:PolicyReference>
    </RequestSecurityToken>

以下で、上記のスキーマ概要で示した属性と要素を説明します。

  • /RequestSecurityToken/wsp:Policy
    この要素は省略可能で、要求するトークンに希望する設定を示すポリシー (WS-Policy で定義されます) を指定します。ポリシーは、上記のセクションで定義した要素によりオーバーライドできる既定値を指定します。
  • /RequestSecurityToken/wsp:PolicyReference
    この要素は省略可能で、要求するトークンに希望する設定を示すポリシー (WS-Policy で定義されます) への参照を指定します。ポリシーは、上記のセクションで定義した要素によりオーバーライドできる既定値を指定します。

4.8. チャレンジ

セキュリティ トークンに対する要求が送信されるときに、WS-Security で説明されるメカニズムを使用してその要求を認証してもよい (MAY)。多くの場合、新鮮度を証明するには、WS-Security で記述されている署名済みのタイムスタンプやノンスで十分です。ただし、場合によっては、サービスは要求者にチャレンジすることを選択してもよい (MAY)。このセクションでは、このフレームワーク内でチャレンジを行う方法とチャレンジに応答する方法を説明します。例については、セクション 4.8.2 を参照してください。

簡単にプロセスを示します ：

Cc465478.ws-trust03(ja-jp,MSDN.10).gif

たとえば、要求者はノンスとタイムスタンプを持つ <RequestSecurityToken> メッセージを送信します。

受信者がそのノンスとタイムスタンプを信頼しないで、埋め込みのチャレンジを持つ <RequestSecurityTokenResponse> メッセージを発行します。

送信者はチャレンジへの答えを持つ <RequestSecurityTokenReponse> メッセージを送信します。

受信者は、発行済みのセキュリティ トークンおよび省略可能な所有の証明トークンを持つ <RequestSecurityTokenResponse> メッセージを発行します。

要求者が手順 1 または手順 3 のいずれかで受信者にチャレンジを行っていることに注意する必要があります。どちらの場合も、手順 2 または手順 4 は送信者のチャレンジに対する答えを保持します。同じようにして、(手順 4 で) 処理を完了する前に、手順 2 と手順 3 を複数回繰り返すことができます。

4.8.1. 構文

チャレンジを記述する要素を含めることによりチャレンジ要求を発行し、レスポンスがその応答を記述する要素を保持します。たとえば、<SignChallenge> 要素を使って、署名チャレンジを処理します。レスポンスは、<SignChallengeResponse> 要素に返されます。チャレンジ要素とレスポンス要素の両方を <RequestSecurityTokenResponse> 要素内で指定します。交渉の形式によっては、他の当事者からのチャレンジに対するレスポンスと共にチャレンジを指定してもよい (MAY)。要求者は、初回の要求で受信者にチャレンジしてもよい (MAY) ことに注意する必要があります。そのため、<RequestSecurityToken> 要素内ではこれらの要素も許可されます。

チャレンジの新鮮度を保証する方法として、チャレンジに <Nonce> 要素と <Timestamp> ヘッダを含めることが推奨される (RECOMMENDED)。他の種類のチャレンジを含めてもよい (MAY)。たとえば、両当事者間で希望するポリシー動作を交渉するために、<Policy> 要素を使用してもかまいません。複数のチャレンジとレスポンスを含めてもよい (MAY)。

この拡張要素の構文は、以下のとおりです。

<SignChallenge>
    <Challenge ...>...</ Challenge>             
 <SecurityTokenReference>...</SecurityTokenReference>  
</SignChallenge>

<SignChallengeResponse>
 <SecurityTokenReference>...</SecurityTokenReference>  
    <ds:Signature>...</ds:Signature>             
</SignChallengeResponse>

<SecurityTokenReference ...>
    ...
</SecurityTokenReference>

<BinaryNegotiation ValueType="...">
    ...
</BinaryNegotiation>

以下で、上記のスキーマで示した属性とタグを説明します。

  • .../SignChallenge
    この要素は省略可能で、指定した情報のセットに署名することを他の当事者に要求するチャレンジを指定します。
  • .../SignChallenge/Challenge
    この要素は必須で、有効なレスポンスの一部として、チャレンジのどの部分に署名する必要があるかを記述します。この要素は、WS-SecurityPolicy で説明した <Integrity> 表明と同じ種類を使用します。
  • .../SignChallenge/SecurityTokenReference
    この要素は省略可能で、交渉処理の一部として渡されたセキュリティ トークンを参照するために使用します。
  • /SignChallenge/{any}
    これは、付加的な種類の交渉の使用を許可するための拡張メカニズムです。
  • /SignChallenge/@{any}
    これは、付加的な属性をスキーマに基づいて要素に追加することを可能にする拡張メカニズムです。
  • .../SignChallengeResponse
    この要素は省略可能で、指定した情報のセットに署名することを要求するチャレンジに対するレスポンスを記述します。
  • .../SignChallengeResponse/ds:Signature
    この要素は省略可能で、署名を添付するための XML Signature 要素です。これは、署名チャレンジに対する答えを提供する方法として、ある当事者が指定します。認証に複数のトークンを使用する場合は、複数の署名が存在してもよい (MAY) ことに注意してください。
  • .../SignChallengeResponse/SecurityTokenReference
    この要素は省略可能で、交渉処理の一部として渡されたセキュリティ トークンを参照するために使用します。
  • /SignChallengeResponse/{any}
    これは、付加的な種類の交渉の使用を許可するための拡張メカニズムです。
  • /SignChallengeResponse/@{any}
    これは、付加的な属性をスキーマに基づいて要素に追加することを可能にする拡張メカニズムです。
  • .../SecurityTokenReference
    この要素は省略可能で、交渉処理の一部として渡されたセキュリティ トークンを参照するために使用します。場合によっては、既存のセキュリティ トークン形式 (例、レガシ バイナリ形式) を使用して交渉を行います。このような場合には、この要素を使用してトークンを参照します。その他の場合は、交渉データが任意のバイナリ BLOB になり、<BinaryNegotiation> 要素を使用する必要がある (SHOULD)。
  • .../BinaryNegotiation
    この要素は省略可能で、既存の交渉プロトコルの一部としてバイナリ BLOB の交換を必要とするセキュリティ交渉に使用します。この要素のコンテンツは BLOB 固有で、Base64 (他の符号化が指定されていない場合) を使って符号化されます。
  • .../BinaryNegotiation/@ValueType
    この属性は必須で、交渉の種類 (および BLOB の値空間 - 要素のコンテンツ) を識別するために QName を指定します。
  • .../BinaryNegotiation/@EncodingType
    この属性は必須で、交渉 BLOB の (Base64 とは異なる) 符号化形式を識別するために QName を指定します。
  • /BinaryNegotiation/@{any}
    これは、付加的な属性をスキーマに基づいて要素に追加することを可能にする拡張メカニズムです。

4.8.2. 例

以下に交換の例を示します。この例では、サービスが認証に別の X.509 証明書を使用する X.509 証明書を要求します。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility">
    <S:Header>
       ...
       <Security>
           <BinarySecurityToken
             wsu:Id="myToken"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgAwIBAgIQEmtJZc0...
           </BinarySecurityToken>
           <ds:Signature xmlns:ds="...">
               ...
           </ds:Signature>
       </Security>
       ...
    </S:Header>
    <S:Body>
       <RequestSecurityToken>
           <TokenType>wsse:X509v3</TokenType>
           <RequestType>wsse:ReqIssue</RequestType>
           <Base>
               <Reference URI="#myToken"/>
           </Base>
       </RequestSecurityToken>
    </S:Body>
</S:Envelope>

受信者サービスは送信者のタイムスタンプを信頼しない (またはタイムスタンプが指定されなかった) ので、チャレンジを発行します。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility">
    <S:Header>
       ...
       <Security>
           <BinarySecurityToken
             wsu:Id="myToken2"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             DFJHuedsujfnrnv45JZc0...
           </BinarySecurityToken>
           <ds:Signature xmlns:ds="...">
               ...
           </ds:Signature>
           <Nonce>FKJh...</Nonce>
       </Security>
       ...
    </S:Header>
    <S:Body>
    <RequestSecurityTokenResponse>
        <SignChallenge>
            <Challenge>
              <MessageParts xmlns:wsse=".../secext">
                  GetInfosetForNode(GetHeader(/)/wsse:Security/wsse:Nonce)
              </MessageParts>
            </Challenge>
        </SignChallenge>
    </RequestSecurityTokenResponse>
    </S:Body>
</S:Envelope>

送信者は受信者のチャレンジを受け取り、レスポンスを発行します。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility">
    <S:Header>
       ...
       <Security>
           <BinarySecurityToken
             wsu:Id="myToken"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgAwIBAgIQEmtJZc0...
           </BinarySecurityToken>
           <ds:Signature xmlns:ds="...">
               ...
           </ds:Signature>
       </Security>
       ...
    </S:Header>
    <S:Body>
       <RequestSecurityTokenResponse>
           <SignChallengeResponse>
               <ds:Signature xmlns:ds="...">
                   ...
               </ds:Signature>
           </SignChallengeResponse>
       </RequestSecurityTokenResponse>
    </S:Body>
</S:Envelope>

受信者は、チャレンジに応答している送信者の署名を検証し、要求されたトークンを発行します。

<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility">
    <S:Header>
       ...
       <Security>
           <BinarySecurityToken
             wsu:Id="myToken2"
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             DFJHuedsujfnrnv45JZc0...
           </BinarySecurityToken>
           <ds:Signature xmlns:ds="...">
               ...
           </ds:Signature>
       </Security>
       ...
    </S:Header>
    <S:Body>
    <RequestSecurityTokenResponse>
        <RequestedSecurityToken>
           <BinarySecurityToken
             ValueType="wsse:X509v3"
             EncodingType="wsse:Base64Binary">
             MIIEZzCCA9CgAwIBAgIQEmtJZc0...
           </BinarySecurityToken>
        </RequestedSecurityToken>
        <RequestedProofToken>
           <ds:KeyInfo xmlns:ds="...">
               <ds:KeyValue>
                   ...
               </ds:KeyValue>
           </ds:KeyInfo>
        </RequestedProofToken>
    </RequestSecurityTokenResponse>
    </S:Body>
</S:Envelope>

5. 信頼の管理

サービスに対して信頼を促すために使用できる、いくつかの異なるモデルが存在します。このセクションでは、使用可能ないくつかの異なるメカニズムを提示します。これらのメカニズムは標準ではなく、必ずしも必要なものではありません。つまり、サービスは任意のメカニズムを使用して自由に信頼を促すことができます。

固定信頼ルート – 最も単純なメカニズムで、受信者は信頼関係の固定的なセットを所持します。このメカニズムはすべての要求を評価し、要求が信頼済みのルートの 1 つからのセキュリティ トークンを保持しているかどうかを判断します。

信頼階層 – 信頼ルート メカニズムに基づいて構築されており、信頼チェインが最終的に信頼ルートの 1 つに到達する限り、サービスは信頼の階層を許可することを選択できます。場合によっては、受信者は完全な階層を提供するために、送信者を必要とすることもあります。その他の場合は、受信者はトークン ストアからその階層のトークンを動的にフェッチできることもあります。

認証サービス – もう 1 つのアプローチは認証サービスを使用することです。これは、実質的には受信者が認証サービスだけを信頼する固定信頼ルートと考えることができます。そのため、受信者は認証を証明する信頼できる声明 (おそらく、別のトークンまたは署名済みドキュメント) を応答する認証サービスにトークンを転送します。

6. 信頼のモデル

このセクションでは、信頼関係の存在を評価する 2 つの手法を説明します。これらの手法は、メッセージ フロー内からの情報に基づいて評価が行われる (イン・バンド) か、メッセージの流れの外部からの情報に基づいて評価が行われる (アウト・オブ・バンド) かによって区別されています。

6.1. イン・バンド

ある形式のセキュリティ トークン (または一部の証明) をもう一方の当事者と交換するために、メッセージの流れの一部として、セキュリティ トークン サービスで要求を行うことがあります。要求者または要求者の代理で別の当事者が、交換要求を行うことができます。セキュリティ トークン サービスが提供されたセキュリティ トークンを信頼 (たとえば、提供されたセキュリティ トークンの発行機関を信頼するなどの理由により) し、要求がそのセキュリティ トークンの所有を証明できる場合は、セキュリティ トークン サービスが交換を処理します。これは、イン・バンド直接信頼関係の一例です。委任された要求 (要求者が要求を提示するのではなく、要求者の代理で別の当事者が要求を提供すること) の場合、新しいトークンを生成するセキュリティ トークン サービスは、新しいセキュリティ トークンの交換に参加するセキュリティ トークン サービスを信頼するので、元のトークンを発行した機関を信頼しなくてもかまいません。信頼の基礎は、2 つのセキュリティ トークン サービス間の関係になります。

この交換を行うために、(上記で説明したように) 要求しているセキュリティ トークンと返されるセキュリティ トークンの RequestSecurityToken 要素と RequestSecurityTokenResponse 要素を使用します。

6.2. アウト・オブ・バンド

管理者またはその他の信頼済みの機関は、特定の種類のすべてのトークンを信頼することを指示できます。セキュリティ トークン サービスは、これを信頼原理として管理し、独自の信頼の決定 (または後での拒否) を行うために、これを信頼エンジンと通信できます。または、セキュリティ トークン サービスは、この機能をサービスとして、信頼しているサービスに提供できます。

7. パスワード ベースの鍵の派生

一部の事例では、WS-Security で記述しているように、認証はユーザー名とパスワードに基づきます。セキュリティで保護されたトランスポートを使用していない場合は、パスワードをクリア テキストで転送してはならない (MUST NOT)。代わりに、パスワードを共有秘密情報として使用することが推奨される (RECOMMEDED)。この共有秘密情報から鍵が派生され、ダイジェストの "署名" に使用されるので、その結果ユーザー名トークンの所有権が証明されます。

複数の鍵派生アルゴリズムを使用できます。そのため、<UsernameToken> 要素で指定できる wsse:Algorithm 属性を定義します。この QName 属性が使用するアルゴリズムを指定します。

本仕様では、初期アルゴリズム wsse:PWDPSHA1 を定義し、アルゴリズムを指定しなかった場合の既定のアルゴリズムとして使用します。

wsse:PWDPSHA1 を使用して署名する鍵を計算するには、RFC 2246 で TLS 用に定義したメカニズムのサブセットを使用しなければならない (MUST)。特に、セキュリティ鍵の生成に使用できるバイト列を生成するために、P_SHA-1 関数を使用します。

secret はパスワード、label はクライアント ラベル (オプションでポリシーで指定します)、シード値はクライアントが指定する "ノンス" 値です (<Nonce> 要素は必須です)。使用する <Username> 要素でこのような要素が指定されている場合、指定されなかった値は <Security> 要素からの値が使用されます。<UsernameToken> 要素で <wsu:Created> 時刻要素が指定されている場合は、この要素も使用されます。 このメッセージが他の当事者との共有コンテキストの一部である場合は、ラベルはクライアントのラベルとサーバーのラベルが連結されたものになり、シード値はクライアントのノンスとサーバーのノンスが連結されたものになります。ノンスはバイナリ オクテット ストリームとして処理され、タイムスタンプは UTF-8 符号化された文字列として処理されます。

  P_SHA1 (password, label + nonce + timestamp)

ここでは、両当事者が P_SHA-1 関数を使用して、必要に応じて共有鍵を生成できます。

受信者が公開鍵を所持する場合は、受信者が特定の種類の攻撃を防ぐために、署名の <ds:SignatureValue> 要素を暗号化する必要がある (SHOULD)。

サービスは、サービスのポリシー内でパスワードから鍵を派生する方法を指定してもよい (MAY)。

8. エラー処理

セキュリティ情報を処理中に "エラー" が発生する状況は数多くあります。エラーは SOAP Fault メカニズムを使用します。

発生するエラー Faultcode
要求が無効か、形式が間違っています。 wsse:InvalidRequest
認証に失敗しました。 wsse:FailedAuthentication
指定した要求に失敗しました。 wsse:RequestFailed
セキュリティ トークンが拒否されました。 wsse:InvalidSecurityToken
ダイジェスト要素が不足しています。 wsse:AuthenticationBadElements
指定された RequestSecurityToken を理解できません。 wsse:BadRequest
要求データが最新ではありません。 wsse:ExpiredData
要求した時刻範囲が無効またはサポートされていません。 wsse:InvalidTimeRange

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

以下の署名に関する声明は、セキュリティで保護されていないチャネルで送信されるメッセージに適用されます。

セキュリティが重要なすべてのメッセージ要素を、メッセージ署名のスコープに含めなければならない (MUST) ことが重要です。同様に、対話認証の署名には、WS-Security およびその補遺に記述されているように、リプレイ防止に必要な程度に応じて、タイムスタンプ、ノンス、またはシーケンス番号を含めなければならない (MUST)。また、対話の確立には、サポートするアルゴリズムやアルゴリズムの優先順位を検証できるように、ポリシーを含める必要がある (SHOULD)。

改ざんを防止するために、セキュリティ トークン発行メッセージには署名する必要がある (REQUIRED)。公開鍵が提供される場合は、所有権を証明するために、対応する秘密鍵で要求に署名する必要がある (SHOULD)。同様に、リプレイ攻撃を除去するために、付加手順を実行する必要があります (詳細については、WS-Security とその補遺を参照してください)。同様に、あらゆる改ざんを防止するために、すべてのトークン参照に署名する必要がある (SHOULD)。

セキュリティ トークンは、サービス拒否攻撃を受けやすい性質があります。そのため、このような攻撃を軽減することをサービスが保証するように注意する必要があります。

セキュリティのためには、対称鍵やパスワードを保持するトークンは、その鍵やパスワードを認識する必要のある当事者のみに送信される必要があります。

プライバシーのために、(申告内、または現在誰と誰が通信しているかを間接的に識別することによって) 個人情報を保持するトークンは、それぞれの組織でこのようなデータを管理するプライバシー ポリシーに従ってのみ送信する必要があります。

10. 謝辞

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

Bob Blakley (IBM)
John Brezak (Microsoft)
Tony Cowan (IBM)
羽田 知史 (IBM)
Heather Hinton (IBM)
Slava Kavsan (RSA Security)
Scott Konersmann (Microsoft)
John Linn (RSA Security)
Paul Leach (Microsoft)
Keith Stobie (Microsoft)
Richard Ward (Microsoft)

11. 参考文献

付録 I – WSDL

以下の WSDL は可能性のあるすべてのメッセージ交換パターンを完全に捕捉しているわけではありませんが、本書で説明した代表的なメッセージ交換パターンを捕捉しています。

<?xml version="1.0"?>
<wsdl:definitions 
    targetNamespace="https://schemas.xmlsoap.org/ws/2002/12/secext" 
    xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/12/secext" 
    xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<!-- これはスキーマをインポートする WS-I BP 準拠の方法です -->
   <wsdl:types>
       <xs:schema>
           <xs:import 
                 namespace="https://schemas.xmlsoap.org/ws/2002/12/secext" 
                 schemaLocation="secext.xsd"/>
       </xs:schema>
   </wsdl:types>
   
<!-- WS-Trust は 2 つの GED を正確に定義します。それらの GED をここに記述します -->
   <wsdl:message name="RequestSecurityTokenMsg">
         <wsdl:part name="request" element="wsse:RequestSecurityToken" />
   </wsdl:message>
   <wsdl:message name="RequestSecurityTokenResponseMsg">
         <wsdl:part name="response" 
                    element="wsse:RequestSecurityTokenResponse" />
   </wsdl:message>
   
<!-- この portType は完全な要求/応答セキュリティ トークン サービスをモデル化します : -->   
        
        <wsdl:portType name="WSSecurityRequester">
           <wsdl:operation name="SecurityTokenResponse">
              <wsdl:input 
                        message="wsse:RequestSecurityTokenResponseMsg"/>
           </wsdl:operation>
           <wsdl:operation name="Challenge">
              <wsdl:input 
                        message="wsse:RequestSecurityTokenResponseMsg"/>
              <wsdl:output 
                        message="wsse:RequestSecurityTokenResponseMsg"/>
           </wsdl:operation>
        </wsdl:portType>
   
<!-- これらの portTypes は個別のメッセージ交換をモデル化します -->   
   
   <wsdl:portType name="SecurityTokenRequestService">
           <wsdl:operation name="RequestSecurityToken">
              <wsdl:input message="wsse:RequestSecurityTokenMsg"/>
           </wsdl:operation>
        </wsdl:portType>

        <wsdl:portType name="SecurityTokenService">
           <wsdl:operation name="RequestSecurityToken">
              <wsdl:input message="wsse:RequestSecurityTokenMsg"/>
              <wsdl:output 
                        message="wsse:RequestSecurityTokenResponseMsg"/>
           </wsdl:operation>
        </wsdl:portType>
</wsdl:definitions>