Konfiguration eines Sicherheitskontexttokens zum Sichern von Dialogen - Ablauf
In diesem Beispielszenario wird gezeigt, wie der Initiator das Sicherheitskontexttoken (SCT, Security Context Token) über das Protokoll WS-Trust für sitzungsbasierte Sicherheit mit dem Empfänger einrichtet. Nach dem Einrichten des Sicherheitskontexttokens werden aus dem Sicherheitskontexttoken abgeleitete Schlüssel verwendet, um die SOAP-Nachrichten für den Zugriffsschutz auf Nachrichtenebene zu signieren und zu verschlüsseln. Dieses Beispiel konzentriert sich auf den Nachrichtenaustausch über das Sicherheitskontexttoken im Gesamtfluss der SOAP-Nachrichten.
Die OASIS-Entwurfsspezifikation (Organization for the Advancement of Structured Information Standards) "Web Services Secure Conversation (WS-SecureConversation)" beschreibt Methoden, um eine sichere Sitzung zwischen dem Initiator und dem Empfänger von SOAP-Nachrichten einzurichten. Die Entwurfsspezifikation "WS-SecureConversation" definiert auch, wie das Protokoll "Web Services Trust" (WS-Trust) verwendet wird, um ein Sicherheitskontexttoken zu konfigurieren. Das Produkt unterstützt Version 1.3 und die Entwurfsversion der Spezifikation WS-SecureConversation.
WebSphere Application Server unterstützt die Fähigkeit eines Endpunkts, ein Sicherheitskontexttoken für WS-SecureConversation auszustellen und damit eine sichere Sitzung zwischen dem Initiator und dem Empfänger von SOAP-Nachrichten einzurichten.
Die folgende Abbildung veranschaulicht den Ablauf, der erforderlich ist, um einen gesicherten Kontext einzurichten und sitzungsbasierte Sicherheit zu verwenden.

Nachrichtenaustausch zwischen dem Initiator und dem Empfänger
Die folgende Abbildung zeigt, wie die Nachrichten zwischen dem Initiator und dem Empfänger ausgetauscht werden, um das Sicherheitskontexttoken einzurichten. Die beiden WS-Trust-Protokolle RequestSecurityToken (RST) und RequestSecurityTokenResponse (RSTR) werden verwendet, um das Sicherheitskontexttoken vom Empfängerendpunkt anzufordern.
Die Bootstraprichtlinie wird verwendet, um die RST-Anforderung zu sichern und die RSTR-Anforderung zu validieren. Dies unterscheidet sich gewöhnlich von der Anwendungssicherheitsrichtlinie.

Szenario zur Verwendung sicherer Dialoge
- Der Client sendet eine RST-Trust-Anforderung (RequestSecurityToken) für ein Sicherheitskontexttoken mit seinem
geheimen Schlüssel an einen Anwendungsendpunkt (Entropie und Zielschlüsselgröße) und fordert den geheimen Schlüssel des Zielservice
an.
Diese Anforderung wird gewöhnlich über asymmetrische Web Services Security gesichert, die in der Bootstraprichtlinie definiert ist.
- Die RST-Anforderung wird vom Trust-Service verarbeitet. Wenn die Anforderung, basierend auf der Sicherheitsrichtlinie
anerkannt wird, gibt der Trust-Service das Sicherheitskontexttoken mit dem geheimen Schlüssel des Zielservice
über eine WS-Trust RequestSecurityTokenResponse (RSTR) zurück.
Diese Anforderung wird gewöhnlich über asymmetrische Web Services Security gesichert. Der Client prüft, basierend auf der Bootstraprichtlinie, ob die RSTR vertrauenswürdig ist.
- Wenn die RequestSecurityTokenResponse vertrauenswürdig ist, sichert (signiert und verschlüsselt) der Client
die nachfolgenden Anwendungsnachrichten mit den Sitzungsschlüsseln.
Die Sitzungsschlüssel werden aus dem geheimen Schlüssel des Sicherheitskontexttokens abgeleitet, das über die ersten WS-Trust-RequestSecurityToken- und -RequestSecurityTokenResponse-Nachrichten angefordert wurde, die zwischen dem Initiator und dem Empfänger ausgetauscht wurden.
- Die Spezifikation definiert einen Algorithmus für die Ableitung der Schlüssel auf der Basis des anfänglichen geheimen Schlüssels. Der Ziel-Web-Service berechnet den abgeleiteten Schlüssel aus den Metadaten, die im Sicherheitsheader der SOAP-Nachrichten enthalten sind, und dem anfänglichen geheimen Schlüssel.
- Der Ziel-Web-Service verwendet den abgeleiteten Schlüssel, um die Nachricht, basierend auf der Anwendungssicherheitsrichtlinie, zu prüfen und zu entschlüsseln.
- Der Ziel-Web-Service verwendet den aus dem geheimen Schlüssel abgeleiteten Schlüssel, um die Antwort, basierend auf der Anwendungssicherheitsrichtlinie, zu signieren und zu verschlüsseln.
- Die Schritte 3 bis 6 werden so lange wiederholt, bis der Nachrichtenaustausch abgeschlossen ist.
Aus dem geheimen Schlüssel des Sicherheitskontexttokens abgeleitete Schlüssel verwenden
Nach dem Einrichten des Sicherheitskontexttokens werden die Anwendungsnachrichten durch Nachrichtenschutz gesichert, indem Schlüssel verwendet werden, die aus dem geheimen Schlüssel des Sicherheitskontexttokens abgeleitet werden. Die abgeleiteten Schlüssel werden verwendet, um die Anwendungsnachrichten durch Signieren und Verschlüsseln zu sichern. Das Sicherheitskontexttoken enthält eine UUID, die als Identifikation eines geheimen Schlüssels verwendet wird. Die Token-UUID kann in der SOAP-Nachricht verwendet werden, um das Sicherheitskontexttoken für den Nachrichtenaustausch zu identifizieren. Der geheime Schlüssel muss von den Sitzungsteilnehmern (in diesem Fall Initiator und Empfänger) im Speicher gehalten und geschützt werden. Die Offenlegung des geheimen Schlüssels untergräbt den sicheren Dialog zwischen den Teilnehmern.

Ein ähnliches Szenario mit Ausnahme von Web Services Reliable Messaging (WS-ReliableMessaging) ist von der WS-SecureConversation-Perspektive aus möglich. Sehen Sie sich das Beispiel für das Einrichten eines Sicherheitskontexttokens zum Sichern des Reliable Messaging an.