Menu
I'm working on a prototype of a claims-based authorisation for our MVC application. We use Asp.Net Identity for authentication.
We would like to have a claim for every controller action and then give/take away users' claims so we have a very fine control over who can go where.
Our application already has 800+ actions and keeps growing. I have made a little test app to see how this number of claims can be handled. And run into a problem: cookies are limited to 4092 bytes.
And having a large number of claims increases Identity Authentication cookie. About 600 claims with short names/values (5 chars each) give me cookie sized over 4K and user with this number of claims just can't login - cookie can't be set in a browser.
And 600 claims is not a limit for our app. We'll probably need more than that.
Is there a way to separate auth-cookie into a few smaller cookies?
p.s. If you are curious, here is my code for claims "profiler" along with the rest of the project.
p.p.s. I know about performance implications of large cookies. Not to worry about it just now.
Update Currently there is no out of the box solution to my answer. But it looks like I'm not the only one with this problem. Microsoft.Owin is handling the auth-cookie. And current source code for Owin.Cookies has ChunkingCookieManager which is assigned by default in CookieAuthenticationMiddleware.
Bad news that this code is very fresh (was checked in on 10th of July 2014, only 20 days old). It is available through pre-release of nuget Microsoft.Owin.Security.Cookies. Not sure I'd want to use RC2 in production site.
Any other way?
347
Cookies provide a means in Web applications to store user-specific information. For example, when a user visits your site, you can use cookies to store user preferences or other information. When the user visits your Web site another time, the application can retrieve the information it stored earlier.
The SetAuthCookie method adds a forms-authentication ticket to either the cookies collection, or to the URL if CookiesSupported is false . The forms-authentication ticket supplies forms-authentication information to the next request made by the browser.
You do not need a separate CookieAuthentication middleware when you are using ASPNET identity. UseIdentity() will do that for you and generate a cookie. You can set the "cookie options" in the AddIdentity block of the application like so: services.
The CookieAuthenticationDefaults. AuthenticationScheme GitHub Source shows it's set to "Cookies" . The authentication cookie's IsEssential property is set to true by default. Authentication cookies are allowed when a site visitor hasn't consented to data collection.
You are using claims incorrectly. Claims represent the identity of the user, not the actions they are allowed to perform. You are running into problems because you are treating claims as a house for user permissions. You really should find a way to separate the two in your application.
In the MVC fashion, this would be creating a custom authorize attribute, getting the user's identity from the claim cookie, and verifying that the user's identity can execute some action.
See related questions below.
Restricting access to records. Is claim-based permissions a good idea
Claims authorization for specific resources
188
I have not solved the direct question. Cookie is too large and it will remain large with large number or claims. Owin v3.0 (Currently in RC2, not production-ready) has a way to chunk the cookies into smaller ones. But large cookies are just bad. So I'm keeping claims only server-side.
I had a discussion on Identity forum and found this question which addresses my questions completely. Basing the question, I've done my own solution and prototyped a little MVC app: https://github.com/trailmax/ClaimsAuthorisation.
The core of the solution is in Startup routine and there is a MVC filter that checks if the required claims are available for the user.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
