secure conversation の使用可能化
secure conversation を使用して、Web サービスのアプリケーション・メッセージをセキュアにします。
始める前に
Web サービスを含むアプリケーションは、デプロイ済みでなければなりません。
このタスクについて
Organization for the Advancement of Structured Information Standards (OASIS) Web Services Secure Conversation (WS-SecureConversation) ドラフト仕様には、SOAP メッセージの起動側と受信側の間でのセキュア・セッションを確立する方法が記述されています。 WS-SecureConversation ドラフト仕様には、セキュリティー・コンテキスト・トークン (SCT) を確立するための OASIS Web Services Trust (WS-Trust) プロトコルの使用法も定義されています。 詳細については、OASIS Web Services Secure Conversation 仕様書を参照してください。
WebSphere® Application Server では、WS-SecureConversation のためのセキュリティー・コンテキスト・トークンを発行するエンドポイントの機能をサポートしており、 それにより SOAP メッセージの起動側と受信側の間のセキュア・セッションを提供します。
次の図は、保護されたコンテキストの確立とセッション・ベース・セキュリティーの使用に必要なフローを表しています。

- クライアントが、その秘密鍵 (エントロピーおよびターゲット鍵サイズ)
で、セキュリティー・コンテキスト・トークンの RequestSecurityToken (RST)
トラスト要求をアプリケーション・エンドポイントに送信し、ターゲット・サービスの秘密鍵を要求します。
通常、この要求はブートストラップ・ポリシーで定義された、非対称の Web Services Security で保護されます。
- RST がトラスト・サービスにより処理されます。
セキュリティー・ポリシーを基にして要求が信頼された場合、
トラスト・サービスは、WS-Trust RequestSecurityTokenResponse
(RSTR) を使用することで、ターゲット・サービスの秘密鍵でセキュリティー・コンテキスト・トークンを戻します。
通常、この要求は非対称の Web Services Security で保護されます。クライアントは、ブートストラップ・ポリシーを基に RSTR が信頼できるかどうかを検証します。
- RequestSecurityTokenResponse が信頼された場合、クライアントはセッション鍵を使用することで、
以降のアプリケーション・メッセージを保護 (署名および暗号化) します。
これらのセッション鍵は、起動側と受信側の間で交換される初期の WS-Trust RequestSecurityToken メッセージと RequestSecurityTokenResponse メッセージから取得する、 セキュリティー・コンテキスト・トークンの秘密事項から派生します。
- 仕様で、初期の秘密事項を基に鍵を派生させる方法のアルゴリズムを定義します。 ターゲット Web サービスは、SOAP メッセージのセキュリティー・ヘッダーに含まれるメタデータと初期秘密事項から派生する鍵を計算します。
- ターゲット Web サービスは、派生した鍵を使用して、アプリケーション・セキュリティー・ポリシーを基にメッセージを検証し、暗号化解除します。
- ターゲット Web サービスは、秘密事項から派生した鍵を使用して、アプリケーション・セキュリティー・ポリシーを基に応答に署名し暗号化します。
- メッセージの交換が完了するまで、ステップ 3 から 6 までを繰り返します。
WS-SecureConversation 仕様では、セキュリティー・コンテキストは <wsc:SecurityContextToken> セキュリティー・トークンによって表されます。 以下の例は、 <wsc:SecurityContextToken> エレメントのアサーション構文を表しています。
<wsc:SecurityContextToken wsu:Id="..." ...>
<wsc:Identifier>...</wsc:Identifier>
<wsc:Instance>...</wsc:Instance>
...
</wsc:SecurityContextToken>
セキュリティー・コンテキスト・トークンは、鍵 ID や鍵の名前を使用した、そのセキュリティー・コンテキスト・トークンへの参照をサポートしていません。 すべての参照は、ID (wsu:Id 属性に対する)、または <wsc:Identifier> エレメントに対する <wsse:Reference> のいずれかを使用する必要があります。
WebSphere Application Server は、 これらの事前定義 secure conversation に関連したポリシーを提供します。
- SecureConveration ポリシー・セットは WS-SecureConversation 仕様と WS-Security 仕様に従い、アプリケーション・メッセージの署名および暗号化用のセキュリティー・コンテキスト・トークンから派生した鍵を使用して、secure conversation を有効にしたポリシー・セットを提供します。
- Username SecureConversation ポリシー・セットは、WS-SecureConversation 仕様と WS-Security 仕様に従い、Username トークンを使用して認証を追加します。
- LTPA SecureConversation ポリシーは、WS-SecureConversation 仕様と WS-Security 仕様に従い、Lightweight Third Party Authentication (LTPA) トークンを使用して認証を提供します。
この例では、secure conversation を使用可能にするというタスクを達成するために、デフォルトの SecureConversation ポリシー・セットと、デフォルトの WS-Security バインディングおよび TrustServiceSecurityDefault バインディングが使用されています。デフォルトの SecureConversation ポリシー・セットには、 アプリケーション・ポリシー (symmetricBinding) とブートストラップ・ポリシー (asymmetricBinding) の両方が含まれています。アプリケーション・ポリシーは、アプリケーション・メッセージをセキュアにするために使用され、 ブートストラップ・ポリシーは RequestSecurityToken (RST) メッセージをセキュアにするために使用されます。
セキュリティー・コンテキスト・トークンを発行するトラスト・サービスは、 TrustServiceSecurityDefault システム・ポリシーと TrustServiceSecurityDefault バインディングを使用して構成されます。トラスト・ポリシーは、RequestSecurityTokenResponse (RSTR) メッセージをセキュアにすることを担います。ブートストラップ・ポリシーを変更した場合、トラスト・ポリシーは構成の両方に一致するように変更しなければなりません。
ここで使用する Web Services Security (WS-Security) のデフォルト・バインディングには、 サンプルの鍵ファイルが含まれており、実働で使用する前にカスタマイズする必要があります。 実稼働環境では、カスタム・バインディングを使用することをお勧めします。 また、「開発テンプレートを使用するサーバーの作成」選択項目を使用してプロファイルを作成する場合は、ステップ 2 および 3 をスキップできることにも注意してください。
secure conversation を構成し、ポリシー・セットを構成し、さらにポリシー・アサーションをポリシーに追加するには、以下のステップを実行します。
手順
タスクの結果
次のタスク
次に、セキュリティー・コンテキスト・トークンを確立して secure conversation を保護する方法についてのサンプル・シナリオを検討します。