Your Guide to Relationship-Based Access Control (ReBAC)
Share
Managing authorization and access control for various stakeholders in growing organizations is complex. Using roles to govern access can work in many scenarios, but it gets unwieldy as organizations run into some common challenges:
The roles are generic and don’t accurately reflect the nuances of how users and resources interact in the “real world”.
The roles are restrictive and need to be endlessly cloned and repurposed to account for all possible scenarios.
This results in developers and IT teams running on the hamster wheel of creating new roles, updating roles, and handling edge cases – all in an attempt to strike a balance between “not leaving things too open” and “not closing things too much.” Not fun.
Enter ReBAC.
In this article, we will explain the basics of ReBAC, share an example of how it works, and outline benefits and drawbacks of using this authorization approach.
What is ReBAC?
Relationship-Based Access Control (ReBAC) is an authorization model that helps organizations assign permissions based on the relationships between different entities. Entities can be anything in an organizational context – users, tenants, devices, or abstract entities like teams or groups. Most commonly, ReBAC refers to relationships between resources and identities (or users).
It’s helpful to visualize ReBAC as a graph, with each node (or vertex) representing a resource or a user, and each edge (or links between vertices) representing a relationship.
If we look at ReBAC alongside the other two common authorization models – RBAC and ABAC – it falls somewhere in between the other two in terms of flexibility and ease of implementation. Role-Based Access Control is relatively easy to set up but can also be restrictive. Attribute-Based Access Control is very flexible but needs a lot of effort to get right.
The diagram below is both literally and conceptually true. Broadly speaking, roles are a type of relationship, and roles and relationships are both a type of attribute.
How long has ReBAC been around?
ReBAC was defined as a term back in 2006 and has been around for a while. However, Google’s Zanzibar system is widely considered the progenitor of modern Relationship-Based Access Control. Google uses this authorization model to implement access control for its various apps like Calendar, Cloud, Drive, Maps, Photos, and YouTube.
Common relationship types
Relationships can be assigned between any two entities in a ReBAC implementation, but there are a few common relationship paradigms in use.
Parent-child relationship
A parent-child relationship is meant for nesting of entities under other entities. A common example of this is any online drive, where “folders” and the “files” within have a parent-child relationship.
The idea behind this relationship is to grant permissions en masse – any permissions assigned to a user based on their relationship with the folder automatically transfer over to all the files within that folder.
Think of the alternative: Assigning permissions individually per user and resource can become cumbersome and leave gaps. Defining parent-child hierarchical structures streamlines this process.
Ownership
This relationship assigns permissions to a resource based on whether the user “owns” that resource. A common example of this is social media posts, where the person who created a post has permissions to edit and delete them, but not to edit or delete posts that other people have created.
Taking the same online drive analogy, people that create a folder can add others to the folder and share it (assuming the folder isn’t in another folder with access control rules that supersede the ownership relationship).
Groups and organizations
Within ReBAC, organizations can assign permissions to groups of users rather than managing individual roles that can lead to sprawl. A common example of this is giving all users on the customer success team permissions to view customer data, or giving all users on the digital marketing team permissions to access company social media accounts.
A group relationship works in a similar manner to a parent-child relationship, but instead of resources nested under other resources, this relationship has users nested under groups.
How does ReBAC work?
A full ReBAC implementation walkthrough is outside the scope of this article. We will use this section to describe a general process you can take to start with ReBAC and share an example.
To see how to add ReBAC to your app with Descope, check out our documentation.
Here are some generalized steps you can follow to get started with ReBAC:
Map out your desired entities and policies: Before touching console or code, visually map out the entities of interest in your ReBAC implementation, how they relate to one another, and what are the major policies you’d like to get started with.
Define and implement your schema: A schema usually contains elements such as namespaces (top-level entities in your organization), relation definitions (defining the relationships between namespaces), and relations (the actual relationships between entities).
Create and check your relations: Once you’ve defined your namespaces and relations, you can start creating and checking actual relations between resources and identities. This can include any derived relations like parent-child or group-based relationships.
Audit and monitor: The granular and recursive nature of ReBAC makes it tricky to audit, so be sure to have a process in mind to continually monitor your system once it’s live to take care of edge cases and unintended access.
An example with Dolrr
Let’s look at a ReBAC implementation in action using an example. Here’s the context:
Dolrr is a fictional B2B SaaS company that helps sellers sell better by doing something or the other. Sellers can create and send message sequences to their prospects and manage their quotas from within this product.
Emile and Reiss are two sellers that use Dolrr as part of their organization. They are part of the same Dolrr tenant.
In ReBAC implementations, we can define roles per resource. Here are the role details per resource for this example:
Dolrr Tenant: Admin (can view, edit, assign users, unassign users), Member (can view)
User Profile: Owner (can view and edit), Manager (can view).
Sales Sequences: Owner (can view and edit), Manager (can view).
Quota Management: Owner (can view and edit), Manager (can view).
Let’s dig deeper into what’s happening here:
Emile has an Admin role and Reiss has a Member role for the Dolrr Tenant.
There are two User Profile resources that belong to the same Dolrr Tenant. Emile and Reiss are both Owners of their respective User Profiles.
Emile is assigned a Manager role to Reiss’s User Profile.
Each User Profile resource is a parent to two resources – Sales Sequences and Quota Management.
Here’s how roles and permissions will derive from this setup for all resources:
Reiss will have a Member role on Emile’s User Profile resource, derived from his Member role assignment on the Dolrr Tenant. This will allow Reiss to view Emile’s profile details.
Reiss and Emile are both Owners of their respective Sales Sequences and Quota Management resources, derived from their Owner role assignment on their User Profile resources. This will allow Emile and Reiss to view and edit the details on their own user profiles.
Emile will have a Manager role for Reiss’ Sales Sequences and Quota Management resources, derived from his Manager role on Reiss’s User Profile resource. This will allow Emile to view Reiss’s sales sequence and quota management details.
Benefits and drawbacks
Now that you have a basic understanding of ReBAC mechanisms, let’s look at some benefits and drawbacks of using this authorization approach.
ReBAC benefits
Aligns better with the real world: Organizations are more than just a collection of roles. ReBAC lets you define nested relationships, hierarchies, and other types of connections between entities, which better captures how these elements interact in real life.
Enables fine-grained authorization: ReBAC helps organizations assign or revoke access to assets based on multiple conditions for that resource (e.g. who is the owner, which groups have access, how is the resource linked to other resources). This enables IT teams and developers to have more control on their authorization systems so that it’s not too restrictive or too permissive.
Avoids RBAC sprawl: Many organizations will use RBAC and ReBAC together. As needs evolve, adding ReBAC functionality prevents RBAC role explosion (i.e. cloning and adding new roles for every new use case) which can become impossible to maintain.
ReBAC drawbacks
There is no “easy and quick” authorization model: Setting up access control systems is time-consuming, full stop. Proper implementation of ReBAC needs thought and consideration, especially during the initial period of schema and relationship definitions.
May require considerable compute: The more resources, identities, and relationships your ReBAC model has, the more processing time and power it will take.
Not a substitute for ABAC: While ReBAC provides much more flexibility than RBAC, it falls short of letting organizations define permissions based on attributes such as time, location, and other dynamic elements.
Fine-grained authorization with Descope
Relationship-Based Access Control helps organizations assign permissions and access in a flexible and granular manner to meet the needs of their various stakeholders. However, implementing and maintaining ReBAC authorization models – especially in combination with other models like RBAC and ABAC – can become laborious for developers and IT teams.
Descope can help. Our no / low code CIAM platform helps organizations add authentication, authorization, and identity management to their apps using drag-and-drop workflows. Descope offers full ReBAC support through our SDKs and APIs, enabling you to define and manage permissions based on relationships in your application.
Sign up for a Free Forever account to get started with Descope. Have questions about ReBAC or our platform? Book time with our auth experts.
