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.
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.
In the context of our previous example,
A `user` who is assigned the role of an `Owner` on a `folder`
Will look like this: Folder#Owner.
Role Assignment
Role Assignment refers to designating specific roles to 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.
New employees in the marketing department might be assigned the Marketing role, which provides access to relevant databases, software, and internal websites without having to configure each access permission individually.
Role Derivation
ReBAC allows us to derive authorization policies based on existing application-level relationships. Put in the simplest way, it allows us to create a policy like this:
A `user` assigned the role of `Owner` on a folder will get the `Owner` role on every `file` within that `folder`.
Creating policies based on relationships rather than roles or attributes saves us from having to create authorization policies on a per-instance basis.
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.
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.
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`.
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.
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`.
Using organizational relationships allows us to give every user editing permissions for every file, without the need to set 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 wouldn’t have to update it for every change we make.
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.
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 better visualize the policies you would need to create.
To learn how to map out and impliment ReBAC using Permit, head on to this section on Building ReBAC policies