We’re working on an OWIN MVC5 project. We use an own implementation of IUserStore<T> to integrate the user-management which is part of our companies framework. So far this works fine.
We want to provide role membership and other security configuration through claims. I have seen (and quickly tested) the ways of either implementing IUserClaimStore<T> or of attaching a ClaimsIdentityFactory to the UserManager.
In both scenarios, I see the issue that the claims are stored in the user’s cookie and when a role or another claim changes behind the web app (through another application which directly accesses the storage of the user management), the users cookie contains the old claims and the user has too much or too less permissions than she ought to have.
A possibility that came into my mind is, to check at every request or at requests in some time interval, if the backend-configuration of the users claims has been changed, and if yes, to refresh the users cookie.
Is this the right approach or does MVC5/Owin spare a more elegant/efficient way to comply with this requirement. If it is the right and only approach, where would be the most efficient place to check and refresh the cookies information?
We added this feature to 2.0, here's how you would configure the CookieMiddleware to get fresh claims every 30 minutes (regenerateIdentity should call into the code that you use to generate the ClaimsIdentity for users when they sign in, and validateInterval controls how often regenerateIdentity is called, but only if the old cookie is still valid)
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider {
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
}
});
Nope, this is in essence what you would have to do if you have the requirement that the cookie be 100% up to date at all times.
The Katana cookie middleware options class has a OnValidateIdentity callback for every time the cookie is presented -- you could check in there and then re-issue the cookie. This is how the ASP.NET Identity 2.0 bits work to expire a cookie if a user's password was changed since the cookie was issued.
Another option might be to use SignalR in a design where logged in user browsers are directed to reacquire the cookie via an Ajax call.
来源：https://stackoverflow.com/questions/22682663/how-to-hold-the-cookies-claims-updated-with-mcv5-owin