ASP.NET MVC 2 und Authentifizierung mit WIF (Windows Identity Foundation)

Question

Gibt es anständige Beispiele für die folgenden zur Verfügung:

Blick durch the WIF SDK gibt es Beispiele für die Verwendung WIF in Verbindung mit ASP.NET verwenden das WSFederationAuthenticationModule (FAM) zu einer ASP.NET-Site Thin Skin auf einem Security Token Service (STS) umleiten, den Benutzer zur Authentifizierung verwendet (über die Bereitstellung eines Benutzernamens und eines Kennworts).

Wenn ich WIF- und forderungsbasierten Zugriff richtig verstehe, möchte ich, dass meine Anwendung einen eigenen Anmeldebildschirm bereitstellt, auf dem Benutzer ihren Benutzernamen und ihr Kennwort angeben und diese an einen STS zur Authentifizierung senden und die Anmeldeinformationen an einen Endpunkt senden über einen Sicherheitsstandard (WS- *) und erwartet, dass ein SAML-Token zurückgegeben wird. Idealerweise würde SessionAuthenticationModule gemäß den Beispielen funktionieren, die FAM in Verbindung mit SessionAuthenticationModule verwenden, d. H. Verantwortlich für das Rekonstruieren des IClaimsPrincipal aus dem Sitzungssicherheits-Chunked-Cookie und das Umleiten auf die Anmeldeseite meiner Anwendung, wenn die Sicherheitssitzung abläuft.

Ist das, was ich beschreibe, möglich mit FAM und SessionAuthenticationModule mit entsprechenden web.config Einstellungen, oder muss ich darüber nachdenken, eine HttpModule selbst zu schreiben, um damit umzugehen? Oder leitet er eine STS auf eine dünne Website um, auf der sich Benutzer in einem passiven Anfordererszenario de facto anmelden?

Answer 1

Ein Beispiel für WIF + MVC ist in diesem Kapitel der „Claims Identity Guide“ zur Verfügung:

http://msdn.microsoft.com/en-us/library/ff359105.aspx

Ich schlage vor, die ersten paar Kapitel lesen alle zugrunde liegenden Prinzipien zu verstehen. Dieser Blog-Eintrag deckt die Besonderheiten der MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx

die Login-Erfahrung zu steuern ist völlig in Ordnung. Sie sollten nur Ihre eigenen STS bereitstellen (in Ihrer Domäne, mit Ihrem Aussehen & fühlen, etc). Ihre Apps würden sich einfach darauf für AuthN verlassen (deshalb wird eine App üblicherweise als "vertrauende Seite" bezeichnet).

Der Vorteil der Architektur ist, dass authn bis 1 Komponente delegiert wird (STS) und nicht in vielen Anwendungen verteilt. Der andere (große) Vorteil besteht darin, dass Sie anspruchsvollere Szenarien sehr einfach aktivieren können. Zum Beispiel können Sie jetzt mit Identitätsanbietern anderer Organisationen zusammenarbeiten.

Hope it Eugenio

@RisingStar hilft:

Das Token (mit den Ansprüchen) kann optional verschlüsselt werden (andernfalls werden sie im Klartext sein wird). Aus diesem Grund wird SSL immer für Interaktionen zwischen dem Browser und dem STS empfohlen.

Beachten Sie, dass Manipulationen nicht möglich sind, obwohl sie im Klartext sind, da das Token digital signiert ist.

Answer 2

Das ist eine interessante Frage, die Sie gestellt haben. Ich weiß, dass Microsoft aus irgendeinem Grund dieses "Windows Identity Foundation" Framework ohne viel Dokumentation veröffentlicht hat. Ich weiß das, weil ich beauftragt wurde, herauszufinden, wie man es mit einem neuen Projekt verwendet und es in die bestehende Infrastruktur integriert. Ich suche seit Monaten im Web nach guten Informationen.

Ich habe einen etwas anderen Blickwinkel genommen, um das von Ihnen beschriebene Problem zu lösen.

Ich nahm eine vorhandene Anmeldung-Anwendung und integriert Microsoft WIF-Installation in es. Damit meine ich, dass ich eine Anwendung habe, in der sich ein Benutzer anmeldet. Die Anmeldeanwendung übermittelt die vom Benutzer angegebenen Anmeldeinformationen an einen anderen Server, der die Benutzeridentität zurückgibt (oder einen Anmeldefehler anzeigt).

auf einige Beispiele von Microsoft Sehen, ich sehe, dass sie wie folgt vor: eine SignInRequestMessage von einem Abfragezeichenfolgeflag Construct (durch eine vertrauende Anwendung generiert), ein Sicherheitstoken-Service aus einer benutzerdefinierten Klasse konstruieren und schließlich FederatedSecurityTokenServiceOperations nennen. ProcessSignInsert mit der aktuellen httpcontext.response. Leider kann ich es hier nicht wirklich erklären; Sie müssen sich wirklich die Code-Beispiele ansehen.

Ein Teil meines Codes ist dem Codebeispiel sehr ähnlich. In der GetOutputClaimsIdentity werden Sie daran interessiert sein, eine Menge Ihrer eigenen Logik zu implementieren. Dies ist die Funktion, die die Anspruchsidentität erstellt, die den angemeldeten Benutzer beschreibt.

Nun, hier ist, was ich denke du bist wirklich daran interessiert zu wissen. Dies sagt Microsoft nicht in seiner Dokumentation AFAIK.

Sobald sich der Benutzer anmeldet, werden sie zurück zur vertrauenden Anwendung geleitet. Unabhängig davon, wie die Anmeldeanwendung funktioniert, senden die WIF-Klassen eine Antwort an den Browser des Benutzers, die eine "versteckte" HTML-Eingabe enthält, die das Tokensignaturzertifikat und die Ansprüche des Benutzers enthält. (Die Ansprüche werden im Klartext). Am Ende dieser Antwort finden Sie eine Weiterleitung zu Ihrer vertrauenden Website.Ich weiß nur über diese Aktion, weil ich es mit "Fiddler"

erfasst habe Wenn die WIF-Klassen wieder auf der Website der vertrauenden Partei zurück sind, werden sie die Antwort behandeln (bevor Ihr Code ausgeführt wird). Das Zertifikat wird validiert. Wenn Sie die Website Ihrer vertrauenden Seite mit FedUtil.exe eingerichtet haben (durch Klicken auf "STS-Verweis in Ihrer vertrauenden Anwendung von Visual Studio aus hinzufügen), überprüft die Klasse von Microsoft standardmäßig den Fingerabdruck des Zertifikats.

Endlich WIF Framework setzt Cookies im Browser des Benutzers (In meiner Erfahrung beginnen die Cookie-Namen mit "FedAuth"), die die Ansprüche des Benutzers enthalten. Die Cookies sind nicht lesbar.

Sobald das passiert, können Sie optional Operationen ausführen die Ansprüche des Nutzers innerhalb der Website der vertrauenden Seite unter Verwendung der ClaimsAuthenticationClass. Hier wird Ihr Code wieder ausgeführt.

Ich weiß, das ist anders als das, was Sie beschreiben, aber ich habe dieses Setup funktioniert. Ich hoffe das hilft!

ps. Überprüfen Sie die anderen Fragen, die ich zu Windows Identity Foundation gestellt habe.

UPDATE: die URL ist

Eine Sache, die ich zu den STS, dass die Umleitung links aus Log-on-Anwendung über eine Umleitung mit einem Abfrage-String geschieht enthalten: Zur Frage unten in Kommentar antworten die Anwendung, bei der sich der Benutzer anmeldet. Diese Umleitung erfolgt automatisch, wenn ein Benutzer zum ersten Mal auf eine Seite zugreift, die eine Authentifizierung erfordert. Alternativ glaube ich, dass Sie die Umleitung manuell mit dem WSFederationAuthentication Modul durchführen können.

Ich habe nie versucht, dies zu tun, aber wenn Sie eine Login-Seite in der Anwendung selbst nutzen wollen, glaube ich, der Rahmen sollte es Ihnen ermöglichen, die folgenden zu verwenden:

1) kapseln Ihre STS Code in einer Bibliothek. 2) Verweisen Sie die Bibliothek von Ihrer Anwendung. 3) Erstellen Sie eine Anmeldeseite in Ihrer Anwendung. Stellen Sie sicher, dass für diese Seite keine Authentifizierung erforderlich ist. 4) Stellen Sie den Emittenten Eigenschaft des wsFederation Element innerhalb des Microsoft.IdentityModel Abschnitt Ihrer web.config zur Anmeldeseite.

Answer 3

Was Sie tun möchten, ist eine aktive Anmeldung. WIF enthält WSTrustChannel(Factory), mit dem Sie direkt mit dem STS kommunizieren und ein Sicherheitstoken erhalten können. Wenn Sie möchten, dass Ihr Anmeldeformular auf diese Weise funktioniert, können Sie dem Beispiel "WSTrustChannel" aus dem WIF 4.0 SDK folgen. Sobald Sie den Code erhalten haben, nehmen Sie den folgenden Code, dass Token und rufen Sie die WIF-Handler eine Session-Token und setzen Sie das entsprechende Cookie zu erstellen:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken) 
{ 
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;    
    var token = handlers.ReadToken(new XmlTextReader(
             new StringReader(genericToken.TokenXml.OuterXml))); 

    var identity = handlers.ValidateToken(token).First(); 
    // create session token 
    var sessionToken = new SessionSecurityToken(
     ClaimsPrincipal.CreateFromIdentity(identity)); 
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken); 
} 

Sobald Sie dies getan haben, Ihre Website sollte das gleiche verhalten als ob eine passive Unterschrift stattgefunden hätte.

Answer 4

Sie könnten das FederatedPassiveSignIn-Steuerelement verwenden.

Answer 5

Setzen Sie Ihren Cookie so: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (sessionToken); Does't Arbeit für SSO zu anderen Domänen.

Zum Cookie sollte von der STS nicht an der RP gesetzt werden.