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.
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.
ReBAC is a powerful but complex form of access control. Some of the key challenges with implementing and using ReBAC include:
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.
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.
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.