Angepasste Anmeldemodule für eine Systemanmeldekonfiguration für JAAS entwickeln
Für WebSphere Application Server sind mehrere JAAS-Plug-in-Punkte (Java™ Authentication and Authorization Service) für die Konfiguration von Systemanmeldungen vorhanden. WebSphere Application Server verwendet Systemanmeldekonfigurationen zum Authentifizieren eingehender Anforderungen, abgehender Anforderungen und interner Serveranmeldungen.
Informationen zu diesem Vorgang
- WEB_INBOUND
- RMI_OUTBOUND
- RMI_INBOUND
- DEFAULT
Vorgehensweise
- Authentifizieren Sie Webanforderungen mit der Anmeldekonfiguration "WEB_INBOUND".
Die Anmeldekonfiguration "WEB_INBOUND" authentifiziert Webanforderungen.
Ausführliche Informationen zur Konfiguration WEB_INBOUND und den zugehörigen Callbacks finden Sie im Abschnitt "RMI_INBOUND, WEB_INBOUND, DEFAULT" im Artikel Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service.
Abbildung 1 zeigt eine Beispielkonfiguration mit einem TAI (Trust Association Interceptor), der aus den an die Anmeldekonfiguration "WEB_INBOUND" übergebenen Ausgangsinformationen ein Subjekt erstellt. Wenn der TAI nicht konfiguriert ist, greift der Authentifizierungsprozess direkt auf die Systemanmeldekonfiguration "WEB_INBOUND" zu, die aus allen in Abbildung 1 zusammengefassten Anmeldemodulen besteht. Abbildung 1 zeigt, an welcher Stelle eigene Anmeldemodule als Plug-in integriert werden können und wo die Anmeldungsmodule ltpaLoginModule und wsMapDefaultInboundLoginModule erforderlich sind.Abbildung 1. Anmeldekonfiguration WEB_INBOUND - Bearbeiten Sie abgehende Anforderungen mit der Anmeldekonfiguration "RMI_OUTBOUND".
Die Anmeldekonfiguration RMI_OUTBOUND ist ein Verbindungspunkt für die Bearbeitung abgehender Anforderungen. WebSphere Application Server verwendet diesen Verbindungspunkt, um die serialisierten Informationen zu erstellen, die ausgehend vom übergebenen Aufrufsubjekt und anderen Daten des Sicherheitskontexts wie Weitergabetoken an nachgeschaltete Server gesendet werden. Ein eigenes Anmeldemodul kann diesen Verbindungspunkt nutzen, um die Identität zu ändern. Weitere Informationen hierzu finden Sie im Artikel Identitätszuordnung für abgehende Anforderungen für einen anderen Zielrealm konfigurieren. Abbildung 2 zeigt, an welcher Stelle Sie eigene Anmeldemodule integrieren können und wo das Anmeldemodul wsMapCSIv2OutboundLoginModule erforderlich ist.
Abbildung 2. Anmeldekonfiguration RMI_OUTBOUNDNähere Informationen zur Anmeldekonfiguration RMI_OUTBOUND einschließlich der zugehörigen Callbacks finden Sie im Abschnitt "RMI_OUTBOUND" im Artikel Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service.
- Bearbeiten Sie eingehende Authentifizierungen von EJB-Anforderungen mit der Anmeldekonfiguration "RMI_INBOUND".
Die Anmeldekonfiguration "RMI_INBOUND" ist ein Verbindungspunkt, der die eingehende Authentifizierung für Enterprise-Bean-Anforderungen bearbeitet. WebSphere Application Server verwendet diesen Verbindungspunkt für eine Erstanmeldung oder eine weitergegebene Anmeldung. Weitere Informationen zu diesen beiden Anmeldetypen enthält der Artikel Weitergabe von Sicherheitsattributen. Bei einer weitergegebenen Anmeldung wird dieser Verbindungspunkt verwendet, um die von einem übergeordneten Server empfangenen Informationen zu entserialisieren. Ein eigenes Anmeldemodul kann diesen Verbindungspunkt nutzen, um die Identität zu ändern, angepasste Token zu bearbeiten, angepasste Objekte zum Subjekt hinzuzufügen usw. Weitere Informationen zum Ändern der Identität mit einem Hashtable-Objekt, wie es in Abbildung 3 gezeigt ist, finden Sie im Artikel Identitätszuordnung für eingehende Anforderungen konfigurieren. Abbildung 3 zeigt, an welcher Stelle Sie eigene Anmeldemodule integrieren können und dass die Anmeldmodule ltpaLoginModule und wsMapDefaultInboundLoginModule erforderlich sind.
Abbildung 3. Anmeldekonfiguration RMI_INBOUNDNähere Informationen zur Anmeldekonfiguration RMI_INBOUND einschließlich der zugehörigen Callbacks finden Sie im Abschnitt "RMI_INBOUND, WEB_INBOUND, DEFAULT" im Artikel Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service.
- Bearbeiten Sie alle anderen Typen von Authentifizierungsanforderungen mit der Anmeldekonfiguration "DEFAULT_login". Anmeldekonfiguration DEFAULT
Die Anmeldekonfiguration DEFAULT ist ein Verbindungspunkt, der alle anderen Arten von Authentifizierungsanforderungen bearbeitet. Dazu gehören administrative SOAP-Anforderungen und die interne Authentifizierung der Server-ID. Weitergegebene Anmeldungen finden an diesem Punkt in der Regel nicht statt.
Weitere Informationen zur Anmeldekonfiguration DEFAULT und den zugehörigen Callbacks finden Sie im Abschnitt "RMI_INBOUND, WEB_INBOUND, DEFAULT" im Artikel Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service.
- Entwickeln Sie Logik für die Anmeldekonfiguration, um festzustellen, wann bestimmte Informationen vorhanden und wie diese Informationen zu verwenden sind. Anmeldemodul schreiben
Wenn Sie ein Anmeldemodul schreiben, das in einer Anwendungsanmeldekonfiguration oder Systemanmeldekonfiguration von WebSphere Application Server eingesetzt wird, lesen Sie die Informationen zum JAAS-Programmiermodell unter folgender Adresse: http://java.sun.com/products/jaas. Das JAAS-Programmiermodell stellt Basisinformationen zu JAAS bereit. Bevor Sie ein Anmeldemodul für die Umgebung von WebSphere Application Server schreiben, sollten Sie jedoch die folgenden Abschnitte dieses Artikels lesen:
- Verwendbare Callbacks
- Gemeinsam genutzte Statusvariablen
- Erstanmeldung und weitergegebene Anmeldungen
- Beispiel für ein kundenspezifisches Anmeldemodul
Verwendbare Callbacks
Jede Anmeldekonfiguration muss die Callbacks dokumentieren, die von der Anmeldekonfiguration erkannt werden. Allerdings werden an die Callbacks nicht immer Daten übergeben. Daher muss die Anmeldekonfiguration eine Logik enthalten, damit festgestellt werden kann, wann bestimmte Informationen vorhanden sind und wie diese Informationen verwendet werden müssen. Wenn Sie beispielsweise ein eigenes Anmeldemodul schreiben, das in allen vier vorkonfigurierten Systemanmeldekonfigurationen eingesetzt werden kann, die weiter oben erwähnt wurden, dann können für die Authentifizierung einer Anforderung drei Gruppen von Callbacks vorhanden sein. Aus anderen Gründen, z. B. aus Gründen der Weitergabe und der Bereitstellung von Informationen für die Anmeldekonfiguration, können weitere Callbacks vorhanden sein.
Die Anmeldeinformation kann in folgenden Kombinationen dargestellt werden:- Benutzername (NameCallback) und Kennwort (PasswordCallback)
- Dies ist eine typische Authentifizierungskombination.
- Nur Benutzername (NameCallback)
- Diese Informationen werden zur Identitätsprüfung, für TAI-Anmeldungen (Trust Association Interceptor) und Zertifikatanmeldungen verwendet.
- Token (WSCredTokenCallbackImpl)
- Diese Informationen werden für die LTPA-Tokenprüfung (LTPA = Lightweight Third Party Authentication) verwendet.
- Liste der Weitergabetoken (WSTokenHolderCallback).
- Diese Informationen werden für eine weitergegebene Anmeldung verwendet.
Die ersten drei Kombinationen werden für die typische Authentifizierung verwendet. Wenn zusätzlich zu einer der drei ersten Kombinationen von Informationen der WSTokenHolderCallback vorhanden ist, dann wird die Anmeldung als Anmeldung mit Weitergabe (propagation login) bezeichnet. Eine weitergegebene Anmeldung bedeutet, dass einige Sicherheitsattribute von einem anderen Server an diesen Server weitergegeben werden. Die Server können diese Sicherheitsattribute wiederverwenden, falls die Authentifizierungsinformationen erfolgreich validiert wurden. In manchen Fällen enthält der WSTokenHolderCallback möglicherweise nicht genügend Attribute für eine vollständige Anmeldung. Prüfen Sie daher die Methode requiresLogin im WSTokenHolderCallback, um festzustellen, ob eine neue Anmeldung erforderlich ist. Sie können die von der Methode requiresLogin() zurückgegebenen Informationen zwar immer ignorieren, aber dabei besteht das Risiko, dass die Informationen dupliziert werden. Die folgende Liste enthält die Callbacks, die in den Systemanmeldekonfigurationen vorhanden sein können. Die Liste enthält den Callback-Namen und eine Beschreibung der jeweiligen Zuständigkeit.- callbacks[0] = new javax.security.auth.callback.NameCallback("Username: ");
- Dieser Callback-Handler erfasst den Benutzernamen für die Anmeldung. Das Ergebnis kann der Benutzername für die Anmeldung mit Basisauthentifizierung (Benutzername und Kennwort) sein oder ein Benutzername zur Anmeldung mit Identitätsprüfung.
- callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false);
- Dieser Callback-Handler erfasst das Kennwort für die Anmeldung.
- callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:");
- Dieser Callback-Handler erfasst das LTPA-Token (Lightweight Third Party Authentication) oder einen anderen Tokentyp für die Anmeldung. Er ist normalerweise dann vorhanden, wenn kein Benutzername und kein Kennwort vorhanden sind.
- callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:");
- Dieser Callback-Handler erfasst die ArrayList mit TokenHolder-Objekten, die durch einen Aufruf der API WSOpaqueTokenHelper.createTokenHolderListFromOpaqueToken zurückgegeben werden, wobei das CSIv2-Berechtigungstoken (Common Secure Interoperability Version 2) als Eingabe verwendet wird.
- callbacks[4] = new com.ibm.websphere.security.auth.callback.WSServletRequestCallback("HttpServletRequest:" );
- Dieser Callback-Handler erfasst das HTTP-Servletanforderungsobjekt, falls vorhanden. Es erlaubt den Anmeldemodulen, Informationen für die Anmeldung aus der HTTP-Anforderung abzurufen und ist nur in der Konfiguration WEB_INBOUND verfügbar.
- callbacks[5] = new com.ibm.websphere.security.auth.callback.WSServletResponseCallback("HttpServletResponse:");
- Dieser Callback-Handler erfasst das HTTP-Servletantwortobjekt, falls vorhanden. Es erlaubt den Anmeldemodulen, als Ergebnis der Anmeldung Informationen in die HTTP-Antwort einzufügen. Ein Beispiel für diesen Fall kann das Hinzufügen des SingleSignonCookie zur Antwort sein. Dieser Callback-Handler wird nur von der WEB_INBOUND-Anmeldekonfiguration bereitgestellt.
- callbacks[6] = new com.ibm.websphere.security.auth.callback.WSAppContextCallback("ApplicationContextCallback:");
- Dieser Callback-Handler erfasst den während der Anmeldung verwendeten Webanwendungskontext. Er setzt sich aus einem HashMap-Objekt, das den Anwendungsnamen enthält, und, sofern vorhanden, der Webadresse für Umleitung zusammen. Er wird nur von den WEB_INBOUND-Anmeldekonfigurationen bereitgestellt.
- callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", default_realm);
- Dieser Callback-Handler erfasst den Realmnamen für die Anmeldeinformationen. Die Realminformationen werden unter Umständen nicht bereitgestellt. Wenn keine Realminformationen bereitgestellt werden, können Sie davon ausgehen, dass es sich um den aktuellen Realm handelt.
- callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]: ");
- Dieser Callback-Handler enthält das Zertifikat, das von SSL (Secure Sockets Layer) validiert wurde, falls die Anmeldequelle ein X.509-Zertifikat aus der SSL-Clientauthentifizierung ist. Das Modul ltpaLoginModule ruft dieselben Zuordnungsfunktionen auf wie die Releases von WebSphere Application Server vor Version 6.1. Nachdem es an die Anmeldung übergeben wurde, kann ein angepasstes Anmeldemodul jedoch das Zertifikat auf eine eigene Weise zuordnen. Anschließend führt es eine Hashtable-Anmeldung durch. Weitere Informationen zur Hashtable-Anmeldung finden Sie im Artikel Identitätszuordnung für eingehende Anforderungen konfigurieren.
- Verwenden Sie gemeinsam genutzte Statusvariablen, die von den Anmeldemodulen in der Anmeldephase gemeinsam genutzt werden können. Falls Sie auf die Objekte zugreifen möchten, die WebSphere Application Server während einer Anmeldung erstellt, verwenden Sie die folgenden gemeinsam genutzten Statusvariablen. Die Variablen werden in den folgenden Anmeldemodulen gesetzt: ltpaLoginModule, swamLoginModule und wsMapDefaultInboundLoginModule.
- Gemeinsam genutzte Statusvariable
- com.ibm.wsspi.security.auth.callback.Constants.WSPRINCIPAL_KEY
- Zweck
- Gibt das Objekt "com.ibm.websphere.security.auth.WSPrincipal" an. Informationen zur Verwendung der API finden Sie in der API-Dokumentation von WebSphere Application Server. Diese gemeinsam genutzte Statusvariable ist schreibgeschützt. Definieren Sie diese Variable für angepasste Anmeldemodule nicht als gemeinsam genutzte Statusvariable.
- Das Anmeldemodul, in dem Variablen festgelegt werden.
- ltpaLoginModule, swamLoginModule und wsMapDefaultInboundLoginModule
- Gemeinsam genutzte Statusvariable
- com.ibm.wsspi.security.auth.callback.Constants.WSCREDENTIAL_KEY
- Zweck
- Gibt das Objekt "com.ibm.websphere.security.cred.WSCredential" an. Informationen zur Verwendung der API finden Sie in der API-Dokumentation von WebSphere Application Server. Diese gemeinsam genutzte Statusvariable ist schreibgeschützt. Definieren Sie diese Variable für angepasste Anmeldemodule nicht als gemeinsam genutzte Statusvariable.
- Anmeldemodul, in dem Variablen gesetzt sind:
- wsMapDefaultInboundLoginModule
- Gemeinsam genutzte Statusvariable
- com.ibm.wsspi.security.auth.callback.Constants.WSAUTHZTOKEN_KEY
- Zweck
- Gibt das Standardobjekt "com.ibm.wsspi.security.token.AuthorizationToken" an. Anmeldemodule können mit diesem Objekt angepasste Attribute festlegen, die nach dem Anmeldemodul "wsMapDefaultInboundLoginModule" eingefügt werden. Die hier definierten Informationen werden an die nachgeschalteten Server weitergeleitet und stehen der Anwendung zur Verfügung. Informationen zur Verwendung der API finden Sie in der API-Dokumentation von WebSphere Application Server.
Erstanmeldung und weitergegebene Anmeldungen
Wie weiter oben erwähnt, gelten einige Anmeldungen aus folgenden Gründen als Erstanmeldungen:- Es ist das erste Mal, dass Authentifizierungsinformationen an WebSphere Application Server übergeben werden.
- Die Anmeldeinformationen werden von einem Server empfangen, der keine Sicherheitsattribute weitergibt, so dass diese Informationen aus einer Benutzerregistry abgerufen werden müssen.
Andere Anmeldungen gelten als Weitergabeanmeldungen, wenn ein WSTokenHolderCallback vorhanden ist und genügend Informationen von einem sendenden Server enthält, um alle die Objekte erneut zu erstellen, die von der Laufzeitumgebung von WebSphere Application Server benötigt werden. Wenn genug Informationen für die Laufzeitumgebung von WebSphere Application Server vorliegen, werden die Informationen, die Sie zum Subjekt hinzufügen könnten, wahrscheinlich bereits von der vorherigen Anmeldung vorhanden sein. Wenn Sie überprüfen möchten, ob Ihr Objekt vorhanden ist, greifen Sie auf die ArrayList im WSTokenHolderCallback zu, und prüfen Sie jede Methode TokenHolder getName in dieser Liste. Auf diese Weise können Sie feststellen, ob WebSphere Application Server Ihr kundenspezifisches Objekt während dieser Anmeldung entserialisiert. Überprüfen Sie den von der Methode getName zurückgegebenen Klassennamen mit der Methode String startsWith, denn die Laufzeitumgebung könnte am Ende des Namens Informationen anfügen, um zu wissen, zu welcher Subjektgruppe das kundenspezifische Objekt nach der Entserialisierung hinzugefügt werden soll.
- Codieren Sie Ihre Methode "login()", um festzulegen, wann genügend Informationen vorhanden sind.
Das folgende Codefragment kann in Ihrer Methode "login()" verwendet werden, um zu ermitteln, wann genügend Informationen vorhanden sind. Ein weiteres Beispiel hierzu finden Sie im Artikel Identitätszuordnung für eingehende Anforderungen konfigurieren.
// Dies ist ein Hinweis von WebSphere Application Server darauf, // dass nicht genügend Informationen für die Weitergabe vorhanden sind. Daher ist eine Anmeldung // erforderlich, um die Informationen bereitzustellen. In diesem Fall kann eine // Anmeldung mit einer Hashtabelle verwendet werden. boolean requiresLogin = ((com.ibm.wsspi.security.auth.callback. WSTokenHolderCallback) callbacks[1]).requiresLogin(); if (requiresLogin) { // Überprüfen Sie, ob Ihr Objekt in der TokenHolder-Liste enthalten ist. // Fügen Sie es ggf. hinzu. java.util.ArrayList authzTokenList = ((WSTokenHolderCallback) callbacks[6]).getTokenHolderList();boolean found = false; if (authzTokenList != null) { Iterator tokenListIterator = authzTokenList.iterator(); while (tokenListIterator.hasNext()) { com.ibm.wsspi.security.token.TokenHolder th = (com.ibm.wsspi.security.token.TokenHolder) tokenListIterator.next(); if (th != null && th.getName().startsWith("com.acme.meineEigeneKlasse")) { found=true; break; } } if (!found) { // Fügen Sie jetzt Ihr eigenes Objekt hinzu. } } } else { // Dieser Code zeigt an, dass genügend Weitergabeinformationen vorhanden sind. // Aufrufe der Benutzerregistry sind nicht erforderlich, damit WebSphere Application Server // ein gültiges Subjekt erstellen kann. Dieser Code kann ein Nullbefehl in Ihrem Anmeldemodul sein. }
Beispiel für ein kundenspezifisches Anmeldemodul
Anhand des folgenden Beispiels können Sie prüfen, wie einige Callbacks und Variablen für gemeinsamen Status verwendet werden.
{ // Variablen für das Anmeldemodul definieren com.ibm.wsspi.security.token.AuthenticationToken customAuthzToken = null; com.ibm.wsspi.security.token.AuthenticationToken defaultAuthzToken = null; com.ibm.websphere.security.cred.WSCredential credential = null; com.ibm.websphere.security.auth.WSPrincipal principal = null; private javax.security.auth.Subject _subject; private javax.security.auth.callback.CallbackHandler _callbackHandler; private java.util.Map _sharedState; private java.util.Map _options; public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options) { _subject = subject; _callbackHandler = callbackHandler; _sharedState = sharedState; _options = options; } public boolean login() throws LoginException { boolean succeeded = true; // Ruft die CALLBACK-Informationen ab javax.security.auth.callback.Callback callbacks[] = new javax.security.auth.callback.Callback[7]; 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: "); callbacks[3] = new com.ibm.wsspi.security.auth.callback. WSServletRequestCallback ("HttpServletRequest: "); callbacks[4] = new com.ibm.wsspi.security.auth.callback.WSServletResponseCallback ("HttpServletResponse: "); callbacks[5] = new com.ibm.wsspi.security.auth.callback. WSAppContextCallback( "ApplicationContextCallback: "); callbacks[6] = new com.ibm.wsspi.security.auth.callback. WSTokenHolderCallback ("Authz Token List: "); try { callbackHandler.handle(callbacks); } catch (Exception e) { // Behandlung der Ausnahmen throw new WSLoginFailedException (e.getMessage(), e); } // Stellt fest, welche Callbacks Informationen enthalten uid = ((NameCallback) callbacks[0]).getName(); char password[] = ((PasswordCallback) callbacks[1]).getPassword(); byte[] credToken = ((WSCredTokenCallbackImpl) callbacks[2]).getCredToken(); javax.servlet.http.HttpServletRequest request = ((WSServletRequestCallback) callbacks[3]).getHttpServletRequest(); javax.servlet.http.HttpServletResponse response = ((WSServletResponseCallback) callbacks[4]).getHttpServletResponse(); java.util.Map appContext = ((WSAppContextCallback) callbacks[5]).getContext(); java.util.List authzTokenList = ((WSTokenHolderCallback) callbacks[6]).getTokenHolderList(); // Ruft die SHARED-STATE-Informationen ab principal = (WSPrincipal) _sharedState.get(com.ibm.wsspi.security.auth.callback.Constants.WSPRINCIPAL_KEY); credential = (WSCredential) _sharedState.get(com.ibm.wsspi.security.auth.callback.Constants.WSCREDENTIAL_KEY); defaultAuthzToken = (AuthorizationToken) _sharedState.get(com.ibm.wsspi.security.auth.callback.Constants.WSAUTHZTOKEN_KEY); // Wie Sie diese Informationen verwenden, ist abhängig von dem Szenarium, das Sie // ausführen möchten. Dieses Beispiel demonstriert den Zugriff auf die // verschiedenen Informationen: // - Feststellen, ob es sich bei der Anmeldung um eine Erstanmeldung oder eine weitergegebene Anmeldung handelt // - Ein angepasstes Berechtigungstoken entserialisieren (Weitere Informationen hierzu enthält der Artikel // Weitergabe von Sicherheitsattributen.) // - Ein neues angepasstes Berechtigungstoken hinzufügen (Weitere Informationen hierzu enthält der Artikel // Weitergabe von Sicherheitsattributen // - WSCredential suchen und ggf. die Attribute lesen // - WSPrincipal suchen und ggf. die Attribute lesen // - Prüfen, ob ein Standard-AuthorizationToken vorhanden ist, und ggf. Attribute hinzufügen // - Die Headerattribute aus der HttpServletRequest lesen, falls die Anforderung gefunden wird // - Ein Attribut zur HttpServletResponse hinzufügen, falls die Antwort gefunden wird // - Den Webanwendungsnamen aus dem appContext abrufen, falls der Kontext gefunden wird // - Stellt fest, ob es sich bei der Anmeldung um eine Erstanmeldung oder eine weitergegebene Anmeldung handelt. // Dies ist besonders hilfreich, wenn das Anmeldemodul das erste Anmeldemodul ist. boolean requiresLogin = ((WSTokenHolderCallback) callbacks[6]).requiresLogin(); // Erstanmeldung - Sichert Berechtigungsattribute auf der Basis der Benutzeridentität zu if (requiresLogin) { // Wenn Sie ein Token von einem anderen Server prüfen, gibt es eine // API zum Abrufen der uniqueID aus dem Token. if (credToken != null && uid == null) { try { String uniqueID = WSSecurityPropagationHelper.validateLTPAToken(credToken); String realm = WSSecurityPropagationHelper.getRealmFromUniqueID (uniqueID); // Legen Sie jetzt die UID fest, die Sie zum Abgleichen oder Anmelden verwenden // können. uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID); } catch (Exception e) { // Behandlung der Ausnahme } } // Fügt eine Hashtabelle für gemeinsame Nutzung hinzu. // Anmerkung: Sie können für den zurückgegebenen NameCallback-Wert einen angepassten Abgleich // durchführen, um die Identität auf der Grundlage Ihrer eigenen Abgleichungsregeln zu ändern. uid = mapUser (uid); // Ruft den Standard-InitialContext für diesen Server ab javax.naming.InitialContext ctx = new javax.naming.InitialContext(); // Ruft das lokale UserRegistry-Objekt ab com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.security.UserRegistry) ctx.lookup("UserRegistry"); // Ruft die uniqueID abhängig von der im NameCallback angegebenen uid aus der // Benutzerregistry ab String uniqueid = reg.getUniqueUserId(uid); uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID); // Ruft den Anzeigenamen abhängig von der uniqueID aus der Benutzerregistry ab String securityName = reg.getUserSecurityName(uid); // Ruft die dieser uniqueID zugeordneten Gruppen ab java.util.List groupList = reg.getUniqueGroupIds(uid); // Erstellt die java.util.Hashtable mit den aus der UserRegistry // gewonnenen Informationen 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 Subjekt verwendet wird. Der Cacheschlüssel kann ein Objekt sein, // aber er sollte die Methode toString() implementieren. Vergewissern Sie sich, // dass der Cacheschlüssel (cacheKey) genügend Informationen für den Benutzer // und die von Ihnen verwendeten zusätzlichen Attribte enthält. Wird diese // Eigenschaft nicht angegeben, wird das Subjekt standardmäßig // der zurückgegebenen WSCREDENTIAL_UNIQUEID zugeordnet. hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_CACHE_KEY, "meinEigenesAttribut" + uniqueid); // Fügt die Hashtabelle zum sharedState-Element des Subjekts hinzu _sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_PROPERTIES_KEY,hashtable); } // Weitergegebene Anmeldung - Verarbeiten weitergegebener Token else { // - Entserialisiert ein kundenspezifisches Berechtigungstoken. Weitere Informationen enthält der Artikel . // Weitergabe von Sicherheitsattributen. // Dies kann von jedem Plug-in-Punkt für Anmeldemodule aus erfolgen // (erster, mittlerer oder letzter Plug-in-Punkt). if (authzTokenList != null) { // Iteriert durch die Liste und sucht das angepasste Token for (int i=0; i<authzTokenList.size(); i++) { TokenHolder tokenHolder = (TokenHolder)authzTokenList.get(i); // Sucht nach Namen und Version Ihrer kundenspezifischen // AuthorizationToken-Implementierung if (tokenHolder.getName().equals("com.ibm.websphere.security.token. CustomAuthorizationTokenImpl") && tokenHolder.getVersion() == 1) { // Übergibt die Bytes zum Entserialisieren an den kundenspezifischen // AuthorizationToken-Konstruktor customAuthzToken = new com.ibm.websphere.security.token. CustomAuthorizationTokenImpl(tokenHolder.getBytes()); } } } // - Ein neues angepasstes Berechtigungstoken hinzufügen (Weitere Informationen hierzu enthält der Artikel // Weitergabe von Sicherheitsattributen.) // Dies kann von jedem Plug-in-Punkt für Anmeldemodule aus erfolgen // (erster, mittlerer oder letzter Plug-in-Punkt). else { // Ruft den PRINCIPAL aus dem Standard-AuthenticationToken ab. Dieser muss // mit allen Token übereinstimmen. defaultAuthToken = (com.ibm.wsspi.security.token.AuthenticationToken) sharedState.get(com.ibm.wsspi.security.auth.callback.Constants. WSAUTHTOKEN_KEY); String principal = defaultAuthToken.getPrincipal(); // Fügt ein neues angepasstes Berechtigungstoken hinzu. Dies // ist eine Erstanmeldung. // Übergibt den Principal an den Konstruktor customAuthzToken = new com.ibm.websphere.security.token. CustomAuthorizationTokenImpl(principal); // Fügt alle Anfangsattribute hinzu if (customAuthzToken != null) { customAuthzToken.addAttribute("key1", "value1"); customAuthzToken.addAttribute("key1", "value2"); customAuthzToken.addAttribute("key2", "value1"); customAuthzToken.addAttribute("key3", "something different"); } } } // - Sucht nach einem WSCredential und liest ggf. die Attribute // Dies ist besonders hilfreich, wenn das Modul als letztes Anmeldemodul integriert wird. if (credential != null) { try { // Liest Daten aus dem Identitätsnachweis String securityName = credential.getSecurityName(); java.util.ArrayList = credential.getGroupIds(); } catch (Exception e) { // Behandlung der Ausnahmen throw new WSLoginFailedException (e.getMessage(), e); } } // - Sucht nach einem WSPrincipal und liest ggf. die Attribute // Dies ist besonders hilfreich, wenn das Modul als letztes Anmeldemodul integriert wird. if (principal != null) { try { // Liest Daten aus dem Principal String principalName = principal.getName(); } catch (Exception e) { // Behandlung der Ausnahmen throw new WSLoginFailedException (e.getMessage(), e); } } // - Sucht nach einem Standard-AuthorizationToken und fügt ggf. Attribute hinzu // Dies ist besonders hilfreich, wenn das Modul als letztes Anmeldemodul integriert wurde. if (defaultAuthzToken != null) { try { // Liest Daten aus dem defaultAuthzToken String[] meinEigenerWert = defaultAuthzToken.getAttributes ("meinSchlüssel"); // Fügt Daten hinzu, die im defaultAuthzToken nicht vorhanden sind if (meinEigenerWert == null) defaultAuthzToken.addAttribute ("meinSchlüssel", "meineEigenenDaten"); } catch (Exception e) { // Behandlung der Ausnahmen throw new WSLoginFailedException (e.getMessage(), e); } } // - Liest die Headerattribute aus der HttpServletRequest, falls die Anforderung gefunden wird. // Dies kann von jedem Plug-in-Punkt für Anmeldemodule aus erfolgen // (erster, mittlerer oder letzter Plug-in-Punkt). if (request != null) { java.util.Enumeration headerEnum = request.getHeaders(); while (headerEnum.hasMoreElements()) { System.out.println ("Header element: " + (String)headerEnum.nextElement()); } } // - Fügt ein Attribut zur HttpServletResponse hinzu, falls die Antwort gefunden wird. // Dies kann von jedem Plug-in-Punkt für Anmeldemodule aus erfolgen // (erster, mittlerer oder letzter Plug-in-Punkt). if (response != null) { response.addHeader ("meinSchlüssel", "meinWert"); } // - Ruft den Webanwendungsnamen aus dem appContext ab, falls der Kontext gefunden wird. // Dies kann von jedem Plug-in-Punkt für Anmeldemodule aus erfolgen // (erster, mittlerer oder letzter Plug-in-Punkt). if (appContext != null) { String appName = (String) appContext.get(com.ibm.wsspi.security.auth.callback.Constants.WEB_APP_NAME); } return succeeded; } public boolean commit() throws LoginException { boolean succeeded = true; // Fügt alle von Ihnen erstellten Objekte hinzu, die zum Subjekt // gehören. Stellen Sie sicher, dass die Objekte noch nicht hinzugefügt // wurden. Falls Sie sharedState-Variablen hinzugefügt haben, entfernen Sie // diese vor dem Beenden. Falls die Methode abort() aufgerufen wird, vergewissern // Sie sich, dass alles bereinigt wird, was dem Subjekt hier hinzugefügt wird. if (customAuthzToken != null) { // Legt das Token customAuthzToken im Subjekt fest try { // Führen Sie diesen Schritt in einem doPrivileged-Block aus, damit der // Anwendungscode keine zusätzlichen Berechtigungen hinzufügen muss. java.security.AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { try { // Fügt das kundenspezifische Berechtigungstoken hinzu, falls es ungleich // null und noch nicht im Subjekt enthalten ist. if ((customAuthzTokenPriv != null) && (!_subject.getPrivateCredentials().contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials().add(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } public boolean abort() throws LoginException { boolean succeeded = true; // Stellt sicher, dass alle Objekte, die bereits hinzugefügt wurden (für Subjekt und gemeinsame Nutzung) // entfernt werden. if (customAuthzToken != null) { // Entfernen des Tokens customAuthzToken aus dem Subjekt try { final AuthorizationToken customAuthzTokenPriv = customAuthzToken; // Führen Sie diesen Schritt in einem doPrivileged-Block aus, damit der Anwendungscode // keine zusätzlichen Berechtigungen hinzufügen muss. java.security.AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { try { // Entfernt das kundenspezifische Berechtigungstoken, falls es ungleich // null und noch nicht im Subjekt enthalten ist. if ((customAuthzTokenPriv != null) && (_subject.getPrivateCredentials(). contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials(). remove(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } public boolean logout() throws LoginException { boolean succeeded = true; // Stellt sicher, dass alle bereits hinzugefügten Objekte (für Subjekt und für gemeinsame // Nutzung) entfernt werden. if (customAuthzToken != null) { // Entfernt das Token "customAuthzToken" aus dem Subjekt try { final AuthorizationToken customAuthzTokenPriv = customAuthzToken; // Führen Sie diesen Schritt in einem doPrivileged-Codeblock aus, damit der Anwendungscode // keine zusätzlichen Berechtigungen hinzufügen muss. java.security.AccessController.doPrivileged(new java.security. PrivilegedAction() { public Object run() { try { // Entfernt das kundenspezifische Berechtigungstoken, falls es ungleich // null und noch nicht im Subjekt enthalten ist. if ((customAuthzTokenPriv != null) && (_subject.getPrivateCredentials(). contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials().remove(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } }
- Konfigurieren Sie die Systemanmeldung für ihr angepasstes Anmeldemodul.
Nach der Entwicklung Ihres eigenen Anmeldemoduls für eine Systemanmeldekonfiguration können Sie die Systemanmeldung entweder über die Administrationskonsole oder mit dem Dienstprogramm "wsadmin" konfigurieren. Klicken Sie zum Konfigurieren der Systemanmeldung mit der Administrationskonsole auf Sicherheit > Globale Sicherheit. Klicken Sie unter "Java Authentication and Authorization Service" auf Systemanmeldungen. Weitere Informationen zur Konfiguration der Systemanmeldung mit dem Dienstprogramm "wsadmin" finden Sie im Artikel Konfiguration für serverseitige JAAS-Authentifizierung und -Anmeldung anpassen. Lesen Sie diesen Artikel auch, wenn Sie sich mit Systemanmeldemodulen vertraut machen und feststellen möchten, ob weitere Anmeldemodule hinzugefügt werden müssen.
Unterartikel
Anwendungsanmeldung mit Java Authentication and Authorization Service anpassen
Mit Java Authentication and Authorization Service (JAAS) können Sie Ihre Anwendungsanmeldung anpassen.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_jaascustlogmod
Dateiname:tsec_jaascustlogmod.html