For the last two decades, role-based access control (RBAC) has dominated the authorization landscape. While other, finer-grained authorization styles such as attribute-based access control (ABAC) have emerged, none has been able to dislodge the king of the mountain.

Things are about to change. Relationship-based access control is poised to take over the authorization crown. Here are five reasons why.

ReBAC combines the best of ACLs and RBAC

Most SaaS applications implement some form of role-based access control (RBAC) - a user has a global role in the application that brings with it a set of permissions. For example, an “editor” can create new items whereas a “viewer” cannot.

Many SaaS applications also support the notion of ownership of a resource (e.g. a list, item, candidate, report), and allow owners to “share” those resources with others, providing either a full or restricted set of permissions. For example, an owner of a document can share that document with another user, but only for the purpose of viewing or adding comments. This is often referred to as implementing an access control list (ACL) for resources.

In our conversations with customers and prospects, one very common problem they describe is that these systems are often implemented and enforced separately. Often, RBAC is enforced centrally, but each microservice implements its own form of ACL management. This leads to ambiguity and complex enforcement logic for edge cases: for example, what if a list is shared with a user with a “viewer” role? Can that user add new items on the list?

ReBAC solves this problem by unifying the concepts of RBAC and ACLs into a single model. “Roles” are defined for each type of resource, carrying a set of permissions that is specific to that resource type. Enforcement of permissions is then a simple matter of ensuring that the user is a member of a relation (role) on the specific resource. No separate global roles to check.

ReBAC provides fine-grained access while eliminating “role explosion”

The reason why RBAC has ruled the roost is that it’s simple and intuitive - a user is assigned one or more roles, and those roles confer a set of permissions.

The biggest drawback of RBAC is that as capabilities are added to an application, new permissions need to be assigned to govern their access. Those permissions either need to be added to existing roles, or new roles need to be created that incorporate them. The more permissions, the more your customers demand to be able to “remix” them into their own custom roles.

You have a tough choice to make - either stay with a small set of roles, which are over-provisioned relative to the number of permissions they confer. Or experience “role explosion,” where the number of roles becomes unmanageable, and it’s very difficult to reason about which permissions are assigned to which users.

Just look at the permissioning systems for any of the cloud providers as a cautionary tale. AWS, Azure, and GCP all provide thousands of fine-grained permissions, grouped into a much smaller set of roles. If you stay with the built-in roles, you grant far more permissions than are necessary. But if you manage these permissions individually, reasoning about what permissions are allocated to which users is a very difficult task.

ReBAC addresses this by scoping “roles” and their associated permissions to each resource type. Some composition is possible - for example, a folder’s "editors" also have edit permission on each of the documents that folder contains. But it’s much easier to reason about roles when they are scoped to a particular resource type.

For example, a hiring manager can create a new job description, and grant recruiters edit access to that job description. A recruiter can add a new candidate, and grant the hiring manager edit access to the candidate. These two “edit” permissions are scoped to their respective resource types, and therefore allow a finer-grained approach to allocating permissions than a global “editor” role, which is over-provisioned for both the hiring manager and recruiter.

ReBAC supports resource hierarchies

A very common access control pattern is that permissions that are granted on a high-level resource group (project, team, list, folder) are inherited by the items contained in those resource groups.

ReBAC supports this model naturally, by allowing a permission to be granted either through a relation that exists directly on the object instance, or through a “parent” relation. For example, the “edit” permission can be granted through the “editor” relation on a document, or through the “editor” relation on the folder that contains (or is the parent of) that document.

Customers that previously had to do this by hand had a ton of custom logic they needed to maintain, often needing to “walk up the resource hierarchy” to find out whether a user has access to a particular resource. With ReBAC, the authorization system can do the walking for you.

ReBAC easily accommodates more levels of indirection

To generalize the previous point, the evaluation model for ReBAC involves a graph-walk from the object (resource) to the subject (user). This makes it easy to expand the number of levels in your resource hierarchy without having to redesign the system.

A good example is the notion of groups. Most SaaS applications allow assigning users into groups, and then assigning roles to those groups instead of to individual users. This greatly simplifies auditing roles and permissions.

ReBAC easily accommodates this by allowing the target of a “document viewer” relation to be a group instead of an individual user. No matter how many levels of indirection exist between a user and a document, the ReBAC algorithm is the same - it is a graph-walk to find a path (which carries the right permission) between the resource and the user.

Groups can contain other groups. Lists can contain other lists. None of this requires any custom logic.

ReBAC facilitates permission discovery

Since ReBAC is built on a graph that links subjects and objects through relations, it’s possible to answer questions like “what objects does this user own” or “who can edit this resource” without having to execute the permissioning logic in the application.

This is a game-changer for admins or auditors that need to understand (or prove) that a sensitive resource is only viewable by specific users.

Indeed, it’s possible to use the relationship graph not just for enforcement, but also for visualization and reporting scenarios. You get all of this “for free” when you model your access control entirely as a graph of relationships. There are a growing set of products that focus entirely on this “permission discovery” scenario, rather than on permission enforcement.

Drawbacks of ReBAC

ReBAC is a huge step forward. But to be fair, it also has some drawbacks relative to the alternatives, most notably attribute-based access control (ABAC).

User attributes

First, not all user or resource attributes are best modeled as relations. For example, a user may have a phone number, and access control logic may want to make decisions based on whether that phone number is in the east coast or west coast. Creating a relation for this may be cumbersome relative to just writing the logic.

Another example is adding a “kill-switch” for a user in the form of an attribute that exists in an upstream system (such as the identity provider). Attribute-based access control logic can short-circuit any graph-walk by simply checking whether this attribute is turned on for a user that needs to have their access removed from everything.

Expressions

Some systems use expressions as a way to make access control decisions. For example, a user has permission to approve a purchase order up to a certain limit, governed by an expression (amount < limit). ReBAC systems aren’t good at this.

Environmental attributes

Sometimes access decisions are made based on environmental attributes, like day / time (“9am to 5pm on weekdays”), current location (“in EU”), or network segment (“on corpnet”). Creating relations that model these, and dynamically adding / removing users from them, is more trouble than it’s worth. It’s easier to add a dynamic check using an attributed-based access control system.

Combining models

Fortunately, there are some approaches that add attribute-based capabilities to ReBAC systems. The Topaz open-source project is one such system, where ReBAC is performed natively, and ABAC is handled through the Open Policy Agent (OPA).

A word of caution: the more access control logic you express using an ABAC policy, the harder it is to answer auditing questions such as “which set of users can access a resource”, since these checks are performed as part of an authorization call. For example, if you have logic that allows a user to access a resource only on weekdays, it won’t be possible to determine what set of users have access to a resource merely by walking the relationship graph.

In conclusion, ReBAC is poised to take over the crown from RBAC as the predominant authorization model for SaaS applications. And for scenarios where ReBAC isn’t enough, there are extensions that make it possible to stretch ReBAC to even the most complex and dynamic scenarios.

Tell us about your authorization model!

We’re always looking for more authorization examples. Whether your domain looks like something we’ve already described, or your problem isn’t something we’ve covered, we’d love to hear about it! Join our community slack to chat about authorization, or schedule some time with one of our engineers!