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

このページを使用して、リソースへアクセスしているクライアントに対してサーバーがサポートするフィーチャーを指定します。

この管理コンソール・ページを表示するには、以下のステップを実行します。
  1. 「セキュリティー」>「グローバル・セキュリティー」とクリックします。
  2. 「認証」において、「RMI/IIOP セキュリティー」>「CSIv2 インバウンド通信」とクリックします。

common secure interoperability (CSI) インバウンド通信設定は、着信要求またはトランスポートに含まれる認証情報のタイプを構成するために使用します。

認証フィーチャーには、以下のような 3 つの認証の層が含まれていますが、 それらは同時に使用することができます。
セキュリティー属性の伝搬

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

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

デフォルト: 使用可能
重要: レプリケーション・サービスを使用する場合には、必ず「セキュリティー属性の伝搬」オプションを使用可能にしてください。
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 のリストを指定します。 この ID は、このサーバーに対する ID アサーションの実行に関して信頼されています。 例えば、serverid1|serverid2|serverid3 です。アプリケーション・サーバーでは、後方互換性のために、リスト区切り文字としてコンマ (,) 文字をサポートしています。アプリケーション・サーバーは、 パイプ文字 (|) で有効なトラステッド・サーバー ID が見つからない場合に、コンマ文字をチェックします。

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

データ型: ストリング
クライアント証明書認証

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

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

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

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

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

常になし
クライアントが、 このサーバーで Secure Sockets Layer (SSL) クライアント証明書の認証を試行できないように指定します。
サポートされる
このサーバーに接続しているクライアントが、 SSL クライアント証明書を使用して認証できるように指定します。ただし、サーバーはこのような認証なしでメソッドを呼び出すことできます。例えば、 代わりに匿名認証または基本認証を使用することができます。
[z/OS] 注: サーバーの CSIv2 インバウンド認証に対して「サポートされる」が設定されている場合は、認証にクライアント証明書が使用されます。
必須
このサーバーに接続しているクライアントが、 メソッドを呼び出す前に、SSL クライアント証明書を使用して認証を行う必要があるように指定します。
トランスポート

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

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

注: セル内にバージョン 6.0.x ノードとそれ以前のノードの両方が存在しない限り、このオプションは z/OS® プラットフォームでは使用できません。
TCP/IP
TCP/IP」を選択すると、サーバーは TCP/IP リスナー・ポートだけを開くため、 すべてのインバウンド要求が SSL で保護されるとは限りません。
SSL 必須
SSL 必須」を選択すると、サーバーは SSL リスナー・ポートだけを開くため、 すべてのインバウンド要求が SSL を使用して受信されます。
SSL サポート
SSL サポート」を選択すると、サーバーは TCP/IP および SSL リスナー・ポートの両方を開き、 ほとんどのインバウンド要求が SSL を使用して受信されます。
以下のポートの固定ポート番号を提供します。ポート番号がゼロの場合は、実行時に動的に割り当てられます。[AIX Solaris HP-UX Linux Windows] [iSeries]

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

[z/OS]

ORB_SSL_LISTENER_ADDRESS

デフォルト: SSL サポート
範囲: TCP/IP、SSL 必須、SSL サポート
SSL 設定

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

[z/OS] 注: セル内にバージョン 6.0.x ノードとそれ以前のノードの両方が存在しない限り、このオプションは z/OS プラットフォームでは使用できません。
データ型: ストリング
[AIX Solaris HP-UX Linux Windows] [iSeries] デフォルト: DefaultSSLSettings
[z/OS] デフォルト: DefaultIIOPSSL
範囲: 「SSL 構成レパートリー」で構成された任意の SSL 設定
メッセージ層認証

メッセージ層認証で選択できるオプションは次のとおりです。
常になし
このサーバーでユーザー ID とパスワードによる認証を受け入れることができないように指定します。
サポートされる
このサーバーと通信するクライアントがユーザー ID とパスワードを指定できるように指定します。 ただし、 このような認証なしでメソッドを呼び出すこともできます。例えば、 代わりに匿名またはクライアント証明書を使用することができます。
必須
このサーバーと通信するクライアントが、 すべてのメソッド要求に対してユーザー ID とパスワードを指定する必要があるように指定します。
クライアントからサーバーへの認証を許可:

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

クライアントからサーバーへの認証で選択できるオプションは以下のとおりです。
Kerberos (KRB5)
Kerberos を認証メカニズムとして指定する場合に選択します。最初に Kerberos 認証メカニズムを構成する必要があります。詳しくは、管理コンソールを使用した認証メカニズムとしての Kerberos の構成を参照してください。
LTPA
LTPA トークン認証を指定する場合に選択します。
基本認証
基本認証は、Generic Security Services Username Password (GSSUP) です。 通常、このタイプの認証では、認証のためにユーザー ID とパスワードがクライアントから サーバーへ送信されます。

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

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

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

ログイン構成

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

セキュリティー」>「グローバル・ セキュリティー」をクリックして、 カスタム・ログイン・モジュールを追加できます。 「認証」において、「Java™ Authentication and Authorization Service」>「システム・ログイン」をクリックします。

ステートフル・セッション

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

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

デフォルト: 使用可能
トラステッド認証レルム - インバウンド (Trusted authentication realms - inbound)

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

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




マーク付きのリンク (オンライン) では、インターネットにアクセスする必要があります。

関連タスク
関連資料
Java Authentication and Authorization Service 用のシステム・ログイン構成エントリー設定
認証メカニズムおよび有効期限


ファイル名: usec_inbound.html