# Author Policy How-to Guide

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>1 -</strong></mark> <mark style="color:blue;"><strong>Manage user metadata how-to guide</strong></mark></td><td></td><td></td><td><a href="../managing-user-metadata/manage-user-metadata-how-to-guide">manage-user-metadata-how-to-guide</a></td><td></td></tr><tr><td><mark style="color:blue;"><strong>2 -</strong></mark> <mark style="color:blue;"><strong>Manage data metadata how-to guide</strong></mark></td><td></td><td></td><td><a href="../managing-data-metadata/manage-data-metadata-how-to-guide">manage-data-metadata-how-to-guide</a></td><td></td></tr><tr><td><strong>3 -</strong> <strong>Author policy how-to guide</strong></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Authoring global subscription policies to automate access controls involves using the data metadata and user metadata in Immuta to identify the data that should be governed and the users the policy should target.

This how-to guide demonstrates how to author a global subscription policy in Immuta to automat access decisions.

For detailed explanations and examples of how to author subscription policies, see the [Author policy guide](https://documentation.immuta.com/saas/govern/getting-started-with-secure/automate-data-access-control-decisions/author-policy).

## Requirements

**Immuta permission**: `GOVERNANCE` global permission, `Manage Policies` domain permission, or own the data source

## Prerequisites

* [User metadata configured](https://documentation.immuta.com/saas/govern/getting-started-with-secure/automate-data-access-control-decisions/managing-user-metadata/manage-user-metadata-how-to-guide)
* [Data metadata configured](https://documentation.immuta.com/saas/govern/getting-started-with-secure/automate-data-access-control-decisions/managing-data-metadata/manage-data-metadata-how-to-guide)

## Understand your metadata

How you author policies is dictated by how your user and data metadata is organized to grant access:

* [**Fact-based (ABAC)**](#abac-policy-authoring): [Many variables](#user-content-fn-1)[^1] determine access, and data sources are tagged at the column and table level.
* [**Logic-based (orchestrated RBAC)**](#orchestrated-rbac-policy-authoring): A [single variable ](#user-content-fn-2)[^2]determines access, and data sources are tagged at the table level. With orchestrated RBAC you have established one-to-one relationships with how your users are tagged (attribute or group) and what that single tag explicitly gives them access to.

## Author a subscription policy

<details>

<summary>ABAC policy authoring</summary>

1. Determine why someone should be given access to data. For example, let’s say that to have access to `Strictly Confidential`, you have determined that someone should be
   * an employee (not contractor)
   * in the US
   * part of the Legal team
2. [Build individual subscription policies](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial) for each piece of logic associated with why someone should have access. Examples are provided below.

**Example policy 1: employee access**

Author a [subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial) that grants read access to users who are a member of group `Employees` that applies to columns tagged `Strictly Confidential`:

> Allow users to subscribe with read access when user is a member of group `Employees` on data sources with columns tagged `Strictly Confidential`.

**Example policy 2: country access**

Author a [subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial) that grants read access to users with attribute `Country.US` that applies to columns tagged `Strictly Confidential`:

> Allow users to subscribe with read access when user possesses attribute `Country` with value `US` on data sources with columns tagged `Strictly Confidential`.

**Example policy 3: legal team access**

Author a [subscription policy](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial) that grants read access to users who are a member of group `Legal Team` that applies to columns tagged `Strictly Confidential`:

> Allow users to subscribe with read access when user is a member of group `Legal Team` on data sources with columns tagged `Strictly Confidential`.

</details>

<details>

<summary>Orchestrated RBAC policy authoring</summary>

1. Determine how user metadata and data metadata is organized. What variable determines access?
2. [Build grant subscription policies using special functions in the advanced DSL builder](https://documentation.immuta.com/saas/govern/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/advanced-dsl-policies) to target tables. Since orchestrated RBAC is all about one-to-one matching of user metadata to data metadata, use the special functions in the subscription policy builder for managing this:
   1. `@hasTagAsAttribute('`[`Attribute Name`](#user-content-fn-3)[^3]`',` [`'dataSource' | 'column'`](#user-content-fn-4)[^4]`)`
   2. `@hasTagAsGroup(`[`'dataSource' | 'column'`](#user-content-fn-5)[^5]`)`

**Example**

Let’s say there are `Strictly Confidential` tables and `Public` tables. Everyone has access to `Public`, and only special people have access to `Strictly Confidential`.

Users are tagged with their access under the `Access` attribute key:

* Bob: `Access: Strictly Confidential`
* Steve: `Access: Public`

Tables are also tagged with the same metadata:

* Table 1: `Strictly Confidential`
* Table 2: `Public`

You would build a grant subscription policy that targets all tables like this:

> Allow users to subscribe with read access when @hasTagAsAttribute(`Access`,`dataSource`) on all data sources.

</details>

## Next steps

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Learn</strong></td><td>Explore this use case to learn more about using Immuta to mask sensitive data.</td><td><a href="../../compliantly-open-more-sensitive-data-for-ml-and-analytics">Compliantly open more sensitive data for ML and analytics</a>: This section focuses on how to safely and compliantly open more sensitive data for your organization to support machine learning and analytics needs.</td></tr><tr><td><strong>Implement</strong></td><td>Follow these guides to test your policies and use Immuta to enforce fine-grained access controls.</td><td><ol><li>Optionally <a href="../../test-and-deploy-policy">test and deploy policy</a>.</li><li><a href="../../compliantly-open-more-sensitive-data-for-ml-and-analytics/open-author-policy/author-policy-how-to-guide">Author a data policy</a>.</li></ol></td></tr></tbody></table>

[^1]: An example of multiple variables determining access is a rule like this: `You must reside in the US and be a full time employee to see data tagged US and Highly Sensitive.`

    See the [Governance use cases introduction](https://documentation.immuta.com/saas/govern/getting-started-with-secure/..#choose-your-path-orchestrated-rbac-or-abac) for further explanation and examples.

[^2]: An example of a single variable determining access is a rule like this: `You must have signed data use agreement x to have access to data y.`

    See the [Governance use cases introduction](https://documentation.immuta.com/saas/govern/getting-started-with-secure/..#choose-your-path-orchestrated-rbac-or-abac) for further explanation and examples.

[^3]: This first argument is the attribute key whose value tags will be matched against

[^4]: This second argument specifies whether the attribute values are matched against data source or column tags.

[^5]: This argument matches the group name to the data source or column tag.