インバウンド ID マッピングの構成

インバウンド ID マッピングでは、カスタム・ログイン・モジュールを作成し、 システム・ログイン構成の中でログイン・モジュールを最初に実行するように WebSphere® Application Server を構成します。 カスタム・ログイン・モジュールを作成する場合は、次のステップを考慮してください。

手順

  1. 必要に応じて、コールバックからインバウンド・ユーザー ID を取得し、その ID をマップします。 このステップはログイン・モジュールのログイン・メソッドで行われます。 有効な認証には、NameCallback と WSCredTokenCallback コールバックのいずれかまたは両方が存在します。 次のコード・サンプルは、ユーザー ID の決定方法を示しています。
    javax.security.auth.callback.Callback callbacks[] =
       new javax.security.auth.callback.Callback[3];
    		callbacks[0] = new javax.security.auth.callback.NameCallback("");
    	callbacks[1] = new javax.security.auth.callback.PasswordCallback
         ("Password: ", false);
    			callbacks[2] = new com.ibm.websphere.security.auth.callback.
         WSCredTokenCallbackImpl("");
    			callbacks[3] = new com.ibm.wsspi.security.auth.callback.
         WSTokenHolderCallback("");
    
    	try
    	{
    		                callbackHandler.handle(callbacks);
    	} 
    	catch (Exception e)
    	{
    		// Handles exceptions
    				throw new WSLoginFailedException (e.getMessage(), e);
    	}
    
    		// Shows which callbacks contain information
    		boolean identitySwitched = false;
    		String uid = ((NameCallback) callbacks[0]).getName();
    		char password[] = ((PasswordCallback) callbacks[1]).getPassword();
    		byte[] credToken = ((WSCredTokenCallbackImpl) callbacks[2]).getCredToken();
    			java.util.List authzTokenList = ((WSTokenHolderCallback) 
         callbacks[3]).getTokenHolderList();
    
    	if (credToken != null)
    	{
    		try
    		{
    						String uniqueID = WSSecurityPropagationHelper.validateLTPAToken(credToken);
    						String realm = WSSecurityPropagationHelper.getRealmFromUniqueID (uniqueID);
           			// Now set the string to the UID so that you can use the result for either
           // mapping or logging in.
    				 	uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID);
    		}
    		catch (Exception e)
    		{
    			// Handles the exception
    		}	
    	}
    		else if (uid == null)
    	{
         // Throws an exception if authentication data is not valid.
         // You must have either UID or CredToken
    				throw new WSLoginFailedException("invalid authentication data.");
    	}
    		else if (uid != null && password != null)
    	{
         		// This is a typical authentication. You can choose to map this ID to
         // another ID or you can skip it and allow WebSphere Application Server
         // to log in for you. When passwords are presented, be very careful to not 
         // validate the password because this is the initial authentication.
    		
    		return true;
    	}
    
        // If desired, map this uid to something else and set the identitySwitched 
        // boolean. If the identity was changed, clear the propagated attributes 
        // below so they are not used incorrectly.
    		uid = myCustomMappingRoutine (uid);
    	
        // Clear the propagated attributes because they are no longer applicable 
        // to the new identity
    		if (identitySwitched)
    	{
    				((WSTokenHolderCallback) callbacks[3]).setTokenHolderList(null);
    	}
  2. ID が同じままである場合は、属性の伝搬が行われたかどうか、ユーザーの属性が既に存在しているかどうかを確認してください。 ユーザー・レジストリー検索への重複呼び出しを回避するため、ユーザー属性が送信サーバーで既に存在しているかどうかを確認してください。 ユーザー属性を確認するには、WSTokenHolderCallback コールバックでメソッドを使用してコールバック内の情報を分析し、WebSphere Application Server が Subject を作成するために十分な情報があるかどうかを判断します。次のコード・サンプルはユーザー属性を確認するものです。
    boolean requiresLogin =
    ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) 
    callbacks[2]).getrequiresLogin();
    許可の実行に必要な WSCredential および WSPrincipal オブジェクトを形成するのに 十分な属性が存在しない場合、上記のコード・サンプルは true の結果を戻します。 結果が false の場合、Subject を作成するのに必要な情報が存在するため、追加のリモート・ユーザー・レジストリー呼び出しを実行することなく、処理の中止を選択することができます。
  3. オプション: ユーザー・レジストリーから必要な属性を検索し、 hashtable にその属性を置いて、その hashtable を共有状態に追加します。 ID がこのログイン・モジュールで切り替えられる場合、次のステップを実行する必要があります。
    1. 次の例で示されているように属性の hashtable を作成します。
    2. hashtable を共有状態に追加します。
    ID が切り替えられていないにもかかわらず、先に示された requiresLogin コード・サンプルの値が true の場合、 属性の hashtable を作成することができます。ただし、WebSphere Application Server がログインを処理するため、 この状態で hashtable を作成する必要はありません。しかし、ユーザー自身の特別なユーザー・レジストリーを使用しているというような特別な場合に、 属性を収集するために hashtable の作成が必要になることがあります。UserRegistry 実装の作成、hashtable の使用、 および WebSphere Application Server による属性の収集が、 最も簡単な解決策となることがあります。次のテーブルはユーザー属性の hashtable の作成方法を示します。
    if (requiresLogin || identitySwitched)
    	{
    				// Retrieves the default InitialContext for this server.
    		javax.naming.InitialContext ctx = new javax.naming.InitialContext();
    
    				// Retrieves the local UserRegistry implementation.
    		com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.
            security.UserRegistry) 
    				ctx.lookup("UserRegistry");				
    
         // Retrieves the user registry uniqueID based on the uid specified
         // in the NameCallback.
    				String uniqueid = reg.getUniqueUserId(uid);
    	 		 	uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueid);
    			
         		// Retrieves the display name from the user registry based on the uniqueID.
    				String securityName = reg.getUserSecurityName(uid);
    	
         		// Retrieves the groups associated with the uniqueID.
    				java.util.List groupList = reg.getUniqueGroupIds(uid);
    			
         		// Creates the java.util.Hashtable with the information that you gathered 
         // from the UserRegistry implementation.
    				java.util.Hashtable hashtable = new java.util.Hashtable();
    					hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_UNIQUEID, uniqueid);
         			hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_SECURITYNAME, securityName);
    					hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_GROUPS, groupList);
    
         // Adds a cache key that is used as part of the lookup mechanism for
         // the created Subject. The cache key can be an object, but should have  
         // an implemented toString method. Make sure that the cacheKey contains 
         // enough information to scope it to the user and any additional attributes 
         // that you are using. If you do not specify this property the Subject is 
         // scoped to the returned WSCREDENTIAL_UNIQUEID, by default.
    					hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid);
    				// Adds the hashtable to the sharedState of the Subject.
    						_sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_PROPERTIES_KEY, hashtable);
    	}
    次の規則によって、hashtable ログインの実行方法が詳細にわたって定義されます。Subject (公開クレデンシャルまたは秘密クレデンシャルのセット) または共有状態 HashMap のいずれかで java.util.Hashtable オブジェクトを使用する必要があります。 com.ibm.wsspi.security.token.AttributeNameConstants クラスは、ユーザー情報を含む鍵を定義します。 hashtable オブジェクトが、Lightweight Third Party Authentication (LTPA) ログイン・モジュールの前にリストされるカスタム・ログイン・モジュールを使用して、ログイン・コンテキストの共有状態に置かれている場合、java.util.Hashtable オブジェクトの値は共有状態 hashMap 内で次の鍵を使用して検索されます。
    プロパティー
    com.ibm.wsspi.security.cred.propertiesObject
    プロパティーの参照
    AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
    説明
    この鍵が、ログイン・コンテキストの共有状態に必要なプロパティーを含むハッシュ・テーブル・オブジェクトを検索します。
    期待される結果
    A java.util.Hashtable object.

    java.util.Hashtable オブジェクトが Subject 内または共有状態領域で検出された場合、 次のプロパティーがハッシュ・テーブルにあるか検査してください。

    プロパティー
    com.ibm.wsspi.security.cred.uniqueId
    プロパティーの参照
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    戻り
    java.util.String
    説明
    プロパティーの値はユーザー固有の表記でなければなりません。 WebSphere Application Server のデフォルトの実装では、このプロパティーは、 アプリケーション許可テーブルに保管される情報を示します。 情報は、デプロイされてユーザーからロールへのマッピングが実行された後、アプリケーションのデプロイメント記述子に配置されます。 ユーザーからロールへのマッピングが WebSphere Application Server ユーザー・レジストリー実装に対する検索を使用して実行される場合は、予想されるフォーマットの例を参照してください。

    サード・パーティーの許可プロバイダーがユーザーからロールへのマッピングをオーバーライドする場合は、 サード・パーティーの許可プロバイダーがフォーマットを定義します。 固有の ID 値のために WebSphere Application Server のデフォルトの実装との互換性を確実にするには、 WebSphere Application Server の public String getUniqueUserId(String userSecurityName) UserRegistry メソッドを呼び出します。

    予想されるフォーマットの例
    表 1. フォーマットの例.

    この表では、インバウンド識別マッピングを構成する際のいくつかのフォーマット例を示します。

    レルム フォーマット (uniqueUserId)
    Lightweight Directory Access Protocol (LDAP) ldaphost.austin.ibm.com:389/cn=user,o=ibm,c=us
    Windows MYWINHOST/S-1-5-21-963918322-163748893-4247568029-500
    UNIX MYUNIXHOST/32

    com.ibm.wsspi.security.cred.uniqueId プロパティーが必要です。

    プロパティー
    com.ibm.wsspi.security.cred.securityName
    プロパティーの参照
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    戻り
    java.util.String
    説明
    このプロパティーは認証ユーザーの securityName を検索します。 この名前は一般的に 表示名 または ショート・ネーム と呼ばれます。 WebSphere Application Server は、getRemoteUser、getUserPrincipal、および getCallerPrincipal アプリケーション・プログラミング・インターフェース (API) の securityName 属性を使用します。 securityName 値のために WebSphere Application Server のデフォルトの実装との互換性を確実にするには、 WebSphere Application Server の public String getUserSecurityName(String uniqueUserId) UserRegistry メソッドを呼び出します。
    予想されるフォーマットの例
    表 2. フォーマットの例. 次の表に、期待されるフォーマットの例を示します。
    レルム フォーマット (uniqueUserId)
    LDAP ユーザー (LDAP UID)
    Windows user (Windows username)
    UNIX user (UNIX username)

    com.ibm.wsspi.security.cred.securityName プロパティーが必要です。

    プロパティー
    com.ibm.wsspi.security.cred.groups
    プロパティーの参照
    AttributeNameConstants. WSCREDENTIAL_GROUPS
    戻り
    java.util.ArrayList
    説明
    この鍵は、このユーザーが属するグループの配列リストを検索します。 このグループは、realm_name/user_name フォーマットで指定されます。 これらのグループのフォーマットは、グループがデプロイメント記述子でロールへのグループのマッピングのために WebSphere Application Server の許可エンジンが使用するため重要です。 提供されるフォーマットは、 WebSphere Application Server のデフォルトの実装で要求されるフォーマットと一致している必要があります。 サード・パーティーの許可プロバイダーを使用している場合、サード・パーティー・プロバイダーで要求されるフォーマットを使用する必要があります。 固有のグループ ID 値について WebSphere Application Server のデフォルトの実装との互換性を確実にするには、 WebSphere Application Server の public List getUniqueGroupIds(String uniqueUserId) UserRegistry メソッドを呼び出します。
    配列リストの各グループで要求されるフォーマットの例
    表 3. フォーマットの例. 次の表に、配列リストの各グループで期待されるフォーマットの例を示します。
    レルム フォーマット
    LDAP ldap1.austin.ibm.com:389/cn=group1,o=ibm,c=us
    Windows MYWINREALM/S-1-5-32-544
    UNIX MY/S-1-5-32-544

    com.ibm.wsspi.security.cred.groups プロパティーは必要ではありません。 ユーザーは関連グループを持っている必要はありません。

    プロパティー
    com.ibm.wsspi.security.cred.cacheKey
    プロパティーの参照
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    戻り
    java.lang.Object
    説明
    この鍵プロパティーは、ユーザー固有の情報と固有性に影響を与える可能性があるユーザー動的属性を含む ログインの固有のプロパティーを示すオブジェクトを指定することができます。 例えば、ユーザーがアクセス制御に影響を与える可能性があるロケーション A からログインする場合、 受け取った Subject が現在のロケーションの正しい Subject となるよう、キャッシュ・キーは、ロケーション A を含む必要があります。

    com.ibm.wsspi.security.cred.cacheKey プロパティーは必要ではありません。 このプロパティーが指定されない場合、キャッシュ検索は WSCREDENTIAL_UNIQUEID に指定される値です。 この情報が java.util.Hashtable オブジェクトにある場合、少なくとも、LTPA の場合、WebSphere Application Server は、 通常のログイン・プロセスを行う Subject に似た Subject を作成します。 新規 Subject には、hashtable オブジェクトで検出される情報が完全に取り込まれている WSCredential オブジェクトおよび WSPrincipal オブジェクトが含まれます。

  4. RMI_INBOUND、WEB_INBOUND、および DEFAULT Java™ Authentication and Authorization Service (JAAS) システム・ログイン構成にカスタム・ログイン・モジュールを追加します。 WebSphere Application Server が新規のカスタム・ログイン・モジュールを最初にロードするように、 RMI_INBOUND ログイン構成を構成します。
    1. セキュリティー」>「グローバル・セキュリティー」>「Java 認証・承認サービス (JAAS)」> 「システム・ログイン」>「RMI_INBOUND」をクリックします。
    2. 追加プロパティーの下で、「JAAS ログイン・モジュール」>「新規」とクリックして、 ログイン・モジュールを RMI_INBOUND 構成に追加します。
    3. RMI_INBOUND の「JAAS ログイン・モジュール」パネルに戻ります。
    4. 「順序の設定」をクリックして、WebSphere Application Server がカスタム・ログイン・モジュールを最初にロードするように、ログイン・モジュールのロード順序を変更します。上へ移動」または「下へ移動」のボタンを使用して、 ログイン・モジュールの順序を調整します。
    5. WEB_INBOUND および DEFAULT ログイン構成用に先の 3 つのステップを繰り返します。

タスクの結果

このプロセスによって、インバウンド要求の ID マッピングが構成されます。

トピックのタイプを示すアイコン タスク・トピック



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