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

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

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

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

受信サーバーが、表明された識別を受け入れるには、 この両方の識別トークンが必要です。受信サーバーは、表明された識別を受け入れるために以下のアクションを実行します。
  • 受信サーバーに送信される送信サーバーの ID は、GSSUP トークン(ユーザー ID とパスワード) または SSL クライアント証明書のいずれかです。 z/OS® では、アクティブ・ユーザー・レジストリーがローカル OS で、SAF 許可が使用可能の場合に、MVS™ が開始したタスクの ID が GSSUP トークンの代わりに送信されます。
  • 送信されている ID に応じて、送信サーバーと受信サーバーの間で信頼が確立されます。
    1. GGSUP トークンが送信される場合、送信サーバー ID が受信サーバーのトラステッド・プリンシパル・リストにあることを検証することによって、信頼が確立されます。
    2. MVS 開始タスク ID が送信される場合、この ID が SAF データベースの CB.BIND <servername> プロファイルに対して UPDATE 権限を持っていることを検証することで、信頼が確立されます。
    3. SSL クライアント証明書が送信される場合、z/OS でこの証明書は、Service Access Facility (SAF) ユーザー ID にマップされます。このユーザー ID が CB.BIND.<servername> プロファイルに対して UPDATE 権限を持っていることを検証することで、信頼が確立されます。
  • 送信サーバーがトラステッド・リストにあることが認識されると、 サーバーはその送信サーバーを認証して、それが確かに送信サーバーであることを確認します。
  • サーバーの認証は、送信サーバーからのユーザー ID およびパスワードを、 受信サーバーのユーザー ID およびパスワードと比較する方法で行われます。 送信サーバーのクレデンシャルが認証されて信頼される場合、 サーバーは識別トークンの評価に移ります。
  • 受信サーバーは、定義済みユーザー・レジストリーを検査して、表明されたユーザー ID が存在するかどうかを調べ、追加のクレデンシャルを、許可の目的 (グループ・メンバーシップなど) のために収集します。そのため、受信サーバーのユーザー・レジストリーには、表明されたすべてのユーザー ID が含まれている必要があります。 そうでなければ、ID アサーションを行うことはできません。 ステートフル・サーバーでは、このアクションは、同じ識別トークンを持つ送信サーバーと受信サーバーのペアに対して一度だけ実行されます。 それ以後の要求は、セッション ID 経由で行われます。
    注: ダウンストリーム・サーバーに、表明されたユーザー ID にそのリポジトリー内でアクセスできるユーザー・レジストリーがない場合は、ID アサーションを使用しないでください。これは、許可検査が失敗するためです。 ID アサーションを使用不可にすると、受信サーバーでの許可検査が不要となります。

[z/OS]ターゲット・サーバーは送信サーバーの権限を検証し、 クライアント証明書によって識別を表明します。クライアント証明書は、SAF データベースに定義された RACDCERT MAP フィルターまたは RACMAP フィルターのいずれかを使用して、Service Access Facility (SAF) ユーザー ID にマップされます。SAF ユーザー ID には、CBIND クラスの CB.BIND.<optionSAFProfilePrefix>.cluster_short_name プロファイルに対する UPDATE 権限が必要です。 クライアント証明書が送信されない場合、送信側サーバーの開始済みタスク ID に対して CBIND 検査が実行されます。

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

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

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

[z/OS]ITTDistinguishedName 識別トーク ンおよび ITTCertChain 識別トークンも同様にマップされます。 どちらのタイプの識別トークンも、RACDCERT (または同等の) マッピング 機能 (RACMAP フィルターなど) を使用して SAF ユーザー ID にマップされた証明書を使用します。 マッピングは、 対象名または発行者名を基にすることができます。

[AIX Solaris HP-UX Linux Windows][IBM i]ID アサーションは、Common Secure Interoperability バージョン 2 (CSIv2) プロトコルを使用した場合にのみ使用可能です。

注: ダウンストリームへの KRB トークンと一緒に ID アサーションを使用する場合は、制限があります。Kerberos が有効になっている ID アサーションを使用すると、ダウンストリーム・サーバーに移動するときに ID アサーションは Kerberos 認証トークン (KRBAuthnToken) を持ちません。その代わりに ID アサーションは、認証に LTPA を使用します。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_csiv2ida
ファイル名:csec_csiv2ida.html