What is ReBAC? (Relationship-Based Access Control)

You may already know about Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). While effective, these models struggle with complex user relationships and interactions in applications.

Relationship-Based Access Control (ReBAC) is a more dynamic approach, determining access based on user-resource relationships. Unlike RBAC and ABAC, ReBAC adapts to changes in these relationships, making it ideal for applications where connections significantly impact permissions. 

For example, in a social media app, access to a post might depend on how users are connected, not just their roles or attributes.

This article will explain ReBAC, its benefits, implementation challenges, real-life scenarios, and how it compares with other access models.

What is ReBAC?

Relationship-based access control (ReBAC) is an authorization model where access is granted based on how users relate to each other and to the resources within a system.

For example, a user may be granted access to a file because they are the file owner, or because they work on the same team as the file owner.

ReBAC is all about relationships. These are the connections between entities, where entities are anything with access rights, like users, files, or data records. 

Relationships can be direct, like a user being a member of a group, or more complex, involving several entities and connection types.

The rules that define access based on these relationships are called policies. A policy in ReBAC might state that "a user can edit a document if they are the project manager or if they are part of the project team directly involved with the document."

To manage access, ReBAC uses a model that might look something like this:

• Identify the entity requesting access.
• Determine the entity’s relationships to other entities and the resource in question. The most common types of relationships are owners, parent-child, and user groups. 
• Evaluate these relationships against the defined access policies to decide whether access should be granted.

ReBAC systems often rely on graph data structures to implement this model. Graphs are ideal for this because they can model entities as nodes and relationships as edges.

When a user requests access to a resource, ReBAC traverses the relationship graph to find a path between the user and the resource. This path can pass through intermediate nodes, which represent other entities or relationships that might influence access decisions. If a valid path that meets the policy criteria is found, access is granted; otherwise, it is denied. 

Suppose a policy states that an employee can access a project document if they are directly involved in the project or if they are in a department that collaborates on the project. The ReBAC system will look for paths that connect the user to the document through direct project involvement or through a departmental collaboration relationship. If such paths are found and align with the policy, access will be granted.

Benefits of using ReBAC

Flexibility

As relationships and responsibilities evolve within an organization, ReBAC policies can automatically adjust access rights. 

For example, if a user transitions from one department to another or takes on a new role in a project, their access permissions can be automatically updated to reflect these changes. 

Handles complex relationships

You can specify access based not just on a user’s static attributes but also on their dynamic relationships with other users and resources. This allows for policies like “managers can access files for employees two levels below them in the org chart” or “project members can access files for their project.” 

Additionally, ReBAC's use of graph structures enables reverse indices. This means a user (x) has access to a resource (y) and also to all entities that have access to that resource (y). 

Aligns with how an organization works

Most organizations don’t function based on static reporting structures and job roles alone. People form working relationships that cross traditional organizational chart boundaries. 

ReBAC policies can directly model these working relationships, capturing the ways people actually collaborate. This helps ensure employees have access to the resources they need to do their jobs, even as those jobs evolve.

Enhanced security

By basing access permissions on the specifics of relationships, ReBAC allows for more nuanced control. This means permissions can be tightly tailored to the exact scenario, reducing over-permissive access, which can be a significant security vulnerability.

ReBAC system's ability to adapt to changes in real-time, also ensures that access permissions are always up-to-date. This reduces the risk of unauthorized access due to outdated permissions.

Limitations of ReBAC

Complexity in policy management

ReBAC systems can become quite complex, especially in large organizations with many employees, roles, and relationships. Mapping all the connections and assigning appropriate access rights across the network requires significant effort and resources. The complexity also makes these systems difficult to audit and maintain.

Limited visibility

It can be difficult to understand all the access rights that exist in a ReBAC system at any given time. The web of relationships and permissions may span the entire organization, so no single person has a complete view. This limited visibility reduces accountability and auditability. 

You will need to have the right tools and monitoring strategies for detailed visibility.

Performance concerns

ReBAC systems often rely on sophisticated queries to graph databases to evaluate access permissions. As the number and complexity of relationships grow, these queries can become resource-intensive, potentially leading to slower response times.

When to use ReBAC

If you’re building an application where relationships between users are a core part of functionality and access often flows through those connections, ReBAC is a great access control model to consider.

For example, for tools focused on collaboration, ReBAC makes a lot of sense. Think project management software, CRMs, or team productivity apps. In these cases, access is often granted based on team membership or account associations. ReBAC allows you to model these types of relationships.

Another example is in social networks, where connections between users are the primary feature. ReBAC enables you to build an access control model based on friendships, followers, and other types of connections. For example, you might allow users to see posts from friends of friends but not beyond that. Or enable photo tagging for friends only.

ReBAC may not be the right choice if your application access is based primarily on user roles or static user attributes.

ReBAC in the real world: Practical examples

Here are some real-world examples of ReBAC in practice:

1. Enterprise content management

ReBAC can be used to manage nuanced access based on departmental roles, project needs, and external collaborations in ECM systems. 

For example, in the marketing department, current team members are automatically granted editing rights to manage and update reports. 

Meanwhile, the sales department has view-only access to finalized marketing materials, enabling them to align their sales strategies accordingly. 

Additionally, access for NDA partners is limited to specific sections of documents, strictly based on the terms of the NDA and their relationship with the organization.

2. Project management tools 

Team members have access based on their roles and project involvement. 

For instance, a project lead might have comprehensive access across all project facets, while a consultant might have limited access tailored to their contribution area.

3. Supply chain management

Access control is based on supplier relationships and data sensitivity. 

For example, access rights can be configured to allow suppliers to view and update information pertinent to their delivery schedules, inventory levels, and performance metrics without accessing competitive data. 

Additionally, for high-sensitivity data, such as proprietary product specifications or pricing strategies, access is restricted to senior management and specific individuals with a direct role in negotiations or strategic decisions.

ReBAC vs. other access control models

While ReBAC offers dynamic and relationship-based permissions, other models may be better suited for certain scenarios:

RBAC (Role-Based Access Control)

RBAC is most effective in environments where roles are well-defined and static. This model excels in settings like financial systems, where access needs to be clearly delineated based on stable roles. 

For example, accountants may need access to transaction records, while auditors require permission to review financial reports.

ABAC (Attribute-Based Access Control)

ABAC is suitable for situations where access decisions must consider multiple attributes, especially dynamic ones like location, time, varying data sensitivity levels, etc. 

For instance, an employee might access certain classified documents only from the office network but not from home.

Combining ReBAC with other access control models

In certain situations, ReBAC can complement these models by adding another layer of context based on relationships. 

For example, in a financial system governed by RBAC, ReBAC could add flexibility by allowing exceptions where employees can access documents necessary for a specific project they are temporarily assigned to, based on their project-based relationships. 

Next steps

Implementing and managing a ReBAC system demands a solid grasp of graph theory, database management, and security policy design, as well as a significant investment in engineering time — it can take months to develop a secure, fully functioning ReBAC system.

Warrant gives you a fully managed and hosted solution for building ReBAC, so you don’t have to deal with implementation complexities. With the easy-to-use APIs and SDKs, getting started is straightforward.