What is ReBAC?

Relationship Based Access Control (ReBAC) is a policy model focused on the way resources and identities (aka users) are connected to each other and between themselves.

Policy as Graph

Extending on RBAC, ReBAC considers the relationships between identities and resources, allowing us to create authorization policies for hierarchical structures. It is easiest to visualize ReBAC as a graph, with each node on the graph representing a resource or identity, and each edge representing a relationship.

Graph-based authorization systems are perfect for mapping hierarchies and nested relationships. Given their ability to manage high volumes of data while maintaining consistency, these systems prove effective in large-scale environments.

Example

The simplest example for ReBAC is a shared file system (e.g. Google Drive). This graph displays a folder titled Bob’s Files. Within that folder, there are two additional folders - Bob’s Docs and Bob’s Pics. Inside each of these folders are several files.

To understand how ReBAC helps us manage access to these files, we need to understand a couple of basic terms:

Resource Roles

To create ReBAC policies, we need to create roles specific to a given resource. This means that the role and the permissions it carries are only relevant in the context of that specific resource. A resource role is formatted as Resource#Role.

The combination of Resource Roles and Role Derivations allows us to derive much more complex and granular roles that are perfectly tailored to handle hierarchies.

Example

In the context of our previous example,

A `user` who is assigned the role of an `Owner` on a `folder`

It will look like this: Folder#Owner.

Role Assignment

Role Assignment refers to designating specific roles for individual users or entities, effectively granting them the permissions associated with those roles. Roles represent a collection of permissions. By assigning a user a particular role, you're essentially giving them access to all the permissions bundled within that role. This mechanism simplifies access management, especially in large systems or organizations, as administrators only need to manage roles rather than each specific permission for every user.

ReBAC role assignment is different from RBAC role assignment because it is assigned to a specific instance and not to the whole resource type scope.

Role Derivation

The ReBAC role derivation functionality allows a user to be granted implicit permissions without an explicit role assignment to an instance.

There are two steps to achieve such an implicit grant of permissions:

1. Configure a derivation between two roles in our system.

   Example

   A user with a role Admin on a Folder resource will also get an implicit assignment of an Editor to all the File resource instances related to that folder.

2. When a relationship tuple is created between resources, a user with an explicit grant to one resource will implicitly gain permissions to any resources it has a relationship with.

   Example

   A user with an assignment of an Admin role to a Documents folder will implicitly get the role Editor on file finance.doc if the Documents instance of a resource Folder has a relationship with the instance finance.doc of type File

With role derivations, implicit permission is granted to users based on the relationship data in the system without an explicit condition for every object on the system.

Role derivation is the building block of ReBAC that leverages the relationships between instances to define relationship-based permissions.

Relationship Tuples

Relationship Tuples are structured sets that detail the relationships between resources and, potentially, users in the system. They represent the relationships between two specific instances of resources, providing a clear way to express and evaluate relationships in access control decisions.

Example

Using a healthcare example, a Relationship Tuple might be represented as:

`Patient` `John Smith` `Medical Record` **treated by** `Doctor` `Jane Doe`

This tuple indicates that Doctor Jane Doe has a treated by relationship with John Smith's medical record. Whenever Jane tries to access the record, the system would evaluate such tuples to determine if she has the necessary relationship-based permissions.

Relationships are at the core of ReBAC. Here are some of the most common relationship types and how they can be leveraged by ReBAC -

Common Relationship Types

Parent-Child Hierarchies

A parent-child hierarchy describes the nesting of resources under other resources. This scenario is similar to what we know from computer file systems, with files being categorized under folders. Parent-child hierarchies are not limited in their number of hierarchy levels.

Example

Such a relationship allows us to derive roles based on the relationship between two resources, like in the previous example: The ReBAC policy for this graph will look like this:

A `user` assigned the role `Folder#Owner` will also be assigned the `File#Owner` when the `Folder instance` is `Parent` of `File instance`.

Creating Hirarchies

In simpler words, if a file resides inside a folder (That’s the Parent-Child relationship), and a user is assigned the owner of that folder, they will also be the owner of the files.

Organizations

An organizational relationship allows us to create policies based on groups of users. Putting several users in one group allows us to derive policies based on their group membership instead of per individual user.

Example

Take a look at this example: Bob, Sam, and Linda are all part of the HR team. We want to grant them editing access to all files the employee data files. Instead of assigning each of them direct editor access to each file, we group them all under the HR Team. This is done via a policy like -

A `user` assigned the role `HR_Group#Member` will also be assigned the `Legal_Docs#Editor` when `HR_Group` is `Parent` of `Legal_Docs`.

The benefit of organizational relationships

Using organizational relationships allows us to give every user editing permissions for every file without setting an explicit direct relationship between each user and each file. If we decide to add members or resources to the group, the policy's logic remains valid, and we don’t have to update it for every change.

Implementing ReBAC

Permit allows you to implement a ReBAC model into any application by using a simple SDK and a low-code UI. You can see a working example of this healthcare demo application modeled using Permit in this GitHub repo.

Where to start?

The first step to understanding how ReBAC should be implemented into your application is to visually map out the resources you want to manage access to via relationships. This can be done by putting all of your resources (as nodes) and the relationships between them (as edges) on a graph. This should allow you to visualize the policies you need to create better.

To learn how to map out and implement ReBAC using Permit, head on to this section on Building ReBAC policies