Ich habe eine Anwendung, die früher verwendet wurdeFormsAuthentication, und vor einiger Zeit habe ich es auf das umgestelltIdentityModel vonWindowsIdentityFramework Damit ich von der anspruchsbasierten Authentifizierung profitieren konnte, war es jedoch ziemlich hässlich, sie zu verwenden und umzusetzen. So, jetzt schaue ichOwinAuthentication.

Ich schaue aufOwinAuthentication und dasAsp.Net Identity Rahmen. Aber dieAsp.Net Identity Frameworks einzige Implementierung im Moment verwendetEntityModel und ich benutzenHibernate. Im Moment versuche ich es also mit der UmgehungAsp.Net Identity und benutze einfach dieOwin Authentication direkt. Ich konnte endlich ein funktionierendes Login bekommen, indem ich die Tipps von "Wie kann ich die Identity Framework-Magie ignorieren und einfach die OWIN-Authentifizierungs-Middleware verwenden, um die von mir gesuchten Ansprüche zu erhalten?", aber jetzt ist mein Cookie mit den Behauptungen ziemlich groß. Als ich das verwendeteIdentityModel Ich konnte einen serverseitigen Caching-Mechanismus verwenden, der die Ansprüche auf dem Server zwischengespeichert hat, und der Cookie enthielt nur ein einfaches Token für die zwischengespeicherten Informationen. Gibt es eine ähnliche Funktion inOwinAuthentication, oder müsste ich es selbst implementieren?

Ich gehe davon aus, dass ich in einem dieser Boote sein werde ...

Der Cookie bleibt 3 KB groß, na ja, er ist etwas groß.Aktivieren Sie eine ähnliche Funktion wieIdentityModel's SessionCaching inOwin das weiß ich nicht.Schreiben Sie eine eigene Implementierung, um die Informationen, die das Aufblähen des Cookies verursachen, zwischenzuspeichern und zu prüfen, ob ich sie bei der Konfiguration anschließen kannOwin beim Start der Anwendung.

Ich mache das alles falsch und es gibt einen Ansatz, an den ich nicht gedacht habe oder in dem ich etwas missbraucheOwin.

public class OwinConfiguration
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            AuthenticationType = "Application",
            AuthenticationMode = AuthenticationMode.Active,
            CookieHttpOnly = true,
            CookieName = "Application",
            ExpireTimeSpan = TimeSpan.FromMinutes(30),
            LoginPath = "/Login",
            LogoutPath = "/Logout",
            ReturnUrlParameter="ReturnUrl",
            SlidingExpiration = true,
            Provider = new CookieAuthenticationProvider()
            {
                OnValidateIdentity = async context =>
                {
                    //handle custom caching here??
                }
            }
            //CookieName = CookieAuthenticationDefaults.CookiePrefix + ExternalAuthentication.ExternalCookieName,
            //ExpireTimeSpan = TimeSpan.FromMinutes(5),
        });
    }
}

AKTUALISIEREN Mit den Informationen von Hongye konnte ich den gewünschten Effekt erzielen und fand die folgende Logik ...

Provider = new CookieAuthenticationProvider()
{
    OnValidateIdentity = async context =>
    {
        var userId = context.Identity.GetUserId(); //Just a simple extension method to get the ID using identity.FindFirst(x => x.Type == ClaimTypes.NameIdentifier) and account for possible NULLs
        if (userId == null) return;
        var cacheKey = "MyApplication_Claim_Roles_" + userId.ToString();
        var cachedClaims = System.Web.HttpContext.Current.Cache[cacheKey] as IEnumerable<Claim>;
        if (cachedClaims == null)
        {
            var securityService = DependencyResolver.Current.GetService<ISecurityService>(); //My own service to get the user's roles from the database
            cachedClaims = securityService.GetRoles(context.Identity.Name).Select(role => new Claim(ClaimTypes.Role, role.RoleName));
            System.Web.HttpContext.Current.Cache[cacheKey] = cachedClaims;
        }
        context.Identity.AddClaims(cachedClaims);
    }
}