Roles Against Approving Claims Asp.net web api-2 with WIF and OWIN Middleware

Question

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

• If roles are also treated as claims, then what are the differences between b / w roles and claims?

• If I stay away from roles, how can I use assertions to protect web-api controllers and their associated action methods. For example, I have an order controller containing CRUD methods. I want one user (for example, a manager) to have access to the Create and Get methods, and a second user (administrator) to have access to all these methods.

  How can I do it? with a role-based system, I would just decorate the action methods with the corresponding Authorize(Role = "Admin") attribute Authorize(Role = "Admin") . How do I manage claims myself? Do I need to add them to the database and submit / cancel these claims for different users through my application?

Answer 1

In principle, there is no significant difference between Role and Claim. I all connected to the claims-based authorization, conducted a lot of research and several test projects. And in the end, you decide which one to use.

As you said, roles are added as a claim type. Therefore, in terms of delivery, this does not matter. But MVC / WebApi already has a built-in infrastructure for handling roles and deny that the user does not have the required role. This way you don’t have to do much on your own.
But you will have to come up with a bunch of attributes on the controllers / actions and make sure that they all exist in the database, so you can assign them to users.

However, I found that you may have too many roles and they become too complex to maintain. In addition, you cannot have too many roles assigned to your user - their cookie authentication will become massive and ultimately will not be able to log in due to browser cookie size limitations (4K per cookie, 16K for all HTTP -headings).

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 several requirements values ​​(Read, Create, Edit, Delete). When using an application with a descent size (we have above 100) you will have to have many roles (4 per controller) to simulate this level of permission control. With claims, we have enum for claim types (Person, Product, Order) and enum for requirement values ​​(Create, Read, Edit, Delete). And in the cookie, you can set integers as the type of request and requirement value - this saves a lot of space on authentication cookies.

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

I played with this concept here and it is an authentication filter for MVC, but the WebApi filter will be very similar. Now the results of this prototype are in production and work very well.

In general, the answer to your question is "it depends." Basically, how important is authentication and how big is this application.