# The Two Paths: Orchestrated RBAC and ABAC

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](#abac-many-to-many). 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](#orchestrated-rbac-one-to-one) 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.`


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.immuta.com/latest/governance/getting-started-with-secure/automate-data-access-control-decisions/the-two-paths.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.