What is relationship-based access control?

Relationship-based access control grants access when a chain of relationships connects a person to a resource. A typical chain runs from a person to a team, from the team to a folder it owns, and from the folder to a document. The relationships are data, stored beside the records they protect, and every check is a question about that data.

Its two neighbors ask different questions. Role-based access control (RBAC) asks which role a person holds. Attribute-based access control (ABAC) asks whether the attributes of the person, the resource and the moment satisfy a policy. An Auth0 article puts the ReBAC version in one line: “Instead of asking, "What role does this user have?" ReBAC asks, "How is this user related to this resource?".”

This article is about how that check works and where it fits. Where in a search or an assistant the check belongs is covered in What is permission-aware retrieval?.

NIST’s guide to ABAC describes RBAC as pre-defined roles that carry privileges, to which people are assigned. Roles made central access management possible, and they still fit coarse questions: who may sign in, who may administer. They fit records badly. The role “mechanic” either reads every maintenance log or none. Narrowing it means a role per base, per fleet, per customer, which the same guide names role explosion.

ABAC evaluates a policy over attributes at the moment of the request: the person’s department, the record’s classification, the time of day, the device. It handles conditions well. It needs every attribute defined the same way in every system, and it does not follow links: the fact that a log belongs to an aircraft serviced at your base is a relationship, not an attribute of you.

ReBAC stores that link. The OWASP Authorization Cheat Sheet recommends preferring ABAC and ReBAC over RBAC for application development. It notes that ReBAC permits permissions on individual objects, not only on roles. The models also combine: a role can be one more relationship, and a condition such as the time of day can sit on top of a relationship check.

The reference design is Zanzibar, the authorization system Google described at USENIX in 2019. Its paper reports that it serves Calendar, Cloud, Drive, Maps, Photos and YouTube. It stores each permission as a relation tuple: user U has relation R to object O. A check takes one form: “does user U have relation R to object O?”

Two ideas in the paper explain why ReBAC stays compact. Groups are objects too, so a group can be a member of another group, and a check may follow a chain of nested memberships. And rewrite rules derive one relation from another: every editor of a document is also a viewer, and every viewer of a folder is a viewer of the documents in it. One tuple on a folder then covers every document filed under it, with no row per document.

The paper also ties access to search. It describes listing everyone who can reach an object so that a search index for access-controlled content can be built from that list. The permissions an index needs are the same relationships the checks walk.

Source systems already think in relationships. A SharePoint site has members, a Jira project has roles, a ticket belongs to a support group, a document sits in a folder. ReBAC can take those relationships as they are, instead of mapping each one onto a role someone invents and then maintains.

Changes stay small. When a mechanic moves from line maintenance to quality, one membership edge goes and one arrives. Every record reachable through the old team drops out at the next check, and every record of the new team comes in. No record is touched, and nothing is relabeled.

• Deep walks on every request. A check that follows nested groups for every record of a search is slow. Systems compute a person’s full group set once and reuse it, or store the allowed groups with each record in the index.
• Relationships that are stale. A check is only as current as the edges it reads. A membership synced once a night grants a night of access after someone leaves a team.
• Conditions forced into edges. The time of day or the device a person uses is not a relationship. Model those as a policy on top of the relationship check, not as edges.
• Everything public. A folder shared with the whole company is a relationship too, and every check honors it.
• A path that skips the check. Code that reads data in a system context, without the person’s identity, sees everything. One such call in a user-facing feature is enough to leak.

Six questions, asked of a real record and two real people:

1. Where do the relationships come from: the source systems, the identity provider, or a second list someone keeps by hand?
2. Can the system explain a decision, showing the chain from the record to the person?
3. Does it answer the reverse question too: who can open this record?
4. Are nested groups followed, and to what depth?
5. How long does a removed membership take to reach the check?
6. Does the same check cover search, a record fetched by id, counts, single fields and an assistant’s tools?

In Curiosity Studio permissions are edges in the same graph as the data, as the access control model describes. Users and teams are nodes. Membership is a pair of edges, and ownership another pair, from a record to the user or team that owns it. A check walks ownership outward from the record and asks whether it reaches the person, directly or through teams nested to any depth.

The engine computes each user’s full set of teams once and caches it, and drops the cache when a team changes. Connectors write the ownership edges together with the records, so access is synced from the source systems. Teams can also be mapped from your identity provider’s groups, refreshed at each sign in. Node types, single fields, endpoints, AI tools and assistants can each be restricted to teams.

Access is checked per record at query time, by the graph engine and by search, as the permission model architecture sets out. Custom endpoints call the same check through the user context variants. The Access Debugger draws the chain that gives a user access to a node. The security page and the Trust Center have the rest.