Common Secure Interoperability バージョン 2 インバウンド通信設定
このページを使用して、リソースへアクセスしているクライアントに対してサーバーがサポートするフィーチャーを指定します。
- をクリックします。
- 「認証」から、 をクリックします。
common secure interoperability (CSI) インバウンド通信設定は、着信要求またはトランスポートに含まれる認証情報のタイプを構成するために使用します。
- CSIv2 属性層。属性層には、アップストリーム・サーバーからの識別情報で、既に認証済みの識別トークンが含まれている 場合があります。 識別層の優先順位は最も高く、次にメッセージ層、トランスポート層の順で低くなります。 クライアントが 3 つの層をすべて送信する場合は、識別層だけが使用されます。 SSL クライアント証明書は、それが要求中に提示された唯一の情報である場合にのみ、識別情報として使用されます。クライアントは、 名前空間から相互運用オブジェクト参照 (IOR) を取り出し、タグ付きコンポーネントから値を読み取って、 セキュリティーに関してサーバーが何を必要とするのかを判別します。
- CSIv2 トランスポート層。トランスポート層 (一番下の層) には、識別情報として Secure Sockets Layer (SSL) クライアント 証明書を含む場合があります。
CSIv2 メッセージ層。メッセージ層には、ユーザー ID とパスワード、または有効期限を持つ認証済みトークンが含まれている場合があります。
セキュリティー属性の伝搬 (Propagate security attributes)
ログイン要求時のセキュリティー属性を伝搬することを指定します。このオプションを選択すると、アプリケーション・サーバーは、使用する認証強度などのログイン要求についての追加情報を保存し、要求発信元の識別およびロケーションを保存します。
このオプションを選択しない場合、アプリケーション・サーバーは、 ダウンストリーム・サーバーに伝搬する追加ログイン情報を受け入れません。
通知 | 値 |
---|---|
デフォルト: | 使用可能 |
ID アサーションの使用
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 フィールドにマップされます。
通知 | 値 |
---|---|
デフォルト: | 使用不可 |
![[z/OS]](../images/ngzos.gif)
- SAF 分散 ID マッピングを使用した証明書および DN のマップ
- このオプションを選択すると、表明された証明書と識別名が、RACMAP フィルターを使用して SAF ユーザー ID にマップされます。
デフォルト値は未チェックです。チェックされた場合、セキュリティー・カスタム・プロパティー com.ibm.websphere.security.certdn.useRACMAPMappingToSAF が boolean: yes に設定されます。
注: このオプションは、アクティブなユーザー・レジストリーがローカル OS で、 セルが混合バージョンでなく (WebSphere Application Server バージョン 8.0 より前のノードがない)、 z/OS セキュリティー製品が SAF ID マッピングをサポートする (RACF® の場合、これは z/OS バージョン 1.11 またはそれ以降を意味します) 場合にのみ表示されます。注: 識別名で属性の間に空白スペースがある場合は、それらの空白を正しく解析するために RACF APAR OA34258 または PTF UA59873、および SAF APAR OA34259 または PTF UA59871 を適用する必要があります。
トラステッド ID
送信サーバーから受信サーバーへ送信されるトラステッド ID を指定します。
パイプ (|) で区切られたトラステッド・サーバーの管理者ユーザー ID のリストを指定します。この ID は、このサーバーに対する ID アサーションの実行に関して信頼されています。例えば、serverid1|serverid2|serverid3 のようになります。 アプリケーション・サーバーでは、後方互換性のために、リスト区切り文字としてコンマ (,) 文字をサポートしています。アプリケーション・サーバーは、パイプ文字 (|) で有効なトラステッド・サーバー ID が見つからない場合に、コンマ文字をチェックします。
このリストを使用して、サーバーが信頼できるか否かを判断します。受信サーバーが送信サーバーの識別トークンを受け入れるには、送信サーバーがリストに載っている場合でも、受信サーバーで送信サーバーを認証する必要があります。
通知 | 値 |
---|---|
データ型: | ストリング |
クライアント証明書認証
メソッド要求時のクライアント/サーバー間の最初の接続時に、認証が行われることを指定します。
トランスポート層では、Secure Sockets Layer (SSL) クライアント証明書認証が行なわれます。メッセージ層では、 基本認証 (ユーザー ID とパスワード) が使用されます。 クライアント証明書認証は通常、メッセージ層認証よりも優れていますが、 追加のセットアップがいくつか必要になります。 これらの追加ステップでは、サーバーが接続先の各クライアントの署名者証明書を信頼していることについての確認が行われます。 クライアントが認証局 (CA) を使用して個人証明書を作成した場合、 必要なのは、SSL トラスト・ファイルのサーバーの署名者セクション内の CA のルート証明書のみです。
証明書を Lightweight Directory Access Protocol (LDAP) ユーザー・レジストリーに対して認証する場合、
識別名 (DN) は LDAP の構成時に指定したフィルターに基づいてマップされます。証明書をローカル OS ユーザー・レジストリーに
対して認証する場合、証明所内の識別名 (DN) の最初の属性 (通常は共通名) が
レジストリー内のユーザー ID にマップされます。
証明書をローカル OS ユーザー・レジストリーに対して認証する場合、
その証明書はレジストリー内のユーザー ID にマップされます。
サーバーに他の認証層が提示されない場合にだけ、クライアント証明書の識別情報が使用されます。
- 常になし
- クライアントが、 このサーバーで Secure Sockets Layer (SSL) クライアント証明書の認証を試行できないように指定します。
- サポートされる
- このサーバーに接続しているクライアントが、SSL クライアント証明書を使用して認証できることを指定します。ただし、サーバーはこのような認証なしでメソッドを呼び出すことできます。例えば、
代わりに匿名認証または基本認証を使用することができます。
注: サーバー上で「サポートあり」が「CSIv2 インバウンド認証」に設定されている場合、クライアント証明書が認証に使用されます。
- 必須
- このサーバーに接続するクライアントが、メソッドを呼び出す前に、SSL クライアント証明書を使用して認証を行う必要があることを指定します。
![[z/OS]](../images/ngzos.gif)
- SAF 分散 ID マッピングを使用した証明書のマップ
- このオプションを選択すると、RACMAP フィルターを使用して、CSIv2 トランスポート層で受信した証明書を SAF ユーザー ID にマップします。
デフォルト値は未チェックです。チェックされた場合、セキュリティー・カスタム・プロパティー com.ibm.websphere.security.certificate.useRACMAPMappingToSAF に true が設定されます。
注: このオプションは、アクティブなユーザー・レジストリーがローカル OS で、 セルが混合バージョンでなく (WebSphere Application Server バージョン 8.0 より前のノードがない)、 z/OS セキュリティー製品が SAF ID マッピングをサポートする (RACF の場合、これは z/OS バージョン 1.11 またはそれ以降を意味します) 場合にのみ表示されます。
トランスポート
クライアントが、接続されているトランスポートの 1 つを使用して、 サーバーへの接続を処理するかどうかを指定します。
サーバーによってサポートされるインバウンド・トランスポートとして、Secure Sockets Layer (SSL) か TCP/IP のいずれか、またはその両方を 選択できます。「TCP/IP」を指定すると、サーバーは TCP/IP のみをサポートし、SSL 接続を受け入れること はできません。「SSL サポート」を指定すると、このサーバーは TCP/IP 接続または SSL 接続をサポートできます。 「SSL 必須」を指定すると、このサーバーと通信しているサーバーはすべて SSL を使用する必要があります。
- TCP/IP
- 「TCP/IP」を選択すると、サーバーは TCP/IP リスナー・ポートだけを開くため、 すべてのインバウンド要求が SSL で保護されるとは限りません。
- SSL 必須
- 「SSL 必須」を選択すると、サーバーは SSL リスナー・ポートだけを開くため、 すべてのインバウンド要求が SSL を使用して受信されます。
- SSL サポート
- 「SSL サポート」を選択すると、サーバーは TCP/IP および SSL リスナー・ポートの両方を開き、 ほとんどのインバウンド要求が SSL を使用して受信されます。
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS
ORB_SSL_LISTENER_ADDRESS
通知 | 値 |
---|---|
デフォルト: | SSL 必須 |
範囲: | TCP/IP、SSL 必須、SSL サポート |
SSL 設定
インバウンド接続用に選択する事前定義された SSL 設定のリストを 指定します。
![[z/OS]](../images/ngzos.gif)
通知 | 値 |
---|---|
データ型: | ストリング |
![]() ![]() |
DefaultSSLSettings |
![]() |
DefaultIIOPSSL |
範囲: | 「SSL 構成レパートリー」で構成された任意の SSL 設定 |
メッセージ層認証
- 常になし
- このサーバーでは、以下で選択されるいずれのメカニズムを使用した認証も受け入れることができないことを指定します。
- サポートされる
- このサーバーと通信するクライアントが、以下で選択されるいずれかのメカニズムを使用して 認証を受けられることを指定します。ただし、 このような認証なしでメソッドを呼び出すこともできます。例えば、 代わりに匿名またはクライアント証明書を使用することができます。
- 必須
- このサーバーと通信するクライアントが、すべてのメソッド要求に対し、以下で選択されるメカニズムを使用して 認証情報を指定しなければならないことを指定します。
クライアントからサーバーへの認証を許可 (Allow client to server authentication with):
Kerberos、LTPA、または基本認証を使用した、 クライアントからサーバーへの認証を指定します。
- Kerberos (KRB5)
- Kerberos を認証メカニズムとして指定する場合に選択します。最初に Kerberos 認証メカニズムを構成する必要があります。詳しくは、管理コンソールを使用した認証メカニズムとしての Kerberos の構成を参照してください。
- LTPA
- LTPA トークン認証を指定する場合に選択します。
- 基本認証
- 基本認証は Generic Security Services Username Password (GSSUP) です。通常、このタイプの認証では、認証のためにユーザー ID とパスワードがクライアントから サーバーへ送信されます。
「基本認証」および「LTPA」を選択し、アクティブな認証メカニズムが LTPA である場合、ユーザー名、パスワード、および LTPA トークンが受け入れられます。
「基本認証」および「KRB5」を選択し、アクティブな認証メカニズムが KRB5 である場合、ユーザー名、パスワード、Kerberos トークン、および LTPA トークンが受け入れられます。
「基本認証」を選択しない場合、ユーザー名もパスワードも、 サーバーで受け入れられません。
ログイン構成
インバウンド認証に使用するシステム・ログイン構成のタイプを指定します。
とクリックして、カスタム・ログイン・モジュールを追加できます。「認証」から、 をクリックします。
ステートフル・セッション
このオプションを選択して、主にパフォーマンス向上のために使用されるステートフル・セッションを使用可能にします。
クライアントとサーバーが最初に接続するときには、認証を完全に実行する必要があります。 しかし、それ以後のすべての接続では、セッションが引き続き有効である間は、セキュリティー情報を再利用します。 クライアントはコンテキスト ID をサーバーに渡し、その ID を使用してセッションが検索されます。 コンテキスト ID の有効範囲は各接続であり、これにより一意性が保証されます。 認証の再試行が使用可能になっている場合 (デフォルトで) は、セキュリティー・セッションが無効になるごとに クライアント側のセキュリティー・インターセプターは、ユーザーにそれを認識させずにクライアント側のセッションを無効にし、 要求を再度実行依頼します。この状態は、セッションがサーバー上に存在しない (例えば、サーバーで障害が発生した後、オペレーションが再開された) 場合に起こることがあります。この値が使用不可の場合、各メソッドの呼び出しを再認証する必要があります。
通知 | 値 |
---|---|
デフォルト: | 使用可能 |
トラステッド認証レルム - インバウンド
このリンクを選択して、レルムのインバウンドの信頼を確立します。 インバウンド認証レルム設定は、CSIv2 固有ではありません。セキュリティー・ドメインが複数ある場合、インバウンドの信頼をどのレルムに付与するかを構成することもできます。
インバウンド認証とは、インバウンド要求に対して受け入れられる認証タイプを決定する構成のことを指します。この認証は、クライアントがネーム・サーバーから取り出す相互運用オブジェクト参照 (IOR) で公示されます。