Programmiermodell der Web Services Security-API

Das Programmiermodell des Anwendungsservers stellt APIs von Web Services Security (WSS-API) für die Sicherung von SOAP-Nachrichten bereit.

Das API-Programmiermodell ist ein schnittstellenbasiertes Programmiermodell, das auf den Standards von Web Services Security Version 1.1 basiert, aber auch Unterstützung für Web Services Security Version 1.0 zum Sichern von SOAP-Nachrichten enthält. Die Implementierung des Programmiermodells mit der WSS-API ist eine vereinfachte Version, die auf einem früheren Entwurfsvorschlag von JSR-183 basiert, einer JSR (Java Specification Request) für die Definition einer Java™-API-Bindung für Web Services Security. Da der Anwendungscode gemäß Design für die Schnittstelle programmiert wird, muss jeder Anwendungscode, der mit der Open-Source-Implementierung programmiert ist, mit minimalen oder überhaupt keinen Änderungen in WebSphere Application Server ausgeführt werden können.

Das Konfigurationsmodell für Web-Services wurde ebenfalls von einem Implementierungsdeskriptormodell auf ein Richtliniensatzmodell umgestellt. Web Services Security kann über einen Richtliniensatz, der in der Administrationskonsole konfiguriert wird, oder über die WSS-API für die Konfiguration aktiviert werden. Die von den Richtliniensatzkonfigurationen bereitgestellten Funktionen entsprechen den Funktionen, die von der WSS-API für die Laufzeitumgebung von Web Services Security unterstützt werden. Die über Richtliniensätze definierte Sicherheitsrichtlinie hat jedoch eine höhere Priorität als die WSS-API. Wenn die WSS-API und der Richtliniensatz in der Anwendung verwendet werden, wird die Sicherheitsrichtlinie standardmäßig über den Richtliniensatz aktiviert, und die WSS-API wird ignoriert. Wenn Sie die WSS-API in der Anwendung verwenden möchten, müssen Sie sicherstellen, dass der Anwendung oder den Anwendungsressourcen kein Richtliniensatz zugeordnet ist bzw. keine Sicherheitsrichtlinie im zugeordneten Richtliniensatz enthalten ist.

Die vorhandenen JAX-RPC-Anwendungen können weiterhin mit Web Services Security verwendet werden. Allerdings können diese Anwendungen die neuen Funktionen von Web Services Security Version 1.1, wie z. B. die Konfiguration der Sicherheitsrichtlinie über einen Richtliniensatz, Verbesserung der OM-Filterleistung, WSS-API, Web Services Secure Conversation (WS-SecureConversation), Kerberos-Token und der zugehörige SHA-1-Schlüssel für Nachrichtenschutz und Identitätsweitergabe und Web Services Trust (WS-Trust) nicht nutzen.

Damit die Funktionen von Web Services Security Version 1.1 genutzt werden können, müssen Sie eine vorhandene JAX-RPC-Anwendung als JAX-WS-Anwendung umschreiben, die die Sicherheitsbedingungen manuell in einen Richtliniensatz rekonfigurieren und eine Codemigration der DOM-basierten SPIs auf die OM-basierten SPIs ausführen.

Wenn Sie z. B. das Programmiermodell JAX-WS verwenden, können Sie aufgrund des verbesserten Designs des Plug-in-fähigen Token-Frameworks dieselbe Sicherheitsimplementierung sowohl für die API als auch für die Richtliniensätze verwenden. Das Framework verwendet das JAAS-Anmeldemodul und den JAAS-Callback-Handler für die Tokenerstellung und Tokenvalidierung.

Die folgenden Abbildungen veranschaulichen die Unterschiede zwischen den Programmiermodellen.

Abbildung 1. Plug-in-Tokenarchitektur mit dem JAX-WS-Programmiermodell
Plug-in-Tokenarchitektur mit dem JAX-WS-Programmiermodell
Abbildung 2. Plug-in-Tokenarchitektur mit dem JAX-RPC-Programmiermodell
Plug-in-Tokenarchitektur mit dem JAX-RPC-Programmiermodell

Unterstützte Komponenten bei der Verwendung der WSS-APIs

Die WSS-API kann nur im Client verwendet werden. Sie können den Java SE 6-Client, den J2EE-Anwendungsclient oder einen Server-Client (einen Service-Provider, der als Client auftritt) über die API verwenden, um SOAP-Nachrichten durch Sicherheit auf Nachrichtenebene zu sichern.

Sie müssen Kenntnisse über Web Services Security (WSS) besitzen, um die WSS-APIs verwenden zu können. Vor der Verwendung der WSS-API müssen Sie beachten, dass die WSS-APIs
  • Java-basierte Schnittstellen sind,
  • über ein Factory-Modell (WSSFactory) implementiert werden,
  • die Standards WS-Security Version 1.0 und 1.1 unterstützen, zu denen die Tokenprofile Username und X.509 der Versionen 1.0 und 1.1 gehören,
  • extrem XML-orientiert sind,
  • ein objektorientiertes Design haben, das die APIs vereinfacht,
  • taskorientiert sind und allgemeine Einsatzszenarien zulassen, wie z. B. das Signieren und das Verschlüsseln des Inhalts des SOAP-Nachrichtenhaupttteils,
  • flexibel und erweiterbar sind und Ihnen die Erweiterung der Unterstützung für Tokentypen ermöglichen,
  • auf dem Provider-Framework basieren und die Verwendung unterschiedlicher Datenmodelle, wie z. B. AXIOM oder DOM ermöglichen,
  • Anwendungsprogrammierern eine bessere und eine höhere Flexibilität beim Anwenden von WSS in ihren Anwendungen ermöglichen.

Die Standardwerte für die WSS-API sind vordefiniert und gehören zur Laufzeitumgebung von Web Services Security. Es werden Standardwerte für Folgendes bereitgestellt:

  • Dauer der Zeitmarke
  • Signaturalgorithmus, Kanonisierungsalgorithmus, Digest-Methode, Umsetzungsalgorithmus, Referenzmethode für Sicherheitstoken und signierte Abschnitte, wie z. B. den SOAP-Hauptteil, WS-Addressing-Header und die Zeitmarke
  • Verschlüsselungsalgorithmus für Schlüssel, Algorithmus für Datenverschlüsselung, Referenzmethode für Sicherheitstoken und verschlüsselte Abschnitte, z. B. den Inhalt des SOAP-Hauptteils (Body)

Die Signaturvalidierung hat ähnliche Standardwerte wie die Signatur (Signaturdaten). Entschlüsselung hat ähnliche Standardwerte wie Verschlüsselung.

Nicht unterstützte Komponenten bei der Verwendung der WSS-APIs

Die mit dem Anwendungsserver bereitgestellte WSS API bietet keine Unterstützung für die folgenden Funktionen:

  • Das Anwendungsprogrammiermodell ist JAX-WS, d. h., JAX-RPC-Anwendungen (JSR-109) werden nicht unterstützt.
  • Die WSS-API ist beim synchronen Nachrichtenaustausch der JAX-WS-Clientanwendung verfügbar. Die WSS-APIs werden für den asynchronen Client nicht unterstützt.
  • Die WSS-API-Unterstützung ist nur für den Anforderer und nicht für den Provider verfügbar.
  • Das Programmiermodell für die Semantik für Zusicherung der Identität wird in den WSS-APIs nicht unterstützt, weil die Zusicherung der Identität nicht zum Standard Web Services Security Version 1.0 gehört. Sie können die WSS-API jedoch verwenden, um der Tokenverarbeitung die Semantik für die Zusicherung der Identität hinzuzufügen.

Szenarien mit WS-Trust und WS-SecureConversation

WS-Trust-SOAP-Nachrichten können auf mehrere Arten gesichert werden:
  • über die im Richtliniensatz definierte Bootstrap-Richtlinie
  • über die WSS API, die "WS-SecureConversation" unterstützt.
  • durch Aktivierung der dynamischen Richtlinie für den Provider, sodass der Client zur Ausführungszeit die Richtlinie auf Providerseite abrufen kann.

Eine Anwendung verwendet die WSS-API, um ein Sicherheitskontexttoken (SCT, Security Context Token) für programmorientierte API-basierte sichere Dialoge anzufordern. Der Trust-Service von WebSphere Application Server ermöglicht einer Anwendung, ein Sicherheitstoken für den Zugriff auf einen Service anzufordern. Umfang und Fokus des Trust-Service beschränken sich auf ein SCT von WebSphere Application Server für WS-SecureConversation.

Die Szenarien mit WS-SecureConversation und WS-Trust konzentrieren sich auf die Interoperabilitätsfunktionen, wie z. B. die Konfigurations- und Laufzeitinteraktion verschiedener Komponenten. Sie verwenden die WSS-API, um Bootstrap-RST und -RSTR zu sichern, um das Sicherheitskontexttoken vom Trust-Service anzufordern. Nach dem Erhalt des Sicherheitskontexttokens wird mit der WSS-API ein abgeleitetes Schlüsseltoken erstellt. Anschließend kann das abgeleitete Schlüsseltoken für die Signatur und Verschlüsselung verwendet werden.

Sehen Sie sich die Beispiele an, die die folgenden Einsatz-Szenarien für Sicherheitskontexttoken beschreiben:
Wenn Sie die WSS-API zum Sichern der SOAP-Nachricht mit Web Services Security verwenden, sind zwei Bedingungen zu berücksichtigen:
  • Generierung der sicheren SOAP-Nachricht im Anwendungscode für den Anforderungsgenerator
  • Konsum der gesicherten SOAP-Nachricht im Anwendungscode für den Antwortkonsumenten

In beiden Fällen wird für das Auftreten eines Fehlers die Java-Ausnahmeklasse com.ibm.websphere.wssecurity.wssapi.WSSException bereitgestellt.

Sicherheitskontext des Web-Service-Clients

Wenn der JAX-WS-Client Web-Services aufruft, wird der aktuelle Sicherheitskontext, der vom Sicherheitshandler erstellt wird, im Objekt "RequestContext" gespeichert. Standardmäßig wird der Sicherheitskontext in der Laufzeitumgebung des JAX-WS-Web-Service-Clients für den nächsten Aufruf der Web-Service-Anforderung wiederhergestellt. Sie können den Sicherheitskontext für nachfolgende Web-Service-Aufrufe beibehalten. Ein Beispiel dafür ist ein Szenario, in dem die Sicherheitsrichtlinie vom Client das Senden eines Username-Sicherheitstoken mit dem Benutzernamen und dem Kennwort anfordert. Wenn der Client die erste Anforderung zum Aufruf des Service sendet, werden Sie aufgefordert, den erforderlichen Benutzernamen und das Kennwort einzugeben. Der Benutzername und das Kennwort werden in einem Username-Sicherheitstoken (SecurityToken) in einem "Subject" im Sicherheitskontext gespeichert. Wenn Sie es vermeiden möchten, bei nachfolgenden Aufrufen erneut denselben Benutzernamen und dasselbe Kennwort eingeben zu müssen, können Sie den Sicherheitskontext beibehalten. Der Sicherheitskontext kann auf zwei Arten beibehalten werden: 1) Konfigurieren Sie die Clientlaufzeit in der Weise, dass der Sicherheitskontext für nachfolgende Anforderungsaufrufe beibehalten wird. 2) Legen Sie manuell fest, dass der Sicherheitskontext beibehalten werden soll.

Wenn die Laufzeitumgebung des JAX-WS-Clients so konfiguriert werden soll, dass der Sicherheitskontext automatisch beibehalten wird, setzen Sie die Java-Systemeigenschaft com.ibm.websphere.wssecurity.context.management auf den Wert true. Wenn diese Systemeigenschaft auf "true" gesetzt ist, kopiert die Laufzeitumgebung des JAX-WS-Clients den vom Sicherheitshandler erstellten Sicherheitskontext automatisch in den "RequestContext", und der Kontext wird für nachfolgende Anforderungsaufrufe verwendet.

Wenn Sie manuell festlegen möchten, dass der Sicherheitskontext beibehalten werden soll, verwenden Sie den folgenden Beispielcode:
// Erste Anforderung
Service svc = Service.create(...);
svc.addPort(...);
Dispatch<String> dispatch = svc.createDispatch(...);
Map<String, Object> requestContext = dispatch.getRequestContext(); 
String response = dispatch.invoke(body.toString());

Object securityContext = requestContext.get(com.ibm.wsspi.websvcs.Constants.WEBSPHERE_SECURITY_CONTEXT);

// Nachfolgende Anforderung

Dispatch<String> dispatch = svc.createDispatch(...);
Map<String, Object> requestContext = dispatch.getRequestContext(); 
Object securityContext = requestContext.put(com.ibm.wsspi.websvcs.Constants.WEBSPHERE_SECURITY_CONTEXT, securityContext);

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_wss_api
Dateiname:cwbs_wss_api.html