WebSphere Application Server - Express, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

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

メッセージ層認証

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

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

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

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

このプロパティーによって使用すべき認証メカニズムが分かりますが、 その一方で、メッセージ層を介して認証を実行するかどうか、すなわち、 BasicAuth またはトークン・ベースのクレデンシャルを取得するかどうかを指定する必要もあります。 このタスクを完了するためには、 com.ibm.CSI.performClientAuthenticationRequired プロパティー (True または False) および com.ibm.CSI.performClientAuthenticationSupported (True または False) プロパティーを指定します。クライアント認証が必須だということは、 あらゆる要求に対してクライアント認証を実行しなければならないということです。 認証メカニズムがサポートされているということは、認証メカニズムを実 行することもできるが必須ではないということです。 リソースが保護されていない一部のサーバーでは、このオプションが適しています。 ほとんどの場合、このメカニズムがサポートされていれば、クライアント とサーバーの両方がこれをサポートしている場合にクライアント認証が実行 されるので、最良の方法です。 クライアント認証は、セキュリティーを必要としない特定のサーバーとの通信時には実行されませんが、 その場合でも、メソッド要求は正常に行われます。

認証再試行の構成

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

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



関連概念
EJB セキュリティーの認証プロトコル
関連タスク
通信の保護
参照トピック    

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

最終更新: Jan 21, 2008 11:31:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_csiv2mes.html