What is ReBAC? Relationship-Based Access Control with Examples

What is ReBAC?

Relationship-based access control (ReBAC) decides access from relationships between users and resources: alice is the owner of a document, bob is a viewer of it, the document is in a folder, the folder belongs to a team. Rules are written once per type of relationship, for example "owners may edit, viewers may read", and every user gets access through the relationships recorded for them.

Typical questions ReBAC answers:

• Is the user the owner of the resource?
• Is the user a member of the project that owns the resource?
• Does the resource belong to a type the user has access to?

It fits applications where sharing is part of the product: document and file sharing, collaboration tools, project trackers, social networks and multi-tenant SaaS.

ReBAC and Google Zanzibar

ReBAC became widely known through Google's paper on Zanzibar (USENIX ATC 2019), the system behind sharing in Google Drive, Calendar and other services. Zanzibar stores relationships as tuples of object, relation and user, such as doc:design.md#viewer@user:bob. Open-source services such as OpenFGA and SpiceDB follow the same design. In Casbin the same fact is one policy row, g, bob, design.md, viewer, and the model's matcher says what each relation allows.

ReBAC vs RBAC vs ABAC

	Access comes from	Example rule
RBAC	The user's role, the same for every resource	editors may edit documents
ReBAC	The user's relationship to this particular resource	the owner of a document may edit it
ABAC	Attributes of the user, resource and environment	people in the document's department may read it during business hours

RBAC with a role per resource ("alice is editor of doc1") is already a simple form of ReBAC, which is how Casbin models it below. Choosing an access control model works through one example in every model and compares them side by side.

ReBAC in Casbin

Casbin models ReBAC with:

• User–resource–role relationships: “user U has role R on resource O” (e.g. alice is collaborator on doc1).
• Resource–type relationships: “resource O is of type T” (e.g. doc1 is of type doc).

Permissions are then “role R can do action A on type T”; a user gets permission if they have R on a resource that is of type T. Example model:

[request_definition]
r = sub, obj, act

[policy_definition]
p = role, obj_type, act

[role_definition]
g = _, _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, r.obj, p.role) && g2(r.obj, p.obj_type) && r.act == p.act

# Permission definition: The "collaborator" role can read files of type "doc"
p, collaborator, doc, read

# User-Resource-Role Relationship: alice is a collaborator of doc1
g, alice, doc1, collaborator

# Resource-Type Relationship: doc1 is of type "doc"
g2, doc1, doc

So: the user must have the right role on the resource and the resource must match the type in the permission rule. Casbin combines g (user–resource–role), g2 (resource–type), and p (role–type–action) to decide access.

FAQ

Do I need a Zanzibar-style service to use ReBAC? No. If relationships fit in your application's database and checks happen inside your service, a library such as Casbin is enough. A dedicated service makes sense when many services must share one relationship store; see Casbin vs. OpenFGA.

Can I try this model without writing code? Yes. Choose the ReBAC example in the online editor.