Category: Access Control Models

Relationship-Based Access Control

Also known as: ReBAC, Relationship-based access control

Simply put

Relationship-Based Access Control (ReBAC) is a way of deciding what someone is allowed to do based on how they are connected to a specific resource, rather than only on a role assigned to them. For example, access might depend on being the owner of a document or a member of the group that holds it. This makes it a model built around the relationships between users and the things they want to access.

Formal definition

ReBAC is an authorization model in which a subject's permission to access a resource is determined by the presence of relationships between subjects and resources (and, in many implementations, between resources themselves), rather than by directly assigned roles as in RBAC. Access decisions are evaluated against how identities and objects are connected, typically expressed as a graph of relationships that policies traverse to resolve whether a given subject may perform an action on a given resource. As an authorization paradigm, ReBAC governs what a principal may do (authorization) and is distinct from authentication; it is one of several access control models and, depending on deployment, may be combined with or contrasted against RBAC, ABAC, or PBAC rather than treated as universally superior.

Why it matters

As applications grow more collaborative and data becomes more interconnected, authorization requirements increasingly depend on how a specific user relates to a specific resource rather than on a coarse organizational role. ReBAC addresses scenarios where permissions naturally flow from connections, a user can edit a document because they own it, view a folder because they belong to a group that was granted access, or manage a project because they were added as its administrator. In these cases, RBAC alone can become unwieldy, since expressing per-resource, per-relationship access through static roles often leads to role explosion or brittle, hard-coded checks scattered across application code.

Because ReBAC models access as a graph of relationships between subjects and resources (and, in many implementations, between resources themselves), it can express nested and inherited permissions more naturally than models that rely on directly assigned roles. This tends to matter most in systems with fine-grained sharing semantics, hierarchical resources, or user-driven collaboration, where the question "who can access this specific object?" is answered by traversing connections rather than by consulting a flat role assignment.

ReBAC is not universally superior to other models, and choosing it involves trade-offs. Depending on deployment, teams may combine ReBAC with RBAC, ABAC, or PBAC, for example, using roles for broad organizational entitlements while relying on relationships for resource-level sharing. It is important to note that ReBAC is an authorization model concerned with what a principal may do; it does not perform authentication and does not verify who the principal is.

Who it's relevant to

Security Architects

Architects evaluating authorization models need to understand where ReBAC fits relative to RBAC, ABAC, and PBAC. ReBAC is well suited to systems with fine-grained, resource-level sharing and hierarchical or interconnected data, but it is one option among several and may be combined with other models depending on requirements. Architects should weigh the expressiveness of relationship graphs against the operational complexity of modeling and maintaining those relationships.

IAM and Application Engineers

Engineers implementing authorization logic benefit from ReBAC when access decisions naturally depend on how users connect to specific resources, ownership, group membership, or resource hierarchy, rather than on static roles. Moving these checks out of scattered application code and into a relationship-driven policy model can reduce role explosion, though it introduces the need to model, store, and query relationships correctly. Implementation details such as graph traversal semantics and inherited permissions vary by the chosen engine or framework.

Identity Governance Leads

Those responsible for access governance should recognize that relationship-driven access changes how entitlements are reasoned about and reviewed. When permissions derive from connections between subjects and resources rather than from directly assigned roles, access reviews and certification must account for how those relationships grant effective access, including inherited or transitive paths. This is a governance consideration distinct from the runtime evaluation that resolves individual access decisions.

Compliance and Audit Teams

Auditors assessing who can access a given resource need visibility into the relationships that produce access, since in ReBAC the answer depends on the connection graph rather than a role assignment list. Understanding how policies traverse relationships, and where access is inherited through nested connections, is essential for validating that effective permissions align with intended controls such as least privilege and segregation of duties, the enforcement of which depends on deployment and policy design.

Inside ReBAC

Relationships (edges)

The core construct of ReBAC, where access decisions derive from the existence and type of relationships between subjects and resources (for example, owner, editor, or member) rather than from statically assigned roles or standalone attributes.

Objects and subjects (nodes)

The entities connected by relationships, typically users, groups, and resources. ReBAC models these as nodes in a graph, with authorization determined by traversing the paths between them.

Relationship graph

The graph-oriented data structure representing subjects, objects, and the relations linking them. Authorization checks are commonly expressed as reachability or path queries over this graph, depending on the implementation.

Direct and indirect (transitive) relationships

ReBAC supports both directly asserted relationships and relationships inherited through chains (for example, a user who is a member of a group that owns a folder may gain access to files within it), depending on how the model defines inheritance.

Policy or schema definition

A declarative definition of which relation types exist and how they confer permissions, including how relationships compose transitively. The exact syntax and capabilities vary by product and implementation.

Runtime enforcement role

As an access control model, ReBAC informs the authorization decision typically evaluated by a policy decision point at runtime; it is an enforcement-time concern and is distinct from identity lifecycle and governance processes.

Common questions

Answers to the questions practitioners most commonly ask about ReBAC.

Is ReBAC just a specialized form of ABAC?

Not quite, though the two are related. ABAC (attribute-based access control) makes decisions by evaluating attributes of the subject, resource, action, and environment against policy. ReBAC (relationship-based access control) makes decisions by evaluating the existence of relationships between entities, for example, whether a user is an owner of a document, or a member of a group that has access to a folder. You can model relationships as attributes, and some implementations blur the line, but ReBAC's distinguishing characteristic is that authorization is derived by traversing a graph of relationships rather than by matching flat attribute values. Treating them as identical obscures the graph-traversal semantics that define ReBAC in most deployments.

Does using ReBAC mean you no longer need roles or RBAC?

No. ReBAC is not universally superior to RBAC, and adopting it does not require abandoning roles. The access control models are not mutually exclusive: many systems express role-like constructs as relationships (for example, a 'member' or 'admin' relation on a group or resource), and roles can coexist with relationship-based rules. The right choice depends on the access patterns you need to express. ReBAC tends to fit hierarchical or ownership-driven scenarios well, while RBAC can be simpler for coarse-grained, role-oriented access. Presenting either as a replacement for the other overstates the case.

How is a ReBAC authorization decision typically evaluated at runtime?

In most deployments, a ReBAC decision is a runtime enforcement concern handled by a policy decision point (PDP) that traverses the relationship graph to determine whether a path exists connecting the subject to the resource under the requested relation. A policy enforcement point (PEP) intercepts the request and consults the PDP, and relationship data may be supplied by a policy information point (PIP) or stored in a dedicated relationship store. This is distinct from identity governance and administration concerns such as provisioning or access certification; ReBAC evaluation is about real-time access decisions, not lifecycle management. Exact behavior varies by implementation.

How should relationship data be kept in sync with the systems of record?

Because ReBAC decisions depend on the accuracy of the relationship graph, keeping that data consistent with authoritative sources is a core operational concern. Depending on configuration, relationships may be written directly by applications as events occur, synchronized from directories, or updated through provisioning pipelines. Note that maintaining the relationship store is separate from identity lifecycle processes such as SCIM-based provisioning or access reviews, though those processes may feed data into it. Stale or missing relationships can cause both over-permissioning and false denials, so many teams treat consistency and update latency as key design constraints.

What are the main performance considerations when adopting ReBAC?

The primary consideration is typically the cost of graph traversal, since decisions often require following chains of relationships that may be deep or branch widely. Depending on the implementation, this can involve computing whether a path exists across many nodes, which affects decision latency. Teams commonly address this with caching, denormalization, or precomputed reachability, but each approach introduces its own consistency trade-offs. Performance characteristics vary substantially by vendor and deployment, so benchmarking against your own relationship shapes and query patterns is advisable rather than relying on general assumptions.

How do you audit or explain why a subject was granted access under ReBAC?

Explainability in ReBAC generally comes from being able to show the specific relationship path that produced a decision, for example, the chain connecting a user to a resource through group membership or ownership. Whether this is exposed depends on the implementation; some systems can return the traversed path or the contributing relations, which supports both debugging and audit. This runtime explainability is distinct from governance activities such as access certification, though the same relationship data can inform those reviews. When evaluating a tool, confirm what decision-trace or path-explanation capabilities it actually provides rather than assuming they exist.

Common misconceptions

ReBAC is simply RBAC with a different name.

RBAC grants access based on roles assigned to subjects, whereas ReBAC derives access from typed relationships between subjects and resources, often traversed transitively through a graph. They are distinct access control models, and one is not universally superior to the other.

ReBAC replaces or is incompatible with attribute-based access control (ABAC).

ReBAC centers on relationships between entities while ABAC evaluates attributes of subjects, resources, and environment. Depending on the deployment they can address different needs, and some implementations combine relationship data with attribute conditions rather than treating them as mutually exclusive.

Adopting ReBAC handles user provisioning, access reviews, and certifications.

ReBAC is a runtime authorization model that determines what a principal may do; it does not by itself perform identity governance functions such as provisioning, access certification, or segregation-of-duties enforcement, which remain separate IGA concerns.

Best practices

Define your relation types and their permission implications explicitly in a schema, including which relationships confer access transitively, so that indirect access paths are intentional rather than accidental.

Model transitive and inherited relationships carefully and test path traversal, since indirect relationships can grant broader access than expected depending on how inheritance is configured.

Keep ReBAC scoped to runtime authorization decisions and integrate it with, rather than substitute it for, IGA processes such as provisioning, access reviews, and segregation of duties.

Evaluate whether ReBAC fits the specific access patterns at hand, and consider combining it with other models (such as RBAC or ABAC) where relationship data alone does not capture all authorization requirements.

Validate that your chosen implementation's relationship-query and consistency behavior meets your latency and correctness needs, since capabilities and semantics vary by product and configuration.

Audit and monitor the relationship graph over time, because stale or orphaned relationships can silently preserve access after the underlying business need has ended.