Übersicht über Authentifizierungsmethoden
Die Implementierung von Web Services Security für WebSphere Application Server unterstützt die folgenden Authentifizierungsmethoden: BasicAuth, Lightweight Third Party Authentication (LTPA), digitale Signatur und Identitätszusicherung.
Wenn WebSphere Application Server für die Verwendung der Authentifizierungsmethode BasicAuth konfiguriert ist, ordnet der Sender das LTPA-Token (Lightweight Third Party Authentication) als BinarySecurityToken aus dem aktuellen Sicherheitskontext oder aus der Konfiguration der Basisauthentifizierungsdaten zu, die sich in der Bindungsdatei im SOAP-Nachrichten-Header befindet. Der Empfänger der WS-Security-Nachricht authentifiziert den Sender, indem er den Benutzernamen und das Kennwort gegen die konfigurierte Benutzerregistry validiert. Beim LTPA-Verfahren ordnet der Sender das LTPA-BinarySecurityToken, das er zuvor im SOAP-Nachrichten-Header empfangen hat, zu. Der Empfänger authentifiziert den Sender, indem er das LTPA-Token und die Verfallszeit des Tokens validiert. Beim Authentifizierungsverfahren der digitalen Signatur ordnet der Sender ein BinarySecurityToken aus einem X509-Zertifikat dem WS-Security-Nachrichtenheader zu. Dabei werden eine digitale Signatur des Nachrichtenhauptteils, eine Zeitmarke, ein Sicherheitstoken bzw. eine Kombination dieser drei Elemente übertragen. Der Empfänger authentifiziert den Sender, indem er mit dem öffentlichen Schlüssel des überprüften Zertifikats die Gültigkeit des X.509-Zertifikats und der digitalen Signatur prüft.
Das Authentifizierungsverfahren der Identitätszusicherung unterscheidet sich von den anderen drei Authentifizierungsverfahren. Bei diesem Verfahren wird die Sicherheitsberechtigung des Senders basierend auf der Trust-Beziehung erstellt. Sie können die Identitätszusicherung verwenden, wenn z. B. ein vermittelnder Server für den Client einen Service von einem Downstream-Server aufruft, jedoch nicht die Daten für die Clientauthentifizierung besitzt. Der vermittelnde Server stellt möglicherweise eine Vertrauensbeziehung zum Downstream-Server her und sichert anschließend demselben Downstream-Server die Clientidentität zu.
- BasicAuth
- Digitale Signatur
- Angenommene Vertrauensbeziehung
Wenn Sie die Trust-Modi BasicAuth und "Digitale Signatur" verwenden, übergibt der vermittelnde Server seine eigenen Authentifizierungsdaten zur Authentifizierung an den Downstream-Server. Im angenommenen Trust-Modus wird eine Vertrauensbeziehung über ein externes Verfahren hergestellt. Beispielsweise kann der vermittelnde Server SOAP-Nachrichten über eine SSL-Verbindung (Secure Socket Layers) weitergeben, indem er den Downstream-Server verwendet und die Authentifizierung über Clientzertifikate auf der Transportebene durchführt.
- Der Downstream-Server validiert die Authentifizierungsdaten des vermittelnden Servers.
- Der Downstream-Server prüft, ob der authentifizierte vermittelnde Server für die Identitätszusicherung autorisiert ist. Beispielsweise muss der vermittelnde Server in der anerkannten Liste für den Downstream-Server aufgeführt sein.
Die Clientidentität kann durch eine Namenszeichenfolge, einen definierten Namen (DN) oder ein X.509-Zertifikat dargestellt werden. Die Clientidentität wird in der WS-Security-Nachricht in Form eines UsernameToken mit lediglich einem Benutzernamen und einem DN oder in einem BinarySecurityToken eines Zertifikats angehängt. In der folgenden Tabelle sind die Typen der Sicherheitstoken aufgeführt, die für die einzelnen Authentifizierungsverfahren erforderlich sind.
Authentifizierungsmethode | Sicherheitstoken |
---|---|
BasicAuth | BasicAuth erfordert <wsse:UsernameToken> mit<wsse:Username> und <wsse:Password>. |
Signature | Signature erfordert <ds:Signature> und <wsse:BinarySecurityToken>. |
IDAssertion | IDAssertion erfordert <wsse:UsernameToken> mit
<wsse:Username> oder <wsse:BinarySecurityToken> mit einem
X.509-Zertifikat für die Clientidentität,
je nach <idType>.
Dieses Verfahren erfordert auch andere Sicherheitstoken gemäß dem
<trustMode>:
|
LTPA | LTPA erfordert ein <wsse:BinarySecurityToken> mit einem LTPA-Token. |
<loginConfig xmi:id="LoginConfig_1052760331326">
<authMethods xmi:id="AuthMethod_1052760331326" text="BasicAuth"/>
<authMethods xmi:id="AuthMethod_1052760331327" text="IDAssertion"/>
<authMethods xmi:id="AuthMethod_1052760331336" text="Signature"/>
<authMethods xmi:id="AuthMethod_1052760331337" text="LTPA"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1052760331336" idType="Username" trustMode="Signature"/>
<loginConfig xmi:id="LoginConfig_1051555852697">
<authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>

Der Sicherheitshandler des Senders ruft die Methode handle() einer Implementierung der Schnittstelle javax.security.auth.callback.CallbackHandler auf. Die Schnittstelle javax.security.auth.callback.CallbackHandler erstellt das Sicherheitstoken und gibt das Token an den Sicherheitshandler des Senders zurück. Der Sicherheitshandler des Senders erstellt das Sicherheitstoken basierend auf den Authentifizierungsdaten im Callback-Array und fügt es in den Header der WS-Secuhrity-Nachricht ein.
Der Sicherheitshandler des Empfängers vergleicht den Tokentyp im Nachrichten-Header mit den erwarteten Tokentypen, die im Implementierungsdeskriptor konfiguriert sind. Wenn im WS-Security-Header der SOAP-Nachricht keiner der erwarteten Tokentypen gefunden wird, wird die Anforderung unter Angabe einer SOAP-Ausnahme zurückgewiesen. Andernfalls wird der Tokentyp für die Zuordnung zu einer JAAS-Anmeldekonfiguration (Java™ Authentication and Authorization Service) verwendet, um das Token zu validieren. Ist die Authentifizierung erfolgreich, wird ein JAAS-Subjekt erstellt und dem Ausführungsthread zugeordnet. Andernfalls wird die Anforderung unter Angabe einer SOAP-Ausnahme zurückgewiesen.