Fine-Grained Authorization & ReBAC
Fine-grained authorization decides whether a specific subject may perform a specific action on a specific object, often using relationships among users, groups, folders, documents, and organisations. ReBAC is the graph-shaped model behind this: permissions are inferred from edges such as owner, viewer, member, or parent, rather than from broad application roles.
The problem appears when access is not uniform across a product. A user may edit one document, only view another, inherit access through a folder, and gain access through a group. A simple role or permissions column can answer coarse questions, but it struggles when sharing, inheritance, revocation, auditing, and cross-service reuse all need to agree on the same answer.
In ReBAC, the system stores relationship facts and evaluates them against a schema. The facts might say that a user is a viewer of a document, a document belongs to a folder, and a group contains a user. The schema defines which relationships imply each permission. A check asks whether the graph contains a valid path from the subject to the object for the requested action.
A Zanzibar-derived system makes that graph query an infrastructure service rather than scattered application code. Services write relationship tuples when sharing settings, group membership, or object hierarchy changes. At request time, they ask a central authorisation service whether a subject can act on an object. The service handles indirect membership, inherited access, caching, and consistency concerns that become difficult to reproduce correctly in each product service.
The trade-off is modelling and operational complexity. You must design relationship types carefully, migrate existing permissions, keep relationship writes in sync with product state, and reason about consistency when access changes. ReBAC is also not a replacement for every policy need. Attribute checks, legal constraints, or risk signals may still belong in a policy layer around the relationship check.
Engineers meet fine-grained authorization in document sharing, project management, messaging, multi-tenant SaaS, internal tools, and organisation hierarchies. The application code usually ends up with a call shaped like: can this user perform this action on this resource? The important difference is that the answer comes from explicit relationships, not from duplicating permission logic across tables, endpoints, and background jobs.
Common questions
- How is ReBAC different from RBAC?
- RBAC assigns permissions through roles such as admin, member, or editor. ReBAC assigns or derives permissions from a subject’s relationship to a particular object. The same person can be an owner of one file, a viewer of another, and unrelated to a third. That object-specific connection is the core difference.
- Why not store allowed users directly on each row?
- That works for very simple cases, but it duplicates derived state. If access comes from parent folders, groups, organisation membership, or shared links, every change must fan out correctly to affected rows. ReBAC stores the underlying relationships instead, then computes whether those relationships imply the requested permission.
- Does ReBAC replace application-level authorization code?
- Not completely. It centralises the hard permission graph and gives application code a clean check, but the application still decides where checks are required, how relationship changes are written, and how non-relationship rules are combined. The honest answer is that ReBAC moves the core model out of scattered business logic, not out of the system entirely.