クレデンシャル情報を定義し、 その情報を、受信サーバーが解釈できるようにネットワークを介して送信します。
トークンを使用してネットワーク上で認証情報を送信する場合は、データがサービス・コンテキスト内のメッセージと共に送信されるため、その伝送はメッセージ層認証と見なされます。
Pure Java クライアントは、クライアントの識別を確立する認証メカニズムとして、基本認証である Generic Security Services Username Password (GSSUP) を使用します。
ただし、
サーブレットは基本認証 (GSSUP) またはサーバーの認証メカニズム (Lightweight Third Party Authentication (LTPA)) のどちらを使用しても、セキュリティー情報をメッセージ層で送信することができます。
LTPA は、サーバーのセキュリティー・メカニズムに対して基本認証のクレデンシャルを認証するか、
マップして使用します。
トークン・ベースのクレデンシャルに含まれるセキュリティー・トークンは、 認証メカニズム特有のものです。 トークンを解釈する方法は、認証メカニズムにしか知られていません。 したがって、個々の認証メカニズムには、それを表すオブジェクト ID (OID) があります。 OID およびクライアント・トークンはサーバーに送信され、それによってサーバーに、 トークンの読み取りおよび妥当性検査にどのメカニズムを使用すればよいかが分かります。 各メカニズムに対する OID のリストは次のとおりです。
BasicAuth (GSSUP): oid:2.23.130.1.1.1
LTPA: oid:1.3.18.0.2.30.2
SWAM: 転送ができないので OID はありません
BasicAuth (GSSUP): oid:2.23.130.1.1.1
SWAM: 転送ができないので OID はありません
ユーザー ID およびパスワードを誤って入力してしまった場合にプロンプトを再表示させたい場合や、 特定のエラーがクライアントに戻されたときにメソッドを再試行したい場合があります。 エラーがクライアント・サイドの情報によって訂正できるようなものである場合は、 システムの構成が適切であれば、クライアントが失敗に気付かなくても、自動的に再試行が行われます。
WebSphere Application Server バージョン 6.x では、 BasicAuth ログインの request_login 中に、 振る舞いが定義されます。 バージョン 5 より前のリリースでは、 BasicAuth ログインは、loginSource メソッドで入力されたユーザー ID とパスワードを受け取り、BasicAuth クレデンシャルを作成するようになっています。 ユーザー ID またはパスワードが無効の場合、クライアント・プログラムは最初のメソッド要求が試行されるまでは、検出を行いません。 ユーザー ID またはパスワードがプロンプトまたは プログラマチック・ログインで指定されると、デフォルトではセキュリティー・サーバーによってユーザー ID とパスワードの認証が行われ、結果として True または False が戻されます。False の場合 、org.omg.SecurityLevel2.LoginFailed 例外がクライアントに戻 され、ユーザー ID およびパスワードが無効であることが示されます。 True の場合は、BasicAuth クレデンシャルが request_login の呼び出し元に戻されます。 ピュア・クライアントでこのフィーチャーを無効にするには、 com.ibm.CORBA.validateBasicAuth=false を指定します。デフォルトで 、この機能は True に設定されています。サーバー・サイドでは、 セキュリティーの動的プロパティーでこのプロパティーを指定します。