How to separate large cookies in Asp.Net Identity

Question

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?

Answer 1

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.

Answer 2

You should use Role

[Authorize(Roles = "Admin, Role1")]
  public ActionResult Index(string id)
{....}
[Authorize(Roles = "Admin, Role2")]
  public ActionResult Index2(string id)
{....}
[Authorize(Roles = "Admin, Role1, Role3")]
  public ActionResult Index3(string id)
{....}

Answer 3

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