クライアントがサーバーに対して認証を行う場合、受信済みクレデンシャルが設定されます。 許可エンジンがクレデンシャルを検査してアクセスが許可されているかどうかを 判別する場合、呼び出し クレデンシャルも設定されます。ID アサーション は、ダウンストリーム・サーバーに対して表明される呼び出しクレデンシャルです。
クライアントがサーバーに対して認証を行う場合、受信済みクレデンシャルが設定されます。 許可エンジンがクレデンシャルを検査してアクセスが許可されているかどうかを判 別する場合、呼び出しクレデンシャルも設定され、Enterprise JavaBeans (EJB) メソッドが他のサーバー上にある別の EJB メソッドを呼び出す場合に、 呼び出しクレデンシャルがダウンストリーム・メソッドの呼び出しに使用される識別であることがあります。 呼び出しクレデンシャルは、エンタープライズ Bean の RunAs モードによって、クライアント識別、 サーバーの識別、または指定するそれ以外の識別を作成するように設定されます。 設定された ID に関係なく、ID アサーションが使用可能なとき、それが、ダウンストリーム・サーバーに対して表明される呼び出しクレデンシャルです。
呼び出しクレデンシャルの識別は、識別トークン内のダウンストリーム・サーバーに送信されます。
さらに、パスワードまたはトークンを含む
送信サーバーの識別は、基本認証が使用可能な場合に、クライアント認証トークンで送信されます。
送信サーバーの識別は、クライアント証明書の認証が使用可能になっている場合、Secure Sockets Layer (SSL) のクライアント
証明書の認証を介して送信されます。
基本認証は、クライアント証明書認証に優先します。
送信サーバーの識別は、SSL クライアント証明書を使用して送信されます。
SSL が使用されない場合、サーバー識別は送信されません。
ターゲット・サーバーは送信サーバーの権限を検証し、
クライアント証明書によって識別を表明します。クライアント証明書は、Service Access Facility (SAF)
ユーザー ID にマップされます。ユーザー ID には、CBIND.servername プロファイルの
更新権限がなければなりません。クライアント証明書が送信されない場合、
デフォルトのユーザー ID に対して CBIND 検査が実行されます。
識別形式の確認と解析が終わると、識別はクレデンシャルにマップされます。 ITTPrincipal 識別トークンの場合、 この識別がユーザー ID フィールドと 1 対 1 でマップされます。
ITTDistinguishedName 識別トークンの場合、マッピングはユーザー・レジストリーごとに異なります。
Lightweight Directory Access Protocol (LDAP) の場合、
構成済み検索フィルターにより、マッピング方法が決定されます。LocalOS の場合、
識別名 (DN) の最初の属性 (通常は共通名と同じ) が、レジストリーのユーザー ID にマップされます。
ITTDistinguishedName 識別トーク
ンおよび ITTCertChain 識別トークンも同様にマップされます。
どちらのタイプの識別トークンも、RACDCERT (または同等の) マッピング
機能を使用して SAF ユーザー ID にマップされた証明書を使用します。
マッピングは、
対象名または発行者名を基にすることができます。
一部のユーザー・レジストリー・メソッドは、 許可によって使用される追加のクレデンシャル情報を収集するために呼び出されます。 ステートフル・サーバーでは、このアクションは、 同じ識別トークンを持つ送信サーバーと受信サーバーのペアに対して一度だけ実行されます。 それ以後の要求は、セッション ID 経由で行われます。
ID アサーションは、Common Secure Interoperability バージョン 2
(CSIv2) プロトコルを使用した場合にのみ使用可能です。