Beziehung zwischen Web Services Security und der Sicherheit Java Platform, Enterprise Edition

Dieser Artikel beschreibt die Beziehung zwischen dem Web Services Security-Modell (Sicherheit auf Nachrichtenebene) und dem Java™-EE-Sicherheitsmodell (Java Platform, Enterprise Edition). Er enthält außerdem Informationen zu rollenbasierten Java-EE-Berechtigungsprüfungen.

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

WebSphere Application Server unterstützt die Java Specification Requests (JSR) 101 und JSR 109. JSRs 101 und 109 definieren Web-Services für die Java-EE-Architektur, sodass Sie Web-Services in der Java-EE-Komponentenarchitektur entwickeln und ausführen können.

Wichtig: Web Services Security bezieht sich auf die Spezifikation "Web Services Security: SOAP Message Security". Weitere Informationen finden Sie im Artikel Unterstützung von Web Services Security.

Web-Services mit der Sicherheit von WebSphere Application Server (rollenbasierte Java-EE-Sicherheit) sichern

Sie können Web-Services mit der vorhandenen Sicherheitsinfrastruktur von WebSphere Application Server, der rollenbasierten Java-EE-Sicherheit und mit der SSL-Sicherheit (Secure Sockets Layer) auf Transportebene sichern.
Abbildung 1. Fluss der SOAP-Nachrichten bei Verwendung der vorhandenen SicherheitsinfrastrukturFluss der SOAP-Nachrichten bei Verwendung der vorhandenen Sicherheitsinfrastruktur

Der Web-Service-Port kann mit der rollenbasierten Java-EE-Sicherheit gesichert werden. Der Web-Service-Sender sendet die Daten für die Basisauthentifizierung im HTTP-Header. Zum Sichern des Transports kann SSL (HTTPS) verwendet werden. Wenn WebSphere Application Server die SOAP-Nachricht empfängt, authentifiziert der Web-Container den Benutzer (in diesem Beispiel user1) und legt den Sicherheitskontext für den Aufruf fest. Nach dem Festlegen des Sicherheitskontextes sendet das SOAP-Router-Servlet die Anforderung an die Implementierung der Web-Services (die Implementierung können JavaBeans- oder Enterprise-Bean-Dateien sein). Für Enterprise-Bean-Implementierungen führt der EJB-Container eine Berechtigungsprüfung für die Identität user1 durch.

Der Web-Service-Port kann auch mit der Java-EE-Rolle gesichert werden. Danach wird die Berechtigung vom Web-Container durchgeführt, bevor die SOAP-Anforderung an die Web-Service-Implementierung verteilt wird.

Web-Services mit Web Services Security auf Nachrichtenebene sichern

Sie können Web-Services auch mit Web Services Security auf Nachrichtenebene sichern. In diesem Fall können Sie einen bestimmten Teil der Nachricht digital signieren oder verschlüsseln. Außerdem unterstützt Web Services Security die Weitergabe von Sicherheitstoken in der SOAP-Nachricht. In dem folgenden Szenario wird davon ausgegangen, dass der Web-Service-Port im Gegensatz zur Enterprise-Bean nicht durch die rollenbasierte Java-EE-Sicherheit gesichert ist.

Abbildung 2. Fluss der SOAP-Nachrichten bei Verwendung von Web Services SecurityFluss der SOAP-Nachrichten bei Verwendung von Web Services Security

In diesem Fall ist der Web-Service-Port nicht durch die rollenbasierte Java-EE-Sicherheit gesichert. Die Web-Service-Engine verarbeitet die SOAP-Nachricht, bevor der Client die Nachricht an den Web-Service-Port sendet. Die Laufzeitumgebung von Web Services Security richtet sich nach den Sicherheitsvorgaben wie digitale Signatur, Verschlüsselung oder Erstellen (und Einfügen) von Sicherheitstoken in die SOAP-Header. In diesem Fall wird <wsse:UsernameToken> mit user1 und dem Kennwort generiert. Auf der Serverseite (Empfang) verarbeiten die Web-Services die eingehende Nachricht, und Web Services Security setzt die Sicherheitsvorgaben durch. Zum Durchsetzen dieser Vorgaben gehören die ordnungsgemäße Signatur, Ver- und Entschlüsselung von Nachrichten, die Authentifizierung des Sicherheitstoken und das Einrichten des Sicherheitskontextes mit der authentifizierten Identität. (In diesem Fall ist user1 die authentifizierte Identität.) Schließlich wird die SOAP-Nachricht an die Web-Service-Implementierung verteilt (falls die Implementierung eine Enterprise-Bean-Datei ist, führt der EJB-Container (Enterprise JavaBeans) eine Berechtigungsprüfung für user1 durch). In diesem Szenario kann auch SSL verwendet werden.

Sicherheitsverfahren kombinieren

Das zweite Szenario zeigt, dass Web Services Security die rollenbasierte Java-EE-Sicherheit ergänzen kann. Beispielsweise kann SSL auf Transportebene eingesetzt werden, um einen sicheren Kanal zu erhalten. Wenn die Web-Service-Implementierung eine Enterprise-Bean-Datei ist, können Sie außerdem durch Berechtigungsprüfungen die rollenbasierte EJB-Berechtigung nutzen. Zur Laufzeit nutzt Web Services Security die Sicherheitsinfrastruktur, um die authentifizierte Identität im Sicherheitskontext festzulegen. Die authentifizierte Identität kann in Downstream-Aufrufen von Java-EE-Ressourcen (oder anderen Ressourcentypen) verwendet werden.

Die Kombination der beiden Szenarien hat geringfügige Auswirkungen. Beispiel: Der HTTP-Transport sendet Daten für die Basisauthentifizierung mit user1 und Kennwort im HTTP-Header, aber im SOAP-Header ist auch ein <wsse:UsernameToken> mit user99 und letmein enthalten. In den vorherigen Szenarien werden zwei Authentifizierungen durchgeführt. Eine vom Web-Container, der user1 authentifiziert, und eine von Web Services Security für die Authentifizierung von user99. Die Laufzeitumgebung von Web Services Security wird ausgeführt, nachdem der Web-Container ausgeführt wurde und user99 die authentifizierte Identität ist, die im Sicherheitskontext definiert ist.

Web Services Security kann für SOAP-JMS-Transporte (Java Message Service) auch Sicherheitstoken vom Sender an den Empfänger weitergeben.

Rollenbasierte Java-EE-Berechtigungsprüfungen

Für Web-Services existiert kein Standard für Berechtigungen. Allerdings haben IBM und Microsoft gemeinsam ein White Paper zur Sicherheit in Web-Services mit dem Titel Security in a Web Services World: A Proposed Architecture and Roadmap veröffentlicht, in dem ein Vorschlag für die Spezifikation der WS-Berechtigung (WS-Authorization) unterbreitet wird. Die Spezifikation WS-Authorization wurde jedoch nicht veröffentlicht.

Die vorhandene Implementierung von Web Services Security basiert auf der Spezifikation Web Services for Java EE oder auf der Spezifikation Java Specification Requirements (JSR) 109. Die Implementierung von Web Services Security nutzt die rollenbasierten Java-EE-Berechtigungsprüfungen. Informationen zu Konzepten finden Sie in der Dokumentation zu rollenbasierten Berechtigung. Wenn Sie einen Web-Service entwickeln, der Berechtigungsprüfungen auf Methodenebene erfordert, müssen Sie zum Implementieren des Web-Service Stateless-Session-Beans verwenden. Weitere Informationen zur Verwendung von Stateless Session-Beans für die Implementierung eines Web-Service finden Sie je nach Programmiermodell im Artikel "Web-Service-Anwendungen mit JAX-WS implementieren" bzw. "Web-Service-Anwendungen mit JAX-RPC implementieren". Lesen Sie auch die Informationen zum Sichern von Enterprise-Bean-Anwendungen. Wenn Sie einen Web-Service entwickeln, der als Servlet implementiert wird, können Sie eine allgemein definierte oder URL-basierte Autorisierung im Web-Container verwenden. In diesem Fall ist es jedoch nicht möglich, die Identität von Web Services Security für Berechtigungsprüfungen zu verwenden. Stattdessen kann die Identität aus dem Transport verwendet werden. Bei Verwendung von SOAP over HTTP ist die Identität dann im HTTP-Transport.


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_wssecurityj2ee
Dateiname:cwbs_wssecurityj2ee.html