このページを使用して、リソースへアクセスしているクライアントに対してサーバーがサポートするフィーチャーを指定します。
common secure interoperability (CSI) インバウンド認証設定は、着信要求またはトランスポートに含まれる認証情報のタイプを構成するために使用します。
基本認証がメッセージ層で発生することを指定します。
メッセージ層で基本認証が発生します。通常、このタイプの認証では、認証のためにユーザー ID とパスワードがクライアントから サーバーへ送信されます。
この認証には、クレデンシャル・タイプが転送可能である場合 (例えば、Lightweight Third Party Authentication (LTPA)) に、既に認証されたクレデンシャルからのクレデンシャル・トークンの代行も含まれます。
「基本認証」をクリックし、LTPA が構成済みの認証プロトコルである場合、 ユーザー名、パスワード、および LTPA トークンが受け入れられます。
基本認証とクライアント証明書認証の両方が実行された場合は、 基本認証がクライアント証明書認証に優先します。
メソッド要求時のクライアント/サーバー間の最初の接続時に、認証が行われることを指定します。
トランスポート層では、Secure Sockets Layer (SSL) クライアント証明書認証が行なわれます。メッセージ層では、 基本認証 (ユーザー ID とパスワード) が行われます。 クライアント証明書認証は通常、メッセージ層認証よりも優れていますが、 追加のセットアップがいくつか必要になります。 これらの追加ステップでは、サーバーが接続先の各クライアントの署名者証明書を信頼していることについての確認が行われます。 クライアントが認証局 (CA) を使用して個人証明書を作成した場合、 必要なのは、SSL トラスト・ファイルのサーバーの署名者セクション内の CA のルート証明書のみです。
証明書をローカル OS ユーザー・レジストリーに対して認証する場合、 その証明書はレジストリー内のユーザー ID にマップされます。
サーバーに他の認証層が提示されない場合にだけ、クライアント証明書の識別情報が使用されます。
このオプションを選択して、ID アサーションが、 ダウンストリーム Enterprise JavaBeans (EJB) 呼び出しの間に、 あるサーバーから別のサーバーへ ID を表明する方法であることを指定します。
このサーバーは、その上流サーバーを信頼しているので、主張された ID を 再度認証することはありません。ID アサーションは、他のすべてのタイプの認証に優先します。
ID アサーションは、属性層で実行され、サーバーでのみ適用されます。 サーバーで決定されるプリンシパルは、優先順位のルールに基づきます。 ID アサーションが実行されると、識別は常にこの属性層から派生します。 基本認証が ID アサーションを伴わずに行われると、 識別は常にメッセージ層から派生します。 最後に、SSL クライアント証明書認証を基本認証や ID アサーションなしで実行する場合、識別はトランスポート層から派生します。
表明される ID は、エンタープライズ Bean の RunAs モードで決定される呼び出しクレデンシャルです。 RunAs モードが「クライアント」の場合、この識別はクライアント識別です。 RunAs モードが「System」の場合、この識別はサーバー識別です。 RunAs モードが「指定」である場合、この識別は指定された識別です。 受信サーバーは、識別トークン内の識別を受信するとともに、 クライアント認証トークン内の送信サーバー識別も受信します。 受信サーバーは、「Trusted Server ID」エントリーのボックスを使用して、送信サーバー識別が信用できる識別であることを検証します。パイプ (|) で区切ったプリンシパル名のリスト (serverid1|serverid2|serverid3 など) を入力します。
すべての識別トークンのタイプは、アクティブ・ユーザー・レジストリーのユーザー ID フィールドにマップされます。 ITTPrincipal 識別トークンの場合、 このトークンがユーザー ID フィールドと 1 対 1 でマップされます。 ITTDistinguishedName 識別トークンの場合、 最初の等号の値が、ユーザー ID フィールドにマップされます。 ITTCertChain 識別トークンの場合、識別名における 最初の等号の値が、ユーザー ID フィールドにマップされます。
LDAP ユーザー・レジストリーに対して認証する場合、LDAP フィルターは ITTCertChain と ITTDistinguishedName の識別タイプのレジストリーへのマップ方法を決定します。トークン・タイプが ITTPrincipal の場合、 プリンシパルは LDAP レジストリーの UID フィールドにマップされます。
データ型: | ストリング |
セミコロン (;) またはコンマ (,) で区切られたトラステッド・サーバー ID のリストを指定します。 この ID は、このサーバーに対する ID アサーションの実行に関して信頼されています。 例えば、serverid1;serverid2;serverid3 や serverid1,serverid2,serverid3 です。
このリストを使用して、サーバーが信頼できるか否かを判断します。受信サーバーが送信サーバーの識別トークンを受け入れるには、送信サーバーがリストに載っている場合でも、受信サーバーで送信サーバーを認証する必要があります。
データ型 | ストリング |
このオプションを選択して、主にパフォーマンス向上のために使用されるステートフル・セッションを使用可能にします。
クライアントとサーバーが最初に接続するときには、認証を完全に実行する必要があります。 しかし、それ以後のすべての接続では、セッションが引き続き有効である間は、セキュリティー情報を再利用します。 クライアントはコンテキスト ID をサーバーに渡し、その ID を使用してセッションが検索されます。 コンテキスト ID の有効範囲は各接続であり、これにより一意性が保証されます。 認証の再試行が使用可能になっている場合 (デフォルトで) は、セキュリティー・セッションが無効になるごとに クライアント側のセキュリティー・インターセプターは、ユーザーにそれを認識させずにクライアント側のセッションを無効にし、 要求を再度実行依頼します。これは、セッションがサーバー上に存在しない (サーバーが失敗し、オペレーションを再開した) 場合に起こることがあります。 この値が使用不可の場合、すべてのメソッド起動を再認証する必要があります。
データ型 | ストリング |
インバウンド認証に使用するシステム・ログイン構成のタイプを指定します。
「セキュリティー」>「グローバル・セキュリティー」をクリックして、 カスタム・ログイン・モジュールを追加できます。「認証」の下で「JAAS 構成」>「システム・ログイン」をクリックします。
このオプションを選択して、ログイン要求時にセキュリティー属性の伝搬をサポートします。 このオプションを選択すると、アプリケーション・サーバーは、使用する認証強度などのログイン要求についての追加情報を保存し、要求発信元の識別およびロケーションを保存します。
認証メカニズムとして、Lightweight Third Party Authentication (LTPA) を使用している ことを確認します。セキュリティー属性伝搬フィーチャーを使用可能にする場合、サポートされる 認証メカニズムは LTPA だけです。
LTPA を構成するには、 「セキュリティー」>「グローバル・セキュリティー」をクリックします。「認証」の下の、 「認証メカニズム」>「LTPA」をクリックします。
このオプションを選択しない場合、アプリケーション・サーバーは、 ダウンストリーム・サーバーに伝搬する追加ログイン情報を受け入れません。