Common Secure Interoperability バージョン 2 インバウンド通信の構成

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

手順

  1. 管理コンソールを開始します。
  2. セキュリティー」>「グローバル・セキュリティー」とクリックします。
  3. 「RMI/IIOP セキュリティー」の下の「CSIv2 インバウンド通信」をクリックします。
  4. 以下のセキュリティーの各レイヤーを検討してください。
    • ID アサーション (属性層)。

      これを選択すると、このサーバーは、アップストリーム・サーバーからの識別トークンを受け入れます。 このサーバーが識別トークンを受信すると、その識別が発信元クライアントから取り出されます。例えば、 識別は、発信元クライアントが最初のサーバーに提示した識別と同じ形式をしています。アップストリーム・サーバーは、発信元クライアントの識別を送信します。 識別のフォーマットは、プリンシパル名、識別名、または証明書チェーンのいずれかです。 場合によっては、識別は、匿名になります。 識別は、識別トークンを送信するアップストリーム・サーバーで認証されるため、このサーバーを信頼することが重要になります。 アップストリーム・サーバーのトラストは、Secure Sockets Layer (SSL) クライアント証明書認証 または基本認証を使用して確立されます。ID アサーションを選択する場合に、 インバウンド認証とアウトバウンド認証の両方で、認証の 2 つの層の 1 つを選択する必要があります。

      [AIX Solaris HP-UX Linux Windows][IBM i]識別トークンとともに、サーバー ID がクライアント認証トークンで送信されます。 このサーバー ID は、トラステッド・サーバー ID リストと照らし合わせて検査されます。 サーバー ID がトラステッド・サーバー・リストにある場合は、そのサーバー ID は認証済みです。 サーバー ID が有効な場合、その識別トークンはクレデンシャルに書き込まれ、要求の許可に使用されます。

      [z/OS]
      注: 構成済みレジストリーがローカル OS の場合、代わりに、CBIND クラスのプロファイル CB.BIND.<optionalSAFProfilePrefix>.<cluster_short_name> に対する UPDATE 権限を使用して、ダウンストリーム・サーバーでアップストリーム・サーバー ID が許可されているかどうかを確認することで、トラストが確立されます。アップストリーム・サーバー ID は、SSL クライアント証明書を使用して送信されます。 SSL が使用されていない場合、CBIND チェックが、アップストリーム・サーバーの開始済みタスク ID に対して実行されます。
      トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): ID アサーションを使用可能にする場合は、メッセージ層またはトランスポート層も使用可能にする必要があります。 サーバー間通信の場合、トランスポート層/クライアント認証を使用可能にする以外に、ID アサーションまたはメッセージ層も使用可能にする必要があります。gotcha

      詳しくは、ID アサーションを参照してください。

    • メッセージ層:

      基本認証 (GSSUP):

      このタイプの認証は、最も一般的です。 ユーザー ID とパスワード、または認証済みトークンは、ピュア・クライアントあるいはアップストリーム・サーバーから送信されます。 ユーザー ID およびパスワードは、サーバーで受信されると、ダウンストリーム・サーバーのユーザー・レジストリーを使用して認証されます。

      Lightweight Third Party Authentication (LTPA):

      この場合、アップストリーム・サーバーから LTPA トークンが送信されます。 LTPA を選択する場合、両方のサーバーで同じ LTPA 鍵を共有しなければなりません。

      Kerberos (KRB5):

      Kerberos を選択するには、アクティブな認証メカニズムが Kerberos である必要があります。この場合、Kerberos トークンはアップストリーム・サーバーから送信されます。

      詳しくは、メッセージ層の認証に関する情報を参照してください。

    • Secure Sockets Layer のクライアント証明書の認証 (トランスポート層)。

      SSL クライアント証明書は、ユーザー ID およびパスワードを使用する代わりに、認証のために使用されます。 サーバーがダウンストリーム・サーバーへ識別を委任した場合は、その識別は、トランスポート層からではなく、クライアント証明書認証を経由して、メッセージ層 (クライアント認証トークン) または属性層 (識別トークン) から来ることになります。

      [AIX Solaris HP-UX Linux Windows][IBM i]クライアントは、クライアント構成の鍵ストア・ファイルに SSL クライアント証明書を保管しています。SSL クライアント認証がこのサーバーで使用可能になっている場合は、このサーバーは、クライアントとの接続が確立されると、 SSL クライアント認証を送信するようクライアントに要求します。 証明書チェーンは、要求がサーバーに送信されるたびに、ソケット上で使用可能になります。 サーバー要求インターセプターは、ソケットから証明書チェーンを取得し、この証明書チェーンをユーザー・レジストリー内のユーザーにマップします。 このタイプの認証は、クライアントからサーバーへ直接通信を行う場合には最適な認証です。ただし、ダウンストリームに移動する必要がある場合、ID は、通常、メッセージ層を流れるか、ID アサーションを経由して流れます。

      [z/OS]クライアントは、クライアント構成の鍵リング・ファイルに SSL クライアント証明書を保管しています。SSL クライアント認証がこのサーバーで使用可能になっている場合は、このサーバーは、クライアントとの接続が確立されると、 SSL クライアント認証を送信するようクライアントに要求します。 証明書チェーンは、要求がサーバーに送信されるたびに、ソケット上で使用可能になります。 サーバー要求インターセプターは、ソケットから証明書チェーンを取得し、この証明書チェーンをユーザー・レジストリー内のユーザーにマップします。 このタイプの認証は、クライアントからサーバーへ直接通信を行う場合には最適な認証です。ただし、ダウンストリームに移動する必要がある場合、識別は、通常、メッセージ層を流れるか、ID アサーションを経由して流れます。

  5. どのタイプの認証を受け入れるかを決定する場合には、以下の点を考慮してください。
    • サーバーは、複数のレイヤーを同時に受信することができるため、優先順位規則によって、使用する識別が決定されます。 優先順位が最も高いのは ID アサーション層です。 その次がメッセージ層で、優先順位が最も低いのがトランスポート層です。 提供されている層がトランスポート層のみの場合は、SSL クライアント証明書認証が 使用されます。 メッセージ層とトランスポート層が提供されている場合は、メッセージ層を使用して、許可に使用される識別を確立します。 ID アサーション層が提供されている場合は、その ID アサーション層を使用して優先順位が確立されます。
    • このサーバーが要求を受信するのは、通常はクライアントからでしょうか。またはサーバーからでしょうか。あるいはその両方からでしょうか。 サーバーが常にクライアントからの要求を受信している場合は、ID アサーションは不要です。メッセージ層、トランスポート層、またはその両方のいずれかから選択することができます。 また、どのようなときに認証を必要とするか、あるいはサポートするかを決定することもできます。 必要に応じて層を選択するには、送信元クライアントがこの層を提供している必要があり、提供されていない場合、要求は拒否されます。 ただし、この層が単にサポートされているだけの場合は、この層は提供されない場合があります。
    • どのようなクライアント識別が提供されていますか。 クライアント識別がクライアント証明書認証であり、その証明書チェーンをダウンストリームに流して、それがダウンストリーム・サーバーのユーザー・レジストリーにマップされるようにする場合は、ID アサーションを選択するのが適切です。 ID アサーションは、発信元クライアントのフォーマットを保持します。 発信元クライアントがユーザー ID とパスワードを使用して認証を行った場合は、 プリンシパル識別が送信されます。 証明書を使用して認証を行った場合は、証明書チェーンが送信されます。

      [AIX Solaris HP-UX Linux Windows][IBM i]クライアントがトークンを使用して認証を行い、Lightweight Directory Access Protocol (LDAP) サーバーが ユーザー・レジストリーである場合などは、識別名 (DN) が送信されます。

  6. トラステッド・サーバー・リストを構成します。 インバウンド要求に対して ID アサーションを選択する場合は、 このサーバーが識別トークンのサブミットをサポートできるサーバー管理者 ID のパイプ (|) 区切りのリストを挿入します。 後方互換性のため、コンマ区切りリストも使用できます。ただし、サーバー ID が識別名 (DN) である場合、 コンマ区切り文字が使用できないため、パイプ (|) 区切りリストを使用する必要があります。 どのサーバーも識別トークンを送信できるようサポートする場合は、このフィールドにアスタリスク (*) を入力します。 この操作は、推定トラスト と呼ばれています。この場合、サーバー間で SSL クライアント証明書認証を使用して信頼を確立します。
    サポートされる構成 サポートされる構成: このステップは、Lightweight Directory Access Protocol (LDAP) またはカスタム・ユーザー・レジストリーを使用している場合に適用できます。 ただし、ローカル・オペレーティング・システムのユーザー・レジストリーあるいは System Authorization Facility (SAF) のユーザー・レジストリーを使用している場合には、適用できません。sptcfg
  7. セッション管理を構成します。 ステートフル・セキュリティーまたはステートレス・セキュリティーのいずれかを選択することができます。 ステートフル・セッションを選択すると、最適なパフォーマンスを得ることができます。 クライアントとサーバー間の最初のメソッド要求が認証されます。 後続の (またはクレデンシャル・トークンが満了するまでの) すべての要求は、セッション情報 (クレデンシャルも含む) を再使用します。 クライアントは、後続要求のコンテキスト ID を送信します。 コンテキスト ID の有効範囲は、一意性の接続です。

タスクの結果

このパネルの構成が完了すれば、クライアントがこのサーバーに何を送信するかを決定する際に集める情報をほとんどを構成したことになります。 クライアントまたはサーバーのアウトバウンド構成は、このサーバーのインバウンド構成とともに、適用するセキュリティーを決定します。 クライアントの送信内容がわかっていると、構成は簡単です。 ただし、異なるセキュリティー要件を持つ、さまざまなクライアントの集合がある場合は、サーバーは、さまざまな層の認証を考慮します。

Java Platform, Enterprise Edition アプリケーション・サーバーの場合の認証の選択肢としては、 通常、ID アサーション層またはメッセージ層のいずれかになります。 これは、発信元クライアントの識別をダウンストリームへ委任するためです。SSL 接続の使用では、クライアント証明書の委任を容易に行うことはできません。 追加のサーバー・セキュリティーは、SSL ハンドシェークの追加のクライアント証明書部分として、SSL 接続の確立全体に多少のオーバーヘッドを追加するので、トランスポート層を使用可能にしても差し支えありません。

次のタスク

このサーバーが受信する可能性のある認証データのタイプを決定すると、アウトバウンド・セキュリティー用に何を選択するかを決定することができます。 詳しくは、 Common Secure Interoperability バージョン 2 アウトバウンド認証の構成を参照してください。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_csiv2inbound
ファイル名:tsec_csiv2inbound.html