# Understanding Access Provisioning and Underlying Policies

One of the key benefits of using Immuta is that access provisioning is automatic: if you're approved for access, Immuta is able to automatically provision the access to the data sources in the access request natively in the data platform(s) using existing Govern app capabilities.

Furthermore, how that provisioning occurs avoids leaking implementation details by not exposing roles to data consumers at all. Data consumers request access to data products or assets, not roles, and Immuta calculates the most efficient policy within the data platform to represent that access, on demand, invisibly to the user. This is done by leveraging the [Immuta attribute-based access control (ABAC) logic](https://www.immuta.com/blog/what-is-abac-attribute-based-access-control-101/) that Immuta has perfected since its inception.

Below are the actions Immuta takes in order to provision access:

## Before any access requests are made

Immuta creates two [grant subscription policies](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies#grant-subscription-policy) that are on standby, ready to service access approvals. With just these policies, all access requests can be provisioned:

* [**Leaf assets policy**](#user-content-fn-1)[^1]: Allow users to subscribe when `@hasTagAsAttribute('Immuta Marketplace', 'dataSource')` on data sources tagged `Immuta Marketplace Data Product` or `Immuta Marketplace Data Object`
* [**Parent assets policy**](#user-content-fn-2)[^2]: Automatically grant users read access when `@hasTagAsAttribute('Immuta Marketplace Infrastructure', 'dataSource')` on all data sources

These policies are protected and cannot be altered or deleted.

## When a data product is published

Each data source in the data product is automatically tagged with the following tag, which cannot be removed except by un-publishing or deleting the data product:

`Immuta Marketplace Data Product.{data product ID}`

The `Immuta Marketplace Data Product` tag is protected and cannot be applied to other data sources manually.

## When a data source is created through connections

Immuta automatically applies [connection tags](https://documentation.immuta.com/saas/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/connections-overview#connection-tags) to all data sources created through connections. Those connection tags are what are leveraged by the parent assets policy, ensuring future grants can be accounted for.

For example, if you have the following in Snowflake registered as the **Snowflake Prod** connection, connection tags would be applied to them all:

| Data object          | Object type | Connection tag                                                            |
| -------------------- | ----------- | ------------------------------------------------------------------------- |
| customer\_orders\_db | Database    | `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db`          |
| december             | Schema      | `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db.december` |
| order\_1             | Table       | `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db.december` |
| order\_2             | Table       | `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db.december` |
| order\_3             | Table       | `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db.december` |

Any future tables in the `december` schema would also get the `Immuta Connections.Snowflake.Snowflake Prod.customer_orders_db.december` tag.

## When a user's access request is approved

The user that was approved access has the below attributes added to them depending on the request type. These attributes can only be removed by revoking access:

* **Data product access**:
  * Key: `Immuta Marketplace`
  * Value: `Immuta Marketplace Data Product.{data product ID}`
* **Leaf asset access**:
  * Key: `Immuta Marketplace`
  * Value: `Immuta Marketplace Data Object.{asset ID}`
  * Additionally, the data source in question is tagged with `Immuta Marketplace Data Object.{asset ID}`
* **Parent asset access**:
  * Key: `Immuta Marketplace Infrastructure`
  * Value: `Immuta Connections.{technology}.{connection key}.{parent}.{parent}.etc`
    * Schema example: `Immuta Connections.{technology}.{connection key}.{database}.{schema}`
    * Database example: `Immuta Connections.{technology}.{connection key}.{database}`

The attribute keys `Immuta Marketplace` and `Immuta Marketplace Infrastructure` are reserved and cannot be applied to users manually, nor can additional values be manually added to that attribute key.

That simple step of Immuta automatically adding that attribute to the user upon approval will trigger Immuta to provision the access in the remote data platform(s) per the policy.

If you would like to understand how the policy is translated into an actual set of grants in your data platform, review the [integration documentation](https://documentation.immuta.com/saas/configuration/integrations/integrations-overview) for the specific data platform.

## Understanding the leaf asset policy

Let's break the policy down step by step:

> Allow users to subscribe when `@hasTagAsAttribute('Immuta Marketplace', 'dataSource')`

What this policy is saying is that it will check the user's attributes under the key `Immuta Marketplace` and see if anything under that key matches a tag on the data source.

Using a real example, let's say our data product ID is `cm4bn6jpi0018wvprctnj5er2` and user `Taylor` was approved access to it:

* Each data source in the data product would be tagged: `Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2`
* `Taylor` would be given the attribute **value** `Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2` under the attribute **key** `Immuta Marketplace`. There could already be several other values (the values are an array) under that `Data Product` key providing Taylor access to other data products.

As you can see, at least one of Taylor's attribute values (`Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2`) under attribute key `Immuta Marketplace` matches the tag on the data source (`Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2`), so Taylor will be provisioned access by Immuta as soon as that attribute is attached to Taylor (or the tag is attached to the data source, as long as they both match, access is automatically provisioned). This is ABAC.

However, there are two additional pieces worth understanding:

1. `On data sources tagged Immuta Marketplace Data Product` or `Immuta Marketplace Data Object` means that this policy will only apply on data sources with the `On data sources tagged Immuta Marketplace Data Product` tag or the `Immuta Marketplace Data Object` tag.

{% hint style="info" %}
Tag hierarchy is dot `.` notated in Immuta, so even though this only says `Immuta Marketplace Data Product` it will work on data sources tagged `Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2` because it matches the root tag in the hierarchy.
{% endhint %}

2. Because this is a grant subscription policy, if this [policy is merged with existing birthright policies](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies#policy-merges), it will be combined with the existing policy with `OR`. Should the policy it is being merged with be a [guardrail subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/reference-guides/subscription-policies#guardrail-subscription-policy), then it will be combined with this policy with `AND`, which is what rightfully can cause access to not occur even if approval was given.

This single policy is able to handle all possible data products because it's driven purely based on matching the user attribute values to the data source tags. So simply updating the attributes and tags drives the policy into action.

## Understanding time bound access policies

When a user requests access to data and is granted it for a set period of time, it works the same as described above; the user will be provisioned access through Immuta policies. However, once the set time duration is up, the user's access to the data will be revoked automatically. They can re-request access if they should need it again.

[^1]: A leaf asset is an asset that aligns with a data source. It does not have any assets within it.

[^2]: A parent asset is an asset that contains other assets, usually a representation of a schema, database, etc.


---

# 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/saas/request/configure/reference-guides/understanding-access-provisioning-and-underlying-policies-in-immuta.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.