Ü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.

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.

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.

Web Services Security unterstützt die folgenden Trust-Modi:
  • 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.

Die Implementierung von Web Services Security für WebSphere Application Server validiert die Vertrauensbeziehung mit der folgenden Prozedur:
  1. Der Downstream-Server validiert die Authentifizierungsdaten des vermittelnden Servers.
  2. 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.

Tabelle 1. Authentifizierungsverfahren und deren Sicherheitstoken. Verwenden Sie die Methoden zur Authentifizierung des Absenders einer Nachricht.
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>:
  • If the <trustMode> is BasicAuth, IDAssertion requires <wsse:UsernameToken> with <wsse:Username> and <wsse:Password>.
  • Wenn der <trustMode> auf Signature gesetzt ist, erfordert IDAssertion ein <wsse:BinarySecurityToken>.
LTPA LTPA erfordert ein <wsse:BinarySecurityToken> mit einem LTPA-Token.
Ein Web-Service kann mehrere Authentifizierungsverfahren gleichzeitig unterstützen. Die Empfängerseite des Implementierungsdeskriptors der Web-Services kann alle unterstützten Authentifizierungsverfahren in der XML-Datei ibm-webservices-ext.xmi angeben. Die Empfängerseite der Web-Services ist, wie im folgenden Beispiel dargestellt, so konfiguriert, dass alle zuvor beschriebenen Authentifizierungsverfahren akzeptiert werden:
<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"/>
Sie können nur ein Authentifizierungsverfahren im Implementierungsdeskriptor der Web-Services auf der Senderseite definieren. Ein Web-Service-Client kann jedes Authentifizierungsverfahren, das von der jeweiligen Web-Service-Anwendung unterstützt wird, verwenden. Das folgende Beispiel veranschaulicht die Konfiguration einer Authentifizierungsmethode für die Identitätszusicherung im erweiterten Implementierungsdeskriptor ibm-webservicesclient-ext.xmi des Web-Service-Clients:
<loginConfig xmi:id="LoginConfig_1051555852697">
      <authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
Wie im Beispiel gezeigt ist der Typ der Clientidentität Username, der Trust-Modus die digitale Signatur ("Signature").
Abbildung 1. Generierung und Validierung von Sicherheitstoken Generierung und Validierung von Sicherheitstoken

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.


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_authmeth
Dateiname:cwbs_authmeth.html