What is relationship-based access control (ReBAC)?

Relationship-based access control (ReBAC) is an authorization model (access control model) that bases access decisions on relationships between users, resources, and other entities within a system. ReBAC emerged around 2006 as a response to the limitations of other models in capturing context-sensitive access requirements in, for example, social networks. It offers a more granular and dynamic approach to managing access compared to traditional models like role-based access control (RBAC). Google’s Zanzibar is viewed as a milestone for ReBAC, demonstrating a practical implementation even at a very large scale.

This approach is particularly well-suited to complex environments where access decisions need to reflect intricate relationships, such as those in collaborative platforms or social networks. In these contexts, it is not the users’ roles that determine appropriate permissions for data as much as how they are related to the data.

As applications and systems have grown in complexity, the need for more nuanced access control mechanisms has become apparent. By leveraging relationships, ReBAC offers a flexible and scalable solution to access management, aligning with both security and business needs. To best protect themselves from insiders and external threats, organizations should aim to implement the principle of least privilege (POLP), with no extraneous permissions present for any user. ReBAC’s flexibility and ability to reference live context allow access control to be expressed more precisely.

Core concepts

ReBAC is built upon a few key concepts:

• Entities: The basic units within a system, such as authenticated subjects (users or services), resources that require protection (e.g., data, posts, APIs), and other objects. All entities on a system are one of a fixed list of entity types.
• Relationships: Defined connections between entities such as “friend,” “owner,” “member,” or “manager”; these are central to determining access permissions.
• Groups: A common and handy form of entity that is an abstraction of a group of entities. Entities are in (i.e., have relationships defined with) any number of groups, and groups can be nested. Relationships such as “member,” “contains,” and “parent” are used to represent organization, parent-child relationships (nesting), etc. Relationships are examined to determine what entities are in a group.
• Permissions: Actions such as “read,” “write,” and “delete” that can be performed on resources.
• Relationship rules: Rules that specify how relationships translate into permissions on the system. These define the conditions under which certain actions are allowed or denied. They are built on the presence or absence of relationships between entities. Note that there is no uniform way in which such policies are expressed.

(The specific terminology used for these concepts can vary.)

These concepts work together to create a flexible access control model that can express complex permissions based on the connections between entities. Here are some examples of hypothetical policies that illustrate how this can work:

• Owner has full permissions: An “owns” relationship between a user and a document means the user is granted full control over the document.
• Can edit if specified: Any user with a “can edit” relationship to a document can modify the document.
• Friends can view posts: Someone can “view” a social media post if they are a “friend” of the “owner” of the post.
• Folder read permission extends to its children: Users that are in a user-type group with “read” permission on a folder-type group can “read” any object related to that folder group as a “child.”

Example scenario

Imagine we are implementing a meal ordering system where the relationships between users, groups, and resources dictate the various permissions. This fits well with the ReBAC model, as the system involves complex relationships between organizers, participants, groups, and orders.

Scenario details

• Groups: Individuals can belong to one or more groups. These groups can be nested, such as with the “mobile app team,” which is part of the “engineering department.”
• Organizers: Anyone in the “organizers” group can initiate a new order, and those not in the group cannot.
• Participants: When creating an order, an organizer can specify who is allowed to add items to the order. This can be done by listing individual users or groups.
• Restaurants: The organizer sets the list of restaurants available for ordering for an order.
• Menus and menu items: Restaurants define a set of menus, such as “entrees,” “beverages,” and “desserts,” each containing menu items that can be added by a user to an order.
• Beverage restriction: Since the company maintains a solid stock of bulk-purchased beverages for employees, company policy prohibits users from ordering drinks from restaurants. There is an exception for organizers, though, who can order them for special occasions (e.g., ordering chai in celebration of Diwali).

Observe that in this system, access is determined not by predefined roles but by the relationships between users, groups, and resources.

Modeling scenario in ReBAC

The following is one way to map the above scenario to ReBAC:

• Entities: The entity types in our schema are:
  • Users
  • Groups of users
  • Restaurants
  • Menus
  • Menu items
  • Orders
  • Ordered items
• Initiating an order: Only those in the “organizers” group have the relationship needed to initiate an order.
• Nested groups: Users and groups can be members of groups. We use membership in groups for permission inheritance.
• Adding to an order: The order organizer defines order participants; each then has a “participant” relationship to the order. A user can add to an order if they are related to the order through a direct relationship (e.g., they are explicitly an order participant) or through an indirect relationship (e.g., they are directly or indirectly a member of a participant group). An ordered item is created and related to the order by a “contains” relationship.
• Restaurant selection: An organizer associates a set of restaurants with the order, giving the order an “item source” relationship for each. Only restaurants associated with the order can be ordered from. The lack of such a relationship means menu items at other restaurants cannot be ordered.
• Restricting beverage orders: When an item is being added to an order, the system will check if the item is from a menu called “beverages” and if the user is in the organizer group. If it is from a “beverages” menu and the user is not an organizer, this addition will be disallowed.

Figure 1: Illustration of the relationships between entity types in the meal ordering ReBAC example, using example entities and relationships. In the interest of simplicity, we focus separately on (1) users and groups, (2) restaurants and menu items, and (3) orders.

Item ordering checks

In our example, when a user tries to add a menu item to an order, checks are needed before it is added as an ordered item. These take the form of a series of ReBAC relationship-based checks. Figure 2 depicts how this might be done.

Figure 2: Flow chart for checks before user “U” is allowed to add menu item “I” to order “O” in the ReBAC example scenario. The checks cover if “U” is a participant on the order, if “I” is from a participating restaurant, and the beverage restriction policy.

Each of these checks (the questions in diamond-shaped nodes in figure 2) involves lookups against the ReBAC state, as described here. Here, we express the checks in English; general-purpose ReBAC implementations would have a specific language or interface for codifying this precisely.

• Can user U participate in order O? They can, if any of the following is true:
  • User U has a participant relationship to order O
  • User U has a member relationship to some group of users that has a participant relationship to order O
  • User U has a chain of group of users member relationships to some group of users that has a participant relationship to order O
• Can menu item I be placed on order O? It can, if the following is true:
  • Order O has an item source relationship to some restaurant that has a child relationship from some menu that has a child relationship from menu item I
• Is menu item I a beverage? It is, if the following is true:
  • Menu item I has a child relationship to a menu called “beverages”
• Is user U subject to beverage restrictions? They are, unless the following is true:
  • User U has a member relationship to the “organizers” group of users 

Extending the scenario

One can imagine wanting to refine the setup in this scenario by, for example, adding support for:

• Manager prerogative: This allows managers (in case there is a guest to the site) to add individuals to an order, assuming they themselves are invited to participate in the order.
• Closing placed orders: To reduce confusion and complexity, we can prohibit additions to orders that are already placed (or that are still being set up). This would be supported with ReBAC if, as is often the case, policies can refer to attributes on entities. Only when the order has its “state” attribute equal to “open” would participants be able to make changes to items on the order.
• Whole-site orders: We may want to have orders be open to an entire site. In the above scenario, this can be done by creating a group with everyone from the site. Users from other sites would not have a valid relationship linking the participant to the order and therefore would not be allowed to add to the order (unless they are invited to the order via a different participant relationship). The key is ensuring that the group is kept up to date. Alternatively, if we had attribute support, we could say the order is open to all users with a certain “site” attribute value.
• Order owners: To increase ordering reliability, instead of every member of the organizer group having broad permissions for all orders, each order can have a specifically assigned owner instead (having an “owner” relationship to the order). This could be the order creator by default; the current order owner might also have the ability to reassign ownership to someone else (owners might be given an “assign ownership” permission).
• Item-requester relationships: The model can be updated to include a “requester” relationship between ordered items and the person who added them to the order. This would allow us to keep track of who ordered what menu items and to allow for policies that restrict permissions on removing items from the order (e.g., to just the requester or the order owner).

How ReBAC works

ReBAC works by checking if a subject’s relationships with a resource allow them to perform a specific action. If the relationships and the system’s rules agree, the user can proceed. This dynamic approach allows for flexible, fine-grained, and context-aware access control that reflects the real-world connections between users and resources.

To use ReBAC, you need:

• To model the system and its policies in ReBAC terms:
  • First, understand the system and the set of policies that should be in place. Policies should be written down in natural language to facilitate this.
  • Next, establish a schema of entities, attributes, and relationships that will meet your needs. This might come naturally from relevant data models or database schemas.
  • Finally, formulate access control rules in terms of that schema. If the policy will be enforced by using a policy engine, such rules will need to be written in a language the policy engine understands or through equivalent user interface actions.
• Entity and relationship data to be available for policy evaluation. ReBAC requires this to be set up initially and continuously maintained to reflect the current system state. This data might already be maintained elsewhere, but must be accessible and up-to-date for accurate policy decisions. For example, adding new orders, removing users, updating user attributes, and adding new menu items necessitate entity and relationship changes to be reflected in the data fed to policy.
• Authorization (authz) checking logic to be hooked in or placed inline at any code point where a restricted action is to be performed. That logic evaluates entities, relationships, and policies to determine if the action should be allowed.
• Rejection of attempted actions whenever the authz logic determines those would be outside of policy.

Effective use cases

ReBAC excels in environments where access is based on the relationships between entities. Some common use cases include:

• Collaborative platforms: Managing access to shared documents, projects, or files based on user roles and relationships, especially those with item ownership and with delegation of permissions
• Social networks: Controlling visibility and interaction based on connections between users, such as friends or followers
• Content management systems: Regulating who can edit or publish content based on hierarchical or peer relationships
• Healthcare systems: Restricting who can access patient data, depending on the relationships between patients, doctors, and other healthcare professionals, and who can update different types of data, depending on the user’s role
• Multi-tenant applications: Defining access based on organizational or team structures within a shared environment

Advantages with ReBAC

• Scalability: Compared to flat lists of permissions, by defining relationships and policies, ReBAC reduces the need to manage individual permissions, scaling better in complex environments.
• Granularity: ReBAC offers finer-grained access control compared to RBAC by focusing on specific relationships rather than broad roles. This allows the organization to implement least-privilege more precisely without having an explosion of roles. To implement the above example scenario in RBAC, there would need to be a new order-participant type of role defined for each order (role explosion) to allow precise customization of the exact set of participating users for each order.
• Flexibility: Relationships can be tailored to reflect real-world connections. ReBAC is adaptable to complex scenarios and can adapt to changing access requirements since relationships can be dynamically created, modified, or revoked. Some of the described extensions to the example scenario do not seem feasible in RBAC.
• Support for hierarchical structures: There is natural support for situations such as nested files and folders or organizational hierarchies.
• Simple permission updates: For certain cases, such as when the owner of a resource changes or a file is added to a directory, a single simple update is all that is required to implement the change in allowed permissions. There is no need for the admin to chase down all of the exact permissions that need to be updated since that will flow from the updated relationships.
• Support for reverse lookups: There is support for looking up what subjects are allowed to take a certain action, by referencing current rules/policies and checking the relationships that are in place.

Limitations and drawbacks

While ReBAC offers significant flexibility and scalability, it also has limitations:

• Complexity:
  • Implementing and managing ReBAC can be more complex than simpler models such as RBAC due to the need to define and maintain relationships. More up-front time is required to appropriately define the schema.
  • It can be hard to reason about policies expressed in ReBAC (e.g., checking if an order organizer can ever abuse their permissions). This can make it hard to audit permissions for appropriateness.
• Performance: Evaluating policies requires current data about entities and their relationships to be fed into authz logic; doing this in real time can be relatively resource-intensive, especially in environments with many entities and relationships and when the implementation is not optimized.
• Lack of standardization: ReBAC lacks widespread standardization, so there is a learning curve when working with each different implementation.
• Limits on expressiveness: While ReBAC allows for nuanced access control, certain types of policies can not be expressed naturally, meaning additional mechanisms or models, such as Attribute-based Access Control, may be required. Extending the example scenario above:
  • To contain costs, having an automatically-enforced spending cap per-user-per-order. This requires a calculation on the attribute of the items (sum of prices). (Similar: a quota on the maximum amount of storage that can be used in a file store.)
  • Having a cut-off time for users for a particular order, after which users cannot adjust their order.
  • Disallowing orders being placed from geolocations far removed from where the food would be available.

Conclusion

Relationship-Based Access Control provides a powerful and flexible approach to managing access permissions, especially for systems where relationships between entities play a crucial role. By focusing on relationships between entities, ReBAC enables more granular and context-aware authorization decisions. Secure by Design demands that applications implement authorization to protect resources, and ReBAC provides a way to do that with good support for least privilege. While it offers significant advantages, it also introduces complexities, possible performance impacts, and some limitations that should be carefully considered before implementing this model.