Roles vs Claims Authorization Asp.net web api-2 wi

Question

I am trying to secure asp.net web-api 2.0 with Windows Identity Foundation 2. The choice I have to make is between role based authorization and claims based authorization. As a practice, I added a users in DbInitializer and assigned him two roles (Admin and Manager). When I log in with that user, I see that ClaimsPrincipal in debug mode, it already has those roles (Admin and Manager) associated as claims. So here are the questions:

1. If roles are also treated as claims, what is the difference b/w roles and claims then?

2. If I keep away from roles, how can I use claims to protect web api controllers and associated action methods. Like, I have an orders controller containing CRUD methods. I want one user (say a manager) to have access to Create and Get method and the second user (an admin) to have access to all those methods.

   How would I do that? with role based system, I would simply decorate the action methods with appropriate Authorize(Role = "Admin") attribute. How would I manage the claims itself? do I need to add them in database and grant/revoke those claims to different users through my application?

Answer 1

In principal there is no massive difference between Role and a Claim. I've been all hooked up for Claims-based authorisation, done a lot of research and a few test projects. And at the end of the day it all down to you to decide which one is to use.

As you said, roles are added as type of claims. So in delivery terms it makes no difference. But MVC/WebApi already have built-in infrastructure to handle roles and deny if user does not have the required role. So you won't have to do much yourself.
But you'll have to come up with a bunch of attributes on controllers/actions and make sure all of them exist in DB, so users can be assigned to them.

However I found that you can have too many roles and they become too much of a burden to maintain. Also you can't have too many roles assigned to your user - their authentication cookie will become massive and eventually will have to be unable to login due to cookie size limitation in browsers (4K per cookie, 16K for all HTTP headers).

With claims you can be more flexible. You can have many different types of claims (we have a bit less than one per controller) and a few claim values (Read, Create, Edit, Delete). With a descent sized application (we have above 100) you'll have to have a LOT of roles (4 per controller) to model this level of permission control. With claims we have an enum for claim types (Person, Product, Order) and enum for claim values (Create, Read, Edit, Delete). And in cookie you can set integers as a claim type and claim value - that saves a lot of space on authentication cookie.

But with claims you'll have to code the authentication mechanisms yourself.

I've been playing with this concept here and this is authentication filter for MVC, but WebApi filter will look very similar. Now results of this prototype are in production and working very well.

Overall, the answer to your question is "it depends". Mostly on how granular the authentication have to be and how big is the application.