Skip to main content

Relationship-Based Access Control (ReBAC)

Relationship-Based Access Control (ReBAC) resolves authorization by examining the relationships between subjects and resources. Instead of asking "what role does this user have" or "do the request attributes satisfy this policy," ReBAC asks "is there a path in the relationship graph that connects this subject to the action it wants to take on this resource."

This page describes ReBAC as an access control model. For SecureAuth Connect's ReBAC capability and how you ship it in production, see Fine-Grained Access (FGA).

The relationship graph​

A ReBAC model is described as a schema with three kinds of elements:

  • Object types, the categories of resources and subjects in your system (for example, document, folder, team, user).
  • Relations, the ways object types can be connected (for example, a user is an owner of a document, a folder contains a document, a user is a member of a team).
  • Permissions, the actions each relation grants (for example, owner grants edit and read, member grants read).

At evaluation time, the ReBAC engine walks this graph from the subject toward the resource. If a valid path exists that grants the requested permission, access is allowed. Otherwise it is denied.

Example​

Consider a document-sharing application. The schema might define:

  • A document has an owner relation to a user.
  • A document has a viewer relation to a user or to a team#member.
  • The owner relation grants edit and read permissions.
  • The viewer relation grants read permission.

With this schema, the engine can answer "can Alice read document X" by checking whether Alice is the owner of X, a direct viewer of X, or a member of a team that has viewer access to X. The answer follows the graph.

When to use ReBAC​

Reach for ReBAC when access depends on how subjects and resources are related, rather than on their attributes or labels:

  • Document, folder, or file permissions where access inherits through container hierarchies.
  • Team membership where team access implies member access.
  • Multi-tenant SaaS where an organization's admins automatically have access to every resource in that organization.
  • Nested organizational structures with inherited permissions.

For role-driven coarse access, see Role-Based Access Control (RBAC). For context-driven or attribute-driven access, see Policy-Based Access Control (PBAC).

ReBAC and Zanzibar​

ReBAC is the conceptual model described in the Google Zanzibar paper. Zanzibar is a specific, graph-based authorization system that popularized ReBAC at scale. When a platform says it is "Zanzibar-based," it means the implementation follows the schema (object types, relations, permissions) and the graph-walk evaluation described in that paper.

ReBAC on SecureAuth Connect​

SecureAuth's ReBAC capability is called Fine-Grained Access (FGA). FGA is delivered through Permission systems and is Zanzibar-based. See the FGA page for the product capability, shipping guidance, and getting-started steps.

See also​