How to save cookie statements updated with MCV5 / OWIN

Question

We worked on the OWIN MVC5 project. We use our own implementation of IUserStore<T> to integrate user management, which is part of the structure of our companies. So far, this works great. We want to provide role membership and a different security configuration through claims. I saw (and quickly tested) ways to implement IUserClaimStore<T> or attach a ClaimsIdentityFactory to a UserManager.

In both scenarios, I see that the claims are stored in user cookies and when the role or other requirement changes for the web application (through another application that directly accesses the user management repository), the user cookie contains old claims and the user has too many or fewer permissions than she should have.

The probability that occurred to me was to check each request or for requests for a certain period of time, if the back configuration of user requests was changed, and if so, update the user cookie.

Is this the right approach or MVC5 / Owin provides a more elegant / efficient way to fulfill this requirement. If this is the right and only approach, where would be the most effective place to check and update cookie information?

Answer 1

We added this feature in 2.0, here, how would you configure CookieMiddleware to receive new requirements every 30 minutes (regeneration of Identity should call the code that you use to create ClaimsIdentity for users when they log in, and validateInterval controls how often restoreateIdentity 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)) } }); 

Answer 2

No, this is essentially what you would need to do if you have a requirement that the cookie is 100% relevant at all times.

The Katana middleware options class cookie has an OnValidateIdentity callback for every moment a cookie is presented - you can check there and then re-issue the cookie. This is how ASP.NET Identity 2.0 bits work to expire a cookie if the user password has been changed since the cookie was issued.

Answer 3

Another option would be to use SignalR in a design where the user’s browsers are aimed at reloading the cookie using an Ajax call.