JAAS のためのプログラマチック・ログイン

プログラマチック・ログインとは、 アプリケーションによる、 認証を目的としたサイト固有のログイン・フォームの表示をサポートするフォーム・ログインのことです。

エンタープライズ Bean クライアント・アプリケーションが、ユーザーに識別情報の提供を要求すると、アプリケーション の書き込み機能は、その情報を収集して、ユーザーを認証する必要があります。 プログラマーの作業は、次のように、実際のユーザー認証が実行される場合によって分類できます。

Web アプリケーションのユーザーは、 いろいろな方法で認証データの入力を求めるプロンプトを受け取ることができます。 Web アプリケーションの デプロイメント記述子ファイル内の <login-config> エレメントは、 この情報の収集に使用されるメカニズムを定義します。 ブラウザー内の 401 ダイアログ・ウィンドウなどの汎用デバイスに依存するのではなく、 ログイン手順をカスタマイズしたいプログラマーは、フォーム・ベースのログインを使用すると、 ログイン情報を収集するためのアプリケーション固有の HTML フォームを作成できます。

管理セキュリティー が使用可能になっていない場合、認証は行われません。 Web アプリケーションにフォーム・ベースのログインを使用する場合は、 各 Web アプリケーションのデプロイメント記述子 内で、<login-config> エレメントの auth-method タグ に FORM を指定する必要があります。

アプリケーションは、WebSphere® Application Server のフォーム・ログインのタイプを使用することによって、 サイト固有のログイン・フォームを表示できます。 Java™ Platform, Enterprise Edition (Java EE) 仕様は、Web アプリケーション用の認証方式の 1 つとして、フォーム・ログインを定義します。 WebSphere Application Server には、フォーム・ログアウトの仕組みがあります。

Java Authentication and Authorization Service プログラマチック・ログイン

Java Authentication and Authorization Service (JAAS) は、WebSphere Application Server の新しいフィーチャーです。 このフィーチャーは、Java EE 1.4 仕様にも準拠したものになっています。 JAAS は、戦略的認証アプリケーション・プログラミング・インターフェース (API) の集合体で、 Common Object Request Broker Architecture (CORBA) プログラマチック・ログイン API に代わるものです。WebSphere Application Server は、JAAS に次のような拡張機能を提供します。

プログラマチック・ログイン API を使用して開発を始める前に、 以下の点を検討してください。
  • 純粋な Java クライアント・アプリケーションまたはクライアント・コンテナー・アプリケーションの場合は、JAAS ログインを実行する前にクライアントのオブジェクト・リクエスト・ブローカー (ORB) セキュリティーの初期設定を行います。 そのためには、JAAS ログインの前に次のコードを実行します。
    ...
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    ...
    // Perform an InitialContext and default lookup prior to logging 
    // in to initialize ORB security and for the bootstrap host/port 
    // to be determined for SecurityServer lookup. If you do not want 
    // to validate the userid/password during the JAAS login, disable 
    // the com.ibm.CORBA.validateBasicAuth property in the 
    // sas.client.props file.
    
    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("");
    [z/OS]注: z/OS® サーバーに接続する場合は、必ず com.ibm.CORBA.validateBasicAuth=false と設定してください。 この関数は、現在では、分散クライアントから z/OS サーバーに対しては機能しないようになっています。これは、SecurityServer が「非認証」のプリンシパルを使用して配置されており、それが z/OS システムでは受け入れられないためです。
  • 純粋な Java クライアント・アプリケーションまたはクライアント・コンテナー・アプリケーションの場合は、ターゲット Java Naming and Directory Interface (JNDI) ブートストラップ・プロパティーのホスト名およびポート番号が、正しく指定されていることを確認します。 詳しくは、CosNaming (CORBA ネーミング・インターフェース) を使用するアプリケーションの開発のセクションを参照してください。
  • アプリケーションがカスタム JAAS ログイン構成を使用する場合は、カスタム JAAS ログイン構成が正しく定義されていることを確認します。 詳しくは、Java Authentication and Authorization Service のプログラマチック・ログインの構成セクションを参照してください。
  • 一部の JAAS API は、Java 2 セキュリティー権限によって保護されています。 これらの API をアプリケーション・コードで使用する場合は、 これらのアクセス権がアプリケーションの was.policy ファイルに追加されていることを確認してください。 詳しくは、was.policy ファイルの Java 2 セキュリティーのアプリケーションへの追加PolicyTool を使用した Java 2 セキュリティー用のポリシー・ファイルの編集、および Java 2 セキュリティー用の was.policy ファイルの構成 のセクションを参照してください。 Java 2 セキュリティー権限で保護される API について詳しくは、IBM® Developer Kit の Java Technology Edition、JAAS および WebSphere Application Server パブリック API の資料を参照してください。 以下のリストには、 この資料で提供されているサンプル・コードで使用される API が含まれています。
    • 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" で保護されています。
  • com.ibm.websphere.security.auth.WSSubject: JAAS バージョン 1.0 の設計上のミスにより、javax.security.auth.Subject.getSubject は、 java.security.AccessController.doPrivileged コード・ブロック内の実行中のスレッドに関連したサブジェクトを戻しません。 このため、矛盾した振る舞いが起こることがあり、それが回避すべき不必要な労力の原因となります。 com.ibm.websphere.security.auth.WSSubject API は、サブジェクトを実行中のスレッドに関連付ける措置を提供します。 com.ibm.websphere.security.auth.WSSubject API は、許可検査のために、JAAS モデルを Java EE リソースに拡張します。 com.ibm.websphere.security.auth.WSSubject.doAs または com.ibm.websphere.security.auth.WSSubject.doAsPrivileged コード・ブロック内の実行中のスレッドに関連したサブジェクトは、Java EE リソース許可検査に使用されます。
  • 新規 JAAS ログイン構成を定義する管理コンソール・サポート: JAAS ログイン構成は、 管理コンソールで構成して、 WebSphere Application Server 構成 API に保管することができます。アプリケーションは、管理コンソールで新規 JAAS ログイン構成を定義でき、データは、WebSphere Application Server 構成 API を使用して保管された 構成リポジトリーで永続化されます。 しかし、 WebSphere Application Server は現在でも、JAAS のデフォルト実装が提供する デフォルトの JAAS ログイン構成フォーマットをサポートしています。 重複ログイン構成が WebSphere Application Server 構成 API とプレーン・テキスト・ファイル・フォーマットの 両方で定義されている場合は、WebSphere Application Server 構成 API で定義されたログイン構成が優先されます。 ログイン構成を WebSphere Application Server 構成 API で定義することには、次のような利点があります。
    • 管理コンソールを使用した JAAS ログイン構成の定義。
    • JAAS ログイン構成の集中的な管理。
    • WebSphere Application Server Network Deployment インストールにおける JAAS ログイン構成の配布。
  • WebSphere Application Server の JAAS ログイン構成は、次のようになります。 WebSphere Application Server は、 アプリケーションが WebSphere Application Server セキュリティー・ ランタイムに対して、プログラマチック認証を 実行できるような、JAAS ログイン構成を提供します。 これらの WebSphere Application Server の JAAS ログイン構成は、 構成済みの認証メカニズムである Simple WebSphere Authentication Mechanism (SWAM) または Lightweight Third-Party Authentication (LTPA) と、提供された認証データに基づくユーザー・レジストリー (ローカル OS、LDAP、またはカスタム) に対して認証を実行します。 これらの JAAS ログイン構成からの認証済みサブジェクトには、WebSphere Application Server セキュリティー・ランタイムが Java EE ロール・ベースの保護リソースで許可検査を実行するために使用できる、必須のプリンシパルとクレデンシャルが含まれています。
    注: SWAM は、WebSphere Application Server バージョン 9.0 では推奨されておらず、将来のリリースでは除去される予定です。
    以下に、WebSphere Application Server が提供する JAAS ログイン構成を示します。
    • WSLogin JAAS ログイン構成: 汎用的な JAAS ログイン構成であり、Java クライアント、クライアント・コンテナー・アプリケーション、サーブレット、JSP ファイル、エンタープライズ Bean などがこれを使用すると、WebSphere Application Server セキュリティー・ランタイムに対して、ユーザー ID とパスワード、あるいはトークンに基づく認証を実行することができます。ただし、この構成は、クライアント・コンテナーのデプロイメント記述子で指定した CallbackHandler ハンドラーを サポートしません。
    • ClientContainer JAAS ログイン構成: この JAAS ログイン構成は、 クライアント・コンテナーのデプロイメント記述子で指定した CallbackHandler ハンドラーを認識します。 ログイン構成のログイン・モジュールは、アプリケーション・コードがログイン・コンテキストで CallbackHandler ハンドラーを指定したとしても、クライアント・コンテナーのデプロイメント記述子で CallbackHandler ハンドラーが 指定されていれば、それを使用します。 これは、クライアント・コンテナー・アプリケーションのためのものです。
    • 前述の JAAS ログイン構成で認証されるサブジェクトには、 プリンシパル com.ibm.websphere.security.auth.WSPrincipal と クレデンシャル com.ibm.websphere.security.auth.WSCredential が含まれています。認証済みのサブジェクトが com.ibm.websphere.security.auth.WSSubject.doAs メソッドまたはその他の doAs メソッドに渡される場合は、WebSphere Application Server セキュリティー・ランタイムは、サブジェクト com.ibm.websphere.security.auth.WSCredential クレデンシャルに基づいて、Java EE リソース上で、許可検査を実行することができます。
  • ユーザー定義の JAAS ログイン構成: 別の JAAS ログイン構成を定義することができます。 詳しくは、Java Authentication and Authorization Service のプログラマチック・ログインの構成を参照してください。カスタム認証メカニズムに対するプログラマチック認証を実行するには、これらのログイン構成を使用します。 ただし、これらのユーザー定義の JAAS ログイン構成からのサブジェクトは、 必要なプリンシパルとクレデンシャルがサブジェクトに含まれていない場合は、 WebSphere Application Server セキュリティー・ランタイムによる許可検査の実行に使用されないことがあります。

JAAS ログインからの根本原因ログイン例外の検出

LoginContext.login API の発行後 LoginException 例外を受け取った場合、 構成済みのユーザー・レジストリーから根本原因例外を見つけることができます。ログイン・モジュールでは、 レジストリー例外は com.ibm.websphere.security.auth.WSLoginFailedException クラスでラップされています。 この例外には、前述のコマンドの発行後にラップされた例外を引き出す際に使用する getCause メソッドがあります。

常に、WSLoginFailedException 例外を受け取るとは保証されませんが、 ユーザー・レジストリーから生成された例外のほとんどはここに表示されます。 次の例は、LoginContext.login API と関連したキャッチ・ブロックを示します。 getCause API を発行する場合は、WSLoginFailedException 例外を com.ibm.websphere.security.auth.WSLoginFailedException クラスにキャストします。

以下の determineCause の例は、 CustomUserRegistry 例外タイプの処理に使用できます。
try   
    {
         lc.login(); 
    } 
    catch (LoginException le)
    {
		// drill down through the exceptions as they might cascade through the runtime
		Throwable root_exception = determineCause(le);
	
		// now you can use "root_exception" to compare to a particular exception type
		// for example, if you have implemented a CustomUserRegistry type, you would 
  //  know what to look for here.
    }


/* Method used to drill down into the WSLoginFailedException to find the "root cause" exception */

    public Throwable determineCause(Throwable e) 
      {
					Throwable root_exception = e, temp_exception = null;

					// keep looping until there are no more embedded WSLoginFailedException or 
				// WSSecurityException exceptions 
         	while (true)
				{
								if (e instanceof com.ibm.websphere.security.auth.WSLoginFailedException)
						{
									temp_exception = ((com.ibm.websphere.security.auth.WSLoginFailedException) e).getCause();
														e).getCause();
						}
							else if (e instanceof com.ibm.websphere.security.WSSecurityException)
						{
									temp_exception = ((com.ibm.websphere.security.WSSecurityException) e).getCause();
														e).getCause();
						}
								else if (e instanceof javax.naming.NamingException)  // check for Ldap embedded exception
								{
													temp_exception = ((javax.naming.NamingException)e).getRootCause();
								}
								else if (e instanceof your_custom_exception_here)
						{
											// your custom processing here, if necessary
						}
						else
						{
											// this exception is not one of the types we are looking for,
											// lets return now, this is the root from the WebSphere 
								//  Application Server perspective
											return root_exception;
						}
						if (temp_exception != null)
						{
																// we have an exception; go back and see if this has another
								//  one embedded within it.
											root_exception = temp_exception;
											e = temp_exception;
								continue;
						}
						else
						{
								// we finally have the root exception from this call path, this
											// has to occur at some point
											return root_exception;
						}
				}
		}

サーブレット・フィルターからの根本原因ログイン例外の検出

ポスト・フォーム・ログイン処理への対処時に、サ ーブレット・フィルターから根本原因例外を受け取ることもできます。 この例外は、ユーザーに何が起こったかを表示してくれるので役立ちます。 以下の API を発行して、根本原因例外を取得することができます。
Throwable t = com.ibm.websphere.security.auth.WSSubject.getRootLoginException();  
if (t != null)  	
         t = determineCause(t);

例外を受け取ったら、前の determineCause の例を通じて実行し、 ネイティブ・レジストリーの根本原因を得ることができます。

純粋な Java クライアントへの根本原因ログイン例外の伝搬の使用可能化

現在、セキュリティー上の理由から、根本原因は純粋なクライアントには伝搬されていません。 ただし、トラステッド環境では、純 粋なクライアントに根本原因を伝搬することができます。 純粋なクライアントへの根本原因ログイン例外の伝搬を使用可能にする場合は、WebSphere Application Server の管理コンソール上で、「セキュリティー」 > 「グローバル・セキュリティー」 > 「カスタム・プロパティー」の順でクリックし、以下のプロパティーを設定してください。

com.ibm.websphere.security.registry.propagateExceptionsToClient=true

非プロンプト・プログラマチック・ログイン

WebSphere Application Server は、javax.security.auth.callback.CallbackHandler インターフェースの非プロンプト実装を提供します。 このインターフェースは、com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl と呼ばれます。 このインターフェースを使用すると、アプリケーションが、認証データを WebSphere LoginModule インスタンスにプッシュして認証を実行することができます。 この機能は、サーバー・サイド・アプリケーション・コードが ID を認証し、その ID を使用して Java EE のダウンストリーム・リソースを呼び出す場合に役に立ちます。
javax.security.auth.login.LoginContext lc = null;

try {
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl("user", "securityrealm", "securedpassword"));

// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determine how authentication data is collected
// in this case, the authentication data is "push" to the authentication mechanism
//   implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " 
+ e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resource using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected EJB
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
+ e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}

com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl コールバック・ハンドラーは、純粋な Java クライアント、クライアント・アプリケーション・コンテナー、エンタープライズ Bean、JavaServer Pages (JSP) ファイル、サーブレット、またはその他の Java 2 Platform, Enterprise Edition (Java EE) リソースで使用できます。

注: WSCallbackHandlerImpl コールバック・ハンドラーは、 WebSphere Application Server セキュリティーを使用するのか、Web Services Security を使用するのかによって異なります。 これは、sas.jar ファイル (セキュリティーの場合)、 または was-wssecurity.jar ファイル (Web Services Security の場合) に あります。

ユーザー・インターフェース・プロンプト・プログラマチック・ログイン

WebSphere Application Server は、javax.security.auth.callback.CallbackHandler 実装のユーザー・インターフェース実装も提供します。 この実装は、ユーザー・インターフェース・ログイン・プロンプトを使用してユーザーから認証データを収集するためのものです。このコールバック・ハンドラー com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl は、 ユーザー・インターフェース・ログイン・パネルを表示して、ユーザーに認証データを求めるプロンプトを出します。
[z/OS][AIX HP-UX Solaris]注: この振る舞いでは、X11 サーバーが DISPLAY 環境によって呼び出されることが必要です。
javax.security.auth.login.LoginContext lc = null;

try {
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl());

// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determine how authentication data is collected
// in this case, the authentication date is collected by GUI login prompt
//   and pass to the authentication mechanism implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " 
+ e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resources using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected enterprise bean
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
+ e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}
重要: com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl コールバック・ハンドラーは、 エンタープライズ Bean、サーブレット、JSP ファイルなどのサーバー・サイド・リソースでは使用しないでください。 ユーザー・インターフェース・ログイン・プロンプトは、 ユーザー入力用のサーバーをブロックします。 この振る舞いは、サーバー・プロセスにとってよくありません。

WebSphere Application Server は、javax.security.auth.callback.CallbackHandler インターフェースの Kerberos クレデンシャル・キャッシュ実装も提供します。コールバック・ハンドラー com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl。 このインターフェースを使用すると、アプリケーションが、 認証データを WebSphere LoginModule インスタンスにプッシュして認証を実行することができます。

この機能は、クライアント・サイド・アプリケーション・コードが Kerberos クレデンシャル・キャッシュを使用して、WebSphere Application Server に対して認証を行うためのものです。

wsjaas_client.conf ファイル内に以下のオプションが存在する場合は、それらを以下のように false に設定してください。

   useDefaultKeytab=false
   useDefaultCcache=false
   tryFirstPass=false
   useFirstPass=false
   forwardable=false
   renewable=false
   renewable=false
   noaddress=false

javax.security.auth.login.LoginContext lc = null;

String krb5Ccache = /etc/krb5/krb5cc_utle;

try {
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(user, krb5Realm, krb5Ccache, false));
// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determines how authentication data is collected
// in this case, the authentication date is collected by stdin prompt
// and passed to the authentication mechanism implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " + e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resource using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected enterprise bean
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}

Application Server with the default Kerberos credential cache.

javax.security.auth.login.LoginContext lc = null;

try {
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(user, krb5Realm, null, true));
// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determines how authentication data is collected
// in this case, the authentication date is collected by stdin prompt
// and passed to the authentication mechanism implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " + e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resource using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected enterprise bean
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}

Application Server with the Microsoft native Kerberos credential cache. The client must
login to the Microsoft Domain Controller.

javax.security.auth.login.LoginContext lc = null;

try {
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(null, null, null, true));
// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determines how authentication data is collected
// in this case, the authentication date is collected by stdin prompt
// and passed to the authentication mechanism implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " + e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resource using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected enterprise bean
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}

WSKRB5Login モジュール

WSKRB5Login JAAS ログイン構成: 汎用的な JAAS ログイン構成であり、Java クライアント、クライアント・コンテナー・アプリケーション、サーブレット、JSP ファイル、またはエンタープライズ Bean がこれを使用すると、WebSphere Application Server セキュリティー・ランタイムに対して、Kerberos プリンシパル名パスワードまたは Kerberos クレデンシャル・キャッシュに基づく認証を実行することができます。 ただし、この構成は、クライアント・コンテナーのデプロイメント記述子で指定した CallbackHandler ハンドラーを サポートしません。

作成済みの krb5.ini または krb5.conf ファイルを、デフォルトのロケーションに配置してください。 どちらのファイルも、デフォルトのロケーションにない場合は、正しいパスおよび Kerberos 構成ファイル名を使用して、java.security.krb5.conf JVM システム・プロパティーを設定する必要があります。

Windows® プラットフォームでは、デフォルトのロケーションは c:¥winnt¥krb5.ini です。

Linux® プラットフォームでは、デフォルトのロケーションは /etc/krb5.conf です。

その他の Unix プラットフォームでは、デフォルトのロケーションは /etc/krb5/krb5.conf です。

z/OS プラットフォームでは、デフォルトのロケーションは /etc/krb5/krb5.conf です。

Kerberos 構成設定、Kerberos 鍵配布センター (KDC) 名、およびレルム設定は、Kerberos 構成ファイルで、または java.security.krb5.kdc および java.security.krb5.realm システム・プロパティー・ファイルを介して提供されます。

標準入力プロンプト・プログラマチック・ログイン

WebSphere Application Server は、javax.security.auth.callback.CallbackHandler インターフェースの標準入力実装も提供します。 このコールバック・ハンドラー、com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl は、 プロンプトを出して、標準入力プロンプトを介してユーザーから認証データを収集します。
javax.security.auth.login.LoginContext lc = null;

try {
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl());

// create a LoginContext and specify a CallbackHandler implementation
// CallbackHandler implementation determines how authentication data is collected
// in this case, the authentication date is collected by stdin prompt
// and passed to the authentication mechanism implemented by the LoginModule.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: failed to instantiate a LoginContext and the exception: " + e.getMessage());
e.printStackTrace();

// maybe javax.security.auth.AuthPermission "createLoginContext" is not granted
//   to the application, or the JAAS login configuration is not defined.
}

if (lc != null)
try {
lc.login();  // perform login
javax.security.auth.Subject s = lc.getSubject();
// get the authenticated subject

// Invoke a Java EE resource using the authenticated subject
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try {
bankAccount.deposit(100.00);  // where bankAccount is a protected enterprise bean
} catch (Exception e) {
System.out.println("ERROR: error while accessing EJB resource, exception: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("ERROR: login failed with exception: " + e.getMessage());
e.printStackTrace();

// login failed, might want to provide relogin logic
}
重要: com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl コールバック・ハンドラーは、エンタープライズ Bean、サーブレット、JSP ファイルなどのサーバー・サイド・リソースでは使用しないでください。 標準入力プロンプトから入力したデータは、サーバー環境へは送信されません。 バックグラウンドで実行されるほとんどのサーバーにはコンソールがありません。 ただし、サーバーにコンソールがある場合には、標準入力プロンプトは、そのサーバーがユーザー入力を行わないようにブロックします。 この振る舞いは、サーバー・プロセスにとってよくありません。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_programlog
ファイル名:csec_programlog.html