Warrant has been acquired by WorkOS! 🎉 Read the official announcement for more details.

What is Relationship Based Access Control (ReBAC)?


Relationship based access control (often abbreviated as ReBAC) is a form of fine grained access control that shares elements of both role based access control (RBAC) and attribute based access control (ABAC). In ReBAC, access to objects is determined based on the relationships between subjects (typically users) and objects.

Like RBAC, ReBAC allows for easy grouping of users, subjects and objects by access level. But unlike with RBAC, hierarchies and complex, cascading rules are easier to express using ReBAC relationships. For this reason, we can think of ReBAC as being somewhere in between RBAC and ABAC in terms of authz and access control granularity.

When should you use ReBAC?

Given that ReBAC is entirely based on relationships between subjects/users and objects, it's a natural choice for modelling access control in any social, graph-based application. For example, you could use ReBAC to model the visibility of comments in a Facebook-like social application. You could define 'friendship' relationships between users and rely on those connections to determine which users can see which comments in the application.

Aside from consumer social applications, ReBAC can also be a powerful access model in B2B enterprise applications and SaaS, especially applications with user-generated content. Google Drive and Dropbox are perhaps the most popular such applications that come to mind. For example, each document in Google Docs can be modeled as an object with an 'owner', a group of 'editors' and a group of 'viewers'. Users can then, in turn, have respective 'owner', 'editor' and/or 'viewer' relationships with specific documents that then grant them certain privileges (i.e. the ability to edit the document contents). All of these relationships can be modeled and enforced via a ReBAC, graph-based access control model. And this same model can be applied to a host of other, common SaaS applications.

Challenges with ReBAC

ReBAC is a powerful but complex form of access control. Some of the key challenges with implementing and using ReBAC include:

Implementation complexity and performance

In general, ReBAC is more complicated to implement, especially when compared to a simpler access model like RBAC. In addition to supporting direct relationships, ReBAC systems need complex logic to support inherited and hierarchical relationships as well as set operations (union, intersection etc.) across multiple relationship 'sub-trees', none of which is particularly trivial to implement. Performance can then also become an issue, especially in systems with complex, nested hierarchical relationships, which might require the usage of more niche, graph databases. Google's Zanzibar is perhaps the most famous ReBAC access control service, which was implemented and iterated on over many years by a dedicated team at Google.

Managing the data model and relationships

Aside from the implementation complexity, managing the relationships between specific users/subjects and objects in a ReBAC system is also not easy, especially in systems where data is changing quickly (ex. systems with user generated content). There are typically 2 modes of operation: either the ReBAC system is the 'data source of truth' and stores all object and user data (including relationships) or the ReBAC system must store the relationships between objects and thus needs to be kept in sync with the data store(s) storing the users/subjects and object data. Neither option comes without tradeoffs. Option 1 is typically not feasible because the ReBAC system often lacks certain database features (ex. when compared to a SQL db). Option 2 is more flexible but keeping data in sync requires complex logic to handle inconsistencies, failures and retries. As such, there's no clear option, and so the choice comes down to the product and application requirements.

Implementing ReBAC

As mentioned above, implementing a ReBAC system from scratch is no easy task. Google's Zanzibar paper goes into more detail about their approach, including the tradeoffs, challenges and implementation details. There are also now quite a few Zanzibar-based open source ReBAC services including Warrant that can serve as good starting points for implementing ReBAC.

For those looking for a fully managed and hosted option, using a 3rd party service or vendor might be a better option. Warrant is one such service that offers Zanzibar-like ReBAC as part of its core, distributed authz offering.

Build Authorization with Warrant

Warrant is a developer platform for implementing authorization in both customer-facing and internal applications. Build robust RBAC, ABAC, and ReBAC for your company or product with Warrant's easy-to-use API and SDKs.

Start Building