The Two Paths: Orchestrated RBAC and ABAC

Orchestrated RBAC and ABA

When following this use case, you need to decide which path you fall in. This decision drives how you will manage user and data metadata as well as policies, so it's a critical decision.

If you aren’t sure, you should strive for ABAC. While it may seem more complicated to get started, in the long run it will provide you powerful flexibility and scalability of policy management. In this method, you tag your users and data with facts and prescribe policies that leverage those facts to make real-time decisions.

Orchestrated RBAC puts more strain on managing access decisions outside of your access logic (Immuta) because you need all access decisions in a single attribute on the user. Because of this, it more closely resembles the role explosion problem, and if you incorrectly select this path you will end up there over time. Orchestrated RBAC is tag-orchestrated RBAC and is supported by Immuta (in fact, many organizations stick to this because of the benefits of the tag-orchestration).

Orchestrated RBAC: one-to-one

Do you have many permutations of static access with no overlap?

This method is for organizations whose access decision typically depends on a single variable:

If you have x, you have access to everything tagged y.

Furthermore, the access decision to objects tagged y never strays beyond x. In other words, there’s only ever one way to get access to objects tagged y - a 1:1 relationship. A good real-world example of orchestrated RBAC is

You must have signed data use agreement x to have access to data y.

ABAC: many-to-many

Do you have a lot of variables at play to determine access?

This method is for organizations that may have many differing x’s for access to objects y. Furthermore, x and y may actually be many different variables, such as

If you have a, b, and c you get access to objects tagged x, y, and z.

or

If you have d, you get access to objects tagged x.

Notice in this example that access to objects tagged x can happen through different decisions.

ABAC is also important when you have federated governance in play, where many different people are making policy logic decisions and that logic may stack on the same objects. A good real world example of ABAC is

you must reside in the US and be a full time employee to see data tagged US and Highly Sensitive.