by Shawn McKinney

RBAC vs ABAC

Frequently debated within info sec circles.  Which one of them is better?

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.

Comments on “A Critique of the ANSI Standard on Role-Based Access Control”

However, there are a number of common fallacies wrt how RBAC works.  For example…

1. RBAC is static. It 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

2. RBAC cannot perform dynamic segregation-of-duty.

RBAC supports dynamic SoD constraints. From the spec:

5.3.2 Dynamic Separation of Duty Relations

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

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

Presumably what is meant here is 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 is being said 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 Comments

  1. Great post!
    In the RBAC implementations, I have never seen context or dynamic SoD being used. I am aware of what the RBAC standard says but these functions rely on the underlying RBAC Implementation which is where things fall flat. The key difference is that roles are still granted at admin time or login time which does not make for a very dynamic system..

    Liked by 1 person

    Reply

    1. RBAC (INCITS 359) defines four possible levels:
      1. RBAC0 – Called the core includes the concept of a session and role activation (more on this in a bit)
      2. RBAC1 – Hierarchical Roles
      3. RBAC2 – Static Separation of Duties
      4. RBAC3 – Dynamic Separation of Duties

      RBAC0 is the minimum to be deemed compliant and many (most?) implementations don’t go beyond it which is perhaps why you haven’t heard much about the others.

      As for not being very dynamic….

      RBAC0 requires that sessions are used which is when assigned roles must then be ‘activated’. This activation is a central aspect of an RBAC system and when dynamic constraints are applied. For example, Apache Fortress limits which roles are activated by time and date based parameters. If the impl supports RBAC3 it also is when DSD constraints are enforced.

      There is a new experimental (abac-like) feature recently added to fortress that allows constraints based on arbitrary attributes — like location or account (as defined by the caller). This area of dynamic constraints (applied during runtime) is the focus of RBAC Policy Enhanced standard (INCITS 494).

      Thanks for your input!

      Shawn

      Like

      Reply

Leave a comment