Beispieldelegierung-, Verbund- und Authentifizierungsszenario in SharePoint
Dieser Artikel enthält Beispielszenarien für identitätsdelegierung und Identitätsverbund.
Beispielszenarien
Die folgenden fiktiven Unternehmen und ihren geschäftsanforderungen werden die Anforderungen in den Beispielszenarien verwendet, die in diesem Artikel beschrieben werden:
Contoso Hybrid ist ein internationaler Autohändler Engine Kooperation von Unternehmen, die spezialisierte sich auf manufacturing elektrische und Brennstoffe Zelle-basierte Hybrid Module, Auto Hersteller innerhalb und außerhalb der USA. Die IT-Abteilung bei Contoso wird in eine strategische Aufwand für die Teile Sortierung optimierte seiner Kunden zu erfüllen damit beauftragt, mit dem Entwickeln und Bereitstellen einer sicheren Internet zugänglichen Webparts Sortierung-Anwendung über dem Hostnamen "contoso.com". Diese Anwendung muss auch mehrere Zugriffsebenen für verschiedene interne Benutzer (Contoso Mitarbeiter) und externe Benutzer (Auto Hersteller Mitarbeiter) bereitstellen. Minimieren der Kosten für die Verwaltung von den Teilen der Anwendung, Sortierung IT vermeiden Sie müssen auch die Notwendigkeit für die Anwendung verwenden und einen zusätzliche Kontospeicher für interne und externe Benutzer auf die Anwendung zugreifen.
Fabrikam Motors ist ein Schwedisch Hersteller von sparsamsten compact Autos und kleine Autos, der bei seiner niedrigem Preis auf Hybrid Automobilen weltweit bekannt ist. Obwohl Sales konsistent jedes Jahr für Fabrikam eine schnellere haben, hat eine bedeutende Zunahme Hybrid Engine Fehlerraten im ersten Jahr, in Autos an Kunden verkauft wurde. Für Fabrikam vermeiden der Standard für high-Level des Diensts verwalten muss er eine effizientere Möglichkeit für hybride Engine Teile über Contoso Hybrid bestellt werden implementieren.
Die beiden folgenden Konzepte sind verwandt:
Identitätsverbund. Dieses Szenario erläutert die Einrichtung eines Verbunds zwischen Contoso Hybrid und Fabrikam Motors, damit Fabrikam-Benutzer für den Zugriff auf Contoso Hybrid-Ressourcen eine Umgebung mit einmaliger Anmeldung erhalten.
Identitätsdelegierung. Erläutert die Möglichkeit, über einen Contoso Hybrid-Webdienst, der ein ActAs-Token erfordert, auf die Ressourcen zuzugreifen. Das heißt, der Dienst benötigt die Identität des unmittelbaren Aufrufers (in der Regel die Identität des Diensts) und des ursprünglichen Benutzers, der die Anforderung initiiert hat (in der Regel die Identität des interaktiven Benutzers).
Identitätsdelegation
In diesem Szenario wird eine Anwendung, die auf Back-End-Ressourcen zugreifen, die erfordern die Identität Delegierung Kette Access Control Prüfungen ausführen muss. Die Informationen auf dem ursprünglichen Anrufer und die Identität des Aufrufers sofortige besteht in der Regel eine einfache Identität Delegierung Kette aus.
Mit dem Kerberos-Delegierung Objektmodell auf der Windows-Plattform heute stehen die Back-End-Ressourcen Zugriff nur für die Identität des Aufrufers sofortige und nicht auf, die mit dem ursprünglichen Aufrufer. Bei diesem Modell wird häufig als des vertrauenswürdigen Subsystems bezeichnet. Windows Identity Foundation (WIF) verwaltet die Identität des anfänglichen Aufrufers und des unmittelbaren Aufrufers in der Delegierungskette mithilfe der Delegate()- Eigenschaft.
Abbildung 1 zeigt ein typisches identitätsdelegationsszenario in dem Fabrikam-Mitarbeiter in einer Anwendung Contoso.com verfügbar gemachten Ressourcen zugreift. Abbildung 1: Forderungsbasierte Verbundauthentifizierung
Die folgenden fiktiven Benutzer sind an diesem Szenario beteiligt:
Frank: Ein Fabrikam-Mitarbeiter, der auf Contoso-Ressourcen zugreifen möchte.
Daniel: Ein Contoso-Anwendungsentwickler, der die notwendigen Änderungen in die Anwendung implementiert.
Adam: Der IT-Administrator von Contoso.
Die folgenden Komponenten sind an diesem Szenario beteiligt:
web1: Eine Webanwendung mit Links zu Back-End-Ressourcen, die die delegierte Identität des ursprünglichen Aufrufers erfordern. Diese Anwendung wurde mit ASP.NET erstellt.
Ein Webdienst, der greift auf einem Computer mit Microsoft SQL Server, die die delegierte Identität mit dem ursprünglichen Aufrufer und der direkte Aufrufer erforderlich sind. Dieser Dienst wird mit Windows Communication Foundation (WCF) erstellt.
sts1: A security token service (STS) that is in the role of federation provider, and emits claims that are expected by the application (web1). It has established trust with Fabrikam.com and also with the application.
sts2: An STS that is in the role of identity provider for Fabrikam.com and that provides an endpoint that the Fabrikam employee uses to authenticate. It has established trust with Contoso.com so that Fabrikam employees are allowed to access resources on Contoso.com.
Beachten Sie, dass der Begriff "ActAs Token" auf ein Token verweist, die von einem STS ausgestellt wurde, und die Identität des Benutzers enthält. Die Delegate() -Eigenschaft enthält die Identität des STS. Wie in Abbildung 1 dargestellt, sieht der Flow in diesem Szenario wie folgt aus:
Die Contoso-Anwendung ist so konfiguriert, dass ein ActAs-Token abgerufen wird, das sowohl die Identität des Fabrikam-Mitarbeiters als auch die Identität des unmittelbaren Aufrufers in der Delegate()- Eigenschaft enthält. Daniel implementiert diese Änderungen in die Anwendung.
Die Contoso-Anwendung wird für die Weitergabe des ActAs-Tokens an den Back-End-Dienst konfiguriert. Daniel implementiert diese Änderungen in die Anwendung.
The Contoso web service is configured to validate the ActAs token by calling sts1. Adam enables sts1 to process delegation requests.
Der Fabrikam-Benutzer Frank greift auf die Contoso-Anwendung zu und erhält Zugriff auf die Back-End-Ressourcen.
Verbundauthentifizierung
Verbundauthentifizierung ermöglicht eine Sicherheitstokendienst (Security Token Service, STS) in einer vertrauenswürdigen Domäne Authentifizierungsinformationen für einen STS in einer anderen vertrauenswürdigen Domäne bereitstellen, wenn es eine Vertrauensstellung zwischen den beiden Domänen ist. Ein Beispiel hierfür ist in Abbildung 2 dargestellt.
Abbildung 2: Forderungsbasiertes Verbundszenario
Von einem Client in der vertrauenswürdigen Domäne von Fabrikam wird eine Anforderung an eine Anwendung einer vertrauenden Seite innerhalb der vertrauenswürdigen Domäne von Contoso gesendet.
Der Client wird von der vertrauenden Seite an einen STS in der vertrauenswürdigen Domäne von Contoso weitergeleitet. Der Client ist dem STS nicht bekannt.
Der Client wird vom STS von Contoso an einen STS in der vertrauenswürdigen Domäne von Fabrikam weitergeleitet, mit dem die vertrauenswürdige Domäne von Contoso über eine Vertrauensstellung verfügt.
Die Identität des Clients wird durch den STS von Fabrikam überprüft, und anschließend wird ein Sicherheitstoken an den STS von Contoso ausgestellt.
Mithilfe des Tokens von Fabrikam wird vom STS von Contoso ein eigenes Token erstellt, das an die vertrauende Seite gesendet wird.
Die Kundenansprüche werden von der vertrauenden Seite aus dem Sicherheitstoken extrahiert, und es wird eine Authentifizierungsentscheidung gefällt.
Dieses Szenario beschreibt eine Anmeldung für einen Mitarbeiter der Partner, wenn er Zugriff auf Ressourcen von einem anderen Partnerdomäne versucht. Er muss nur einmal anmelden. Es gibt drei wichtigsten Spieler in einem Verbundszenario: Identitätsanbieter, verbundanbieter und eine vertrauende Seite. WIF bietet APIs, um alle drei Spieler zu erstellen.Abbildung 3 zeigt eine typische Verbundszenario, in dem ein Fabrikam-Mitarbeiter "contoso.com" Ressourcen zugreifen, ohne dass Sie Re-Anmeldung möchte; d. h., der Mitarbeiter von Fabrikam einmaliges Anmelden verwenden möchte. Abbildung 3: Szenario der Forderungsidentitätsdelegierung
Die folgenden fiktiven Benutzer sind an diesem Szenario beteiligt:
Frank: Ein Fabrikam-Mitarbeiter, der auf Contoso-Ressourcen zugreifen möchte.
Daniel: Ein Contoso-Anwendungsentwickler, der die notwendigen Änderungen in die Anwendung implementiert.
Adam: Der IT-Administrator von Contoso.
Die folgenden Komponenten sind an diesem Szenario beteiligt:
web1: A parts ordering web application that is built with ASP.NET and controls access to the relevant parts.
sts1: An STS that is in the role of federation provider in Contoso.com and emits claims that are expected by the application (web1). It has established trust with Fabrikam.com and is configured to allow access to Fabrikam employees.
sts2: ein Sicherheitstokendienst, dem die Rolle des Identitätsanbieters in Fabrikam.com und bietet einen Endpunkt, der der Mitarbeiter von Fabrikam authentifiziert wird. Es wurde Vertrauensstellung mit Contoso.com festgestellt, sodass Mitarbeiter von Fabrikam "contoso.com"-Ressourcen zugreifen dürfen.
Wie in Abbildung 3 gezeigt, ist der Ablauf in diesem Szenario:
Contoso administrator Adam configures the trust between the application (relying party) and sts1.
Contoso administrator Adam configures the trust with sts2 as an identity provider.
Der Fabrikam-Administrator Frank konfiguriert die Vertrauensstellung mit sts1 als Verbundanbieter und greift dann auf die Anwendung zu.