WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/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 とパスワードを指定する必要があります。

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

クライアント証明書認証

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

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

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

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

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

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

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

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

クライアントとサーバーが最初に接続するときには、認証を完全に実行する必要があります。 しかし、それ以後のすべての接続では、セッションが引き続き有効である間は、セキュリティー情報を再利用します。 クライアントはコンテキスト 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 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/usec_inbound.html