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.

Abbildung 1. Ablauf zwischen dem Client und dem Web-Service und dem SicherheitstokenserviceAblauf zwischen dem Client, dem Sicherheitstokenservice und dem Web-Service

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.

Abbildung 2. WS-Trust-Protokolle RST und RSTR zum Einrichten des SCT zwischen Initiator und Empfänger verwendenWS-Trust-Protokolle RST und RSTR zum Einrichten des Sicherheitskontexttokens zwischen Initiator und Empfänger verwenden

Szenario zur Verwendung sicherer Dialoge

Gewöhnlich muss zur Verwendung sicherer Dialoge (Secure Conversation) die folgenden Schritte ausgeführt werden:
  1. 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.

  2. 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.

  3. 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.

  4. 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.
  5. Der Ziel-Web-Service verwendet den abgeleiteten Schlüssel, um die Nachricht, basierend auf der Anwendungssicherheitsrichtlinie, zu prüfen und zu entschlüsseln.
  6. 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.
  7. 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.

Abbildung 3. Anwendungsnachrichten mit den Schlüsseln sichern, die aus dem geheimen Schlüssel des Sicherheitskontexttokens abgeleitet werdenAnwendungsnachrichten werden mit Schlüsseln gesichert, die aus dem geheimen Schlüssel des Sicherheitskontexttokens abgeleitet werden

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.


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_establishsct_sc
Dateiname:cwbs_establishsct_sc.html