WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

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

Common Secure Interoperability インバウンド認証設定

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

この管理コンソール・ページを表示するには、以下のステップを実行します。
  1. セキュリティー」>「セキュア管理、アプリケーション、およびインフラストラクチャー」とクリックします。
  2. 「認証」の下の「RMI/IIOP security」>「CSIv2 インバウンド認証」をクリックします。
サーバー・ページのこの管理コンソール・ページは、以下のステップを実行しても表示できます。
  1. サーバー」>「アプリケーション・サーバー」>「サーバー名 (server_name)」とクリックします。
  2. 「セキュリティー」の下の「サーバー・セキュリティー」をクリックします。
  3. 「追加プロパティー」の下の「CSIv2 インバウンド認証」をクリックします。

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

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

「構成」タブ

基本認証

基本認証がメッセージ層で発生することを指定します。

メッセージ層で基本認証が発生します。通常、このタイプの認証では、認証のためにユーザー ID とパスワードがクライアントから サーバーへ送信されます。

この認証には、クレデンシャル・タイプが転送可能である場合 (例えば、Lightweight Third Party Authentication (LTPA)) に、既に認証されたクレデンシャルからのクレデンシャル・トークンの代行も含まれます。

基本認証」をクリックし、LTPA が構成済みの認証プロトコルである場合、 ユーザー名、パスワード、および LTPA トークンが受け入れられます。

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

基本認証とクライアント証明書認証の両方が実行された場合は、 基本認証がクライアント証明書認証に優先します。

クライアント証明書認証

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

[z/OS] [この情報が適用されるのはバージョン 6.0.x と、バージョン 6.1 セルに統合された以前のサーバーだけです。] 注: このフィールドは、 バージョン 6.1 サーバーには適用されませんが、 ご使用の環境にバージョン 6.0.x 以前のサーバーが存在する場合には使用可能です。

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

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

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

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

常になし
このオプションを選択すると、クライアントは、 このサーバーでは Secure Sockets Layer (SSL) クライアント証明書認証を試行できなくなります。
サポートされる
このオプションを選択すると、このサーバーに接続するクライアントは、 SSL クライアント証明書を使用して認証を行うことができるようになります。 ただし、サーバーはこのような認証なしでメソッドを呼び出すことできます。例えば、 代わりに匿名認証または基本認証を使用することができます。
必須
このオプションを選択すると、このサーバーに接続するクライアントは、 メソッドを呼び出す前に、SSL クライアント証明書を使用して認証を行う必要があります。
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

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

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

データ型 ストリング
ステートフル・セッション

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

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

データ型 ストリング
ログイン構成

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

セキュリティー」>「セキュア管理、アプリケーション、およびインフラストラクチャー」をクリックして、カスタム・ログイン・モジュールを追加できます。「認証」の下の、「Java Authentication and Authorization Service」>「システム・ログイン」をクリックします。

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

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

認証メカニズムとして、Lightweight Third Party Authentication (LTPA) を使用している ことを確認します。セキュリティー属性伝搬フィーチャーを使用可能にする場合、サポートされる 認証メカニズムは LTPA だけです。

LTPA を構成するには、「セキュリティー」>「セキュア管理、アプリケーション、およびインフラストラクチャー」をクリックします。「認証」の下で「認証メカニズムおよび有効期限」をクリックします。

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




関連タスク
Common Secure Interoperability バージョン 2 インバウンド認証の構成
関連資料
Java Authentication and Authorization Service 用のシステム・ログイン構成エントリー設定
認証メカニズムおよび有効期限
参照トピック    

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

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/usec_inbound.html