Identitätszuordnung für eingehende Anforderungen konfigurieren

Hinsichtlich der Identitätszuordnung für eingehende Anforderungen wird empfohlen, dass Sie ein angepasstes Anmeldemodul schreiben und WebSphere Application Server dahingehend konfigurieren, dass er das Anmeldemodul innerhalb der Konfigurationen für die Systemanmeldung zuerst ausführt. Beachten Sie beim Schreiben Ihres Anmeldemoduls die folgenden Schritte.

Vorgehensweise

  1. Rufen Sie die Benutzeridentität für eingehende Anforderungen aus den Callbacks ab, und ordnen Sie die Identität zu, falls erforderlich. Dieser Schritt wird in der Methode login des Anmeldemoduls ausgeführt. Eine gültige Authentifizierung enthält die folgenden Callbacks: NameCallback und/oder WSCredTokenCallback. Das folgende Codebeispiel veranschaulicht, wie die Benutzeridentität bestimmt wird:
    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)
    	{
    			// Behandlung der Ausnahmen
    				throw new WSLoginFailedException (e.getMessage(), e);
    	}
    
    		// Anzeigen, welche Callbacks Informationen enthalten
    		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);
           // Die Zeichenfolge auf die UID setzen, damit das Ergebnis für die
           // Zuordnung oder die Anmeldung verwendet werden kann.
    						uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID);
    		}
    		catch (Exception e)
    		{
    						// Ausnahme behandeln
    		}	
    	}
    		else if (uid == null)
    	{
         // Löst eine Ausnahme aus, wenn die Authentifizierungsdaten nicht gültig sind.
         // Sie benötigen die UID oder das CredToken.
    				throw new WSLoginFailedException("invalid authentication data.");
    	}
    		else if (uid != null && password != null)
    	{
         // Dies ist eine typische Authentifizierung. Sie können festlegen, dass diese ID einer anderen ID
         // zugeordnet werden soll oder Sie können den Schritt überspringen und WebSphere Application Server
         // die Anmeldung durchführen lassen. Wenn Kennwörter angegeben werden, achten Sie darauf,
         // das Kennwort zu validieren, da es sich um die erste Authentifizierung handelt.
    		
    		return true;
    	}
    
        // Sie können diese UID nach Bedarf einem anderen Element zuordnen und identitySwitched
        // boolean setzen. Wurde die Identität geändert, löschen Sie unten die weitergegebenen
        // Attribute, damit sie nicht falsch verwendet werden.
    		uid = myCustomMappingRoutine (uid);
    	
        // Löschen Sie die weitergegebenen Attribute, da sie für die neue
        // Identität nicht mehr gültig sind.
    		if (identitySwitched)
    	{
    				((WSTokenHolderCallback) callbacks[3]).setTokenHolderList(null);
    	}
  2. Prüfen Sie, ob Attribute weitergegeben wurden und die Attribute für den Benutzer bereits vorhanden sind, wenn die Identität gleich bleibt. Prüfen Sie, ob die vom Server zu sendenden Benutzerattribute bereits eingetroffen sind, um den Lookup der Benutzerregistry nicht unnötigerweise zweimal aufzurufen. Führen Sie für die Suche nach Benutzerattributen eine Methode für den WSTokenHolderCallback aus, die die im Callback vorhandenen Information analysiert. Auf diese Weise können Sie feststellen, ob die Informationen ausreichen für das Erstellen eines Subjekts durch den WebSphere Application Server. Das folgende Codebeispiel sucht nach den Benutzerattributen:
    boolean requiresLogin = 
    ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) 
    callbacks[2]).getrequiresLogin();
    Wenn keine Attribute vorhanden sind, die ausreichen, um die für die Berechtigung erforderlichen WSCredential- und WSPrincipal-Objekte zu erstellen, gibt das vorherige Codebeispiel ein Ergebnis mit dem Wert true zurück. Wird ein Ergebnis mit dem Wert false zurückgegeben, können Sie festlegen, dass die Verarbeitung gestoppt werden soll, da Sie genügend Informationen haben, um das Subjekt zu erstellen, ohne zusätzliche Fernaufrufe der Benutzerregistry durchzuführen.
  3. Optional: Suchen Sie die erforderlichen Attribute in der Benutzerregistry, stellen Sie die Attribute in die Hashtabelle (hashtable), und versetzen Sie die Hashtabelle in den Status für gemeinsame Nutzung (sharedState). Wenn die Identität in diesem Anmeldemodul gewechselt wird, müssen Sie die folgenden Schritte ausführen:
    1. Erstellen Sie die Hashtabelle (hashtable) mit Attributen, wie im folgenden Beispiel dargestellt.
    2. Versetzen Sie die Hashtabelle in den Status für gemeinsame Nutzung (sharedState).
    Wenn die Identität nicht gewechselt wird, der Wert des zuvor gezeigten Codebeispiels requiresLogin jedoch den Wert true hat, können Sie die Hashtabelle mit Attributen erstellen. Sie müssen in dieser Situation jedoch keine Hashtabelle erstellen, da WebSphere Application Server die Anmeldung für Sie durchführt. Sie können jedoch eine Hashtabelle erstellen, um Attribute in besonderen Fällen, in denen Sie Ihre eigene Benutzerregistry verwenden, zu erfassen. Die einfachste Lösung kann sein, eine UserRegistry-Implementierung mit einer Hashtabelle zu erstellen und WebSphere Application Server die Benutzerattribute erfassen zu lassen. Die folgende Tabelle veranschaulicht, wie eine Hashtabelle (hashtable) mit Benutzerattributen erstellt wird:
    if (requiresLogin || identitySwitched)
    	{
    				// Standard-InitialContext für den Server abrufen
    		javax.naming.InitialContext ctx = new javax.naming.InitialContext();
    
    				// Ruft die lokale UserRegistry-Implementierung ab.
    				com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.
            security.UserRegistry) 
    				ctx.lookup("UserRegistry");				
    
         // Ruft die uniqueID der Benutzerregistry ab, die auf der im
         // NameCallback angegebenen Benutzer-ID basiert.
    				String uniqueid = reg.getUniqueUserId(uid);
    	 				uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueid);
    			
         // Ruft den auf der uniqueID basierenden Anzeigenamen von der Benutzerregistry ab.
    				String securityName = reg.getUserSecurityName(uid);
    	
         // Ruft die der uniqueID zugeordneten Gruppen ab.
    				java.util.List groupList = reg.getUniqueGroupIds(uid);
    			
         // Erstellt die java.util.Hashtable mit den Informationen, die Sie
         // in der UserRegistry-Implementierung erfasst haben.
    				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);
    
         // Fügt einen Cacheschlüssel hinzu, der als Teil des Mechanismus für die Suche nach
         // dem erstellten Subject verwendet wird. Der Cacheschlüssel kann ein Objekt sein,
         // muss jedoch eine implementierte Methode toString besitzen. Vergewissern Sie
         // sich, dass der cacheKey genügend Informationen enthält, um den Benutzer und alle
         // weiteren verwendeten Attribute abzudecken. Wenn Sie diese Eigenschaft nicht angeben,
         // gilt das Subjekt standardmäßig für die zurückgegebene WSCREDENTIAL_UNIQUEID.
    		hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid);
    						// Fügt die Hashtabelle zum sharedState-Element des Subjekts hinzu
    				_sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_PROPERTIES_KEY, hashtable);
    	}
    Die folgenden Regeln definieren detailliert, wie eine Anmeldung über die Hashtabelle durchgeführt wird. Sie müssen ein java.util.Hashtable-Objekt im Subjekt (öffentlicher oder privater Satz mit Berechtigungsnachweisen) oder in der sharedState Hashmap verwenden. Die Klasse com.ibm.wsspi.security.token.AttributeNameConstants definiert die Schlüssel mit den Benutzerinformationen. Wenn das hashtable-Objekt mit einem angepassten Anmeldemodul, das vor dem LTPA-Anmeldemodul (Lightweight Third Party Authentication) aufgelistet ist, in den Status für gemeinsame Nutzung des Anmeldekontextes versetzt wird, wird der Wert des Objekts java.util.Hashtable in der sharedState hashMap mit dem folgenden Schlüssel durchsucht:
    Eigenschaft
    com.ibm.wsspi.security.cred.propertiesObject
    Referenz auf die Eigenschaft
    AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
    Erläuterung
    Dieser Schlüssel sucht nach dem Hashtable-Objekt, das die erforderlichen Eigenschaften im gemeinsam genutzten Status des Anmeldekontextes enthält.
    Erwartetes Ergebnis
    Ein java.util.Hashtable-Objekt.

    Wenn ein Objekt java.util.Hashtable im Subjekt oder im gemeinsam genutzten Statusbereich ermittelt wurde, vergewissern Sie sich, dass die folgenden Eigenschaften in der Hashtabelle vorhanden sind:

    Eigenschaft
    com.ibm.wsspi.security.cred.uniqueId
    Referenz auf die Eigenschaft
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    Rückgabewerte
    java.util.String
    Erläuterung
    Der Eigenschaftswert muss den Benutzer eindeutig bezeichnen. Für die Standardimplementierung von WebSphere Application Server gibt diese Eigenschaft die Informationen an, die in der Tabelle für Anwendungsberechtigungen gespeichert sind. Die Informationen werden im Anwendungsimplementierungsdeskriptor gespeichert, nachdem sie implementiert wurden und die Zuordnung von Benutzern zu Rollen durchgeführt wurde. Prüfen Sie in den Beispielen für das erwartete Format, ob die Zuordnung von Benutzern zu Rollen mit einem Lookup in der Implementierung der Benutzerregistry von WebSphere Application Server durchgeführt wurde.

    Wenn der Berechtigungsprovider eines Fremdanbieters die Zuordnung von Benutzern zu Rollen überschreibt, definiert dieser Provider das Format. Um die Kompatibilität mit der Standardimplementierung von WebSphere Application Server hinsichtlich des Wertes für die eindeutige ID sicherzustellen, müssen Sie die UserRegistry-Methode "WebSphere Application Server public String getUniqueUserId(String userSecurityName)" aufrufen.

    Erwartete Formatbeispiele
    Tabelle 1. Formatbeispiele.

    Diese Tabelle enthält Formatbeispiele für die Konfiguration der Zuordnung eingehender Identitäten.

    Realm Format (uniqueUserId)
    Lightweight Directory Access Protocol (LDAP) ldaphost.austin.ibm.com:389/cn=user,o=ibm,c=us
    Windows MEINWINHOST/S-1-5-21-963918322-163748893-4247568029-500
    UNIX MEINUNIXHOST/32

    Die Eigenschaft "com.ibm.wsspi.security.cred.uniqueId" ist erforderlich.

    Eigenschaft
    com.ibm.wsspi.security.cred.securityName
    Referenz auf die Eigenschaft
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    Rückgabewerte
    java.util.String
    Erläuterung
    Diese Eigenschaft sucht nach dem securityName des Benutzers der Authentifizierung. Dieser Name wird im Allgemeinen als Anzeigename oder Kurzname bezeichnet. WebSphere Application Server verwendet das Attribut securityName für die APIs getRemoteUser, getUserPrincipal und getCallerPrincipal. Um die Kompatibilität mit der Standardimplementierung von WebSphere Application Server hinsichtlich des securityName-Wertes sicherzustellen, müssen Sie die UserRegistry-Methode "WebSphere Application Server public String getUserSecurityName(String uniqueUserId)" aufrufen.
    Erwartete Formatbeispiele
    Tabelle 2. Formatbeispiele. Diese Tabelle enthält Beispiele für erwartete Formate.
    Realm Format (uniqueUserId)
    LDAP user (UID für LDAP)
    Windows user (Windows username)
    UNIX user (UNIX username)

    Die Eigenschaft "com.ibm.wsspi.security.cred.securityName" ist erforderlich.

    Eigenschaft
    com.ibm.wsspi.security.cred.groups
    Referenz auf die Eigenschaft
    AttributeNameConstants. WSCREDENTIAL_GROUPS
    Rückgabewerte
    java.util.ArrayList
    Erläuterung
    Dieser Schlüssel sucht nach der Array-Liste der Gruppen, zu der dieser Benutzer gehört. Die Gruppen werden im Format Realmname/Benutzername angegeben. Das Format dieser Gruppen ist wichtig, da die Engine von WebSphere Application Server für Berechtigungen die Gruppen Rollen zuordnet. Das Format muss mit dem von der Standardimplementierung von WebSphere Application Server erwarteten Format übereinstimmen. Wenn Sie den Berechtigungsprovider eines Fremdanbieters verwenden, müssen Sie das Format, das von diesem Provider erwartet wird, verwenden. Zur Gewährleistung der Kompatibilität mit der Standardimplementierung von WebSphere Application Server für die eindeutigen Gruppen-IDs rufen Sie die Methode "public List getUniqueGroupIds(String uniqueUserId) UserRegistry" von WebSphere Application Server auf.
    Erwartete Formatbeispiele für alle Gruppen in der Array-Liste
    Tabelle 3. Formatbeispiele. Diese Tabelle enthält Beispiele für erwartete Formate für alle Gruppen in der Array-Liste.
    Realm Format
    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

    Die Eigenschaft "com.ibm.wsspi.security.cred.groups" ist nicht erforderlich. Einem Benutzer müssen keine Gruppen zugeordnet sein.

    Eigenschaft
    com.ibm.wsspi.security.cred.cacheKey
    Referenz auf die Eigenschaft
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    Rückgabewerte
    java.lang.Object
    Erläuterung
    Dieses Schlüsseleigenschaft kann ein Objekt angeben, das die eindeutigen Eigenschaften der Anmeldung beinhaltet. Dazu gehören die benutzerspezifischen Daten und die dynamischen Benutzerattribute, die die Eindeutigkeit beeinträchtigen können. Wenn der Benutzer sich beispielsweise an Position A anmeldet, was sich möglicherweise auf die Zugangssteuerung auswirkt, muss der Cacheschlüssel Position A beinhalten, damit das empfangene Subjekt für die aktuelle Position gültig ist.

    Die Eigenschaft "com.ibm.wsspi.security.cred.cacheKey" ist nicht erforderlich. Wenn diese Eigenschaft nicht angegeben ist, ist die Cachesuche der für WSCREDENTIAL_UNIQUEID angegebene Wert. Wenn diese Information im Objekt java.util.Hashtable ermittelt wird, erstellt WebSphere Application Server ein Subject, das dem beim normalen Anmeldungsprozess verwendeten Subject ähnelt (zumindest für LTPA). Das neue Subjekt enthält ein WSCredential-Objekt und ein WSPrincipal-Objekt, das vollständig mit den im hashtable-Objekt ermittelten Informationen gefüllt ist.

  4. Fügen Sie das angepasste Anmeldemodul zu den folgenden Konfigurationen der JAAS-Systemanmeldung (Java™ Authentication and Authorization Service) hinzu: RMI_INBOUND, WEB_INBOUND und DEFAULT. Konfigurieren Sie die Anmeldekonfiguration RMI_INBOUND, damit WebSphere Application Server das neue angepasste Anmeldemodul zuerst lädt.
    1. Klicken Sie auf Sicherheit > Globale Sicherheit > Java Authentication and Authorization Service > Systemanmeldungen > RMI_INBOUND.
    2. Klicken Sie unter "Weitere Eigenschaften" auf JAAS-Anmeldemodule > Neu, um das Anmeldemodul der Konfiguration RMI_INBOUND hinzuzufügen.
    3. Kehren Sie in die Anzeige "JAAS-Anmeldemodule" für RMI_INBOUND zurück.
    4. Klicken Sie auf Reihenfolge festlegen, um die Reihenfolge, in der die Anmeldemoduls geladen werden, so zu ändern, dass WebSphere Application Server das angepasste Anmeldemodul zuerst lädt. Verwenden Sie die Schaltflächen Nach oben und Nach unten, um die Reihenfolge der Anmeldemodule anzupassen.
    5. Wiederholen Sie die vorherigen drei Schritte entsprechend für die Anmeldekonfigurationen WEB_INBOUND und DEFAULT.

Ergebnisse

Mit diesem Prozess wird die Identitätszuordnung für eine eingehende Anforderung konfiguriert.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_configinbidentmap
Dateiname:tsec_configinbidentmap.html