Role-based access control (RBAC) vs. Claims-based access control (CBAC) in ASP.NET MVC

Question

What are the main benefits of using CBAC vs. RBAC? When is it better to use CBAC and when is it better to use RBAC?

I'm trying to understand the general concepts of the CBAC model but the general idea is still not clear for me.

Answer 1

I will try to show how you can benefit from Claim Based Access Control in an ASP.NET MVC Context.

When you are using Role based authentication, if you have an action for creating customer and you want that the people who are in 'Sale' role should be able to do that, then you write code like this:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Later, you realized that, sometimes, people from 'Marketing' role should be able to create Customer. Then, you update your Action method like that

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Now, you realized that, some of the marketing people must not be able to create Customer, but it is not possible to assign a different role for those people who are in Marketing. So, you are forced to allow all marketing people to create Customers.

you spotted another problem, anytime you decide that Marketing people should be allowed to create customers, you have to update all of your MVC Action methods Authorize attribute, compile your application, test and deploy. Some days later, you decided, not marketing but some other role should be allowed to do the task, so you search in your codebase and delete all 'Marketing' from Authorize attribute and add your new role name in Authorize attribute... Not a healthy solution. At that point, you would realize a need for Permission Based Access Control.

Permission Based access control is a way of assigning various permissions to various users and checking if a user has permission to execute an action from the code in run time. After you assign various permissions to various users, you realize that you need to allow some users to execute some code if the user has some property like "Facebook User", "Long time User" etc. Let me give an example. Say you want to allow access to a specific page if the user is logged in using Facebook. Now, would you create a permission 'Facebook' for that user ? No, 'Facebook' does not sound like a permission. Does it ? Rather it sounds like a claim. At the same time, Permissions can sound like Claim too !! So, it is better to check for claims and allow access.

Now, lets go back to the concrete example of claim based access control.

You can define some set of claims like this :

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer".. etc..

Now, you can decorate your Action Method like this:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(please note, [ClaimAuthorize(Permission="CanCreateCustomer")] may not be built into MVC class library, I am just showing as an example, you can use some class library which has such Attribute class definition)

Now, you can see that, CreateCustomer action method will always need permission 'CanCreateCustomer' and it will never change or hardly change. So, in your database, you create a table of permissions (claims) and user-permission relation. From your admin panel, you can set permission (claim) for each user who can do what. You can assign 'CanCreateCustomer' permission (claim) to anyone you like and only permitted user will be able to create customer and permitted user will be able to create only customer and nothing else (unless you assign other permissions to the same user).

This security model offers you clean code practice. Moreover, when you write your Action Method, you dont have to think about who can use this method, rather you can always be assured that whoever is using this method will have proper permission (claim) given by the Admin. Then, Admin can decide who will be able to do what. Not you as a developer. Thats how your business logic is separated from Security logic.

Whenever someone signs in, your application will check whatever permissions are available for that user and that permission (claim) set will be available as additional properties of currently logged in user (usually the claim set is stored as cookie for the logged in user), so you don't have to check permission set all the time from database. The bottom line is, you get more control of your security logic in your application if you apply claim based access rather than role based access. In fact, a Role can be considered as a Claim too.

If your application is a very little application where there would be only 2 roles : Customer and Admin and there is no chance that Customer will be able to do anything else other than what they are meant to do in your application, then perhaps, Role based access control will serve the purpose, but as your application grows, you will start to feel the need of claim based access control at some point.