Relationship-based access control

Relationship-based access control (ReBAC) grants permission from the connection between a principal and a resource. A shared-document system, customer portal, or ticketing platform can ask not merely whether someone has a role, but whether they are an owner, viewer, editor, manager of an owner, or another authorized relation. This makes access follow collaboration, delegation, ownership, and organizational structure as those relationships change. section 6.1 section 6.1.4

ReBAC represents principals, teams, and resources as nodes in a relationship graph. Static rules define which relations permit which actions; the current graph supplies the changing policy data. An authorization service evaluates a request against both, so rules can remain stable while sharing, ownership, team membership, and management relationships change over time. section 6.1.1 section 6.4

Figure 6.1 A relationship graph used by ACME Corp’s Customer Collaboration platform. Employees like Bob and Alice are linked to customer accounts through roles such as support engineer and solution architect. Access to resources such as support tickets and deployment plans is controlled by these relationships, allowing for dynamic, fine-grained authorization decisions based on who is connected to what and how.

Inspect the relationship graph to see how employee-to-account links and resource relations support fine-grained decisions for tickets and deployment plans. section 6.1

A practical ReBAC design separates durable relationship facts from the rules that interpret them:

• Model meaningful, durable relations such as owner, viewer, editor, team member, customer collaborator, and manager. section 6.1 section 6.1.5
• Define permissions as paths through those relations, including direct access and indirect access such as a manager of the resource owner. section 6.1.1
• Update relationships through sharing dialogs, project assignments, or administration tools; these changes alter future decisions without rewriting rules. section 6.1.2
• Provide graph visibility, path tracing, and auditing because a small graph change can create non-obvious access paths. section 6.1.3 section 6.1.5

ReBAC is strongest where people naturally reason about “who is connected to what and how”: shared workspaces, documents, developer portals, support tools, customer collaboration, and scoped project work. It avoids forcing every ownership or delegation variation into a new role, and lets people close to the work grant or revoke access through familiar interface actions. section 6.1.3 section 6.1.4

Relationships alone do not express transient conditions well. Time of day, device posture, geographic location, and similar runtime context should not be disguised as graph edges; attribute-based access control (ABAC) or another policy mechanism can evaluate them directly. Hybrid authorization can retain RBAC for broad responsibilities, use ReBAC for collaboration, and apply ABAC for context-sensitive constraints. section 6.1.5 section 6.3.3

Operational safety depends on relationship lifecycle management and governance. Delegated sharing improves agility but distributes policy-authoring power, so systems need well-designed relationship models, training, guardrails, simulations, and tools that explain why access was allowed. Large or densely connected graphs can make a single change difficult to audit or debug without tracing the full path. section 6.1.3 section 6.1.5

A ReBAC service can fit a standard authorization architecture: an enforcement point intercepts requests, a decision point evaluates static rules against the relationship graph, a policy information point supplies graph and identity data, and policy administration often occurs through the application UI. Systems such as OpenFGA provide a Zanzibar-inspired graph model in which typed relations and permission rules are evaluated dynamically. section 6.1.2 section 8.3