ASP.NET MVC 2 und Authentifizierung mit WIF (Windows Identity Foundation)
Gibt es keine vernünftigen Beispiele für die folgenden zur Verfügung:
Blick durch die WIF-SDKgibt es Beispiele für die Verwendung in Verbindung mit WIF ASP.NET mit der WSFederationAuthenticationModule (FAM)
eine Umleitung zu einem ASP.NET Webseite dünne Haut auf der Spitze eines Security Token Service (STS), der Benutzer authentifizieren (über die Versorgung Benutzername und Passwort).
Wenn ich verstehe, WIF und claims-based access korrekt, ich würde gerne meine Anwendung, um seine eigenen login-Bildschirm, wo der Benutzer den Benutzernamen und das Kennwort, und lassen Sie diese delegieren, um eine STS für die Authentifizierung, versenden der login-Daten zu einem Endpunkt über eine Sicherheits-Standards (WS-*), und die Erwartung eines auf SAML-token zurückgegeben werden. Idealerweise SessionAuthenticationModule
funktionieren würde, wie pro die Beispiele mit FAM
in Verbindung mit SessionAuthenticationModule
also verantwortlich sein für die Rekonstruktion der IClaimsPrincipal
aus der Sitzung Sicherheits-chunked-cookie und umleiten auf mein Anwendungs-login-Seite, wenn der Sicherheits-Sitzung abläuft.
Ist, was ich beschreiben möglich mit FAM
und SessionAuthenticationModule
mit entsprechenden web.config-Einstellungen, oder muss ich denken, über das schreiben einer HttpModule
mich, dies zu behandeln? Alternativ ist die Umleitung auf eine dünne web-site, STS, wo sich Benutzer anmelden, die de-facto-Ansatz in eine passive requestor Szenario?
InformationsquelleAutor der Frage Russ Cam | 2010-04-12
Du musst angemeldet sein, um einen Kommentar abzugeben.
Beispiel WIF + MVC ist in diesem Kapitel von "Forderungen Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
Ich schlage vor, dem Lesen der ersten paar Kapiteln zu verstehen, alle zugrunde liegenden Prinzipien. Dieser blog-post behandelt die Besonderheiten von MVC + WIF:
http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx
Steuerung der login Erfahrung ist völlig in Ordnung. Sollten Sie nur einsetzen, um Ihre eigenen STS (in Ihrer Domäne, mit Ihrem look & feel, etc). Ihre apps würde einfach darauf verlassen, dass es für AuthN (das ist, warum eine app ist in der Regel als eine "relying party").
Den Vorteil der Architektur ist, dass authN ist delegiert an die 1-Komponente (STS) und nicht verteilt in ganz vielen apps. Aber die anderen (großen) Vorteil ist, dass Sie können mehr anspruchsvolle Szenarien sehr leicht. Zum Beispiel können Sie jetzt einen Verbund mit anderen Organisation als identitätsanbieter.
Hoffe es hilft
Eugenio
@RisingStar:
Token (mit der Forderung) kann Optional verschlüsselt werden (sonst werden Sie in Klartext). Das ist, warum SSL ist immer empfehlenswert, für die Interaktion zwischen dem browser und dem STS.
Beachten Sie, dass obwohl Sie im klar text, die Manipulation ist nicht möglich, da der token ist Digital signiert.
InformationsquelleAutor der Antwort Eugenio Pace
Das ist eine interessante Frage, die Sie gestellt haben. Ich weiß, dass aus welchem Grund auch immer, hat Microsoft diese "Windows Identity Foundation" - Rahmen ohne viel Dokumentation. Ich weiß das, denn ich habe die Aufgabe, herauszufinden, wie man es mit einem neuen Projekt und Integration mit vorhandener Infrastruktur. Ich habe lange gesucht das web für Monate auf der Suche nach guten Informationen.
Habe ich einen etwas anderen Blickwinkel auf die Lösung der problem, das Sie beschreiben.
Nahm ich eine vorhandene log-on-Anwendung und integriert Microsoft WIF Sanitär in es. Damit meine ich, ich habe eine Anwendung, wo sich ein Benutzer anmeldet. Die log-on-Anwendung übermittelt die Zugangsdaten die durch den Benutzer zu einem anderen server gibt die Benutzer-Identität (oder gibt log-Fehler).
Blick auf einige der Microsoft-Beispiele, sehe ich, dass Sie Folgendes tun:
Konstruieren Sie eine
SignInRequestMessage
aus einem querystring (erzeugt durch eine Anwendung der vertrauenden Seite), erstellen Sie einen security token service aus einer benutzerdefinierten Klasse, und schließlich rufen FederatedSecurityTokenServiceOperations.ProcessSignInresponse mit den aktuellen httpcontext.Antwort. Leider kann ich nicht wirklich erklären, es auch hier; Sie wirklich brauchen, zu betrachten, die code-Beispiele.Einige meiner code ist sehr ähnlich zu dem code-Beispiel. Wo Sie gehen, um sein Interesse in der Umsetzung viel von Ihrer eigenen Logik in der
GetOutputClaimsIdentity
. Dies ist die Funktion, dass Konstrukte, die Forderungen-Identität beschreibt den angemeldeten Benutzer.Nun, hier ist, was ich denke, Sie sind wirklich daran interessiert zu wissen. Dies ist, was Microsoft sagt nicht, Sie in Ihrer Dokumentation, AFAIK.
Sobald sich der Benutzer anmeldet, erfolgt die Weiterleitung zurück an die relying party-Anwendung. Unabhängig davon, wie die log-on-Anwendung arbeitet, die WIF-Klassen sendet eine Antwort an den browser des Benutzers, enthält eine "versteckte" HTML-input, enthält das token-Signaturzertifikat und Ansprüchen des Nutzers. (Die Forderungen werden in Klartext). Am Ende dieser Reaktion ist eine Weiterleitung auf Ihre relying-party-website. Ich weiß nur über diese Aktion, weil ich es eingefangen mit "Fiddler"
Einmal zurück an die relying-party-web-site, die WIF-Klassen mit der Antwort (vor der Ihr code ausgeführt wird). Das Zertifikat bestätigt wird. Standardmäßig wird, wenn Sie festgelegt haben, um Ihre relying party-web-site mit FedUtil.exe (durch klicken auf "Add STS Reference in Ihrem relying party-Anwendung von Visual Studio), Microsoft-s-Klasse wird überprüfen Sie den Fingerabdruck des Zertifikats.
Schließlich die WIF framework setzt cookies im browser des Benutzers (In meiner Erfahrung, die cookie-Namen beginnen mit "FedAuth"), die die Benutzer enthalten Forderungen. Die cookies werden nicht von Menschen lesbar.
Wenn das passiert, können Sie Optional Operationen auf Ansprüchen des Nutzers innerhalb der relying party website mit der
ClaimsAuthenticationClass
. Dies ist, wo Ihren code wieder läuft.Ich weiß, das ist Verschieden von dem, was Sie beschreiben, aber ich habe dieses setup funktioniert. Ich hoffe, das hilft!
ps. Bitte schauen Sie sich die anderen Fragen, die ich gestellt habe über die Windows Identity Foundation.
UPDATE: Zur Beantwortung der Frage in Kommentar unten:
Eine Sache, die ich ausgelassen habe ist, dass die Umleitung auf die STS-log-on-Anwendung geschieht durch eine Umleitung mit einem query-string, der die URL der Anwendung, die der Benutzer bei der Anmeldung an. Diese Umleitung geschieht automatisch beim ersten mal, wenn ein Benutzer versucht auf eine Seite zuzugreifen, die eine Authentifizierung erfordert. Alternativ, ich glaube, dass könnten Sie die Umleitung manuell mit der
WSFederationAuthentication
Modul.Ich habe nie versucht, dies zu tun, aber wenn Sie wollen verwenden Sie eine log-in-Seite innerhalb der Anwendung selbst, ich glaube, der Rahmen sollte es Ihnen ermöglichen, verwenden Sie die folgende:
1) Kapseln STS-code innerhalb einer Bibliothek.
2) Verweis auf die Bibliothek aus Ihrer Anwendung.
3) Erstellen Sie ein log-in-Seite innerhalb der Anwendung. Stellen Sie sicher, dass eine solche Seite ist keine Authentifizierung erforderlich.
4) die Emittentin Eigentum der
wsFederation
element innerhalb derMicrosoft.IdentityModel
- Abschnitt Ihrer web.config auf die login-Seite.InformationsquelleAutor der Antwort Daniel Allen Langdon
Was Sie tun möchten, ist eine active-signin. WIF umfasst WSTrustChannel(Fabrik) die es Ihnen ermöglicht, direkt zu kommunizieren mit der STS und erhalten einen Sicherheits-token. Wenn Sie möchten, dass Ihre login-Formular auf diese Weise zu arbeiten, können Sie die "WSTrustChannel" - Beispiel aus der WIF-4.0-SDK. Sobald Sie erhalten haben, die token, die folgenden code nehmen, token, und rufen Sie die WIF-handler zum erstellen eines session-Tokens und legen Sie den entsprechenden cookie:
Sobald Sie dies getan haben, wird Ihre Website sollte sich so verhält, als wenn die passive Unterzeichnung stattgefunden hatte.
InformationsquelleAutor der Antwort jlew
Könnten Sie die FederatedPassiveSignIn Kontrolle.
InformationsquelleAutor der Antwort Nixie
Ihre cookie-Einstellung wie diese:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens T Arbeit für SSO zu anderen Domänen.
Zum cookie ist, soll gesetzt werden von der STS nicht am RP.
InformationsquelleAutor der Antwort Max