Java Authentication and Authorization Service によるプログラマチック・ログインの開発
このトピックを使用して、Java™ Authentication and Authorization Service によるプログラマチック・ログインを開発します。
始める前に
JAAS は、
Common Object Request Broker Architecture (CORBA) プログラマチック・ログイン・アプリケーション・プログラミング・インターフェース (API) に置き換わるものです。
- シン・クライアント・アプリケーションがサーバー上のリモート・リソースにアクセスするように環境をセットアップする方法について詳しくは、CosNaming (CORBA ネーミング・インターフェース) を使用するアプリケーションの開発に関する情報を参照してください。
- アプリケーションがカスタム JAAS ログイン構成を使用する場合は、JAAS ログイン構成が正しく定義されていることを確認します。 詳しくは、Java Authentication and Authorization Service のプログラマチック・ログインの構成を参照してください。
- 一部の JAAS API は、Java 2 セキュリティー権限によって保護されています。
これらの API
をアプリケーション・コードで使用する場合は、これらのアクセス権がアプリケーションの was.policy
ファイルに追加されていることを確認してください。詳しくは、以下の項目を参照してください。 Java 2 セキュリティー権限で保護される API について詳しくは、IBM® Developer Kit の Java Technology Edition で、『セキュリティー: 学習用リソース』の項目の JAAS および WebSphere Application Server のパブリック API の資料を参照してください。この資料のサンプル・コードで使用される API の一部、およびこれらの API によって要求される Java 2 セキュリティー権限を以下のリストに示します。
- javax.security.auth.login.LoginContext コンストラクターは、javax.security.auth.AuthPermission の "createLoginContext" オブジェクトで保護されています。
- javax.security.auth.Subject.doAs および com.ibm.websphere.security.auth.WSSubject.doAs メソッドは、javax.security.auth.AuthPermission の "doAs" オブジェクトで保護されています。
- javax.security.auth.Subject.doAsPrivileged および com.ibm.websphere.security.auth.WSSubject.doAsPrivileged メソッドは、javax.security.auth.AuthPermission の "doAsPrivileged" オブジェクトで保護されています。
- 許可検査用 Java Platform, Enterprise Edition (Java EE) リソースに対する拡張モデル。
JAAS バージョン 1.0 の設計上のミスにより、javax.security.auth.Subject.getSubject メソッドは、 java.security.AccessController.doPrivileged コード・ブロック内の実行スレッドに 関連付けられているサブジェクトを戻しません。このミスのため、矛盾した振る舞いが発生し、望ましくない影響を受ける可能性があります。 com.ibm.websphere.security.auth.WSSubject クラスは、サブジェクトを実行スレッドに関連付ける予備手段を提供します。com.ibm.websphere.security.auth.WSSubject クラスは、JAAS モデルを許可検査用に、Java Platform, Enterprise Edition (Java EE) リソースに拡張します。サブジェクトが com.ibm.websphere.security.auth.WSSubject.doAs メソッド内の実行スレッドと関連付けられる場合、または com.ibm.websphere.security.auth.WSSubject.doAsPrivileged コード・ブロックが製品の証明書を含む場合、サブジェクトは Java EE リソースの許可検査のために使用されます。
- 新規 JAAS ログイン構成の定義におけるユーザー・インターフェース・サポート。JAAS ログイン構成は、管理コンソールで構成して、構成リポジトリーに保管することができます。アプリケーションは、管理コンソールで新規 JAAS ログイン構成を定義でき、 データは構成リポジトリーで永続化されます。 その場合にも、WebSphere Application Server は、JAAS のデフォルト実装が提供するデフォルトの JAAS ログイン構成フォーマット (プレーン・テキスト・ファイル) をサポートしています。 重複ログイン構成が構成リポジトリーとプレーン・テキスト・ファイル・フォーマットの両方で定義されている場合は、リポジトリーで定義された構成が優先されます。 ログイン構成を構成リポジトリーで定義することには、次のような利点があります。
- JAAS ログイン構成を定義する際に、管理コンソールがサポートされます。
- JAAS ログイン構成の集中管理
- JAAS ログイン構成の配布
- プログラマチック認証を行うアプリケーション・サポート。
WebSphere Application Server は、アプリケーションが WebSphere セキュリティー・ランタイムに対してプログラマチック認証を行うための JAAS ログイン構成を提供しています。 これらの構成は、WebSphere Application Server によって構成された認証メカニズム (Simple WebSphere Authentication Mechanism (SWAM)、Lightweight Third Party Authentication (LTPA)) および提供される認証データに基づくユーザー・レジストリー (ローカル OS、Lightweight Directory Access Protocol (LDAP) と Kerberos 認証、カスタム・レジストリー、または統合リポジトリー) に対して認証を行います。 これらの JAAS ログイン構成で認証されたサブジェクトには、WebSphere セキュリティー・ランタイムが Java EE ロール・ベースの保護リソースに対して許可検査を実行するのに使用できるプリンシパルおよびクレデンシャルが含まれています。
注: SWAM は WebSphere Application Server バージョン 9.0 では推奨されません。 また、将来のリリースでは除去される予定です。以下に、WebSphere Application Server が提供する JAAS ログイン構成を示します。- WSLogin JAAS ログイン構成。汎用的な JAAS ログイン構成では、Java クライアント、クライアント・コンテナー・アプリケーション、サーブレット、JavaServer Pages (JSP) ファイル、および Enterprise JavaBeans (EJB) コンポーネントを使用して、ユーザー ID とパスワード、またはトークンに基づく認証を、WebSphere Application Server のセキュリティー・ランタイムに対して実行することができます。ただし、 この構成は、クライアント・コンテナーのデプロイメント記述子で指定されている CallbackHandler ハンドラーを受け入れません。
- WSKRB5Login JAAS ログイン構成。汎用的な JAAS ログイン構成では、Java クライアント、 クライアント・コンテナー・アプリケーション、サーブレット、JavaServer Pages (JSP) ファイル、 および Enterprise JavaBeans™ (EJB) コンポーネントを使用して、ユーザー ID とパスワードに基づく認証、またはトークンに基づく WebSphere Application Server のセキュリティー・ランタイムに対する認証を行うことができます。ただし、 この構成は、クライアント・コンテナーのデプロイメント記述子で指定されている CallbackHandler ハンドラーを受け入れません。
- ClientContainer JAAS ログイン構成。この JAAS ログイン構成は、
クライアント・コンテナーのデプロイメント記述子で指定される CallbackHandler ハンドラーに従います。
このログイン構成のログイン・モジュールは、アプリケーション・コードがログイン・コンテキストでコールバック・ハンドラーを
指定したとしても、クライアント・コンテナーのデプロイメント記述子で CallbackHandler ハンドラーが指定されていれば、
それを使用します。この構成は、クライアント・コンテナー・アプリケーションのためのものです。
前述の JAAS ログイン構成で認証されるサブジェクトには、プリンシパル com.ibm.websphere.security.auth.WSPrincipal と クレデンシャル com.ibm.websphere.security.cred.WSCredential が含まれています。認証済みのサブジェクトが com.ibm.websphere.security.auth.WSSubject.doAs またはその他の doAs メソッドに渡されると、製品のセキュリティー・ランタイムは、com.ibm.websphere.security.cred.WSCredential サブジェクトに基づき、Java EE リソース上で許可検査を実行することができます。
- ユーザー定義 JAAS ログイン構成。
上記以外の JAAS ログイン構成を 定義して、クライアント・プロセスまたはサーバー・プロセスでカスタム・サブジェクトを作成する プログラマチック・ログインを実行することができます。本製品のセキュリティー・ランタイムの サブジェクトを、プロトコル経由でクライアントから認証情報を送信したり、 サーバー上で許可を処理したりするために使用するには、 特定のクレデンシャルとプリンシパルが必要です。必要なクレデンシャルは、 提供されているログイン・モジュールから生成されます。
Pure Java クライアントのログインに必要なログイン・モジュールは次のとおりです。- com.ibm.ws.security.common.auth.module.WSLoginModuleImpl (必須);
- javax.security.auth.callback.NameCallback
- javax.security.auth.callback.PasswordCallback
ピュアな Java クライアントで伝搬を使用可能にする方法については、アプリケーション・サーバー間のセキュリティー属性の伝搬の該当するステップを参照してください。注: 正常な状態を招くには、サブジェクトに追加されるクラスが Java シリアライズ可能かつデシリアライズ可能でなければなりません。サーバー・ログインに必要なログイン・モジュールは次のとおりです。- com.ibm.ws.security.server.lm.ltpaLoginModule (必須);
- com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule (必須);
- ピュアな Java クライアントでのプログラマチック・ログインのネーミング要件。
ピュアな Java クライアント上でプログラマチック・ログインが行われ、プロパティー com.ibm.CORBA.validateBasicAuth が true である場合、セキュリティー・コードは SecurityServer がある場所を認識する必要があります。 通常、java.naming.provider.url プロパティーがシステム・プロパティーとして設定されている場合、あるいはそのプロパティーが jndi.properties ファイルで設定されている場合は、デフォルトの InitialContext で十分です。 それ以外の場合は、システム全体で同じ java.naming.provider.url プロパティーを 設定することは望ましくありません。 この場合は、sas.client.props ファイルで、セキュリティー固有のブートストラップ情報を指定する必要があります。 以下は、ピュアな Java クライアントで SecurityServer を検出する方法を決定する場合の優先順位を示しています。
手順
例: BasicAuth を使用したプログラマチック・ログイン
この例は、アプリケーション・プログラムが、BasicAuth を使用してプログラマチック・ログインを実行する方法を示しています。
次に示すように、Kerberos トークンによるプログラマチック・ログインを追加します。
LoginContext lc = null;
try {
lc = new LoginContext("WSKRB5Login",
new WSCallbackHandlerImpl("userName", "password"));
} catch (LoginException le) {
System.out.println("Cannot create LoginContext. " + le.getMessage());
// Insert the error processing code
} catch(SecurityException se) {
System.out.println("Cannot create LoginContext." + se.getMessage());
// Insert the error processing code
}
try {
lc.login();
} catch(LoginException le) {
System.out.println("Fails to create Subject. " + le.getMessage());
// Insert the error processing code
例に示されているように、新規のログイン・コンテキストが、 WSKRB5Login ログイン構成および WSCallbackHandlerImpl コールバック・ハンドラーを 使用して初期化されます。プロンプトが望ましくないサーバー・サイド・アプリケーション では、WSCallbackHandlerImpl インスタンスを使用します。WSCallbackHandlerImpl インスタンスは、指定されたユーザー ID、 パスワードおよびレルム情報により初期化されます。 WSKRB5Login ログイン構成によって指定されている現在の Krb5LoginModuleWrapperClient クラス実装が取得できるのは、 指定されたコールバック・ハンドラーからの認証情報のみです。ログイン・コンテキストは、Subject オブジェクトにより構成することができますが、 Subject は現在の Krb5LoginModuleWrapperClient 実装によって無視されます。
ピュアな Java アプリケーション・クライアントの場合、 製品は他に 2 つのコールバック・ハンドラー実装を提供します。 これは、WSStdinCallbackHandlerImpl および WSGUICallbackHandlerImpl であり、 それぞれにコマンド行とポップアップ・パネルでユーザー ID、パスワード、 およびレルム情報の入力を求めるプロンプトを出します。 特定のアプリケーション環境に応じて、これらの製品のコールバック・ハンドラー実装のいずれかを選択できます。 これらの実装のいずれもがユーザーの特定のアプリケーション要件に 適合しない場合は、新規のコールバック・ハンドラーを開発することができます。
WSKRB5Login で使用できる追加のコールバックとして、WSAuthMechOidCallbackImpl および WSCcacheCallBackHandlerImpl があります。WSAuthMechOidCallbackImpl を使用すると、認証メカニズム OID を指定できます。Kerberos 認証メカニズム OID の値は "1.2.840.113554.1.2.2" です。WSCcacheCallBackHandlerImpl を使用すると、ユーザー名、Kerberos レルム名、Kerberos クレデンシャル・キャッシュの絶対パス、および Kerberos クレデンシャル・キャッシュのデフォルト・ロケーションを使用するかどうかを指定できます。Kerberos クレデンシャル・キャッシュのデフォルト・ロケーションを使用することを選択した場合、Kerberos クレデンシャル・キャッシュは無視されます。Kerberos を認証に使用している場合は、sas.client.props ファイルを更新する必要があります。
また、デフォルトの WSLoginModuleImpl 実装がすべての 要件を満たさない場合は、独自のログイン・モジュールを作成することもできます。 この製品には、カスタム・ログイン・モジュールにより使用可能なユーティリティー 機能が付属しています。これについては、次のセクションで説明します。
java.naming.provider.url プロパティーが、
システム・プロパティーとして設定されていないか、
あるいは jndi.properties ファイル内にない場合、
製品サーバーが localhost:2809 ロケーションになければ、
デフォルトの InitialContext コンテキストは機能しません。
この場合には、JAAS ログインの前に新規 InitialContext コンテキストを
プログラマチックに構成してください。
JAAS は、commit メソッドを実行する前に、入力されたユーザー ID またはパスワードが
正しいかどうかを検証するためにセキュリティー・サーバーの場所を知る必要があります。
このトピックで後述されている方法で新規 InitialContext コンテキストを構成することによって、
セキュリティー・コードには、セキュリティー・サーバーの場所とターゲット・レルムを見つけるために必要な情報が入ります。
java.naming.provider.url プロパティーが、
システム・プロパティーとして設定されていないか、
あるいは jndi.properties ファイル内にない場合、
製品サーバーが sever_name:2809 ロケーションになければ、
デフォルトの InitialContext コンテキストは機能しません。
この場合には、JAAS ログインの前に新規 InitialContext コンテキストを
プログラマチックに構成してください。
JAAS は、commit メソッドを実行する前に、入力されたユーザー ID またはパスワードが
正しいかどうかを検証するためにセキュリティー・サーバーの場所を知る必要があります。
このトピックで後述されている方法で新規 InitialContext コンテキストを構成することによって、
セキュリティー・コードには、セキュリティー・サーバーの場所とターゲット・レルムを見つけるために必要な情報が入ります。
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
...
// Perform an InitialContext and default lookup prior to logging in so that target realm
// and bootstrap host/port can be determined for SecurityServer lookup.
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL, "corbaloc:iiop:myhost.mycompany.com:2809");
Context initialContext = new InitialContext(env);
Object obj = initialContext.lookup("");
LoginContext lc = null;
try {
lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl("userName", "realm", "password"));
} catch (LoginException le) {
System.out.println("Cannot create LoginContext. " + le.getMessage());
// insert error processing code
} catch(SecurityException se) {
System.out.printlin("Cannot create LoginContext." + se.getMessage();
// Insert error processing
}
try {
lc.login();
} catch(LoginException le) {
System.out.printlin("Fails to create Subject. " + le.getMessage());
// Insert error processing code
}