Ich schaue mir die neuen Bits der ASP.NET MVC 5-Authentifizierung, und bemerkte, dass jetzt alles ein ClaimsIdentity ist. Ich habe mich gefragt, wo diese Werte gespeichert sind:ClaimsIdentity in ASP.NET MVC 5
Sitzung, Cache oder im Cookie selbst.
Wenn es im Cookie gespeichert ist, gibt es ein offensichtliches Limit für die Anzahl der Ansprüche, die Sie speichern können, bevor Sie die Größenbeschränkung für Cookies überschreiten.
ClaimsIdentity selbst hat keinen Speichermechanismus. Aber wenn Sie die OWIN-Cookie-Middleware verwenden, wird diese ja in einem Cookie gespeichert. Und ja - es gibt eine Grenze.
Standardmäßig generiert die MVC5-Vorlage die ClaimsIdentity aus der Datenbank und speichert diese in einem Cookie-Formular, das für eine Weile gültig ist. Die Benutzerdaten werden jedoch standardmäßig in einer SQL-Datenbank gespeichert.
Standardmäßig sind die Domain-Daten in SQL Server gespeichert, ich verstehe diesen Teil, aber wenn Sie das ClaimsIdentity-Objekt erstellen und an den AuthenticationManager zu diesem Zeitpunkt füttern, speichert es die gleichen Daten im Cookie. Wenn Ihre Daten für einen Cookie zu groß sind, wird der Cookie niemals an den Browser gesendet, da er aufgrund von Größenbeschränkungen abgelehnt wird. –
Ja, die Owin CookieMiddleware kümmert sich darum, ClaimsIdentity in einen Cookie zu verwandeln –
Wie oben erwähnt, können die Ansprüche aus verschiedenen Quellen zwischen den Sitzungen über ein Cookie beibehalten werden, das bei der Authentifizierung standardmäßig mit OWIN erstellt wird. Dies wird normalerweise in \ App_Start \ Startup.Auth.cs konfiguriert. Sie können festlegen, wann der Cookie abläuft, ob Sie einen gleitenden Ablauf wünschen (Cookie-Timeout wird bei Rückkehrbesuchen aktualisiert), wo Ihr Authentifizierungs-/Autorisierungsendpunkt ist, usw. Der spätere Teil ermöglicht es Ihnen, während des ClaimsPrincipal zusätzliche Claims bereitzustellen und ClaimsIdentity Erstellungsprozess. Mit einem anständigen Ablauf müssen Sie dies nur einmal für die Benutzersitzung tun. Bei nachfolgenden Reisen zu Ihrer Website analysiert die OWIN-Middleware den Cookie und erstellt alle Ansprüche aus diesem Schritt neu.
Sie sollten sich keine Sorgen über die Cookie-Größe machen und die neue OWIN-Auth Middleware implementiert Cookie-Chunking (es ist derzeit von den Vorveröffentlichungsquellen verfügbar - stabile Version klumpt nicht).
Wir haben dies in unserem Unternehmen implementiert und verfügen über mehrere Anspruchsquellen: unseren internen Einzelanmeldungsservice, das Active Directory und die eigene Anwendungsdatenbank (für Rollen und zusätzliche Eigenschaften über den Benutzer, den wir verfolgen möchten).
Bummer, wie gehen Sie also mit Rollen um, die aus Active Directory kommen, die aufgrund von Unternehmensumgebungen 20 oder 30 sein können? Ich denke, Sie müssten eine hybride ClaimsIdentity erstellen, die irgendwie mit Active Directory verknüpft war. –
Sie speichern sie nicht im Cookie? – leastprivilege
Oder verwenden Sie Windows-Authentifizierung - auf diese Weise erhalten Sie eine WindowsIdentity. – leastprivilege