ReBAC is an authorization model that assigns permissions based on relations between resources. Relations include data ownership, parent-child relationships, groups, and hierarchies. Google Zanzibar, the authorization system for Drive, YouTube, and other Google services, is most commonly associated with this authorization model.
ReBAC allows organizations to model their application’s resource hierarchy so that the authorization model matches it. Most B2B apps have tenants or organizations at the top of their resource hierarchy, followed other object types, such as teams, projects, lists, folders, and even individual items. ReBAC allows organizations to restrict access at any level of the hierarchy and apply the principle of least privilege using fine-grained access control.
To build relationship-based access control, developers need to describe a relationship graph between subjects (users/groups) and objects (teams, projects, lists, folders, individual items) in their system. Once done, the authorization policy will check whether a particular type of relationship exists for any user or resource and determine which permissions are granted based on that information.
In the RBAC example, we looked at a wiki system. Now let's look at a hierarchical document storage system where permissions need to be fine-grained down to the level of files and folders. We can define different object types like
document. Next we can define relations between documents and users, such as
viewer, as well as a
parent relation between documents and folders. Finally we can define permissions that are granted based on relations being present.
As an example, we can say that users that have the
owner relation on a
folder are granted the
can_read permission; and
owners of the
folder are granted the
parent is a special relation that inherits the
can_write permissions from the parent folder.
Here is a table showing the objects, relations, and granted permissions.
Notice in the table the power of ReBAC. We're able to define permissions in a very fine-grained way, and we can have them flow down the hierarchy.
Pros and Cons
The table below indicates the pros and cons of using a ReBAC model:
|Allows very fine-grained access control down to an individual resource||Requires managing the relationships|
|Very flexible||Can be difficult to scale due to storage requirements|
|Aligns with the organization hierarchy||Can run into consistency issues between the system of record and the authorization system|