Sicherheitstoken weitergeben
In diesem Beispiel werden Sicherheitstoken über Web Services Security, die Sicherheitsinfrastruktur von WebSphere Application Server, und die Java™-EE-Sicherheit (Java Platform, Enterprise Edition) weitergegeben.
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.0.x und höher.
Beispielszenario
In diesem Beispiel ruft Client 1 Web-Service 1 auf. Anschließend ruft Web-Service 1 die EJB-Datei 2 auf. Die EJB-Datei 2 ruft Web-Service 3 und Web-Service 3 dann Web-Service 4 auf.
Abbildung 1. Sicherheitstoken weitergeben

Im vorherigen Beispiel werden Sicherheitstoken
über Web Services Security, die Sicherheitsinfrastruktur
von WebSphere Application Server,
und die Java-EE-Sicherheit
(Java Platform, Enterprise Edition)
weitergegeben.
Web-Service 1 ist so konfiguriert, dass nur <wsse:UsernameToken> akzeptiert
werden und das Authentifizierungsverfahren BasicAuth verwendet wird. Web-Service 4 hingegen ist so konfiguriert,
dass <wsse:UsernameToken> mit dem Authentifizierungsverfahren BasicAuth
und Lightweight Third Party Authentication (LTPA) als <wsse:BinarySecurityToken> akzeptiert werden.
Die folgenden Schritte beschreiben das in der vorherigen Abbildung gezeigte Szenario:
- Client 1 sendet eine SOAP-Nachricht an Web-Service 1 mit Benutzer1 und Kennwort im Element <wsse:UsernameToken>.
- Die Werte Benutzer1 und Kennwort werden von der Laufzeitumgebung von Web Services Security authentifiziert und im aktuellen Sicherheitskontext als JAAS-Subjekt (Java Authentication and Authorization Service) gesetzt.
- Web-Service 1 ruft die EJB-Datei 2 mit dem Protokoll RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) auf.
- Die ID Benutzer1 wird an den Downstream-Aufruf weitergegeben.
- Der EJB-Container von EJB-Datei 2 führt eine Berechtigungsprüfung für Benutzer1 durch.
- EJB-Datei 2 ruft Web-Service 3 auf, und Web-Service 3 ist so konfiguriert, dass LTPA-Token akzeptiert werden.
- Die RunAs-Rolle von EJB-Datei 2 ist auf Benutzer2 gesetzt.
- Die Implementierung des LTPA-CallbackHandler extrahiert das LTPA-Token aus dem aktuellen JAAS-Subjekt in den Sicherheitskontext, und die Laufzeitumgebung von Web Services Security fügt das Token als <wsse: BinarySecurityToken> in den SOAP-Header ein.
- Die Laufzeitumgebung von Web Services Security in Web-Service 3 ruft die JAAS-Anmeldekonfiguration auf, um das LTPA-Token zu validieren und als JAAS-Subjekt im aktuellen Sicherheitskontext zu setzen.
- Web-Service 3 ist so konfiguriert, dass die LTPA-Sicherheit an Web-Service 4 gesendet wird. In diesem Fall ist davon auszugehen, dass die RunAS-Rolle nicht für Web-Service 3 konfiguriert ist. Das LTPA-Token von Benutzer2 wird an Web-Service 4 weitergegeben.
- Client 2 verwendet das Element <wsse:UsernameToken>, um die Basisauthentifizierungsdaten an Web-Service 4 weiterzugeben.
Web Services Security ergänzt die Sicherheitslaufzeit von WebSphere Application Server und die rollebasierte Java-EE-Sicherheit. Dieses Beispiel veranschaulicht, wie Sicherheitstoken an mehrere Ressourcen wie Web-Services und EJB-Dateien weitergegeben werden.