MVC5 Claims Based Authentication - Suitable claim items

Question

I am just getting started with claims based security on an existing web application. I have a number of items that fit well into claims on the identity such as email and first and last names but there are other security related items that im not sure should go there.

For example, there are a number of fine grain boolean permissions for different areas of the site that im not sure where to put. eg - CanAccessX, CanAccessY, CanAccessZ etc..

Can someone tell me if these sorts of items are fine for turning into claims or do they belong somewhere else?

As a secondary concern, as all the claims are serialised into the cookie, is it a bad idea to load it up with too many claims? what would be the line at which one would retrieve additional claims post authentication and only put a small subset on the cookie.

Thanks.

Answer 1

Turning permissions into claims is generally a good idea, if that matches the requirements of the application. One of the benefits of claims based security is the decoupling between the user's meta data (name, role, age, permission, ...) and the applications security demands. If for example some "action" requires the user to be of a certain age, only a simple check HasClaim(c => c.Type == Age && c.Value >= 18) is necessary. And if it requires a simple permission, why not just check HasClaim(CanAccessX)?

Many applications (mis)use groups / roles like "CanAccessX" / "CanReadY" / "CanWriteZ" to implement a less complicated (= better) security mechanism. With claims this concept becomes somehow natural.

Secondly, cookie bloating can be an issue, though. Like for example token bloating with Kerberos can be an issue, if a user has too much groups / roles / permissions / whatever. One approach to solve this can be some kind of role based security in front of claims based security: if there are n roles for m permissions (n should be much less than m), you can only write the n roles to the cookie, but convert them behind the scenes within a simple module / middleware. Another solution may be a custom identity / permission mapping, so you have only to write the user's identity to the cookie, but match it with its (cached) permissions before actually processing the request.

I would start with the direct approach (just write all the claims to the cookie). Then, if it gets too big and compromises application's performance, you can optimize it's behavior with a more or less complicated module / middleware, which should not affect the actual "code".

Note, there are already .NET mechanisms to handle that cookie stuff securely: for classic (current) IIS applications you can use the Session Authentication Module, for modern (future) OWIN applications you can use a Cookie Authentication Middleware.