ABAC, RBAC and ReBAC: Which Model Answers Which Question

RBAC, ABAC and ReBAC are three authorization models that answer three different questions. Role-based access control (RBAC) answers what a job function is permitted to do. Attribute-based access control (ABAC) answers whether the current combination of subject, resource and environment attributes matches a rule. Relationship-based access control (ReBAC) answers whether a path exists between the requester and the object through a graph of relationships. They are not competing generations. Most production systems run at least two of them, and choosing correctly starts with knowing which question each one is shaped to answer.

What RBAC is and what question it answers

Role-based access control grants permissions to roles and assigns roles to users. A user acquires a permission by holding a role that carries it, never directly. RBAC was standardized as ANSI/INCITS 359, first published in 2004 and revised in 2012, following the NIST unified model published in 2000.

The standard model has three layers. Core RBAC defines users, roles, permissions and sessions. Hierarchical RBAC lets a senior role inherit the permissions of junior roles. Constrained RBAC adds separation of duty, static and dynamic.

RBAC answers the question: what is this job function allowed to do? It is a statement about organizational structure, evaluated against a stored assignment. RBAC is fast, easy to review and easy to explain to an auditor, because the grant is a visible fact rather than a computation.

What ABAC is and what question it answers

Attribute-based access control evaluates attributes at request time instead of consulting a stored grant. NIST SP 800-162, Guide to Attribute Based Access Control Definition and Considerations, first published in January 2014 and updated in final form on 2 August 2019, defines ABAC as a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations and, in some cases, environment conditions against policy, rules or relationships describing the allowable operations for a given set of attributes.

Attributes fall into categories: subject attributes such as clearance or employment status; object attributes such as classification, jurisdiction or owner; action attributes such as read or export; and environment attributes such as time, location, device posture and network position.

ABAC answers the question: do the current facts match a rule? Because the facts are read when the request arrives, ABAC produces different answers for the same user at different times without anyone editing a grant.

What ReBAC is and what question it answers

Relationship-based access control derives permission from the relationships connecting a subject to an object. Instead of "engineers may read design documents", ReBAC expresses "the owner of a folder may read the documents in it, and members of a team related to that folder inherit that relationship". The term emerged from access-control research on social platforms in the late 2000s, where the meaningful unit was the connection between two people rather than a role either held.

The model reached mainstream engineering through Zanzibar: Google's Consistent, Global Authorization System, presented at USENIX ATC 2019. Zanzibar stores authorization data as relation tuples binding an object and a relation to a subject, evaluates a check by traversing that graph, and adds a consistency mechanism so a permission change is not read stale.

ReBAC answers the question: is this requester connected to this object, and how? It is strong where hierarchy and sharing dominate: documents, folders, repositories, tenants, nested groups.

ABAC, RBAC and ReBAC compared

None of the three models is a superset of the others. A rule engine can express a role as an attribute, and a graph can encode an attribute as a relation, but expressing a model is not the same as operating it. The failure modes above are properties of how humans maintain each structure, not of the notation.

The difference between ABAC and RBAC

The difference between ABAC and RBAC is when the answer is computed and what it is computed from. RBAC computes the answer in advance: an administrator assigns a role, the assignment is stored, and every later request reads that stored fact. ABAC computes the answer during the request, from attribute values read at that moment.

That timing difference produces every other difference. RBAC cannot express a condition that was not true at assignment time, so "read this only from a managed device, inside the country of origin, for an approved purpose" has no RBAC encoding; the closest approximation is a role per combination, which is where role explosion begins.

The direction reverses on review. RBAC makes "who can do this" trivially answerable by listing role holders. ABAC makes the same question hard, because the answer is whoever might match the rule under some future set of attribute values. Organizations that migrate wholesale from RBAC to ABAC frequently trade a permissions problem for an attribute governance problem. That tradeoff is examined as a default-setting decision in ABAC vs RBAC: Which Should Be the Zero Trust Default.

How ABAC and ReBAC are used together

ABAC and ReBAC compose cleanly because they constrain different halves of the same request. ReBAC establishes eligibility: does a relationship path connect this requester to this object at all. ABAC establishes conditions: given eligibility, do the current attributes permit this action now.

A common production pattern runs ReBAC first as a structural filter, then ABAC as a conditional gate. A contractor related to a project folder is eligible to read its contents; an ABAC rule still denies the read from an unmanaged device, outside the contracted jurisdiction, or for a purpose the engagement does not cover. Neither model alone produces that answer: ReBAC has no notion of device posture, and ABAC would need to reconstruct the folder hierarchy as attributes.

The integration point is the policy decision point, which receives both the relationship result and the attribute values and evaluates them as one decision, as set out in What Is a Policy Decision Point.

When RBAC is the correct choice

RBAC is not obsolete and is the right answer for a large class of problems. It is correct when duties are stable, populations are bounded, and the decision genuinely is about job function rather than circumstance.

Administrative and operational permissions are the clearest case. Who may approve a payment, restart a production service or modify a firewall rule is a question about role, and encoding it as an attribute rule adds evaluation cost and review difficulty without adding precision. Regulated environments that require a named human to attest to a permissions list are also better served, because the list exists as an artifact.

RBAC degrades when roles start encoding circumstance. A role named "contractor read access, EU only, managed device" is an attribute rule wearing a role's clothing, and each condition multiplies the role count. Role explosion signals that the problem has become conditional and the model has not.

The question none of these three models answers

RBAC, ABAC and ReBAC all answer variations of the same underlying question: who may act. The subject is the variable. The object is a target the model refers to but does not carry any state of its own.

None of the three answers a second question: should this specific object open, right now, under these conditions. That question is scoped to an individual object rather than a class, and it has to remain answerable after the object leaves the system that evaluated the policy. A copied file, a forwarded attachment, an exported table or a document ingested into a retrieval index has left the reach of every model above, because all three are properties of a system rather than of the object.

Closing that gap requires the policy to travel inside the object and the enforcement point to sit at decrypt rather than at the application boundary, as described in What Is Data-Centric Security. It does not replace RBAC, ABAC or ReBAC. It answers the question they were never shaped to answer, and consumes their output as input.

Frequently asked questions

What is the difference between ABAC and RBAC?

RBAC grants permissions to roles and assigns roles to users, so the answer is computed at provisioning time and stored. ABAC evaluates attributes of the subject, object, action and environment when the request arrives, so the answer reflects current conditions. RBAC is easier to review and cannot express per-request conditions. ABAC expresses conditions and makes "who can access this" much harder to enumerate.

What is relationship-based access control?

Relationship-based access control (ReBAC) derives permission from the relationships connecting a requester to an object, such as ownership, membership, or containment in a folder or team. Permission is decided by traversing that relationship graph rather than by matching a role or an attribute rule. Google's Zanzibar paper, presented at USENIX ATC 2019, described the relation-tuple model most current ReBAC implementations follow.

How are ABAC and ReBAC used together?

ReBAC and ABAC constrain different halves of a request. ReBAC establishes eligibility by proving a relationship path exists between requester and object. ABAC then applies conditions to that eligibility: device posture, location, time, purpose of use and object sensitivity. Running ReBAC as a structural filter and ABAC as a conditional gate avoids duplicating a folder hierarchy as attributes or modeling device posture as a relationship.

Is RBAC obsolete?

No. RBAC remains correct where duties are stable and the decision is genuinely about job function, including administrative permissions, approval authority and operational access. It is also the easiest model to present as a reviewable artifact for attestation. RBAC degrades when roles begin encoding circumstance such as location or device state, which produces role explosion and then over-broad roles created to contain it.

Which authorization model is best for zero trust?

Zero trust requires the decision to be made at request time against current conditions, which rules out RBAC used alone but does not rule out RBAC used as an attribute source. Most zero trust deployments evaluate ABAC at a policy decision point, take role and relationship data as inputs, and place enforcement where it survives the application. The model matters less than where the enforcement point sits.

How Lattix applies these models

The Lattix policy decision point evaluates attribute-based access control (ABAC) across subject, device, environment and geography, purpose of use, network posture, risk and data-object attributes. Role and relationship data are consumed as subject attributes, so an organization keeps its existing role structure and directory relationships. The decision returned is signed and short-lived, carrying allow or deny, the reasons, the policy version hash and the object identifier. The Lattix policy enforcement point acts at decrypt time, which is what extends any of these models past the boundary of the system that evaluated them. Defaults are fail-closed and revocation propagates to deny. Applying the same models to non-human requesters is covered in How to Give an AI Agent Access to Sensitive Data Safely.