Role-Based Access Control Disadvantages

Question

According to NIST, RBAC models are the most widely used schemes among enterprises of 500 or more. What happens if the size of the enterprises are much larger in number of individuals involved. In other words, what are the main disadvantages of RBAC models?

Answer 1

The main disadvantage of RBAC is what is most often called the 'role explosion': due to the increasing number of different (real world) roles (sometimes differences are only very minor) you need an increasing number of (RBAC) roles to properly encapsulate the permissions (a permission in RBAC is an action/operation on an object/entity). Managing all those roles can become a complex affair.

Because of the abstraction choices that form the foundation of RBAC, it is also not very well suited to manage individual rights, but this is typically deemed less of a problem.

The typically proposed alternative is ABAC (Attribute Based Access Control). ABAC has no roles, hence no role explosion. Yet, with ABAC, you get what people now call an 'attribute explosion'. The two issues are different in the details, but largely the same on a more abstract level. (A cynic might point to the market saturation for RBAC solutions and the resulting need for a 'newer' and 'better' access control solution, but that's another discussion.)

Answer 2

There are different issues with RBAC but like Jacco says, it all boils down to role explosions.

RBAC is:

• identity-centric i.e. it focuses on the user identity, the user role, and optionally the user group
• typically entirely managed by the IAM team
• admin-time: roles and permissions are assigned at administration time and live for the duration they are provisioned for.

What's not so good with RBAC?

• it is coarse-grained. If you have a role called doctor, then you would give the doctor role a permission to "view medical record". That would give the doctor the right to view all medical records including their own. This is what leads to role explosion
• it is static. RBAC cannot use contextual information e.g. time, user location, device type...
• it ignores resource meta-data e.g. medical record owner.
• it is hard to manage and maintain. Very often, administrators will keep adding roles to users but never remove them. You end up with users that dozens if not hundreds of roles and permissions
• it cannot cater to dynamic segregation-of-duty.
• it relies on custom code within application layers (API, apps, DB...) to implement finer-grained controls.
• Access reviews are painful, error-prone and lengthy

Is ABAC the solution?

ABAC - Attribute-Based Access Control - is the next-generation way of handling authorization. It is driven by the likes of NIST and OASIS as well as open-source communities (Apache) and IAM vendors (Oracle, IBM, Axiomatics).

ABAC can be see as authorization that is:

• Externalized: Access control is externalized from the business logic
• Centralized: Access control policies are maintained centrally
• Standardized: Access control policies use XACML, the eXtensible Access Control Markup Language, the standard defined by OASIS and implemented by most ABAC solutions
• Flexible: ABAC can be applied to APIs, databases, and more
• Dynamic: Access decisions are made dynamically at runtime
• Context-based / Risk-based: ABAC can take time, location, and other contextual attributes into account when reaching decisions.

ABAC provides:

• an architecture with the notion of a policy decision point (PDP) and policy enforcement point (PEP)
• a policy language (XACML)
• a request / response scheme (JSON/XACML)

Answer 3

Role based access control is an access control policy which is based upon defining and assigning roles to users and then granting corresponding privileges to them.

Disadvantages:

Following are the disadvantages of RBAC (Role based access model):

1. If you want to create a complex role system for big enterprise then it will be challenging as there will be thousands of employees with very few roles which can cause role explosion.

2. Using RBAC, some restrictions can be made to access certain actions of system but you cannot restrict access of certain data.

3. The permissions and privileges can be assigned to user roles but not to operations and objects.