Common Secure Interoperability バージョン 2 インバウンド通信設定

ログイン要求時のセキュリティー属性を伝搬することを指定します。このオプションを選択すると、アプリケーション・サーバーは、使用する認証強度などのログイン要求についての追加情報を保存し、要求発信元の識別およびロケーションを保存します。

このオプションを選択しない場合、アプリケーション・サーバーは、 ダウンストリーム・サーバーに伝搬する追加ログイン情報を受け入れません。

ダウンストリーム Enterprise JavaBeans (EJB) の呼び出し時に、あるサーバーから別のサーバーへ ID を表明する方法として 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 フィールドにマップされます。

アクティブなユーザー・レジストリーがローカル OS ユーザー・レジストリーで、お使いの z/OS セキュリティー・バージョンが分散 ID マッピングをサポートする適切なレベルであり、さらに、WebSphere Application Server バージョン 8.0 より前のノードがない場合に、次のオプションが使用可能になります。

SAF 分散 ID マッピングを使用した証明書と識別名のマップ

このオプションを選択すると、RACMAP フィルターを使用して、表明された証明書および識別名を SAF ユーザー ID にマップします。

デフォルト値は未チェックです。チェックされた場合、セキュリティー・カスタム・プロパティー com.ibm.websphere.security.certdn.useRACMAPMappingToSAF に true が設定されます。

注: このオプションは、アクティブなユーザー・レジストリーがローカル OS で、 セルが混合バージョンでなく (WebSphere Application Server バージョン 8.0 より前のノードがない)、 z/OS セキュリティー製品が SAF ID マッピングをサポートする (RACF® の場合、これは z/OS バージョン 1.11 またはそれ以降を意味します) 場合にのみ表示されます。

注: ご使用の DN 名で、属性の間にブランク・スペースがある場合、 ブランクを正しく解析するために RACF APAR OA34258 または PTF UA59873 と、SAF APAR OA34259 または PTF UA59871 を 適用する必要があります。

送信サーバーから受信サーバーへ送信されるトラステッド ID を指定します。

パイプ (|) で区切られたトラステッド・サーバーの管理者ユーザー ID のリストを指定します。 この ID は、このサーバーに対する ID アサーションの実行に関して信頼されています。 例えば、serverid1|serverid2|serverid3 です。アプリケーション・サーバーでは、後方互換性のために、リスト区切り文字としてコンマ (,) 文字をサポートしています。アプリケーション・サーバーは、 パイプ文字 (|) で有効なトラステッド・サーバー ID が見つからない場合に、コンマ文字をチェックします。

このリストを使用して、サーバーが信頼できるか否かを判断します。受信サーバーが送信サーバーの識別トークンを受け入れるには、送信サーバーがリストに載っている場合でも、受信サーバーで送信サーバーを認証する必要があります。

メソッド要求時のクライアント/サーバー間の最初の接続時に、認証が行われることを指定します。

トランスポート層では、Secure Sockets Layer (SSL) クライアント証明書認証が行なわれます。メッセージ層では、 基本認証 (ユーザー ID とパスワード) が使用されます。 クライアント証明書認証は通常、メッセージ層認証よりも優れていますが、 追加のセットアップがいくつか必要になります。 これらの追加ステップでは、サーバーが接続先の各クライアントの署名者証明書を信頼していることについての確認が行われます。 クライアントが認証局 (CA) を使用して個人証明書を作成した場合、 必要なのは、SSL トラスト・ファイルのサーバーの署名者セクション内の CA のルート証明書のみです。

証明書を Lightweight Directory Access Protocol (LDAP) ユーザー・レジストリーに対して認証する場合、 識別名 (DN) は LDAP の構成時に指定したフィルターに基づいてマップされます。証明書をローカル OS ユーザー・レジストリーに 対して認証する場合、証明所内の識別名 (DN) の最初の属性 (通常は共通名) が レジストリー内のユーザー ID にマップされます。

証明書をローカル OS ユーザー・レジストリーに対して認証する場合、 その証明書はレジストリー内のユーザー ID にマップされます。

サーバーに他の認証層が提示されない場合にだけ、クライアント証明書の識別情報が使用されます。

アクティブなユーザー・レジストリーがローカル OS ユーザー・レジストリーで、お使いの z/OS セキュリティー・バージョンが分散 ID マッピングをサポートする適切なレベルであり、さらに、WebSphere Application Server バージョン 8.0 より前のノードがない場合に、次のオプションが使用可能になります。

SAF 分散 ID マッピングを使用して証明書をマップする

このオプションを選択すると、RACMAP フィルターを使用して、CSIv2 トランスポート層で受信した証明書を SAF ユーザー ID にマップします。

デフォルト値は未チェックです。チェックされた場合、セキュリティー・カスタム・プロパティー com.ibm.websphere.security.certificate.useRACMAPMappingToSAF に true が設定されます。

注: このオプションは、アクティブなユーザー・レジストリーがローカル OS で、 セルが混合バージョンでなく (WebSphere Application Server バージョン 8.0 より前のノードがない)、 z/OS セキュリティー製品が SAF ID マッピングをサポートする (RACF の場合、これは z/OS バージョン 1.11 またはそれ以降を意味します) 場合にのみ表示されます。

クライアントが、接続されているトランスポートの 1 つを使用して、 サーバーへの接続を処理するかどうかを指定します。

サーバーによってサポートされるインバウンド・トランスポートとして、Secure Sockets Layer (SSL) か TCP/IP のいずれか、またはその両方を 選択できます。「TCP/IP」を指定すると、サーバーは TCP/IP のみをサポートし、SSL 接続を受け入れること はできません。「SSL サポート」を指定すると、このサーバーは TCP/IP 接続または SSL 接続をサポートできます。 「SSL 必須」を指定すると、このサーバーと通信しているサーバーはすべて SSL を使用する必要があります。

以下のポートの固定ポート番号を提供します。ポート番号がゼロの場合は、実行時に動的に割り当てられます。

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

ORB_SSL_LISTENER_ADDRESS

インバウンド接続用に選択する事前定義された SSL 設定のリストを 指定します。

注: セル内にバージョン 6.1 ノードとそれ以前のノードの両方が存在しない限り、このオプションは z/OS プラットフォームでは使用できません。

通知	値
データ型:	ストリング
デフォルト:	DefaultSSLSettings
デフォルト:	DefaultIIOPSSL
範囲:	「SSL 構成レパートリー」で構成された任意の SSL 設定

Kerberos、LTPA、または基本認証を使用した、 クライアントからサーバーへの認証を指定します。

「基本認証 (Basic Authentication)」および「LTPA」を選択し、アクティブな認証メカニズムが LTPA である場合、ユーザー名、パスワード、および LTPA トークンが受け入れられます。

「基本認証 (Basic Authentication)」および「KRB5」を選択し、アクティブな認証メカニズムが KRB5 である場合、ユーザー名、パスワード、Kerberos トークン、および LTPA トークンが受け入れられます。

「基本認証 (Basic Authentication)」を選択しない場合、ユーザー名もパスワードも、 サーバーに受け入れられません。

インバウンド認証に使用するシステム・ログイン構成のタイプを指定します。

「セキュリティー」>「グローバル・ セキュリティー」とクリックして、 カスタム・ログイン・モジュールを追加できます。 「認証」から、 「Java 認証・承認サービス」>「システム・ログイン」をクリックします。

このオプションを選択して、主にパフォーマンス向上のために使用されるステートフル・セッションを使用可能にします。

クライアントとサーバーが最初に接続するときには、認証を完全に実行する必要があります。 しかし、それ以後のすべての接続では、セッションが引き続き有効である間は、セキュリティー情報を再利用します。 クライアントはコンテキスト ID をサーバーに渡し、その ID を使用してセッションが検索されます。 コンテキスト ID の有効範囲は各接続であり、これにより一意性が保証されます。 認証の再試行が使用可能になっている場合 (デフォルトで) は、セキュリティー・セッションが無効になるごとに クライアント側のセキュリティー・インターセプターは、ユーザーにそれを認識させずにクライアント側のセッションを無効にし、 要求を再度実行依頼します。この状態は、セッションがサーバー上に存在しない (例えば、サーバーで障害が発生した後、オペレーションが再開された) 場合に起こることがあります。この値が使用不可の場合、各メソッドの呼び出しを再認証する必要があります。

このリンクを選択して、レルムのインバウンドの信頼を確立します。 インバウンド認証レルム設定は、CSIv2 固有ではありません。セキュリティー・ドメインが複数ある場合、インバウンドの信頼をどのレルムに付与するかを構成することもできます。

インバウンド認証とは、インバウンド要求に対して受け入れられる認証タイプを決定する構成のことを指します。この認証は、クライアントがネーム・サーバーから取り出す相互運用オブジェクト参照 (IOR) で公示されます。