WebSphere Application Server - Express, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

Common Secure Interoperability バージョン 2 インバウンド認証の構成

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

プロシージャー

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

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

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

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

    • ユーザー ID およびパスワード (メッセージ層)。

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

      通常、トークンはアップストリーム・サーバーから送信され、 サーブレットを含め、ユーザー ID およびパスワードはクライアントから送信されます。 サーバー・レベルでトークンが受信されると、 トークンの妥当性検査が行われ、改ざんが発生したか、または期限切れであるかどうかが検査されます。

      詳しくは、 ユーザー ID およびパスワードを参照してください。

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

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

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

      詳しくは、 Secure Sockets Layer のクライアント証明書の認証を参照してください。

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

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

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

結果

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

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

次の作業

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



サブトピック
Common Secure Interoperability インバウンド認証設定
関連タスク
Common Secure Interoperability バージョン 2 アウトバウンド認証の構成
IIOP 認証の構成
関連資料
ダウンストリーム・サーバーに対する ID アサーション
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 11:31:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_csiv2inbound.html