Freigeben über

Föderation

  • Artikel

Der Partnerverbund ermöglicht die Delegierung der Autorisierungsbehörde an andere Mitglieder eines Interoperabilitätsunternehmens. Betrachten Sie z. B. das folgende Geschäftsproblem: Das Autopart-Fertigungsunternehmen Contoso Ltd möchte autorisierten Mitarbeitern des Kunden Fabrikam Inc. erlauben, sicher auf contosos Parts Order Web Service zuzugreifen.For example, consider the following business problem: The auto parts manufacturing company Contoso Ltd would like to allow authorized employees of its customer Fabrikam Inc to securely access contoso parts order Web Service. 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 Vorgang kann wie folgt funktionieren:

  • Fabrikam, wenn es ein Partner von Contoso wird, richtet eine Vertrauensvereinbarung mit Contoso ein. Ziel dieses Schritts ist es, den Sicherheitstokentyp und den Inhalt zu vereinbaren, der die Autorisierung von Fabrikam darstellt und für Contoso akzeptabel ist. Es kann beispielsweise entschieden werden, dass ein vertrauenswürdiges X.509-Zertifikat mit dem Antragstellernamen "CN=Fabrikam Inc Supplier STS" ein SAML-Token für diese SAML signieren soll, die vom Contoso-Webdienst akzeptiert werden soll. Darüber hinaus kann entschieden werden, dass der Sicherheitsanspruch im ausgestellten SAML-Token entweder "https://schemas.contoso.com/claims/lookup" (für die Part-Nachschlageautorisierung) oder "https://schemas.contoso.com/claims/order" (für die Teilebestellungsautorisierung) sein sollte.
  • Wenn ein Fabrikam-Mitarbeiter die interne Teilebestellungsanwendung verwendet, kontaktiert er zuerst einen Sicherheitstokendienst (Security Token Service, STS) innerhalb von Fabrikam. Dieser Mitarbeiter wird mithilfe des internen Fabrikam-Sicherheitsmechanismus authentifiziert (z. B. Windows-Domänenname/Kennwort), seine Autorisierung zum Bestellen von Teilen wird überprüft, und er wird ein kurzlebiges SAML-Token ausgestellt, das die entsprechenden Ansprüche enthält und vom oben beschlossenen X.509-Zertifikat signiert wurde. Die Teilebestellungsanwendung kontaktiert dann den Contoso-Dienst, der das ausgestellte SAML-Token darstellt, um die Sortieraufgabe zu authentifizieren und auszuführen.

Hier fungiert der Fabrikam STS als "ausstellende Partei" und der Contoso-Webpartdienst als "vertrauende Seite". Diagramm mit einer ausstellenden Partei und einer vertrauenden Seite in einem Partnerverbund.

Partnerverbundfeatures

Im Folgenden werden die unterstützten Sicherheitsfeatures für die Parteien oder Rollen aufgeführt, die in einem Verbundszenario beteiligt sind:

  • Clientseitig: Zum Abrufen des Sicherheitstokens vom STS kann eine WsRequestSecurityToken-Funktion verwenden. Alternativ kann eine clientseitige Sicherheitstokenanbieterbibliothek wie CardSpace oder LiveID verwendet werden und dann ihre Ausgabe verwenden, um lokal ein Sicherheitstoken mit WsCreateXmlSecurityTokenzu erstellen. Auf beide Weise kann der Client, sobald der Client das Sicherheitstoken hat, einen Kanal zum Dienst erstellen, der WS_XML_TOKEN_MESSAGE_SECURITY_BINDING angibt, um das Token darzustellen, zusammen mit einer Transportsicherheitsbindung wie WS_SSL_TRANSPORT_SECURITY_BINDING zum Schutz des Kanals.
  • Serverseitig: In einem Verbundszenario mit einem Sicherheitstokendienst, der SAML-Token ausgibt, kann der Server das WS_SAML_MESSAGE_SECURITY_BINDINGzusammen mit einer Transportsicherheitsbindung wie WS_SSL_TRANSPORT_SECURITY_BINDING verwenden, um den Kanal zu schützen.
  • STS-side: Beachten Sie, dass es sich bei stS um eine Webdienstanwendung handelt, und sie kann die Sicherheitsanforderungen für diejenigen angeben, die ein Sicherheitstoken von ihr anfordern, indem sie eine Sicherheitsbeschreibung Struktur bei der Listenererstellung genau wie jeder andere sichere Webdienst verwenden würde. Es kann dann eingehende Anforderungs-Nachrichtennutzlasten analysieren, um die Tokenanforderungen zu überprüfen und ausgestellte Token als Antwortnachrichtennutzlasten zu senden. Derzeit werden keine Features bereitgestellt, um diese Analyse- und Ausgabeschritte zu unterstützen.

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 zu verstehen und zu verarbeiten. Die Schritte für Sicherheitstokenanforderung und -antwort verwenden die in der WS-Trust Spezifikation definierten Konstrukte.

Komplexere Verbundszenarien

Ein Verbundszenario kann mehrere STSs 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 mit T3 beim Zieldienst S.

Hier bilden liveID STS, STS1, STS2 und S die Verbundkette. Die STSs 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, Anonymisierter und Ressourcenmanager.

STS-Anforderungsparameter und Metadatenaustausch

Damit der Client eine erfolgreiche WsRequestSecurityToken Aufruf ausführen kann, muss er die Parameter dieses Aufrufs kennen (z. B. den erforderlichen Tokentyp und Anspruchstypen), die Sicherheitsbeschreibung Anforderungen des Anforderungskanals an den STS und die Endpunktadresse des STS. Die Clientanwendung kann eine der folgenden Techniken zum Ermitteln dieser Informationen verwenden:

  • Hartcodierten Sie die Informationen in der Anwendung als Teil der Entwurfszeitentscheidungen.
  • Lesen Sie diese Informationen aus einer Konfigurationsdatei auf Anwendungsebene, die vom lokalen Anwendungsbereitstellungsdienst eingerichtet wurde.
  • Ermitteln Sie diese Informationen zur Laufzeit mithilfe des Metadatenimports Feature mit der WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT Struktur dynamisch.

Um die Verwendung dynamischer MEX mit Partnerverbund zu veranschaulichen, berücksichtigen Sie das obige 3 STS-Beispiel. Der Kunde wird zunächst 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 tun, um Informationen über T2 und STS1 zu finden usw.

Daher erfolgen die dynamischen MEX-Schritte in der Reihenfolge 4, 3, 2, 1, um die Partnerverbundkette aufzubauen, und die Tokenanforderungs- und Präsentationsschritte werden in der Reihenfolge 1, 2, 3, 4 durchgeführt, um die Verbundkette abzuwickeln.

Anmerkung

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