WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

メッセージ層認証

クレデンシャル情報を定義し、 その情報を、受信サーバーが解釈できるようにネットワークを介して送信します。

トークンを使用してネットワーク上で認証情報を送信する場合は、データがサービス・コンテキスト内のメッセージと共に送信されるため、その伝送はメッセージ層認証と見なされます。

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 はありません

注: SWAM は WebSphere Application Server バージョン 6.1 では推奨されておらず、将来のリリースでは除去される予定です。
サーバー上では、認証メカニズムはトークンを解釈してクレデンシャルを作成することができます。 あるいは、クライアントからの基本認証データを認証してクレデンシャルを作成することもできます。 どちらの方法でも、作成されたクレデンシャルは受信した クレデンシャルであり、 許可検査で、ユーザーにそのメソッドを呼び出すアクセス権があるかどうかを判断する際に使用されます。 認証メカニズムは、クライアント・サイドで、 次のプロパティーを使用して指定することができます。 現時点では、基本認証が唯一の有効値です。 サーバーは、管理コンソールを介して構成することができます。
注:perform basic authentication」が使用可能になっているときに、クライアントが同様に構成されていない場合 (また、ユーザー ID やパスワードなどの信用証明情報を渡さない場合) は、サーバーの Object Request Broker (ORB) も構成されません。

認証再試行の構成

ユーザー ID およびパスワードを誤って入力してしまった場合にプロンプトを再表示させたい場合や、 特定のエラーがクライアントに戻されたときにメソッドを再試行したい場合があります。 エラーがクライアント・サイドの情報によって訂正できるようなものである場合は、 システムの構成が適切であれば、クライアントが失敗に気付かなくても、自動的に再試行が行われます。

この種のエラーには、以下のようなものがあります。
  • 有効ではないユーザー ID およびパスワードを入力している
  • サーバー上のクレデンシャルが期限切れになっている
  • サーバー上で Stateful Session が見つからない
デフォルトでは認証の再試行は使用可能になっており、クライアントにエラーを戻す前に 3 回再試行が実行されます。 プロパティー com.ibm.CORBA.authenticationRetryEnabled (True または False) を使用して認証の再試行を使用可能にしたり使用不可にします。 プロパティー com.ibm.CORBA.authenticationRetryCount を使用して、再試行の回数を指定します。

基本認証ログインの即時検証

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 に設定されています。サーバー・サイドでは、 セキュリティーの動的プロパティーでこのプロパティーを指定します。

注: z/OS サーバーに接続する場合は 必ず com.ibm.CORBA.validateBasicAuth=false と設定してください。この関数は、現在は、 分散クライアントから z/OS サーバーに対しては機能しません。これは、SecurityServer が「非認証」のプリンシパルを使用して配置されており、それが z/OS システムでは受け入れられないためです。



関連タスク
通信の保護
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/rsec_csiv2mes.html