Skip to main content

← Back to glossary

Term · 2. Authentication & Authorization

Relationship-Based Access Control ReBAC

Relationship-based access control (ReBAC) grants access based on relationships between subjects and resources — a user can edit a document if they own the folder it lives in. Popularized by Google's Zanzibar model, ReBAC excels at hierarchical and shared-resource permissions in collaboration, social and SaaS products. It answers whether a user is related to an object in a way that permits the action, rather than checking roles or attributes alone.

IDM/IGA Domain

Definition

Authorization model where access decisions are derived from relationships between subjects and objects in a graph (e.g. "owner of", "member of team that manages", "manager of"). Popularised by Google Zanzibar and implementations such as OpenFGA / SpiceDB. Complements RBAC, ABAC, and PBAC — well suited to fine-grained, hierarchical and ownership-based permissions in modern applications.

Application
midPoint: relationship-derived authorization can be expressed in midPoint via object references and mapping expressions, complementing the primary RBAC model.
Sources
FAQ

Frequently asked questions

What is ReBAC best for?

ReBAC fits products with nested ownership and sharing — documents, folders, repositories, org hierarchies — where permissions flow along relationships. It is the model behind Drive-style sharing and is implemented by systems like OpenFGA and SpiceDB.

ReBAC vs RBAC vs ABAC?

RBAC uses roles, ABAC uses attribute rules, ReBAC uses graph relationships. They overlap: ReBAC can be seen as ABAC where the key attribute is a relationship. Choose ReBAC when who is connected to what is the natural way to express access.

What is Google Zanzibar?

Zanzibar is Google's global authorization system that stores relationships as tuples and answers permission checks at scale. Its published design inspired open-source ReBAC engines such as OpenFGA, SpiceDB and Ory Keto.