スタックされた JAAS ログイン・モジュールを使用した UsernameToken コンシューマーの認証メソッドの置き換え
デフォルトでは、Web サービス・セキュリティーの UsernameToken コンシューマーの UNTConsumeLoginModule は、常に WebSphere レジストリーに対してトークン内に含まれているユーザー名とパスワードを検証します。GenericSecurityTokenFactory が提供する SPI を使用して、この認証方式をバイパスすることができます。
このタスクについて
UNTConsumeLoginModule が使用する認証方式を置き換える場合は、独自のカスタム JAAS ログイン・モジュールを指定して認証を行う必要があります。カスタム・ログイン・モジュールは、カスタム JAAS 構成の UNTConsumeLoginModule の下にスタックされます。 UNTConsumeLoginModule は、トークン XML を使用して検証します。ユーザー名とパスワードに指定した値の検証は、カスタムでスタックされたログイン・モジュールに据え置かれます。
UNTConsumeLoginModule を使用すると、ユーザー名とパスワードを認証するという前提があるため、動的トークンの機能を提供することのみが想定されているログイン・モジュールに対してより、この機能の実行のみが目的のスタックされたログイン・モジュールに対して、より多くの要件が設定されます。
ユーザー名とパスワードを認証しないよう UNTConsumeLoginModule に指示するには、構成されたコールバック・ハンドラーに以下のプロパティーを設定する必要があります。
com.ibm.wsspi.wssecurity.token.UsernameToken.authDeferred=true
ほとんどの WS-Security ログイン・モジュールと同様、UNTConsumeLoginModule は常に、スタック内のすべてのログイン・モジュールがアクセスできる共有状態のマップ内に、使用されるトークンを配置します。コミット・フェーズ中に authDeferred=true が指定されている場合、UNTConsumeLoginModule によって元々共有状態に置かれていた同じ UsernameToken オブジェクトが、共有状態の別のロケーションに置かれます。この UsernameToken オブジェクトが見つからない場合には、LoginException が発生します。このため、付属するログイン・モジュールがトークンを共有状態に返さずに、コールバック・ハンドラーで authDeferred=true を設定することはできません。