Verbund

Der Verbund ermöglicht die Delegierung der Autorisierungsautorität an andere Mitglieder eines Unternehmensinterprise. Betrachten Sie beispielsweise das folgende Geschäftsproblem: Das Autoteilehersteller Contoso Ltd. möchte autorisierten Mitarbeitern des Kunden Fabrikam Inc den sicheren Zugriff auf den Teilebestellungswebdienst von Contoso ermöglichen. Eine Sicherheitslösung für dieses Szenario besteht darin, dass Contoso einen Vertrauensmechanismus mit Fabrikam einrichten kann, um die Zugriffsautorisierungsentscheidung an Fabrikam zu delegieren. Dieser Prozess kann wie folgt funktionieren:

• Wenn Fabrikam partner von Contoso wird, richtet eine Vertrauensstellungsvereinbarung mit Contoso ein. Das Ziel dieses Schritts besteht darin, den Sicherheitstokentyp und den Inhalt zu vereinbaren, der die Autorisierung von Fabrikam darstellt und für Contoso akzeptabel ist. Beispielsweise kann entschieden werden, dass ein vertrauenswürdiges X.509-Zertifikat mit dem Antragstellernamen "CN=Fabrikam Inc Supplier STS" ein SAML-Token signieren soll, damit dieses SAML vom Contoso-Webdienst akzeptiert wird. Darüber hinaus kann entschieden werden, dass der Sicherheitsanspruch im ausgestellten SAML-Token entweder "https://schemas.contoso.com/claims/lookup" (für die Teilweise-Nachschlageautorisierung) oder "https://schemas.contoso.com/claims/order" (für die Teilsortierungsautorisierung) sein sollte.
• Wenn ein Fabrikam-Mitarbeiter die anwendung für die interne Teilebestellung verwendet, kontaktiert er zuerst einen Sicherheitstokendienst (Security Token Service, STS) in Fabrikam. Dieser Mitarbeiter wird mithilfe des internen Fabrikam-Sicherheitsmechanismus (z. B. Benutzername/Kennwort der Windows-Domäne) authentifiziert, seine Autorisierung zum Bestellen von Teilen wird überprüft, und ihm wird ein kurzlebiges SAML-Token ausgestellt, das die entsprechenden Ansprüche enthält und mit dem oben entschiedenen X.509-Zertifikat signiert ist. Die Anwendung für die Teilebestellung kontaktiert dann den Contoso-Dienst, der das ausgestellte SAML-Token vorstellt, um sich zu authentifizieren und die Bestellaufgabe auszuführen.

Hier fungiert fabrikam STS als "ausstellende Partei", und der Contoso-Teiledienst fungiert als "vertrauende Seite".

Verbundfeatures

Im Folgenden finden Sie die unterstützten Sicherheitsfeatures für die Parteien oder Rollen, die an einem Verbundszenario beteiligt sind:

• Clientseitig: Zum Abrufen des Sicherheitstokens vom STS kann die WsRequestSecurityToken-Funktion verwendet werden. Alternativ kann eine clientseitige Sicherheitstokenanbieterbibliothek wie CardSpace oder LiveID verwendet werden, um dann mithilfe von WsCreateXmlSecurityToken lokal ein Sicherheitstoken zu erstellen. Sobald der Client über das Sicherheitstoken verfügt, kann er dann einen Kanal für den Dienst erstellen, der WS_XML_TOKEN_MESSAGE_SECURITY_BINDING angibt, um das Token zusammen mit einer Transportsicherheitsbindung wie WS_SSL_TRANSPORT_SECURITY_BINDING zum Schutz des Kanals zu präsentieren.
• Serverseitig: In einem Verbundszenario mit einem Sicherheitstokendienst, der SAML-Token ausgibt, kann der Server die WS_SAML_MESSAGE_SECURITY_BINDING zusammen mit einer Transportsicherheitsbindung wie WS_SSL_TRANSPORT_SECURITY_BINDING verwenden, um den Kanal zu schützen.
• STS-seitig: Beachten Sie, dass der STS eine Webdienstanwendung ist und die Sicherheitsanforderungen für diejenigen angeben kann, die ein Sicherheitstoken von ihr anfordern, indem eine Sicherheitsbeschreibungsstruktur zur Erstellungszeit des Listeners verwendet wird, genau wie jeder andere sichere Webdienst. Anschließend kann die Nutzlast eingehender Anforderungsnachrichten analysiert werden, um die Tokenanforderungen zu überprüfen und ausgestellte Token als Antwortnachrichtennutzlasten zurückzusenden. Derzeit werden keine Features zur Unterstützung dieser Analyse- und Ausgabeschritte bereitgestellt.

Beachten Sie, dass die Clientseite das ausgestellte Sicherheitstoken generisch als XML-Sicherheitstoken verarbeiten kann, ohne den Tokentyp zu kennen oder eine bestimmte Verarbeitung des Tokentyps durchzuführen. Der Server muss jedoch den spezifischen Sicherheitstokentyp verstehen, um ihn verstehen und verarbeiten zu können. Die Schritte zur Anforderung und Antwort von Sicherheitstoken verwenden die in der WS-Trust-Spezifikation definierten Konstrukte.

Komplexere Verbundszenarien

Ein Verbundszenario kann mehrere STS umfassen, die eine Verbundkette bilden. Betrachten Sie das folgende Beispiel:

• Der Client authentifiziert sich beim LiveID STS mit einem LiveID-Benutzernamen/Kennwort und ruft ein Sicherheitstoken T1 ab.
• Der Client authentifiziert sich mit T1 bei STS1 und ruft ein Sicherheitstoken T2 ab.
• Der Client authentifiziert sich mit T2 bei STS2 und ruft ein Sicherheitstoken T3 ab.
• Der Client authentifiziert sich mithilfe von T3 beim Zieldienst S.

Hier bilden liveID STS, STS1, STS2 und S die Verbundkette. Die STS in einer Verbundkette können verschiedene Rollen für das gesamte Anwendungsszenario ausführen. Beispiele für solche STS-Funktionsrollen sind Identitätsanbieter, Autorisierungsentscheidungsträger, Anonymisierer und Ressourcenmanager.

STS-Anforderungsparameter und Metadatenaustausch

Damit der Client einen erfolgreichen WsRequestSecurityToken-Aufruf durchführen kann, muss er die Parameter dieses Aufrufs (z. B. den erforderlichen Tokentyp und Anspruchstypen), die Sicherheitsbeschreibungsanforderungen des Anforderungskanals zum STS und die Endpunktadresse des STS kennen. Die Clientanwendung kann eine der folgenden Techniken verwenden, um diese Informationen zu ermitteln:

• Hartcodierung der Informationen in der Anwendung als Teil der Entwurfszeitentscheidungen.
• Lesen Sie diese Informationen aus einer Konfigurationsdatei auf Anwendungsebene, die vom lokalen Anwendungsbereitstellungsprogramm eingerichtet wurde.
• Dynamisches Ermitteln dieser Informationen zur Laufzeit mithilfe des Metadatenimportfeatures mit der WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT-Struktur .

Um die Verwendung von dynamischer MEX mit Verbund zu veranschaulichen, sehen Sie sich das obige 3 STS-Beispiel an. Der Kunde wird zuerst eine dynamische MEX mit S durchführen, um Informationen über T3 (d.h. was von STS2 zu fragen) sowie die dynamische STS2 MEX-Adresse (d. h. wo STS2 zu finden ist) zu erhalten. Anschließend werden diese Informationen verwendet, um eine dynamische MEX mit STS2 zu erstellen, um Informationen über T2 und STS1 usw. zu ermitteln.

Daher erfolgen die dynamischen MEX-Schritte in der Reihenfolge 4, 3, 2, 1 zum Aufbau der Verbundkette, und die Tokenanforderungs- und Präsentationsschritte erfolgen in der Reihenfolge 1, 2, 3, 4 zum Entladen der Verbundkette.

Hinweis

Windows 7 und Windows Server 2008 R2: WWSAPI unterstützt nur Ws-Trust und Ws-SecureConversation , wie durch Lightweight Web Services Security Profile (LWSSP) definiert. Ausführliche Informationen zur Implementierung von Microsoft finden Sie im Abschnitt MESSAGE Syntax von LWSSP.