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