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.

  • When you get up to 500-odd people, you need most of the "big organisation" procedures, so there's not so much difference when you scale up further. – paj28 Feb 14 '17 at 18:05

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.)

  • 1
    Expanding on the role explosion (ahem)... one artifact is that roles tend not to be hierarchical so you end up with a flat structure of roles with esoteric naming like Role_Permission_Scope. As such they start becoming about the permission and not the logical role. – Steve Feb 15 '17 at 14:19
  • Hierarchical RBAC is one of the four levels or RBAC as defined in the RBAC standard set out by NIST. Most people agree, out of the four standard levels, the Hierarchical one is the most important one and nearly mandatory if for managing larger organizations. – Jacco Feb 15 '17 at 14:51
  • I should have prefaced with 'in practice', meaning in most large organizations I've worked with over the years. – Steve Feb 15 '17 at 15:17

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)
  • RBAC does include dynamic SOD (separation of duty). – Jacco Feb 15 '17 at 8:45
  • Also, the first four (Externalized, Centralized, Standardized & Flexible) characteristics you mention for ABAC are equally applicable and the fifth (Dynamic) is partially applicable to RBAC. The context-based part is what sets ABAC appart from RBAC, but this comes at the cost of severely hampering auditability. – Jacco Feb 15 '17 at 8:51
  • @Jacco RBAC does not include dynamic SoD. It is a fallacy to claim so. I know lots of papers write it but it is just not true. We have so many instances of customers failing on SoD because of dynamic SoD rules. Standardized is not applicable to RBAC. It has a model but no implementation language. Externalized is not entirely true of RBAC because it only externalize role management and role assignment but not the actual authorization logic which you still have to write in code. – David Brossard Feb 15 '17 at 13:59
  • I don't know what your definition of dynamic SoD is, but it is part of the NIST standard and many implementations support it. – Jacco Feb 15 '17 at 14:49
  • Runtime dynamic and standardized – David Brossard Feb 15 '17 at 15:14

Use the right tool for the job as they say. RBAC, like any access control model, has its weaknesses. Many are well understood, even discussed by the original NIST team who framed the model.


However, there were some inaccuracies in the answer by David Brossard. For example...

I. It is static. RBAC cannot use contextual information e.g. time, user location, device type...

Constraints are commonly applied during user, role and permission activation in RBAC. For example, placing temporal constraints on a role activation. Indeed INCITS 494 prescribes their use:

5.4 RBAC Policy Enhanced Constraints

Enhanced constraints go beyond the INCITS 359 RBAC Standard by including additional types of constraints. Constraints on roles may be static or dynamic. Static constraints are applied off- line before the role is activated by the user. Dynamic constraints are applied on-line after the role(s) are activated. These enhanced dynamic constraints can introduce attributes into the RBAC environment.

INCITS 494-2012, p. 8

II. It cannot cater to dynamic segregation-of-duty.

RBAC supports dynamic SoD constraints. From the spec:

Dynamic Separation of Duty Relations Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions.

ANSI INCITS 359-2004, p. 10

III. It relies on custom code within application layers (API, apps, DB...) to implement finer-grained controls.

A bit confused by this statement because you earlier stated that RBAC is coarse-grained.

Do you mean that custom code must be written because RBAC controls don't adequately satisfy security requirements for authorization?

Where are ABAC's published functional specifications? Where are the standard object (data) and functional (api) model for computing (and storing) its decisions?

Perhaps it is better to use a proven, non-standard ABAC implementation than a custom app widget? If that is what you are saying then I agree, but neither are ideal.

ABAC has its place as does RBAC. Knowing when to use one, the other, or both, is important. Understanding the limitations and strengths of each is crucial before adequately addressing the challenges we face as security practitioners.

  • 2
    Don't reply to an answer in another answer, this is not a forum, answer the question, if you want to address a point, comment. – Tensibai Feb 15 '17 at 11:07
  • I'm a brand new user w/out enuf karma (rep points) to comment on another's answer. :/ – Shawn McKinney Feb 15 '17 at 11:50
  • 1
    And there's reason for that, earn rep and you'll be able to comment. This is not a forum, linking your answer to another one is hard when even possible and absolutely not useful. There's some rules, take the tour and read help center. I'm just giving you the information about it. – Tensibai Feb 15 '17 at 12:19
  • 2
    I am aware of the rules. Please refrain from commenting on my answer unless you'd like to address it specifically. Thanks. – Shawn McKinney Feb 15 '17 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.