Java Authentication and Authorization Service 用のシステム・ログイン構成エントリー設定

このページを使用して、Java™ Authentication and Authorization Service (JAAS) システム・ログイン構成のリストを指定します。

この管理コンソール・ページを表示するには、以下のステップを実行します。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」において、「Java Authentication and Authorization Service」 > 「システム・ログイン」をクリックします。
アプリケーション・サーバーの セキュリティー・ランタイムの認証用に、 追加のログイン・モジュールを定義し始める 前に、Java Authentication and Authorization Service (JAAS) の資料をお読みください。 以下のシステム・ログイン・モジュールは除去しないでください。
ICSF [z/OS]

認証メカニズムとして Integrated Cryptographic Services Facility (ICSF) を使用すると、 ログイン要求を処理します。

RMI_INBOUND、WEB_INBOUND、DEFAULT

Remote Method Invocation (RMI)、Web アプリケーション、 およびその他のほとんどのログイン・プロトコルのインバウンド・ログイン要求を処理します。

RMI_INBOUND
このログイン構成は、インバウンド RMI 要求のログインを処理します。 通常、これらのログインは Enterprise JavaBeans™ (EJB) ファイルへのア クセスの認証の要求です。RMI コネクターを使用している場合は、これらのログインは Java Management Extensions (JMX) に対する要求になる場合もあります。
WEB_INBOUND
このログイン構成は、サーブレットおよび JavaServer Pages (JSP) ファイルを含む Web アプリケーション要求のログインを処理します。 このログイン構成により、トラスト・アソシエーション・インターセプター (TAI) が構成されていれば、 そこから生成される出力との相互作用が可能になります。WEB_INBOUND ログイン構成に渡されるサブジェクトには、TAI によって生成されたオブジェクトが含まれている場合があります。
DEFAULT
このログイン構成は、他のほとんどのプロトコルおよび内部認証によって作成されるインバウンド要求のログインを処理します。

これらの 3 つのログイン構成は、以下のコールバック情報に含まれて、受け渡されます。 コールバック情報は、これらの構成内のログイン・モジュールによって処理されます。これらのコールバックは、 同時には受け渡されません。ただし、これらのコールバックの組み合わせにより、アプリケーション・サーバーがユーザーを 認証する方法が決定されます。

コールバック

callbacks[0] = new javax.security.auth.callback.NameCallback("Username:
");

担当処理
ログイン時に提供されるユーザー名を収集します。この情報は、 以下のログイン・タイプのユーザー名とすることができます。
  • 基本認証 として知られている、ユーザー名およびパスワードのログイン。
  • ID アサーションのためだけに使用するユーザー名。
コールバック

callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:
", false);

担当処理
ログイン時に提供されるパスワードを収集します。
コールバック

callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential
Token: ");

担当処理
ログイン時に Lightweight Third Party Authentication (LTPA) トークンまたは他のトークン・タイプを収集します。通常、この情報は、ユーザー名およびパスワードが存在しない場合に存在します。
コールバック

callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz
Token List: ");

担当処理
WSOpaqueTokenHelper への呼び出しから戻される TokenHolder オブジェクトの ArrayList リストを収集します。 このコールバックでは、入力として Common Secure Interoperability バージョン 2 (CSIv2) 許可トークンがある createTokenHolderListFromOpaqueTokentoken メソッドを使用します。
制約事項: このコールバックは、「セキュリティー属性の伝搬」オプションが 使用可能になっており、ログインが伝搬ログインである場合にのみ存在します。伝搬ログインでは、要求と同時に十分なセキュリティー属性が伝搬され、 追加属性のためにユーザー・レジストリーにアクセスする必要がなくなります。 アウトバウンド、およびインバウンドの両方の認証についてセキュリティー属性の伝搬を使用可能にする必要があります。
CSIv2 アウトバウンド認証の「セキュリティー属性の伝搬」オプションは、 次のステップによって使用可能にできます。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」の下で、「RMI/IIOP security」を展開し、「CSIv2 アウトバウンド認証」をクリックします。
  3. セキュリティー属性の伝搬」オプションを使用可能にします。
CSIv2 インバウンド認証の「セキュリティー属性の伝搬」オプションは、 次のステップによって使用可能にできます。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」の下で、「RMI/IIOP security」を展開し、「CSIv2 インバウンド認証」をクリックします。
  3. セキュリティー属性の伝搬」オプションを使用可能にします。

システム・ログイン構成で、アプリケーション・サーバーは、コールバックによって収集された情報に基づいてユーザーを認証します。ただし、カスタム・ログイン・モジュールは、 これらのいずれのコールバック上でも動作する必要はありません。以下のリストで、 これらのコールバックの典型的な組み合わせについて説明します。

  • callbacks[0] = new javax.security.auth.callback.NameCallback("Username: "); コールバックのみ

    CSIv2 ID アサーション、Web および CSIv2 X509 証明書ログイン、旧式のトラスト・アソシエーション・ インターセプター・ログインなどに対して、 このコールバックが発生します。 Web および CSIv2 X509 証明書ログインでは、アプリケーション・サーバーは、 証明書をユーザー名にマップします。このコールバックは、ユーザー名のみを使用してトラストを確立する すべてのログイン・タイプで使用されます。

  • callbacks[0] = new javax.security.auth.callback.NameCallback("Username: "); コールバックおよび callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false); コールバックの両方。

    このコールバックの組み合わせは、 基本認証ログインで一般的に使用されます。 ほとんどのユーザー認証は、これらの 2 つのコールバックを使用している際に行われます。

  • callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token: "); のみ
    このコールバックは、 Lightweight Third Party Authentication (LTPA) トークンを検証するために使用されます。この検証は、通常は、 シングル・サインオン (SSO) またはダウンストリーム・ログインの際に行われます。 アプリケーション・サーバーから要求が発信されるたびに、純粋なクライアントの代わりに、LTPA トークンがターゲット・サーバーに送信されます。シングル・サインオン (SSO) の場合、LTPA トークンが Cookie で受け取られ、そのトークンがログイン用に使用されます。 カスタム・ログイン・モジュールが LTPA トークンからのユーザー名を必要とする場合、 モジュールは、次のメソッドを使用して、トークンから固有の ID を取得することができます。

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    validateLTPAToken(byte[])

    固有 ID を取得したら、 次のメソッドを使用してユーザー名を取得します。

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    getUserFromUniqueID(uniqueID)

    重要: カスタム・ログイン・モジュールが、 アプリケーション・サーバーのログイン・モジュールより先にプラグインされ、 クレデンシャル・マッピング・サービスを使用して ID を変更する場合は、 このログイン・モジュールが、LTPA トークン (あれば) を検証することが重要になります。 LTPA トークンの信用を検証するには、以下のメソッドを呼び出せば、十 分です。

    com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
    validateLTPAToken(byte[])

    この検証が正常に機能するためには、受信サーバーが送信サーバーと同じ LTPA 鍵を持っている必要があります。この LTPA トークンが存在する場合に、これが検証されないと、 機密漏れが生じる恐れがあります。
  • 前述の任意のコールバックと callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List: "); コールバックの組み合わせ。
    このコールバックは、 伝搬された一部の属性がサーバーに到着したことを示します。伝搬された属性では、以下の認証メソッドのいずれかが必要となります。
    • callbacks[0] = new javax.security.auth.callback.NameCallback("Username:
      ");

    • callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:
      ", false);

    • callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential
      Token: ");

    属性が、純粋なクライアントからのサブジェクトに追加される場合 、NameCallback および PasswordCallback コールバックにより情報が認証され、 トークン・ホルダーでシリアライズされたオブジェクトが認証済みサブジェクトに追加されます。

    CSIv2 ID アサーションおよび伝搬が使用可能になっている場合、 アプリケーション・サーバーは NameCallback コールバックおよび (伝搬されたすべての属性を 含む) トークン・ホルダーを使用して、 ほとんどのオブジェクトをデシリアライズします。 アプリケーション・サーバーが NameCallback コールバックを使用するのは、 信頼が、CSIv2 トラステッド・サーバー・リストで示すサーバーで確立されるためです。トラステッド・サーバーを指定するには、 以下のステップを実行します。
    1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
    2. 「認証」の下の「CSIv2 インバウンド認証」をクリックします。

    カスタム・ログイン・モジュールは、カスタム・シリアライゼーションを処理する必要があります。 詳しくは、インフォメーション・センターの『セキュリティー属性の伝搬』を参照してください。

以前に定義されたコールバックのほかに、WEB_INBOUND ログイン構成は、以下の追加コールバックのみを含むことができます。
コールバック

callbacks[4] = new com.ibm.websphere.security.auth.callback.WSServletRequestCallback("HttpServletRequest:
");

担当処理
HTTP サーブレット要求オブジェクトが存在する場合は、これを収集します。 このコールバックにより、ログイン・モジュールは、 ログイン時に使用する HTTP 要求から情報を取得することができます。
コールバック

callbacks[5] = new com.ibm.websphere.security.auth.callback.WSServletResponseCallback("HttpServletResponse:
");

担当処理
HTTP サーブレット応答オブジェクトが存在する場合は、これを収集します。 このコールバックにより、ログイン・モジュールは、ログインの結果として HTTP 応答に情報を追加することができます。 例えば、ログイン・モジュールは応答に SingleSignonCookie という Cookie を追加する場合があります。
コールバック

callbacks[6] = new com.ibm.websphere.security.auth.callback.WSAppContextCallback("ApplicationContextCallback:
");

担当処理
ログイン時に使用される Web アプリケーション・コンテキストを収集します。 このコールバックはハッシュ・テーブルから構成されます。 ハッシュ・テーブルには、アプリケーション名、および存在する場合はリダイレクト Web アドレスが含まれています。
コールバック

callbacks[7] = new WSRealmNameCallbackImpl("Realm Name: ", <default_realm>);

担当処理
ログイン情報のレルム名を収集します。レルム情報は、常に提供されるとは限らず、提供されていない場合は現行のレルムと推定する必要があります。
コールバック

callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]: ");

担当処理
ログイン・ソースが SSL クライアント認証からの X509Certificate である場合、このコールバックは SSL によって妥当性検査をした証明書を含みます。 ltpaLoginModule は、以前のリリース同様、同じマッピング関数を呼び出します。 関数がログインに渡されると、 カスタマイズした方法で証明書をマップするための機会を待つカスタム・ログイン・モジュールを提供します。 次に、hashtable ログインを実行します (hashtable ログインの例については、 関連リンク「インバウンド・マッピングのためのカスタム・ログイン・モジュール」 を参照してください)。.
セキュリティー属性の伝搬を WEB_INBOUND ログイン構成で使用する場合は、 シングル・サインオンのパネルで「Web インバウンド・セキュリティー属性の伝搬」オプションを使用可能にできます。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」の下で、「Web security」を展開して、「シングル・サインオン (SSO)」をクリックします。
  3. Web インバウンド・セキュリティー属性の伝搬」オプションを選択します。
以下のログイン・モジュールは、RMI_INBOUND、WEB_INBOUND、 および DEFAULT システム・ログイン構成用に事前定義されています。カスタム・ログイン・モジュールは、これらのログイン・モジュールの配列の前、間、または後に追加することができますが、これらの事前定義されたログイン・モジュールを除去することはできません。
  • com.ibm.ws.security.server.lm.ltpaLoginModule
    属性の伝搬が使用可能または使用不可になっている場合に、 1 次ログインを実行します。 1 次ログインでは、ユーザー ID およびパスワード、LTPA トークン、またはトラスト・アソシエーション・インターセプター (TAI) および証明書識別名 (DN) などの通常の認証情報を使用します。以下のシナリオのいずれかに当てはまる場合には、 このログイン・モジュールは使用されず、com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule モジュールが 1 次ログインを実行します。
    • 必須ユーザー属性を保持する java.util.Hashtable オブジェクトは、サブジェクトに含まれます。
    • 必須ユーザー属性を保持する java.util.Hashtable オブジェクトは 、LoginContext の sharedState HashMap に含まれます。
    • WSTokenHolderCallback コールバックは、指定されたパスワードなしで存在します。 ユーザー名とパスワードが、WSTokenHolderCallback コールバック (伝搬される情報を表します) を伴う場合、 要求は、おそらく、既存の ID をユーザー ID とパスワードにマップした別のレルムからの、 純粋なクライアントまたはサーバーから発信されることになります。
  • com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
    このログイン・モジュールは、 以下の条件のいずれかに当てはまる場合、通常の認証情報を使用する 1 次ログインを実行します。
    • 必須ユーザー属性を保持する java.util.Hashtable オブジェクトが、サブジェクトに含まれる。
    • 必須ユーザー属性を保持する java.util.Hashtable オブジェクトが、LoginContext コンテキストの sharedState HashMap に存在する。
    • WSTokenHolderCallback コールバックは、PasswordCallback コールバックなしで存在します。

    java.util.Hashtable オブジェクトが存在する場合、ログイン・モジュールは、 オブジェクト属性を有効なサブジェクトにマップします。WSTokenHolderCallback コールバックが存在する場合、ログイン・モジュールは、バイト・トークン・オブジェクトを デシリアライズし、シリアライズされたサブジェクトのコンテンツを再生成します。java.util.Hashtable ハッシュ・テーブルは、他のすべてのログイン・フォームより優先されます。 アプリケーション・サーバーによって以前に伝搬されたものが複製またはオーバーライドされないように注意してください。

    java.util.Hashtable ハッシュ・テーブルを、他の認証情報に優先するように指定することにより、 カスタム・ログイン・モジュールは、LTPA トークンがあれば、それが十分なトラストを確立するように検証したはずです。カスタム・ログイン・モジュールは、 com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) メソッドを使用して、WSCredTokenCallback コールバックに存在する LTPA トークンを検証することができます。LTPA トークンの検証に失敗すると、 セキュリティー・リスクが発生します。

    アプリケーション・サーバーが十分なログイン情報として使用する、 既知の、適切な形式の属性を含むハッシュ・テーブルの追加について詳しくは、インフォメーション・センターの 『インバウンド ID マッピングの構成』を参照してください。

RMI_OUTBOUND

com.ibm.CSI.rmiOutboundLoginEnabled プロパティーまたは com.ibm.CSIOutboundPropagationEnabled プロパティーのどちらかが true である場合に、 別のサーバーにアウトバウンド送信されるリモート・メソッド呼び出し (RMI) 要求を処理します。

これらのプロパティーは、「CSIv2 authentication」パネルで設定されます。パネルにアクセスするには、以下のステップを実行します。
  1. セキュリティー」>「グローバル・セキュリティー」をクリックします。
  2. 「認証」の下で、「RMI/IIOP security」を展開し、「CSIv2 アウトバウンド認証」をクリックします。
com.ibm.CSI.rmiOutboundLoginEnabled プロパティーを設定するには、「カスタム・アウトバウンド・マッピング」を選択します。 com.ibm.CSIOutboundPropagationEnabled プロパティーを設定するには、「セキュリティー属性の伝搬」オプションを選択します。

このログイン構成により、ターゲット・サーバーおよび そのセキュリティー・ドメインのセキュリティー機能が決定されます。 例えば、アプリケーション・サーバーのバージョン 5.1.1 以降 (または、z/OS® の場合は 5.1.0.2) がバージョン 5.x のアプリケーション・サーバーと通信する場合、バージョン 5.1.1 のアプリケーション・サーバー は、LTPA トークンを使用して、認証情報のみをバージョン 5.x のアプリケーション・サーバーに送信します。しかし、WebSphere® Application Server バージョン 5.1.1 以降がバージ ョン 5.1.x アプリケーション・サーバーと通信する場合は、送信側と受信側の両方のサーバーで伝搬が使用可能になっていれば、 認証情報と許可情報が受信アプリケーション・サーバーに送信されます。 アプリケーション・サーバーが認証情報と許可情報の両方をダウンストリームに送信する場合は、 アプリケーション・サーバーは、ユーザー・レジストリーに再度アクセスして、 許可目的でユーザーのセキュリティー属性を検索する必要がなくなります。 さらに、送信サーバーで追加されるカスタム・オブジェクトは、 ダウンストリーム・サーバーのサブジェクト内に存在します。

RMI_OUTBOUND ログイン構成では以下のコールバックが使用可能です。 このコールバックによって戻された com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy オブジェクトを使用して、この特定のアウトバウンド要求のセキュリティー・ポリシーを照会することができます。 この照会は、ターゲット・レルムが現行レルムと異なるかどうか、 および、アプリケーション・サーバーがレルムをマップしなければならないかどうかを判別する際に役立ちます。 詳しくは、インフォメーション・センターの『異なるターゲット・レルムへのアウトバウンド・マッピングの構成』 を参照してください。

コールバック
callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");
担当処理

このアウトバウンド呼び出しでのログイン・モジュールのプロトコル固有のポリシー情報を提供します。 この情報は、ターゲット・レルム、ターゲット・セキュリティー要件、および合体セキュリティー要件を含む セキュリティーのレベルを判別するために使用します。

以下のメソッドは、この特定のログイン・モジュールから CSIv2PerformPolicy ポリシーを取得します。

csiv2PerformPolicy = (CSIv2PerformPolicy)
((WSProtocolPolicyCallback)callbacks[0]).getProtocolPolicy();

RMI 以外のプロトコルでは、異なるタイプのポリシー・オブジェクトが使用される可能性があります。

以下のログイン・モジュールは、RMI_OUTBOUND ログイン構成で事前定義されています。 カスタム・ログイン・モジュールは、 これらのログイン・モジュールの配列の前、間、または後に追加することができますが、 これらの事前定義されたログイン・モジュールを除去することはできません。
com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule
Common Secure Interoperability Version 2 (CSIv2) 許可トークン・レイヤーを使用して別のサーバーに送信される 不透明なバイトを作成する前に、以下のトークンおよびオブジェクトを取得します。
  • サブジェクトからの転送可能な com.ibm.wsspi.security.token.Token 実装
  • サブジェクトからのシリアライズ可能なカスタム・オブジェクト
  • スレッドからの伝搬トークン

このログイン・モジュールの前にカスタム・ログイン・モジュールを使用して、 クレデンシャル・マッピングを実行することができます。ただし、ログイン・モジュールを用いて、 ログイン・フェーズで渡されるサブジェクトのコンテンツを変更することをお勧めします。この推奨方法に従う場合、 このログイン・モジュールが新規サブジェクト・コンテンツ上で動作した後に、それらのログイン・モジュールが処理されます。

詳しくは、インフォメーション・センターの『異なるターゲット・レルムへのアウトバウンド・マッピングの構成』 を参照してください。

SWAM [AIX Solaris HP-UX Linux Windows] [iSeries]

Simple WebSphere Authentication Mechanism (SWAM) が認証メソ ッドとして使用されている場合に、 単一サーバー環境でログイン要求を処理します。

SWAM は、転送可能なクレデンシャルをサポートしていません。SWAM が認証メソッドである場合、 アプリケーション・サーバーはサーバーからサーバーへ要求を送信できません。この場合、LTPA を使用する必要があります。
注: SWAM ログイン構成は、推奨されていません。将来のリリースでは除去される予定です。
[z/OS] 注: SWAM は、アプリケーション・サーバー バージョン 7.0 では推奨されておらず、将来のリリースでは除去される予定です。
SWAM [z/OS]

このログイン構成を使用すると、Lightweight Directory Access Protocol (LDAP) ユーザー・レジストリー内 の ID を System Authorization Facility (SAF) ユーザー ID にマップできます。

[z/OS] 注: SWAM は、アプリケーション・サーバー バージョン 7.0 では推奨されておらず、将来のリリースでは除去される予定です。
wssecurity.IDAssertion

ID アサーションを使用して Web サービス・セキュリティーのログイン構成要求を処理します。

このログイン構成は、バージョン 5.x システムに対応しています。詳しくは、 インフォメーション・センターの『ID アサーション認証メソッド』を参照してください。

wssecurity.PKCS7

Public Key Cryptography Standards #7 (PKCS7) オブジェクトの証明書失効リストで、X.509 証明書を検査します。

このログイン構成は、バージョン 6.0.x システムに対応しています。

wssecurity.PkiPath

Public Key Infrastructure (PKI) パスで X.509 証明書を検査します。

このログイン構成は、バージョン 6.0.x システムに対応しています。

wssecurity.signature

デジタル・シグニチャー検証を使用して、Web サービス・セキュリティーのログイン構成要求を処理します。

このログイン構成は、バージョン 5.x システムに対応しています。

wssecurity.UsernameToken

基本認証 (ユーザー名およびパスワード) を検査します。

このログイン構成は、バージョン 6.0.x システムに対応しています。

wssecurity.X509BST

証明書および証明書パスの妥当性を検査することによって、X.509 バイナリー・セキュリティー・トークン (BST) を検査します。

このログイン構成は、バージョン 6.0.x システムに対応しています。

LTPA_WEB

サーブレット、JavaServer Pages (JSP) ファイルなど、Web コンテナーのコンポーネントに対するログイン要求を処理します。

com.ibm.ws.security.web.AuthenLoginModule ログイン・モジュールは、 LTPA ログイン構成で事前定義されています。カスタム・ログイン・モジュールは 、LTPA_WEB ログイン構成で、このモジュールの前または後に追加することができます。

LTPA_WEB ログイン構成は、コールバック・ハンドラーを使用して渡される HttpServletRequest オブジェクト 、HttpServletResponse オブジェクト、および Web アプリケーション名を処理することができます。 詳しくは、インフォメーション・センターの 『例: サーバー・サイドの Java Authentication and Authorization Service の認証およびログオン構成のカスタマイズ』を参照してください。

LTPA

LTPA_WEB ログイン構成では処理されないログイン要求を処理します。

このログイン構成は、WebSphere Application Server バージョン 5.1 以前のバージョンによって使用されます。

com.ibm.ws.security.server.lm.ltpaLoginModule ログイン・モジュールは、 LTPA ログイン構成で事前定義されています。カスタム・ログイン・モジュールは 、LTPA ログイン構成で、このモジュールの前または後に追加することができます。 詳しくは、インフォメーション・センターの 『例: サーバー・サイドの Java Authentication and Authorization Service の認証およびログオン構成のカスタマイズ』を参照してください。




マーク付きのリンク (オンライン) では、インターネットにアクセスする必要があります。

関連概念
関連タスク
関連資料
Java Authentication and Authorization Service 用のエントリー設定の構成


ファイル名: usec_sysjaas.html