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

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

ダウンストリーム・サーバーに対する ID アサーション

クライアントがサーバーに対して認証を行う場合、受信済みクレデンシャルが設定されます。 許可エンジンがクレデンシャルを検査してアクセスが許可されているかどうかを 判別する場合、呼び出し クレデンシャルも設定されます。ID アサーション は、ダウンストリーム・サーバーに対して表明される呼び出しクレデンシャルです。

クライアントがサーバーに対して認証を行う場合、受信済みクレデンシャルが設定されます。 許可エンジンがクレデンシャルを検査してアクセスが許可されているかどうかを判 別する場合、呼び出しクレデンシャルも設定され、Enterprise JavaBeans (EJB) メソッドが他のサーバー上にある別の EJB メソッドを呼び出す場合に、 呼び出しクレデンシャルがダウンストリーム・メソッドの呼び出しに使用される識別であることがあります。 呼び出しクレデンシャルは、エンタープライズ Bean の RunAs モードによって、クライアント識別、 サーバーの識別、または指定するそれ以外の識別を作成するように設定されます。 設定された ID に関係なく、ID アサーションが使用可能なとき、それが、ダウンストリーム・サーバーに対して表明される呼び出しクレデンシャルです。

呼び出しクレデンシャルの識別は、識別トークン内のダウンストリーム・サーバーに送信されます。 さらに、パスワードまたはトークンを含む 送信サーバーの識別は、基本認証が使用可能な場合に、クライアント認証トークンで送信されます。 送信サーバーの識別は、クライアント証明書の認証が使用可能になっている場合、Secure Sockets Layer (SSL) のクライアント 証明書の認証を介して送信されます。 基本認証は、クライアント証明書認証に優先します。

受信サーバーが、表明された識別を受け入れるには、 この両方の識別トークンが必要です。受信サーバーは、表明された識別を受け入れるために以下のアクションを実行します。
  • サーバーは、基本認証トークンまたは SSL クライアント証明書を使用して送信される送信サーバーの識別が、 受信サーバーのトラステッド・プリンシパル・リストにあるかどうかを判別します。 サーバーは、送信サーバーが受信サーバーに識別トークンを送信できるかどうかを判断します。
  • 送信サーバーがトラステッド・リストにあることが認識されると、 サーバーはその送信サーバーを認証して、それが確かに送信サーバーであることを確認します。
  • サーバーの認証は、送信サーバーからのユーザー ID およびパスワードを、 受信サーバーのユーザー ID およびパスワードと比較する方法で行われます。 送信サーバーのクレデンシャルが認証され、トラステッド・プリンシパル・リストにある場合は、 サーバーは識別トークンの評価に移ります。
識別トークンの評価は、識別トークンに存在する次の 4 つの ID 形式で構成されます。
  • プリンシパル名
  • 識別名
  • 証明書チェーン
  • 匿名 ID
認証情報を受信する製品サーバーは、通常、これらの 4 つの識別タイプをすべてサポートしています。 送信サーバーは、元のクライアントが認証された方法に基づいて、どのタイプの識別を選択するかを決定します。その時点でのタイプは、 クライアントが最初に送信サーバーに対して認証を行う方法によって決まります。 例えば、クライアントが Secure Sockets Layer (SSL) クライアント認証を使用して送信サーバーに対する認証を行っている場合には、ダウンストリーム・サーバーに送信される識別トークンには、証明書チェーンが含まれます。 この情報によって、受信サーバーは独自の証明書チェーンをマッピングで き、他のベンダーおよびプラットフォームとのインターオペラビリティーが向上します。

識別形式の確認と解析が終わると、識別はクレデンシャルにマップされます。 ITTPrincipal 識別トークンの場合、 この識別がユーザー ID フィールドと 1 対 1 でマップされます。

ITTDistinguishedName 識別トークンの場合、マッピングはユーザー・レジストリーごとに異なります。 Lightweight Directory Access Protocol (LDAP) の場合、 構成済み検索フィルターにより、マッピング方法が決定されます。LocalOS の場合、 識別名 (DN) の最初の属性 (通常は共通名と同じ) が、レジストリーのユーザー ID にマップされます。

ITTCertChain 識別トークンの場合、LDAP ユーザー・レジストリーに対す るこの処理の方法についての詳細は、ユーザーへの証明書のマッピングのセクションを参照してください。 LocalOS の場合、証明書の DN の最初の属性は、レジストリーのユーザー ID にマップするために使用されます。

一部のユーザー・レジストリー・メソッドは、 許可によって使用される追加のクレデンシャル情報を収集するために呼び出されます。 ステートフル・サーバーでは、このアクションは、 同じ識別トークンを持つ送信サーバーと受信サーバーのペアに対して一度だけ実行されます。 それ以後の要求は、セッション ID 経由で行われます。

ID アサーションは、Common Secure Interoperability バージョン 2 (CSIv2) プロトコルを使用した場合にのみ使用可能です。




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

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

最終更新: Jan 22, 2008 12:07:38 AM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rsec_csiv2ida.html