Ich möchte, dass sich meine Benutzer mit ihren Organisationskonten (AD, AAD, O365) in meiner Webanwendung anmelden und Asp.Net Identity verwenden, um anwendungsspezifische Profil- oder Rolleninformationen lokal in meiner Anwendung zu speichern, Informationen, die ich nicht verwende Ich möchte mein Verzeichnis oder das meiner Mieter nicht mit Erde beschmutzen.
Ich bin mir nicht sicher, ob das Szenario realistisch ist, da ich so wenig Informationen darüber finde. In MVC 4 war es machbar. Ich würde eine leere MVC4-Webanwendung erstellen, das Identity- und Access-Tool zum Einrichten der Verbundauthentifizierung verwenden und den Namensanspruch in einer Users-Tabelle speichern, die ich mit SimpleMembership eingerichtet habe (wie dies .)
Es scheint jedoch besser zu sein, Asp.Net Identity gegenüber SimpleMembership für neue Entwicklungen zu bevorzugen. Aber da sieht es viel schwieriger aus. Wenn ich die ASP.NET-Webvorlagen in Visual Studio 2013 RTM betrachte, müsste ich die Bits aus der Vorlage "Individuelle Konten" mit denen der Vorlage "Organisationskonten" kombinieren. Ich habe gesehen, dass Asp.Net Identität externe Login-Informationen in der AspNetUserLogins-Tabelle out-of-the-Box speichert (die ich mit EF6-Code zuerst ändern kann), aber ich kann nicht herausfinden, welche Informationen von meiner ClaimsIdentity ich speichern würde best (mandantId und name claim?) oder zu welchem Zeitpunkt im code. Die Vorlage "Organisationskonten" verweist auf Microsoft.Aspnet.Identity, scheint diese jedoch nie aufzurufen.
Ist mein Szenario machbar? Wird es eine Probe geben, auf der ich mit der endgültigen Version von VS2013 aufbauen kann? Wäre es besser, eine eigene Implementierung zu verwenden, um Rollen- und Profilinformationen anstelle von Asp.Net Identity zu speichern?
Dies ist ein gültiges Szenario und ich habe etwas ähnliches implementiert. Angenommen, Sie möchten die Metadaten eines WAAD-Benutzers in Ihrem lokalen Repository speichern. Mit Metadaten meine ich grundlegende Identifizierungsinformationen, die Sie verwenden können, um den Benutzer in Ihrem lokalen Repository an denselben Eintrag in WAAD zu binden. Folgendes würde ich speichern:
IdentityProvider (in diesem Fall WAAD)
TenantId (das Format dieses Felds kann zwischen Identitätsanbietern variieren, aber eine Zeichenfolge sollte ausreichen)
< strong> UserId (das Format dieses Felds kann wiederum innerhalb von idPs variieren, aber eine Zeichenfolge würde funktionieren ... in diesem Fall name claim, sofern sie innerhalb eines Mandanten eindeutig ist)
Dies sind Informationen, die Sie aus ClaimsPrincipal / ClaimsIdentity entnehmen können. Ich habe meine Anwendung implementiert, bevor VS 2013 auf den Plan kam, also habe ich meine eigene Version erstellt, aber nachdem ich das neue "one" ASP.NET-Identitätsdokument gelesen habe, sieht es ziemlich erweiterbar aus und es könnte eine gute Idee sein, damit zu gehen. Sie können sogar verschiedene Speicheranbieter anschließen (nicht nur relationale Datenbanken).
Tags und Links azure visual-studio-2013 asp.net-identity asp.net-mvc-5