Relationship-based access control (ReBAC)
Permissions that follow relationships like owner, member, parent, or shared-with, so access can inherit through a graph.
See it
What it is
ReBAC derives permissions from relationships in a graph: a user belongs to a team, the team owns a folder, the folder contains a document, so the user may view the document. Direct shares, group membership, ownership, and parent-child inheritance become stored relationship tuples instead of columns or role checks scattered through code.
Reach for it when access follows collaboration and hierarchy, as in Google Drive, GitHub organizations, project workspaces, or nested folders. Google's Zanzibar paper made this model famous at enormous scale; systems such as SpiceDB expose the same basic check: does this subject have this permission on this resource?
The gotcha is that checking one object is only half the product. Lists must return only objects the person may see, relationship changes need clear consistency behavior, and cycles or accidental inheritance can grant surprising access. Model the graph deliberately, deny by default, and test the negative paths around nested groups and removed members.
Ask AI for it
Implement relationship-based access control with SpiceDB. Define a schema for user, team, folder, and document; model team membership, folder ownership, parent folders, direct viewer and editor shares, and document view and edit permissions. Write relationship tuples when memberships and shares change, call CheckPermission on every resource read or mutation, and use LookupResources to build filtered document lists instead of loading everything and filtering in memory. Carry organization boundaries into the schema, choose and document the consistency level for share revocation, and add tests for nested-group access, inherited folder access, removed members, cycles, and cross-organization denial.