Mit Richtliniensätzen und Bindungen werden die von WebSphere Message
Broker unterstützten WS-Security- und WS-RM-Anforderungen für die SOAPInput-, SOAPReply-, SOAPRequest-, SOAPAsyncRequest- und SOAPAsyncResponse-Knoten definiert und konfiguriert.
Ein Richtliniensatz ist ein Container für den Richtlinientyp 'WS-Security' und
den Richtlinientyp 'WS-RM'.
Eine Richtliniensatzbindung ist einem Richtliniensatz zugeordnet. Sie enthält umgebungs- und plattformspezifische Informationen, beispielsweise die Schlüsselinformationen.
Mit Richtliniensätzen und Bindungen können Sie für SOAP-Anforderungs- und SOAP-Antwortnachrichten Folgendes definieren:
- Authentifizierung für die folgenden Token:
- Username-Token (benötigt ein Sicherheitsprofil für die Angabe des externen Sicherheitsproviders)
- X.509-Zertifikate (benötigt den Broker-Keystore und -Truststore bzw. ein Sicherheitsprofil zur Angabe des externen Sicherheitsproviders)
- SAML-Zusicherungen mit SAML 1.1- oder -2.0-Durchgriffsfunktion (benötigt ein Sicherheitsprofil für die Angabe des externen Sicherheitsproviders)
- LTPA-Token mit LTPA-Durchgriff (erfordert ein Sicherheitsprofil für die Angabe des externen Sicherheitsproviders)
- Asymmetrische Verschlüsselung (Vertraulichkeit) mit X.509-Zertifikaten (benötigt den Broker-Keystore bzw. -Truststore)
- Symmetrische Verschlüsselung (Vertraulichkeit) mit Kerberos-Token (benötigt den Host, der für Kerberos konfiguriert werden muss)
- Asymmetrische Verschlüsselung (Integrität) (benötigt den Broker-Keystore bzw. -Truststore)
Der gesamte Nachrichtentext der SOAP-Nachricht oder Teile des Headers und des Nachrichtentextes können verschlüsselt und signiert werden.
Richtliniensätze und Bindungen werden mit dem WebSphere Message
Broker Explorer
verwaltet, mit dem Sie Richtliniensätze und Bindungen hinzufügen, löschen, anzeigen und bearbeiten
können. Alle Änderungen an Richtliniensätzen oder Bindungen im Toolkit werden direkt im zugehörigen Broker gespeichert.
Damit die neuen Konfigurationsdaten wirksam werden, müssen Sie den Nachrichtenfluss stoppen und anschließend erneut starten.
Sie können die Richtliniensätze und Bindungen auch aus einem Broker exportieren und importieren.
Richtliniensätze und ihre zugehörigen Bindungen müssen gemeinsam gespeichert und wieder hergestellt werden.
Richtliniensätze werden im Brokerarchiveditor einem Nachrichtenfluss, einem Knoten oder beidem zugeordnet. Sie können die Angaben für Provider und Konsument auch einfach auf Nachrichtenflussebene angeben. Die Angabe des Providers gilt für alle SOAPInput- und SOAPReply-Knoten im Nachrichtenfluss. Die Angabe des Konsumenten gilt für alle SOAPRequest-, SOAPAsyncRequest- und SOAPAsyncResponse-Knoten. Es ist möglich, einzelne Richtliniensätze und Bindungen im Brokerarchiveditor auf Knotenebene zuzuordnen; diese haben dann Vorrang vor den auf Nachrichtenflussebene angegebenen Einstellungen für den Provider und Konsumenten. Die Standardeinstellung ist keine, d. h. keine Richtliniensätze und Bindungen werden verwendet.
Es können auch mehrere Knoten des gleichen Nachrichtenflusses auf denselben Richtliniensatz und
dieselben Bindungen verweisen. Der Administrator muss sicherstellen, dass die benötigten
Richtliniensätze während der Ausführungszeit zur Verfügung stehen. Wenn der Broker keine zugehörigen Richtliniensätze oder Bindungen findet, wird ein Fehler gemeldet.
Im verbleibenden Teil dieses Abschnitts werden einige Begriffe erläutert, die in Verbindung mit der Konfiguration von Richtliniensätzen und Bindungen verwendet werden.
Standardrichtliniensatz und Standardbindungen
Bei der Erstellung eines Brokers werden ein Standardrichtliniensatz und Standardbindungen erstellt (WSS10Default). Dieser Standardwert enthält eine eingeschränkte Sicherheitsrichtlinie, die vorgibt, dass in (eingehenden) Anforderungsnachrichten an SOAPInput-Knoten im zugehörigen Nachrichtenfluss ein Username-Token vorhanden ist. Darüber hinaus wird der WS-RM-Standardrichtliniensatz 'WSRMDefault' erstellt.
Die standardmäßige Richtliniensatzbindung bezieht sich auf den Standardrichtliniensatz 'WSS10Default', nicht auf 'WSRMDefault'.
Beide können nicht bearbeitet werden.
Knoten als Konsument oder Provider
Bei Knoten handelt es sich entweder um Konsumenten oder um Provider.
- Knoten als Konsumenten
- SOAPRequest
- SOAPAsyncRequest
- SOAPAsyncResponse
- Knoten als Provider
-
Anforderung und Antwort
Das Konzept 'Anforderung und Antwort' ist ein Muster des Nachrichtenaustauschs (MEP). Darunter versteht man einen Client, der eine SOAP-Anforderungsnachricht an einen Web-Services-Server sendet, der dem Client wiederum eine SOAP-Antwortnachricht zurücksendet. Die Anforderungsnachricht ist immer die vom Client an den Server gesendete SOAP-Nachricht, während die Antwortnachricht immer die vom Server an den Client gesendete Antwort auf die SOAP-Nachricht ist. In der folgenden Tabelle wird dies im Hinblick auf die SOAP-Knoten von
WebSphere Message
Broker beschrieben:
Knoten |
Aus der Sicht des Brokers |
Anforderung |
Antwort |
SOAPInput |
Ankommende SOAP-Nachricht |
Ankommende Nachricht |
Nicht zutreffend |
SOAPReply |
Abgehende SOAP-Nachricht |
Nicht zutreffend |
Abgehende Nachricht |
SOAPRequest |
Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht |
Abgehende Nachricht |
Ankommende Nachricht |
SOAPAsyncRequest |
Abgehende SOAP-Nachricht |
Abgehende Nachricht |
Nicht zutreffend |
SOAPAsyncResponse |
Ankommende SOAP-Nachricht |
Nicht zutreffend |
Ankommende Nachricht |
Initiator und Empfänger
Die am Austausch von SOAP-Nachrichten beteiligten Rollen sind 'Initiator' und 'Empfänger'.
- Initiator
- Die Rolle, die innerhalb eines Nachrichtenaustausches die Startnachricht sendet.
- Empfänger
- Die Zielrolle, die die Startnachricht innerhalb eines Nachrichtenaustausches verarbeitet.
In der folgenden Tabelle werden diese Rollen im Hinblick auf die
SOAP-Knoten beschrieben:
Knoten |
Aus der Sicht des Brokers |
Initiator |
Empfänger |
SOAPInput |
Ankommende SOAP-Nachricht |
Externer Client, der eine SOAP-Nachricht an den Broker sendet |
SOAPInput-Knoten |
SOAPReply |
Abgehende SOAP-Nachricht |
Externer Client, der die SOAP-Startnachricht an den Broker gesendet hat |
SOAPReply-Knoten |
SOAPRequest (abgehend) |
Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht |
SOAPRequest-Knoten
|
Externer Provider, der die SOAP-Nachricht empfängt |
SOAPRequest (eingehend) |
Abgehende SOAP-Nachricht gefolgt von einer ankommenden SOAP-Nachricht |
SOAPRequest-Knoten |
Externer Provider, der die SOAP-Nachricht empfängt |
SOAPAsyncRequest |
Abgehende SOAP-Nachricht |
SOAPAsyncRequest-Knoten |
Externer Provider, der die SOAP-Nachricht empfängt |
SOAPAsyncResponse |
Ankommende SOAP-Nachricht |
SOAPAsyncRequest-Knoten |
Externer Provider, der die SOAP-Nachricht empfängt |
SOAPInput- und SOAPReply-Knoten
In diesem Diagramm ist der Broker der Empfänger. Ein
SOAPInput-Knoten empfängt eine Nachricht von einem Client (dem Initiator). Ein
SOAPReply-Knoten schickt eine Antwort. Eingehende und abgehende Nachrichten werden signiert und verschlüsselt.
In der Anforderungsnachricht:- Der Initiator verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.
In der Antwortnachricht: - Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Initiators und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Initiator entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.
SOAPRequest-Knoten
Dieses Diagramm zeigt den Broker als Initiator. Über den
SOAPRequest-Knoten sendet er eine synchrone Anforderung an einen externen Provider (den Empfänger). Eingehende und abgehende Nachrichten werden signiert und verschlüsselt. Die Verwendung von Token ist ähnlich wie im Beispiel mit den asynchronen SOAP-Knoten oben.
In der Anforderungsnachricht:- Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Empfängers und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Empfänger entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.
In der Antwortnachricht: - Der Empfänger verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.
Asynchrone SOAP-Knoten
Dieses Diagramm zeigt den Broker als Initiator. Über asynchrone SOAP-Knoten sendet er eine Anforderung an einen externen Provider (den Empfänger). Eingehende und abgehende Nachrichten sind signiert und verschlüsselt.
In der Anforderungsnachricht:- Der Broker verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Empfängers und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Empfänger entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Brokers.
In der Antwortnachricht: - Der Empfänger verschlüsselt die Nachricht mit dem öffentlichen Verschlüsselungstoken des Brokers und signiert sie mit dem eigenen privaten Signaturtoken.
- Der Broker entschlüsselt die Nachricht mit dem eigenen privaten Verschlüsselungstoken und überprüft die Signatur anhand des öffentlichen Signaturtokens des Initiators.