Authorization becomes difficult when access depends on more than a job title. Relationship-based access control (ReBAC) decides whether to allow an action by examining how a user, group, project, or resource is connected to the target. section 17.0 section 17.1.3
An entity is anything that can participate in access control, such as a user, group, document, team, or project. A relationship describes its connection to another entity, such as membership, ownership, responsibility, or sharing. section 17.1.3
ReBAC asks questions such as:
- Does this user own the document? section 17.1.3
- Was the document shared with this user? section 17.1.3
- Does the user belong to a team or project that owns the resource? section 17.1.3
- Is the user responsible for the person or resource involved? section 17.1.3
Shared document access
A document-sharing service should not grant access merely because someone has a general viewer role. It can allow viewing when the user owns the document, received an explicit share, or belongs to a team that owns it. The policy therefore follows the document's relationship graph rather than a static role. section 17.1.3
ReBAC is especially useful for:
- Collaborative features such as shared files, boards, and tasks. section 17.1.3
- Multitenant applications where customers must see only their own data. section 17.1.3
- Organizational hierarchies, such as managers viewing direct reports' reports. section 17.1.3
- Delegation, project-based access, and explicit dynamic sharing. section 17.1.3
In a monolith, relationship data can be loaded locally and checked where the action occurs. In distributed systems, services commonly synchronize ownerships, memberships, and associations to a central relationship store or query an authorization service. section 17.2.1 section 17.2.2
The flexibility has costs. Relationship graphs can become complex, graph traversal or relationship lookups may affect performance, and an unavailable central store can block access checks across otherwise healthy services. High availability and carefully defined relationships are essential. section 17.1.3
