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.

Wichtig: Es gibt eine wichtige Unterscheidung zwischen Anwendungen der Version 5.x und Anwendungen der Version 6 und höher. Die Informationen in diesem Artikel gelten nur für Anwendungen der Version 5.x, die in WebSphere Application Server Version 6.0.x und höher verwendet werden. Diese Informationen gelten nicht für Anwendungen der Version 6 und höher.

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.

Die Implementierung der Schnittstelle CallbackHandler, die Sie für das Generieren des erforderlichen Sicherheitstoken verwenden, ist im Element <loginBinding> in der Bindungsdatei ibm-webservicesclient-bnd.xmi von Web Services Security definiert. Beispiel:
<loginBinding xmi:id="LoginBinding_1052760331526" authMethod="BasicAuth"
      callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/>
Das Element <loginBinding> ordnet die Schnittstelle "com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler" der Authentifizierungsmethode BasicAuth zu. WebSphere Application Server stellt die folgende Gruppe von Implementierungen der Schnittstelle "CallbackHandler" zur Verfügung, die Sie verwenden können, um verschiedene Typen von Sicherheitstoken zu erstellen:
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".
Abbildung 1 zeigt den Sicherheitshandler des Senders bei der Verarbeitung der Nachricht des Anforderungssenders.
Abbildung 1. Verarbeitung der SOAP-Nachricht des AnforderungssendersVerarbeitung der SOAP-Nachricht des Anforderungssenders
Der Sicherheitsserver auf der Empfängerseite kann so konfiguriert werden, dass mehrere Authentifizierungsmethoden und Typen von Sicherheitstoken unterstützt werden. Die folgenden Schritte beschreiben den SOAP-Nachrichtenprozess beim Anforderungssender:
  1. 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.
  2. 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".

  3. 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.
  4. Die Laufzeitumgebung von Web Services Security ruft die Methode newCallbackHandler() auf, um das Objekt javax.security.auth.CallbackHandler abzurufen, das das erforderliche Sicherheitstoken generiert.
  5. 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ängersVerarbeitung der SOAP-Nachricht des Anforderungsempfängers
    Das Standardelement <LoginMapping> ist in den folgenden Dateien definiert:
    • Datei ws-security.xml auf Zellenebene und Datei ws-security.xml auf Serverebene
    Sind in den Informationen für die Bindungsdatei keine entsprechenden Angaben definiert, wird die Standarddatei ws-security.xml verwendet. Ein Administrator kann jedoch die Standardeinstellung überschreiben, indem er ein neues <LoginMapping>-Element in der Bindungsdatei definiert.
  6. Der Client liest die Standardbindungsinformationen aus der Datei ${Installationsverzeichnis}/properties/ws-security.xml.
  7. 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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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