Übersicht über das WS-Verbundauthentifizierungsmodul

Windows® Identity Foundation (WIF) bietet durch das WS-Verbundauthentifizierungsmodul (WS-Federated Authentication Module, WS-FAM) Unterstützung für Verbundauthentifizierung in ASP.NET-Anwendungen. Dieses Thema soll Ihnen die Funktionsweise und Verwendung der Verbundauthentifizierung vermitteln.

Übersicht über die Verbundauthentifizierung

Die Verbundauthentifizierung ermöglicht es einem Sicherheitstokendienst (Security Token Service, STS) in einer Vertrauensdomäne, Authentifizierungsinformationen für einen STS in einer anderen Vertrauensdomäne bereitzustellen, wenn zwischen den beiden Domänen eine Vertrauensstellung vorhanden ist. Ein Beispiel dafür wird in der folgenden Abbildung gezeigt.

1. Ein Client in der Fabrikam-Vertrauensdomäne sendet eine Anforderung an eine RP-Anwendung (Anwendung einer vertrauenden Seite) in der Contoso-Vertrauensdomäne.

2. Die RP leitet den Client in der Contoso-Vertrauensdomäne an einen STS um. Dieser STS weiß nichts über den Client.

3. Der Contoso-STS leitet den Client an einen STS in der Fabrikam-Vertrauensdomäne um, mit dem die Contoso-Vertrauensdomäne eine Vertrauensstellung hat.

4. Der Fabrikam-STS überprüft die Identität des Clients und stellt ein Sicherheitstoken für den Contoso-STS aus.

5. Der Contoso-STS erstellt mithilfe des Fabrikam-Tokens ein eigenes Token, das von der RP verwendet werden kann, und sendet es an die RP.

6. Die RP extrahiert die Ansprüche des Clients aus dem Sicherheitstoken und trifft eine Autorisierungsentscheidung.

Verwenden des Verbundauthentifizierungsmoduls mit ASP.NET

WSFederationAuthenticationModule (WS-FAM) ist ein HTTP-Modul, mit dem Sie die Verbundauthentifizierung zu einer ASP.NET-Anwendung die hinzufügen können. Durch die Verbundauthentifizierung wird die Authentifizierungslogik vom STS verarbeitet, sodass Sie sich auf das Schreiben Ihrer Geschäftslogik konzentrieren können.

Sie konfigurieren das WS-FAM, um den STS anzugeben, an den nicht authentifizierte Anforderungen umgeleitet werden sollen. Mit WIF haben Sie zwei Möglichkeiten, Benutzer zu authentifizieren:

1. Mithilfe des FederatedPassiveSignIn-Steuerelements. Wenn ein nicht authentifizierter Benutzer versucht, auf eine geschützte Ressource zuzugreifen, wird er zu einer Anmeldeseite in der Anwendung umgeleitet. In dieser Anmeldeseite ist das FederatedPassiveSignIn-Steuerelement eingebettet. Dieses Steuerelement wurde mit Ausstellerinformationen (STS) konfiguriert. Dies ist der richtige Ansatz, wenn Sie keinen anwendungsweiten Schutz sondern eine Anmeldeseite in der Anwendung benötigen, und möchten, dass die Benutzer auf das Steuerelement klicken (z. B. auf der Internetseite einer Bank mit einer Anmeldeseite).

2. Passive Umleitung: Wenn Sie einen nicht authentifizierter Benutzer, der versucht, auf eine geschützte Ressource zuzugreifen, einfach an einen STS umleiten möchten, ohne dass eine Anmeldeseite erforderlich ist, dann ist dies der richtige Ansatz. Der STS überprüft die Identität des Benutzers und gibt ein Sicherheitstoken aus, das die entsprechenden Ansprüche für diesen Benutzer enthält. Für diese Option muss das WS-FAM der HTTP-Modulpipeline hinzugefügt werden. Weitere Informationen finden Sie unter Einrichten einer Vertrauensstellung zwischen einer ASP-Anwendung der vertrauenden Seite und einem STS mithilfe von FedUtil.

Bei passiver Umleitung wird sämtliche Kommunikation über Antwort/Umleitung vom Client (in der Regel ein Browser) ausgeführt. Das WS-FAM unterstützt zwei Arten der passiven Umleitung:

1. Sie können das WS-FAM zur HTTP-Pipeline Ihrer Anwendung hinzufügen, um sie auf nicht authentifizierte Benutzeranforderungen zu überwachen und die Benutzer an einen von Ihnen angegebenen STS umzuleiten.

2. Sie können das WS-FAM instanziieren und es zum Überprüfen von Anforderungen verwenden. Dies ist die Funktionsweise des FederatedPassiveSignIn-Steuerelements.

Das WS-FAM löst zudem mehrere Ereignisse aus, mithilfe derer Sie die Funktionalität in einer ASP.NET-Anwendung anpassen können.

Funktionsweise des WS-FAM

Das WS-FAM wird in der WSFederationAuthenticationModule-Klasse implementiert. In der Regel fügen Sie das WS-FAM zur HTTP-Pipeline Ihrer ASP.NET-RP-Anwendung hinzu. Wenn ein nicht authentifizierter Benutzer versucht, auf eine geschützte Ressource zuzugreifen, gibt der RP die HTTP-Antwort "401 Autorisierung verweigert" zurück. Das WS-FAM fängt diese Antwort ab, sodass der Client sie nicht empfangen kann. Dann wird der Benutzer an den angegebenen STS umgeleitet. Der STS stellt ein Sicherheitstoken aus, das vom WS-FAM erneut abgefangen wird. Das WS-FAM verwendet das Token, um eine Instanz von IClaimsPrincipal für den authentifizierten Benutzer zu erstellen. Dadurch werden die regulären .NET Framework Autorisierungsmechanismen aktiviert.

Da HTTP ohne Zustand ist, wird eine Methode benötigt, die verhindert, dass dieser gesamte Prozess bei jedem Versuch eines Benutzers, auf eine geschützte Ressource zuzugreifen, wiederholt werden muss. An diesem Punkt kommt SessionAuthenticationModule ins Spiel. Wenn der STS ein Sicherheitstoken für den Benutzer ausstellt, wird von SessionAuthenticationModule auch ein Sitzungssicherheitstoken für den Benutzer erstellt und in einem Cookie abgelegt. Bei nachfolgenden Anfragen fängt das SessionAuthenticationModule dieses Cookie ab und rekonstruiert damit das IClaimsPrincipal des Benutzers.

Wenn Sie möchten, dass Ihre RP-Anwendung Ansprüche unterstützt, Sie jedoch nicht über einen STS verfügen (die RP verwendet z. B. Formularauthentifizierung oder integrierte Windows-Authentifizierung), können Sie das ClaimsPrincipalHttpModule verwenden. Dieses Modul befindet sich in der HTTP-Pipeline der Anwendung und fängt Authentifizierungsinformationen ab. Es generiert für jeden Benutzer einen IClaimsPrincipal auf Grundlage des Benutzernamens, der Gruppenmitgliedschaften und anderer Authentifizierungsinformationen. ClaimsPrincipalHttpModule muss am Ende der <httpModules>-Pipeline eingefügt werden. Dabei handelt es sich um das erste Element im <modules>-Abschnitt von <system.webServer> zu IIS 7.

Das folgende Diagramm zeigt den gesamten Informationsfluss an, der stattfindet, wenn der Benutzer zum Festlegen von Anmeldeinformationen auf eine Anmeldeseite umgeleitet und nach der Authentifizierung zur Zielseite umgeleitet wird:

Das folgende Diagramm zeigt ausführlicher, was geschieht, wenn der Benutzer für den STS authentifiziert wurde und seine Sicherheitstoken an die Anmeldeseite gesendet werden:

Im folgenden Diagramm schließlich wird ausführlich dargestellt, was geschieht, wenn die Sicherheitstoken des Benutzers in Cookies serialisiert wurden und vom SessionAuthenticationModule abgefangen werden:

Das folgende Diagramm zeigt den gesamten Informationsfluss im Fall einer passiven Umleitung an. Die Anforderung wird automatisch über den STS umgeleitet, um Anmeldeinformationen ohne eine Anmeldeseite festzulegen:

Das folgende Diagramm zeigt ausführlicher, was geschieht, wenn der Benutzer für den STS authentifiziert wurde und seine Sicherheitstoken von WSFederationAuthenticationModule verarbeitet werden:

Ereignisse

WSFederationAuthenticationModule, SessionAuthenticationModule und ihr übergeordnetes Element, HttpModuleBase, lösen in verschiedenen Phasen der Verarbeitung einer HTTP-Anforderung Ereignisse aus. Sie können diese Ereignisse in der Datei global.asax der Anwendung ASP.NET behandeln.

• HttpModuleBase löst das Init-Ereignis aus, wenn das Modul initialisiert wird.

• WSFederationAuthenticationModule löst beim Laden der Dienstkonfiguration das ServiceConfigurationCreated-Ereignis aus. Das Ereignis wird nur einmal ausgelöst, nicht pro Modul. Dieses Ereignis stellt die ServiceConfiguration zur Verfügung, mit der Sie die Dienstkonfiguration ändern können. Sie sollten dieses Ereignis in der Methode "Application_Start" erfassen:

  void Application_Start { FA.ServiceConfigurationCreated += new ServiceConfigurationCreatedEventHandler( <Signatur Ihres Ereignishandlers>); }
  

  Der ServiceConfiguration enthält einfach die statischen Eigenschaften für FederatedAuthentication. FederatedAuthentication enthält Verweise auf die konfigurierten WSFederationAuthenticationModule und SessionAuthenticationModule, die jeweils eigene Verweise auf den ServiceConfiguration für FederatedAuthentication aufweisen.

  Wenn Sie möchten, dass WSFederationAuthenticationModule oder SessionAuthenticationModule über eigene Konfigurationen verfügt, müssen Sie eine eigene Klasse von WSFederationAuthenticationModule oder SessionAuthenticationModule ableiten, eine neue ServiceConfiguration erstellen und den ServiceConfiguration-Verweis in der abgeleiteten Klasse erneut der ServiceConfiguration, die Sie erstellt haben, zuweisen.

• Das WS-FAM löst beim Abfangen eines von STS ausgestellten Sicherheitstokens SecurityTokenReceived aus.

• Der WS-FAM löst nach der Überprüfung des Tokens SecurityTokenValidated aus.

• Das SessionAuthenticationModule löst SessionSecurityTokenCreated aus, wenn ein Sitzungssicherheitstoken für den Benutzer erstellt wird.

• Das SessionAuthenticationModule löst SessionSecurityTokenReceived aus, wenn nachfolgende Anforderungen mit dem Cookie abgefangen werden, das das Sitzungssicherheitstoken enthält.

• Bevor das WS-FAM den Benutzer an den Aussteller umleitet, löst es das RedirectingToIdentityProvider-Ereignis mit der 'Verbundanforderung' als Parameter aus. Möglicherweise möchten Sie die Anforderung bearbeiten, bevor Sie sie an den Aussteller senden.

• Das WS-FAM löst SignedIn aus, wenn das Cookie erfolgreich geschrieben und der Benutzer angemeldet wurde.

• Wenn die Sitzung geschlossen wird, löst das WS-FAM für jeden Benutzer einmal pro Sitzung SigningOut aus. Es wird nicht ausgelöst, wenn die Sitzung auf der Clientseite (z. B. durch das Löschen des Sitzungscookies) geschlossen wird. In einer SSO-Umgebung kann der IP-STS zudem jeden RP anfordern, sich abzumelden. Dadurch wird ebenfalls dieses Ereignis ausgelöst, wobei IsIPInitiated auf true festgelegt ist.

Unterstützte Szenarien

Das WS-FAM unterstützt die folgenden Szenarien:

• Zugreifen auf Ansprüche in einer ASP.NET-RP-Anwendung, die WS-Verbundauthentifizierung verwendet. Wenn die RP-Anwendung Formularauthentifizierung oder integrierte Windows-Authentifizierung verwendet, ist nur ClaimsPrincipalHttpModule erforderlich. Weitere Informationen finden Sie unter Vorgehensweise: Zugreifen auf Ansprüche auf einer ASP.NET-Seite.

• Verwaltete Kartenanmeldung bei einer ASP.NET-Anwendung. Hiefür ist nur das SessionAuthenticationModule erforderlich.

Konfiguration der Verbundauthentifizierung

Der folgende Konfigurationsausschnitt beschreibt die Attribute, die im Konfigurationselement <federatedAuthentication> konfiguriert werden können:

<federatedAuthentication>< !, <wsFederattion> definiert Parametereinstellungen für WS-VERBUND-Protokoll-STS. Dies wirkt sich auf die Einstellungen für das WSFederationAuthenticationModule aus.

ATTRIBUTE

passiveRedirectEnabled – boolescher Wert – standardmäßig False Steuert, ob das Modul aktiviert wird, um nicht autorisierte Anforderungen automatisch an einen STS umzuleiten.

Aussteller – Zeichenfolge – Standard "" Der URI des Tokenausstellers.

Bereich – Zeichenfolge – Standard "" Der URI des anfordernden Bereichs.

Aktualität – Float – Standard "" Der Wert der erforderlichen Aktualität.

Antwort – Zeichenfolge – Standard "" Der URI der Antwortadresse.

Anforderung – Zeichenfolge – Standard "" Der URI der WS-VERBUND-Anforderung.

requestPtr – Zeichenfolge – der Standard"" Der URI des WS-VERBUND-Anforderungszeigers.

Ressource – Zeichenfolge – Standard "" Der URI des WS-VERBUND-Ressourcenwerts.

Authentifizierungstyp – Zeichenfolge – Standard "" der wauth-Parameter, den die Anwendung für den STS angeben möchte.

requireHttps – boolescher Wert – standardmäßig False Das boolesche Flag, das angibt, ob für die Aussteller-URL HTTPS erforderlich ist.

signInMode – Zeichenfolge – Standard-"Sitzung" Entweder sitzungsbasiertes Cookie oder Einzelcookie

homeRealm – Zeichenfolge – Standard "" Geben Sie einen homeRealm-Wert ein

signInQueryString – Zeichenfolge – Standard ""

signOutQueryString – Zeichenfolge – Standard ""

signOutReply – Zeichenfolge – Standard ""

--> <wsFederation passiveRedirectEnabled="true|false" issuer="http://sts.com/request.aspx" realm="http://sts.com/request.aspx" freshness="10" reply="" request="" requestPtr="" resource="" /> <!-- <cookieHandler> steuert den CookieHandler, der für das Lesen und Schreiben von Rohcookies auf HTTP-Protokollebene zuständig ist. Das SessionAuthenticationModule verwendet den cookieHandler zum Lesen und Schreiben von Cookies.

MODI

Standard (Standard) Entspricht "Aufgeteilt".

Für "Aufgeteilt" wird eine Instanz der ChunkedCookieHandler-Klasse verwendet. Dieser Cookiehandler stellt sicher, dass einzelne Cookies ein festgelegte Maximalgröße nicht überschreiten. Dies wird erreicht, indem ein Cookie potenziell in mehrere Netzwerkcookies "aufgeteilt" wird.

Benutzerdefinierte Verwendungen einer Instanz einer benutzerdefinierten, von einem  CookieHandler abgeleiteten Klasse, auf die vom <customCookieHandler>- Element verwiesen wurde.

ATTRIBUTE

Domäne – Zeichenfolge – Standard "" Der Domänenwert für beliebige geschriebene Cookies.

hideFromScript – boolescher Wert – Standard True Steuert, ob das "HttpOnly"-Flag für alle geschriebene Cookies ausgegeben wird. Bestimmte Webbrowser reagieren auf dieses Flag, indem sie den Zugriff clientseitiger Skripts auf den Cookiewert verhindern.

Name – Zeichenfolge – Standard "FedAuth" Steuert den Basisname alle geschriebenen Cookies.

Pfad – Zeichenfolge – Standard HttpRuntime.AppDomainAppVirtualPath Steuert den Pfadwert für alle geschriebenen Cookies. 

requireSsl – boolescher Wert – Standard False Steuert, ob das "Secure"-Flag für alle geschriebenen Cookies ausgegeben wird. Wenn dieser Wert festgelegt ist, sind die Anmeldesitzungscookies nur über HTTPS verfügbar.

--> <cookieHandler mode="Default|Chunked|Custom" domain=".example.com" hideFromScript="true" name="FedAuth" path="/" requireSsl="false"> <!-- <chunkedCookieHandler> ist möglicherweise nur vorhanden, wenn der cookieHandler/@mode "Standard" oder "Chunked" ist. Es steuert den ChunkedCookieHandler.

ATTRIBUTE

chunkSize – Int32 – Standard 2000 Die maximale Größe der HTTP-Cookiedaten für ein einzelnes HTTP-Cookie in Zeichen. Beim Einstellen der Segmentgröße ist Vorsicht geboten. Webbrowser haben unterschiedliche Grenzen für die Größe von Cookies und die Anzahl pro Domäne. Die ursprüngliche Netscape-Spezifikation hat diese Grenzen festgelegt: 300 Cookies insgesamt, 4.096 Bytes pro Cookieheader (einschließlich Metadaten, nicht nur des Cookiewerts) und 20 Cookies pro Domäne. 

--> <chunkedCookieHandler chunkSize = "2000" />< !, <customCookieHandler> ist möglicherweise nur vorhanden, wenn der cookieManager/@mode "Benutzerdefiniert" ist. Es verweist auf einen benutzerdefinierten Typ, der vom CookieHandler abgeleitet werden muss. Weitere Informationen finden Sie in den Kommentaren vor dem <Konfigurations>-Element benutzerdefinierter Typverweise.

--> <customCookieHandler type="MyTypes.MyCookieHandler, MyTypes" /> </cookieHandler> </federatedAuthentication>