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

StackOverflow https://stackoverflow.com/questions/2621496

Frage

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

Beim Blick durch die WIF SDK gibt es Beispiele von WIF in Verbindung mit ASP.NET mit dem WSFederationAuthenticationModule (FAM) mit zu einer ASP.NET-Website dünne Haut umleiten auf einem Security Token Service (STS), dass Benutzer Verwendungen zum Authentifizieren (über einen Benutzernamen und ein Passwort liefert).

Wenn ich verstehe, WIF und forderungsbasierten Zugriff richtig, würde ich meine Bewerbung gerne einen eigenen Login-Bildschirm zur Verfügung zu stellen, wo Benutzer ihre Benutzernamen und ein Kennwort eingeben, und lassen Sie diese Delegierten ein STS für die Authentifizierung, das Senden der Login-Daten an einen Endpunkt über Token zurück ein Sicherheitsstandard (WS- *) und eine SAML erwartet. Idealerweise würden funktionieren die SessionAuthenticationModule gemäß den Beispielen FAM in Verbindung mit SessionAuthenticationModule d verantwortlich sein für die Rekonstruktion des IClaimsPrincipal aus der Sitzungssicherheit chunked Cookie und Umleiten auf meine Bewerbung Login-Seite zu verwenden, wenn die Sicherheits Sitzung abläuft.

Ist das, was ich beschreiben mögliche FAM und SessionAuthenticationModule mit entsprechenden web.config Einstellungen verwenden, oder muss ich über das Schreiben eines HttpModule mich selbst zu denken brauchen, dies zu umgehen? Alternativ wird auf eine dünne Website STS umleiten, wo sich Benutzer in der De-facto-Ansatz in einem passiven Anforderer Szenario?

War es hilfreich?

Lösung

Ein Beispiel für WIF + MVC ist in diesem Kapitel des "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 Steuerung der Login-Erfahrung ist völlig in Ordnung. Sie sollten nur Ihre eigenen STS (in Ihrer Domain mit Ihrem Look & Feel, etc.) bereitstellen. Ihre Anwendungen würden einfach verlassen es für AuthN (deshalb eine App in der Regel ein „vertrauende“ genannt wird).

Der Vorteil der Architektur ist, dass authn bis 1 Komponente delegiert wird (STS) und nicht in vielen Anwendungen verteilt. Aber auch die andere (sehr groß) Vorteil ist, dass man sehr leicht komplexere Szenarien ermöglichen kann. Zum Beispiel können Sie jetzt mit einer anderen Organisation, die Identität Anbieter verbünden.

Hope es hilft Eugenio

@RisingStar:

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

Beachten Sie, dass, obwohl sie in Klartext sind, Manipulation nicht möglich ist, weil das Token digital signiert ist.

Andere Tipps

Das ist eine interessante Frage, die Sie gefragt haben. Ich weiß, dass aus irgendeinem Grund, Microsoft diese „Windows Identity Foundation“ Rahmen ohne viel Dokumentation löschte. Ich weiß das, weil ich habe mit herauszufinden, beauftragt worden, wie es zu verwenden, um mit einem neuen Projekt und mit dem bestehenden Infrastruktur zu integrieren. Ich habe im Internet nach Monaten der Suche nach guten Informationen.

Ich habe einen etwas anderen Winkel zur Lösung des Problems Sie beschreiben.

Ich habe ein vorhandenes Login-Anwendung und integriert Microsofts WIF Sanitär hinein. Damit meine ich, dass ich eine Anwendung, wo sich ein Benutzer anmeldet. Die Log-on Antrag einreicht, die vom Benutzer angegebenen Anmeldeinformationen auf einen anderen Server, die die Benutzer Identität zurückgibt (oder zeigt Log-on failure).

Mit Blick auf einige Microsoft-Beispiele, wie ich sehe, dass sie folgendes tun: Konstruieren Sie einen SignInRequestMessage von einem Abfragezeichenfolgeflag (erzeugt durch eine vertrauende Anwendung), bauen einen Sicherheitstoken-Service aus einer benutzerdefinierten Klasse und schließlich ruft FederatedSecurityTokenServiceOperations.ProcessSignInresponse mit dem aktuellen httpcontext.response. Leider kann ich es nicht wirklich gut hier erklären; Sie müssen wirklich an den Codebeispielen suchen.

Einige meiner Code ist sehr ähnlich zu dem Codebeispiel. Wo Sie bei der Umsetzung viel von Ihrer eigenen Logik zu interessieren gehen im GetOutputClaimsIdentity. Dies ist die Funktion, die die Ansprüche Identität konstruiert, die beschreibt, der angemeldete Benutzer.

Nun, hier ist, was ich denke, Sie sind wirklich daran interessiert zu wissen. Dies ist, was Microsoft sagt Ihnen nicht, in ihrer Dokumentation, AFAIK.

Sobald der Benutzer anmeldet, werden sie auf die vertrauende Anwendung umgeleitet zurück. Unabhängig davon, wie die Login-Anwendung funktioniert, die WIF-Klassen werden eine Antwort auf den Browser des Benutzers senden, die eine „versteckte“ HTML-Eingabe enthält, die das Token-Signaturzertifikat enthält und die Ansprüche des Nutzers. (Die Ansprüche werden im Klartext sein). Am Ende dieser Antwort eine Umleitung auf Ihre Berufung Anbieter-Website. Ich weiß nur, über diese Aktion, weil ich es mit „Fiddler“ eingefangen

Auch nach der Rückkehr an der vertrauende Website, werden die WIF-Klassen die Antwort behandeln (vor einem Code ausgeführt wird). Das Zertifikat wird validiert werden. Standardmäßig, wenn Sie Ihre vertrauende Website mit FedUtil.exe eingerichtet haben (indem Sie auf „Hinzufügen STS Referenz in Ihrer vertrauende Anwendung von Visual Studio), Microsofts Klasse wird das Zertifikat Daumenabdruck überprüfen.

Schließlich werden die WIF Rahmensätze Cookies in den Browser des Benutzers (Nach meiner Erfahrung die Cookie-Namen beginnen mit „FedAuth“), die die Benutzer Ansprüche enthalten. Die Cookies sind nicht Menschen lesbar.

Sobald das geschieht, können Sie optional führen Operationen auf die Ansprüche des Benutzers innerhalb der vertrauende Webseite des ClaimsAuthenticationClass verwenden. Dies ist, wo Code läuft wieder.

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

ps. Bitte beachten Sie auch die anderen Fragen, die ich über Windows Identity Foundation gefragt haben.

UPDATE: Zur Antwort Frage Kommentar unten:

Eine Sache, die ich ausgelassen ist, dass die Umleitung auf die STS Log-on-Anwendung über eine Umleitung erfolgt mit einer Abfrage-Zeichenfolge, die die URL der Anwendung enthält, die Benutzer bei anmeldet. Diese Umleitung erfolgt automatisch beim ersten Mal, wenn ein Benutzer versucht, auf eine Seite zuzugreifen, die Authentifizierung erfordert. Alternativ glaube ich, dass Sie manuell mit dem WSFederationAuthentication Modul die Umleitung tun könnten.

Ich habe nie versucht, dies zu tun, aber wenn Sie eine Login-Seite innerhalb der Anwendung verwenden möchten selbst, ich glaube, der Rahmen erlauben sollten Sie folgendes verwenden:

1) Encapsulate Ihre STS-Code innerhalb einer Bibliothek. 2) Verweisen Sie auf die Bibliothek aus Ihrer Anwendung. 3) Erstellen Sie eine Login-Seite in Ihrer Anwendung. Stelle sicherdass eine solche Seite erfordert keine Authentifizierung. 4) Stellen Sie den Emittenten Eigenschaft des wsFederation Element innerhalb des Microsoft.IdentityModel Abschnitt Ihrer web.config zur Login-Seite.

Was möchten Sie tun, ist ein aktiver signin. WIF enthält WSTrustChannel (Factory) , die Sie mit der direkt kommunizieren STS und ein Sicherheitstoken erhalten. Wenn Sie Ihr Login-Formular mögen auf diese Weise arbeiten, können Sie die „WSTrustChannel“ Probe aus dem WIF 4.0 SDK folgen. Sobald Sie das Token erhalten haben, wird der folgende Code, der Token nehmen und die WIF-Handler rufen Sie 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 tun, als ob passive Unterzeichnung stattgefunden hatte.

Sie könnten die FederatedPassiveSignIn Steuerung verwenden.

Einstellen Cookie wie folgt aus: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (session); Doens't Arbeit für SSO auf andere Bereiche.

Um Cookie sollte von den STS nicht auf RP eingestellt werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top