WebSphere Application Server の Web サービス・セキュリティーの実装では、認証メソッドである BasicAuth、Lightweight Third Party Authentication (LTPA)、 デジタル・シグニチャー、および ID アサーションをサポートしています。
WebSphere Application Server を、 BasicAuth 認証メソッドを使用するように構成すると、送信側は、 Lightweight Third Party Authentication (LTPA) トークンを、 現行セキュリティー・コンテキストまたは基本認証データ構成からの BinarySecurityToken として、 SOAP メッセージ・ヘッダーのバインディング・ファイルに付加します。 Web サービス・セキュリティー・メッセージの受信側は、ユーザー名とパスワードを構成済みのユーザー・レジストリーに照らして検証することによって、送信側の認証を行います。 LTPA メソッドでは、送信側は、 以前に SOAP メッセージ・ヘッダーで受信した LTPA BinarySecurityToken を付加します。 受信側は、LTPA トークンとそのトークンの有効期限を検証して、送信側の認証を行います。 デジタル・シグニチャー認証メソッドでは、送信側は、X509 証明書の BinarySecurityToken を、 Web サービスのセキュリティー・メッセージ・ヘッダーに、メッセージ本文、タイム・スタンプ、 セキュリティー・トークン、あるいはこの 3 つを組み合わせたもののデジタル・シグニチャーとともに付加します。 受信側は、検査済み証明書の公開鍵を使用して X.509 証明書とデジタル・シグニチャーの妥当性を検証することによって、 送信側の認証を行います。
ID アサーション認証メソッドは、他の 3 つの認証メソッドとは異なります。 このメソッドは、信頼関係に基づいて、送信側のセキュリティー信任状を作成します。 例えば、仲介サーバーがクライアントに代わってダウンストリーム・サーバーからサービスを呼び出す場合には、 ID アサーション認証メソッドを使用することができますが、その場合、クライアントの認証情報は得られません。 仲介サーバーは、ダウンストリーム・サーバーとの信頼関係を確立してから、その同じダウンストリーム・サーバーに対してクライアントの識別を表明します。
BasicAuth トラスト・モードとデジタル・シグニチャー・トラスト・モードを使用する場合、 仲介サーバーは、それ自身の認証情報を、認証の際にダウンストリーム・サーバーに渡します。 推定トラスト・モードは、何らかの外部メカニズムを使用して信頼関係を確立します。 例えば、仲介サーバーは、ダウンストリーム・サーバーとの Secure Sockets Layers (SSL) 接続や、 トランスポート層クライアント証明書認証を介して、SOAP メッセージを渡す場合があります。
クライアント ID は、名前ストリング、識別名 (DN)、 X.509 証明書などで表されます。 クライアント ID は、ユーザー名だけが含まれる UsernameToken、DN、 あるいは証明書の BinarySecurityToken 内の、Web サービス・セキュリティー・メッセージに付加されます。 次の表は、各認証メソッドで必要なセキュリティー・トークンのタイプを要約したものです。
認証メソッド | セキュリティー・トークン |
---|---|
BasicAuth | BasicAuth は、 <wsse:Username> および <wsse:Password> と共に <wsse:UsernameToken> を必要とします。 |
Signature | Signature は、 <ds:Signature> および <wsse:BinarySecurityToken> を必要とします。 |
IDAssertion | IDAssertion は、
<wsse:Username>、
または、<idType> によっては、クライアント ID のための
X.509 証明書が組み込まれた
<wsse:BinarySecurityToken> と共に、
<wsse:UsernameToken> を必要とします。
このメソッドでは、
<trustMode> によっては、
以下のように他のセキュリティー・トークンも必要になります。
|
LTPA | LTPA は、LTPA トークンと共に <wsse:BinarySecurityToken> を必要とします。 |
<loginConfig xmi:id="LoginConfig_1052760331326"> <authMethods xmi:id="AuthMethod_1052760331326" text="BasicAuth"/> <authMethods xmi:id="AuthMethod_1052760331327" text="IDAssertion"/> <authMethods xmi:id="AuthMethod_1052760331336" text="Signature"/> <authMethods xmi:id="AuthMethod_1052760331337" text="LTPA"/> </loginConfig> <idAssertion xmi:id="IDAssertion_1052760331336" idType="Username" trustMode="Signature"/>
<loginConfig xmi:id="LoginConfig_1051555852697"> <authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/> </loginConfig> <idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
送信側のセキュリティー・ハンドラーは、javax.security.auth.callback.CallbackHandler インターフェースのインプリメンテーションの handle() メソッドを呼び出します。 javax.security.auth.callback.CallbackHandler インターフェースは、 セキュリティー・トークンを作成し、それを送信側のセキュリティー・ハンドラーに戻します。 送信側のセキュリティー・ハンドラーは、コールバック配列内の認証情報に基づいてセキュリティー・トークンを構成し、そのセキュリティー・トークンを、Web サービスのセキュリティー・メッセージ・ヘッダーに挿入します。
受信側のセキュリティー・ハンドラーは、メッセージ・ヘッダーのトークン・タイプを、 デプロイメント記述子で構成された予想されるトークン・タイプと比較します。 SOAP メッセージの Web サービス・セキュリティー・ヘッダーで、予想されるトークン・タイプがまったく検出されない場合は、SOAP 障害例外が出されて要求はリジェクトされます。 それ以外の場合は、そのトークン・タイプを使用して、 トークンを検証するための Java Authentication and Authorization Service (JAAS) ログイン構成にマップします。 認証に成功すると、JAAS サブジェクトが作成され、実行中のスレッドに関連付けられます。 認証に失敗した場合は、SOAP 障害例外が出されて、要求はリジェクトされます。