WS-Trust ist ein OASIS-Standard, der Webdienst-Clients und -Anbieter anweist, mit dem Sicherheitstokendienst (STS) zu interagieren, um Sicherheitstoken auszustellen, zu erneuern und zu validieren, damit eine vertrauenswürdige Verbindung hergestellt werden kann. Dieser Austausch kann zwischen verschiedenen Webgeräten, APIs oder Anwendungen über SOAP-Nachrichten (Simple Object Access Protocol) erfolgen. Wenn die empfangende Stelle das Sicherheitstoken der anfragenden Stelle erfolgreich validiert, kann die Verbindung hergestellt werden. Schlägt die Validierung fehl, wird die Anfrage abgelehnt.
Ein OASIS-Webstandard
„Das Ziel von WS-Trust besteht darin, Anwendungen für den Austausch vertrauenswürdiger [SOAP]-Nachrichten zu befähigen. Das Vertrauen wird durch den Austausch und die Vermittlung von Sicherheitstoken repräsentiert. Diese Spezifikation bietet eine protokollunabhängige Möglichkeit zur Ausstellung, Erneuerung und Validierung dieser Sicherheitstoken.“ 1
In einem Webdienst, der WS-Trust verwendet, wird der STS von beiden Seiten verwendet, um den Authentifizierungsprozess abzuschließen.
Wenn zum Beispiel ein Client Zugang zum Dienst anfordert, sendet er eine Nachricht an den Server, die ein Token mit XML-Datensätzen enthält, das ihn identifiziert. Das Token ist durch eine starke Kryptographie geschützt und enthält auch Informationen über seine Lebensdauer und seine Eigentümer. Wenn der Server die Nachricht vom Client erhält, authentifiziert der Server die Identität des Clients anhand der Daten in seiner eigenen Datenbank nicht selbst, sondern er sendet die Anfrage an den STS, der sie dann bewertet und validiert. Im Anschluss an diesen umfassenden Austausch kann der Client dem Server das Token für den Zugriff vorlegen.
Das Konzept der universellen Übersetzung von Token und eines STS hat seinen Ursprung bei den Webservices Schon früh verhinderte das Fehlen einer Standardmethode für das Kommunizieren von Benutzeridentitäten die breite Akzeptanz von Web-Service-Anwendungen im Unternehmensbereich. In der SOAP-Welt sind daraufhin Standards aufgetaucht, wie zum Beispiel WS-Security und WS-Trust, die durch die Integration von standardmäßigen Sicherheitstoken in die SOAP-Nachrichten ermöglichen sollten, dass Web-Services die Benutzeridentitäten weitergeben können.
Während WS-Trust die Token-Verarbeitung in zwei Phasen beim Web-Service-Client und -Provider vorsieht, gibt es beim zugrunde liegenden STS keine derartigen Einschränkungen. Infolgedessen haben größere Unternehmen mit mehreren Sicherheitsdomänen den Wert eines Security Token Service (STS) als „universellen Token-Übersetzer“ erkannt, der jede Art von Sicherheitstoken in jedes beliebige andere Sicherheitstoken umwandeln kann – auch dann, wenn keine Webdienste in Anspruch genommen werden.
Der WS-Trust-Standard legt fest, dass der Security Token Service (STS) sowohl von Web-Service-Clients als auch von Anbietern zur Durchführung von Operationen mit standardmäßigen Sicherheitstoken genutzt werden kann. Auf der Seite des Web-Service-Clients, bei dem es sich um eine Web-Anwendung oder um eine umfangreiche Desktop-Anwendung handeln kann, wandelt der STS jedes beliebige, lokal verwendete Sicherheitstoken in ein standardmäßiges Security Assertion Markup Language (SAML)-Token um. Dieses enthält die Benutzeridentität, die daraufhin an den Web-Service-Anbieter weitergegeben wird. Auf der Seite des Web-Service-Anbieters validiert der STS die eingehenden Sicherheitstoken und kann ein neues lokales Token für die Verwendung mit anderen Anwendungen erzeugen.
Der Prozess beginnt damit, dass der Anfragende den Dienstanbieter nach seinen Sicherheitsrichtlinien fragt und diese mit seinen eigenen Anforderungen abgleicht, um festzustellen, ob er über die erforderlichen Sicherheitstoken für den Zugang zu diesem Dienstanbieter verfügt. Der Dienst kann an ein elektronisches Gerät gebunden sein, das mit dem Kunden über das Internet kommuniziert, oder er kann sich auf einem Computer befinden, der Anfragen über einen bestimmten Port in einem Netzwerk empfängt.
Wenn der Anfragende kein gültiges Token verfügbar hat, kann er eines vom STS anfordern. Auf diese Weise fungiert der STS für den Anfragenden wie ein Identitätsanbieter, denn er stellt Token für die Authentifizierung aus und erneuert sie.
Wenn der Anbieter das Token vom Client erhält, wird sein STS das Token entweder validieren oder zurückzuweisen.
Wenn der Anbieter das Token akzeptiert, wird eine Verbindung hergestellt. Wenn es nicht akzeptiert wird, findet keine Nachrichtenübermittlung statt.
Ressourcen zu diesem Thema
Starten Sie jetzt
Erfahren Sie, wie Ping Sie dabei unterstützen kann, sichere Mitarbeiter- und Kundenerlebnisse in einer sich schnell entwickelnden digitalen Welt zu schaffen.
Kostenlose Demo anfordern