Common Secure Interoperability バージョン 2 アウトバウンド通信の構成
「Common Secure Interoperability バージョン (CSIv2) アウトバウンド通信 (Common Secure Interoperability Version 2 (CSIv2) outbound communications)」パネルで構成する際に、以下の項目を選択できます。
始める前に
このタスクについて
手順
- 「ID アサーション」(属性層) を選択します。 これを選択すると、 このサーバーは、ダウンストリーム・サーバーが ID アサーションをサポートしていれば、ダウンストリーム・サーバーへ 識別トークンを発信します。発信元クライアントがこのサーバーに対して認証を行う場合、 提供された認証情報は、アウトバウンドの識別トークン内に保持されます。このサーバーに対して認証を行うクライアントが、クライアント証明書認証を使用した場合、その識別トークンのフォーマットは、 インバウンド・ソケットからの正確なクライアント証明書チェーンを含む証明書チェーンとなります。 同様のことが、認証の他のメカニズムに関しても言えます。 詳しくは、ID アサーションのトピックを 参照してください。
「ユーザー ID」および「パスワード」(メッセージ層) を選択します。 このタイプの認証は、最も一般的です。 ダウンストリーム・サーバーがインバウンド認証パネルでメッセージ層認証をサポートしている場合、 ユーザー ID とパスワード (BasicAuth クレデンシャルの場合) または認証済みトークン (認証済みクレデンシャルの場合) が、 ダウンストリーム・サーバーへアウトバウンド送信されます。 詳しくは、メッセージ層認証の項目を参照してください。
- 「SSL クライアント証明書認証」(トランスポート層) を選択します。 あるサーバーからダウンストリーム・サーバーへのアウトバウンド Secure Sockets Layer (SSL) クライアント認証を使用可能にする主な理由は、これらのサーバー間にトラステッド環境を作成することにあります。 クライアント・クレデンシャルを委任する場合は、上記の 2 つの層のどちらかを使用します。 ただし、自分のドメイン内のすべてのサーバー用に SSL 個人証明書を作成し、SSL トラストストア・ファイル内のこれらのサーバーのみを信頼する場合があります。 他のサーバーまたはクライアントは、このドメイン内のサーバーへ接続することが できなくなります (それらを必要とする層を除く)。 この処理により、サーブレット・サーバーを除くすべてのサーバーまたはクライアントは、エンタープライズ Bean サーバーにアクセスできなくなります。
例
通常、アウトバウンド認証構成は、アップストリーム・サーバーがダウンストリーム・サーバーと通信するためのものです。 ほとんどの場合、アップストリーム・サーバーはサーブレット・サーバーで、ダウンストリーム・サーバーは Enterprise JavaBeans (EJB) サーバーです。サーブレット・サーバーでは、サーブレットにアクセスするために行われるクライアント認証は、クライアント証明書および基本認証を含む、多くの異なるタイプの認証のうちの 1 つにすることができます。 基本認証データを受信すると、それがプロンプト・ログインまたはフォーム・ベースのログインのいずれを経由している場合であっても、 通常は基本認証情報が認証され、Lightweight Third Party Authentication (LTPA) などのサーバーがサポートするメカニズム・タイプの クレデンシャルが形成されます。 LTPA がそのメカニズムの場合は、転送可能トークンがクレデンシャル内に存在しています。 クライアント・クレデンシャルを伝搬させるには、メッセージ層 (BasicAuth) 認証を選択してください。 クレデンシャルが証明書ログインを使用して作成され、その証明書のダウンストリーム送信を保持する場合は、アウトバウンド ID アサーションを使用することができます。