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

このページを使用して、サーバーが、別のダウンストリーム・サーバーに対してクライアントとして動作するときに サポートする機能を指定します。

この管理コンソール・ページを表示するには、以下のステップを実行します。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」において、「RMI/IIOP セキュリティー」>「CSIv2 アウトバウンド通信」をクリックします。
認証フィーチャーには、以下のような 3 つの認証の層が含まれていますが、 それらは同時に使用することができます。

「構成」タブ

セキュリティー属性の伝搬

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

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

デフォルト: 使用可能
ID アサーションの使用 [z/OS]

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 が使用されている場合、Lightweight Third Party Authentication (LTPA) トークン内のサーバー ID。
WebSphere® Application Server 以外のアプリケーション・サーバーとのインターオペラビリティーを確保するには、 以下のいずれかの方法を使用します。
  • レジストリー内でサーバー ID およびパスワードを構成します。
  • LTPA トークンではなく、相互運用が可能な Generic Security Services Username Password (GSSUP) トークンが送信されるように、「サーバー・トラステッド ID (Server-trusted identity)」オプションを選択して、トラステッド ID およびパスワードを指定します。
デフォルト: 使用不可
代替的トラステッド ID の指定

サーバー ID を送信する代わりにターゲット・サーバーに送信されるトラステッド ID として、代替ユーザーを指定します。

ID アサーションには、このオプションが推奨されます。 ID は、同じセル内で送信されて同じセル内のトラステッド ID リストに入れる必要がない場合には、自動的に信頼されます。ただし、この ID は 外部セルのターゲット・サーバーのレジストリーに入っている必要があり、 ユーザー ID はトラステッド ID リストに入っている必要があります。 そのようになっていない場合、ID はトラスト評価中に拒否されます。

デフォルト: 使用不可
Trusted identity

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

このフィールドで ID を指定すると、 構成済みユーザー・アカウント・リポジトリーのパネルで選択できます。ID を指定しない場合、 サーバー間で Lightweight Third Party Authentication (LTPA) トークンが送信されます。

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

[z/OS] セミコロン (;) またはコンマ (,) で区切られたトラステッド・サーバー ID のリストを指定します。 この ID は、このサーバーに対する ID アサーションの実行に関して信頼されています。 例えば、serverid1;serverid2;serverid3serverid1,serverid2,serverid3 です。

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

パスワード

トラステッド ID に関連付けられているパスワードを指定します。

データ型: テキスト
確認パスワード

トラステッド ID に関連付けられているパスワードを確認します。

データ型: テキスト
メッセージ層認証

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

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

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

基本認証」および「LTPA」を選択し、 アクティブな認証メカニズムが LTPA である場合、サーバーは、ユーザー名、パスワード、または LTPA トークンを使用してダウンストリーム・サーバーに接続します。

基本認証」および「KRB5」を選択し、 アクティブな認証メカニズムが KRB5 である場合、サーバーは、ユーザー名、パスワード、Kerberos トークン、 または LTPA トークンを使用してダウンストリーム・サーバーに接続します。

基本認証」を選択していない場合、サーバーは、ユーザー名とパスワードを使用してダウンストリーム・サーバーに接続しません。

トランスポート

クライアントが、接続されているトランスポートの 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 設定
クライアント証明書認証

サーバーとダウンストリーム・サーバー間で SSL 接続を行う場合に、ダウンストリーム・サーバーがクライアント証明書認証をサポートするとき、このサーバーに対する認証を、構成されている鍵ストアにあるクライアント証明書を使用して行うかどうかを指定します。

通常、クライアント証明書認証はメッセージ層認証よりもパフォーマンスの面で優れていますが、 追加のセットアップをいくつか行う必要があります。この追加ステップには、このサーバーが個人証明書を保有すること、およびダウンストリーム・サーバーがこのサーバーの署名者証明書を保有することについての検証も含まれます。

「クライアント証明書認証」を選択すると、以下のオプションが選択可能になります。
常になし
このサーバーが、 ダウンストリーム・サーバーとの Secure Sockets Layer (SSL) クライアント証明書認証を試行しないように指定します。
サポートされる
このサーバーが、 SSL クライアント証明書を使用して、ダウンストリーム・サーバーの認証を行うことができるように指定します。ただし、 このような認証なしでメソッドを呼び出すこともできます。例えば、サーバーでは、 代わりに匿名の認証や基本認証を使用することができます。
必須
このサーバーに対して、ダウンストリーム・サーバーの認証に SSL クライアント証明書の使用を求めるよう指定します。
デフォルト: 使用可能
ログイン構成

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

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

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

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

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

カスタム・アウトバウンド・マッピング

カスタム Remote Method Invocation (RMI) アウトバウンド・ログイン・モジュールを使用可能にします。

カスタム・ログイン・モジュールは、事前定義された RMI アウトバウンド呼び出しの前に、 他の関数をマップするか、完了します。

カスタム・アウトバウンド・マッピングを宣言するには、以下のステップを実行します。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」において、「Java Authentication and Authorization Service」> 「システム・ログイン」>「新規」をクリックします。
トラステッド認証レルム - アウトバウンド (Trusted authentication realms - outbound)

RMI/IIOP 通信が複数の異なるレルム間で行われる場合、アウトバウンドのトラステッド・レルムを追加するには、このリンクを使用します。

証明書トークンは、トラステッド・レルムにのみ送信されます。 また、受信側のサーバーは、インバウンドのトラステッド・レルム構成を使用して LTPA トークンの検証を行い、このレルムを信頼する必要があります。




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

関連タスク


ファイル名: usec_outbound.html