Role-based access control (RBAC) vs. Claims-based

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

More broadly, you should consider attribute-based access control (ABAC). RBAC and ABAC are both concepts defined by NIST, the National Institute of Standards and Technology. CBAC, on the other hand, is a model pushed by Microsoft which is very similar to ABAC.

Read more here:

• Role-based access control NIST page
• Attribute-based access control NIST page

Answer 2

I don't fully agree with Emran's answer

[Authorize(Roles="Sale")]

Is naive

The question is how

  [Authorize(Roles="CustomerCreator")]

is different from

 [ClaimAuthorize(Permission="CanCreateCustomer")]

If both are equally good, why we need claim ?

I think because

Claims concept is more generic compared to Role

In context of the example above we can say "CustomerCreator" is a claim of type "role" provided by "Asp.NETroleProvider"

Additional examples of claims.

1. "AAA" is claim of type "MYExamSite.Score" provided by "MYExamSite.com"

2. "Gold" is claim of type "MYGYM.Membershiptype" provided by "MYGYMApp"

Answer 3

The fundamental between RBAC and CBAC is that:

RBAC: a user must be assigned to a role to be authorized to perform an action.

CBAC : user must have a claim with the correct value, as expected by the application, to be authorized. Claims-based access control is elegant to write and easier to maintain.

Beside that claims are issued to the application by an issuing authorize services (Security Service Token STS) that is trusted by your application (Relying Party)

Answer 4

Role is just one type of Claim. Like that, there can be many other claim types, for example user name is one of the claim type

Answer 5

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.

Answer 6

I think this question could be answered from the database prospective. if you noticed how the tables involved in this implantation you will find the following

1. AspNetUsers : each user has one row with all the attributes required by all users like email, address phone, password.....
2. AspNetRoles ; defines different roles as per application requirements like GM , CTO, HRM,ADMIN, EMP. what each roles defines is as per application needs.
3. AspNetUserRoles: each row links AspNetUsers and AspNetRoles and effectively links between one user and many roles.
4. AspNetUserClaims: each row has key to AspNetUsers and one type and value. so effectively add one attribute for each user that could be added/removed at run time.

The usage of this tables could be tweaked at one moment of user/application life time to match specific needs.

Consider the early stage of "Purchasing Manager" (PM), we could have three approachs

1. Application populates AspNetUserRoles with one row to grants 'PM' right to buy. To issue purchasing order with any amount, user only need "PM" role.

2. Application populates AspNetUserRoles with one row to grants 'PM' right to buy, and populates the AspNetUserClaims a claim of TYPE 'Purchasing Amount' type and "<1000" value to set the amount limit. To issue purchasing order, user need to has 'PM'and the order amount be less than claim value of claim TYPE 'Purchasing Amount'.

3. Application populate AspNetUserClaims with claim of TYPE 'Purchasing Amount' type and "<1000" value. Any user can issue purchasing order, given the the amount to be less than claim value of claim TYPE 'Purchasing Amount' for this user.

As it could be noticed, role based is coarse grained of rigid rights that would simplify the life of the application user from the system management point of view. however it will limits the user abilities from the business requirements point of view. At the other hand claim based is very fine rights that need to be assigned to each user. claim based will push the business too the limit, however will make the system management very complex.