Anmeldezuordnungen
Anmeldezuordnungen in der XML-Datei ibm-webservices-bnd.xmi (Extended Markup Language) enthalten eine Zuordnungskonfiguration. Diese Zuordnungskonfiguration definiert, wie der WS-Security-Handler das Tokenelement <ValueType>, das in dem aus dem Nachrichtenheader extrahierten Sicherheitstoken enthalten ist, der entsprechenden Authentifizierungsmethode zuordnen soll. Das Tokenelement <ValueType> ist in dem Sicherheitstoken enthalten, das aus einem SOAP-Nachrichtenheader extrahiert wurde.
Der WS-Security-Handler auf der Senderseite generiert Sicherheitstoken auf der Basis des Elements <AuthMethods>, das im Implementierungsdeskriptor angegeben wurde, und ordnet diese zu. Wenn die Authentifizierungsmethode BasicAuth verwendet wird, generiert der Sicherheitshandler auf der Absenderseite ein UsernameToken (mit Benutzername und Kennwort) und hängt es an den SOAP-Nachrichtenheader an. Die Laufzeitumgebung von Web Services Security verwendet die JAAS-Schnittstelle (Java™ Authentication and Authorization Service) "javax.security.auth.callback.CallbackHandler" als Sicherheitsprovider, um Sicherheitstoken auf der Clientseite zu generieren (oder wenn die Web-Services als Client fungieren).
Der Sicherheitshandler des Absenders ruft die Methode handle() einer Implementierung der Schnittstelle "javax.security.auth.callback.CallbackHandler" auf. Diese Implementierung erstellt das Sicherheitstoken und übergibt das Token zurück an den Sicherheitshandler des Senders. Der Sicherheitshandler des Senders erstellt das Sicherheitstoken basierend auf den Authentifizierungsdaten im Callback-Array. Der Sicherheitshandler fügt dann das Sicherheitstoken in den WS-Security-Nachrichtenheader ein.
<loginBinding xmi:id="LoginBinding_1052760331526" authMethod="BasicAuth"
callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/>
- com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler
- Wenn keine Basisauthentifizierungsdaten in den Bindungsdaten für die Anmeldung definiert sind (nicht mit den Basisauthentifizierungsdaten für HTTP identisch), fordert der vorherige Tokentyp in einer Anmeldeanzeige dazu auf, den Benutzernamen und das Kennwort einzugeben. Die Implementierung verwendet die Basisauthentifizierungsdaten, die in der Anmeldebindung definiert sind. Verwenden Sie diese Implementierung von CallbackHandler mit der Authentifizierungsmethode "BasicAuth". Da diese Implementierung von CallbackHandler Sie zur Eingabe der Anmeldebindungsdaten auffordert, sollten Sie sie nicht im Server verwenden.
- com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler
- Falls in der Anmeldebindung keine Basisauthentifizierungsdaten definiert sind (diese Informationen sind nicht
identisch mit den HTTP-Basisauthentifizierungsdaten), fordert die Implementierung Sie zur Eingabe des Benutzernamens
und des Kennworts in der Standardeingabe (stdin) auf.
Die Implementierung verwendet die Basisauthentifizierungsdaten,
die in der Anmeldebindung definiert sind.
Verwenden Sie diese Implementierung von CallbackHandler mit der Authentifizierungsmethode
"BasicAuth".
Da diese Implementierung von CallbackHandler
Sie zur Eingabe der
Anmeldebindungsdaten auffordert, sollten Sie sie nicht im Server verwenden.
Einschränkung: Wenn Sie einen Multithread-Client haben und mehrere Threads versuchen, gleichzeitig aus der Standardeingabe zu lesen, ist keiner der Threads in der Lage, den Benutzernamen und das Kennwort erfolgreich abzurufen. Deshalb können Sie die com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler-Implementierung nicht für einen Multithread-Client verwenden, wenn mehrere Threads versuchen können, gleichzeitig Daten aus der Standardeingabe abzurufen.
- com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler
- Diese Implementierung von CallbackHandler Implementierung fordert Sie nicht zur Eingabe von Daten auf. Stattdessen verwendet sie die Basisauthentifizierungsdaten, die in den Bindungsdaten für die Anmeldung definiert sind (diese Informationen sind nicht identisch mit den HTTP-Basisauthentifizierungsdaten). Verwenden Sie diese Implementierung von CallbackHandler für die Authentifizierungsmethode "BasicAuth". Sie müssen die Basisauthentifizierungsdaten in den Bindungsdaten für die Anmeldung dieser Implementierung von CallbackHandler definieren. Sie können diese Implementierung verwenden, wenn Web-Services als Client ausgeführt werden und Basisauthentifizierungsdaten (<wsse:UsernameToken>) an den Downstream-Aufruf senden muss.
- com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler
- Der CallbackHandler generiert LTPA-Token (Lightweight Third Party Authentication) aus dem run as-JAAS-Subject (Aufruf-Subject) des aktuellen Sicherheitskontextes von WebSphere Application Server. Falls in der Anmeldebindung jedoch Basisauthentifizierungsdaten (nicht die HTTP-Basisauthentifizierungsdaten) definiert sind, verwendet die Implementierung die Basisauthentifizierungsdaten und das generierte LTPA-Token. Die Werte von URI des Tokentyps und Lokaler Name des Tokentyps müssen in den lokalen Anmeldebindungsdaten für diese Implementierung von CallbackHandler definiert sein. Mit dem Wert des Tokentyps wird das Token für die Bindungskonfiguration des Anforderungssenders und des Anforderungsempfängers validiert. Die Laufzeitumgebung von Web Services Security fügt das LTPA-Token als binäres Sicherheitstoken (<wsse:BinarySecurityToken>) in den SOAP-Nachrichtenheader ein. Der Werttyp ist "mandatory". (Weitere Informationen hierzu finden Sie im Artikel LTPA.) Verwenden Sie diese Implementierung von CallbackHandler mit der Authentifizierungsmethode "LTPA".

- Nach dem Empfang einer Nachricht vergleicht der WS-Security-Handler des Empfängers den Tokentyp (im Nachrichtenheader) mit den erwarteten Tokentypen, die im Implementierungsdeskriptor konfiguriert sind.
- Der Web Services Security-Handler extrahiert das Sicherheitstoken
aus dem Nachrichtenheader und ordnet das Tokenelement <ValueType>
der entsprechenden Authentifizierungsmethode zu. Die Zuordnungskonfiguration ist im
Element <loginMappings> in
der XML-Datei ibm-webservices-bnd.xmi definiert. Beispiel:
<loginMappings xmi:id="LoginMapping_1051977980074" authMethod="LTPA" configName="WSLogin"> <callbackHandlerFactory xmi:id="CallbackHandlerFactory_1051977980081" classname="com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl"/> <tokenValueType xmi:id="TokenValueType_1051977980081" uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" localName="LTPA"/> </loginMappings>
Die Schnittstelle "com.ibm.wsspi.wssecurity.auth.callback.CallbackHandlerFactory" ist eine Factory für "javax.security.auth.callback.CallbackHandler".
- Die Laufzeitumgebung von Web Services Security initialisiert die Factory-Implementierungsklasse und übergibt die Authentifizierungsdaten vom WS-Security- über die gesetzten Methoden an die Factory-Klasse.
- Die Laufzeitumgebung von Web Services Security ruft die Methode newCallbackHandler() auf, um das Objekt javax.security.auth.CallbackHandler abzurufen, das das erforderliche Sicherheitstoken generiert.
- Wenn der Sicherheitshandler ein
LTPA-BinarySecurityToken empfängt, verwendet er die Konfiguration für die
WSLogin -JAAS-Anmeldung und die Methode
newCallbackHandler(), um das Sicherheitstoken zu
validieren. Wenn im WS-Security-Header der SOAP-Nachricht keiner der
erwarteten Tokentypen gefunden wird, wird die Anforderung unter Angabe eines
SOAP-Fehlers zurückgewiesen. Wird ein Tokentyp ermittelt, wird er verwendet, um
eine Zuordnung zu einer JAAS-Anmeldekonfiguration für die Tokenvalidierung
durchzuführen. Ist die Authentifizierung erfolgreich, wird ein JAAS-Subject erstellt und
dem Ausführungsthread zugeordnet. Andernfalls wird die Anforderung unter Angabe eines
SOAP-Fehlers zurückgewiesen. In der folgenden Tabelle sind die Authentifizierungsmethoden und JAAS-Anmeldekonfigurationen aufgeführt.
Tabelle 1. Authentifizierungsmethoden und JAAS-Anmeldekonfigurationen. Die Authentifizierungsmethoden werden für die Tokenvalidierung der JAAS-Anmeldekonfiguration zugeordnet. Authentifizierungsmethode JAAS-Anmeldekonfiguration BasicAuth (Basisauthentifizierung) WSLogin Signatur system.wssecurity.Signature LTPA WSLogin IDAssertion (Zusicherung der Identität) system.wssecurity.IDAssertion Abbildung 2 zeigt den Sicherheitshandler des Empfängers bei der Verarbeitung der Nachricht des Anforderungsempfängers.Abbildung 2. Verarbeitung der SOAP-Nachricht des AnforderungsempfängersDas Standardelement <LoginMapping> ist in den folgenden Dateien definiert:- Datei ws-security.xml auf Zellenebene und Datei ws-security.xml auf Serverebene
- Der Client liest die Standardbindungsinformationen aus der Datei ${Installationsverzeichnis}/properties/ws-security.xml.
- Die Serverlaufzeit lädt die folgenden Dateien, falls vorhanden:
- Datei ws-security.xml auf Zellenebene und Datei ws-security.xml auf Serverebene. Die zwei Dateien werden in der Laufzeit zusammengefasst und bilden eine wirksame Gruppe von Standardbindungsinformationen.
Im Basisanwendungsserver (Base Application Server) lädt die Serverlaufzeitkomponente nur die Datei ws-security.xml auf Serverebene. Die Serverdatei ws-security.xml und die WS-Security-Bindungsinformationen der Anwendung werden mit der Administrationskonsole verwaltet. Sie können die Bindungsinformationen während der Anwendungsimplementierung über die Administrationskonsole angeben. Die Sicherheitsrichtlinie für Web-Services werden im erweiterten Implementierungsdeskriptor (ibm-webservicesclient-ext.xmi) und die Bindungen in der IBM® Bindungserweiterung (ibm-webservicesclient-bnd.xmi) gespeichert. Die Datei ${Installationsverzeichnis}/properties/ws-security.xml definiert jedoch den Standardbindungswert für den Client. Wenn in der Bindungsdatei keine Bindungsdaten angegeben sind, liest die Laufzeit die Bindungsdaten aus der Standarddatei ${Installationsverzeichnis}/properties/ws-security.xml.