User Types

By leveraging the Request app, you introduce new user types in your Immuta deployment:

Data stewards: These users process the data consumer access requests to approve, deny, or temporarily approve access. Data stewards are assigned to assets and data products based on request forms. If the request form delegates the selection of data stewards, then they are assigned in the actual asset or data product.

Data consumers: These are the users who search for, discover, and request access to data. Once approved, the data consumer can query the data natively in the data platform, where the access is provisioned automatically. Data consumers can initiate access requests to data from within data catalogs or within data products in Immuta.

Data product manager: If you choose to use Immuta as a marketplace, these users own the management of the metadata around data products and publish the data products.

Data stewards

Data stewards process the data consumer access requests to approve, deny, or temporarily approve access to data. These users are assigned as data stewards based on request forms, or if the request form delegates, then by the object being requested. Data stewards can be granted stewardship based on the following sources:

• Global permission (e.g., GOVERNANCE)

• Domain-specific permission for the domain the data product is built from (e.g., Manage Identifiers)

• Group

• Attribute

• Username (i.e., selecting a specific user)

Request details

The data steward has a difficult job; historically, they have been asked to make extremely subjective determinations on access requests with too little information. The Access requests page resolves that problem by presenting a range of request details all in a single view, making the data steward's job much easier.

The following information is in each request to help the data steward with their decision:

• The requestor's answers to the required question(s) from the request form.

• Confirmation that the requestor has agreed to the data use agreement, if there is one. The data use agreement can also be viewed through a link.

• Any other approvals that have already been given for the access request and the reason for approval.

If the user is making a masking exception request, the request will also include the following column-level details about the requested columns:

• Column names

• Column tags

• Masking policies applied to the column

If the user is requesting access to a data product, the request will also include the following:

• The last five approvals (if available) and denials (if available) on the data product with details about each: when they happened, who was approved or denied, who approved or denied them, and why.

  • This will help the approver understand if the user requesting access aligns with the past five users and the people who have already made approvals in case there are questions.

• For each data source in the data product, any existing access details:

  • If the user already has access via a birthright subscription policy

  • If the user cannot gain access due to an existing birthright subscription policy

What happens once an access request is approved or denied?

Access requests may require a single approval or the approval of all data stewards depending on the configured request form. This can impact the effect of the determination:

Single approver

If an access request requires any data steward's determination, then once a single data steward makes a determination, it goes into effect.

• If approved:

  • Access to the data objects will be auto-provisioned in the data platform(s) for the requested data. This is done natively in the data platform, which means the requesting user can query those data objects directly from the data platform. This provisioning is represented as an understandable and scalable Immuta policy that will be combined with any existing policies.

  • For masking exceptions, approved columns will be auto-provisioned with unmasked access in the data platform(s) where the user has access to the data source. This exception to the masking policy is represented as an understandable and scalable Immuta policy that will be combined with any existing policies.

• If denied, the user will not be granted access to the data.

Multiple approvers

Data product managers

Data product managers are able to manage data product metadata, add data sources, create request forms, and publish data products in Immuta.

Any user with GOVERNANCE permission is able to publish data products. However, you can also delegate data product management to users without giving them the power that comes with GOVERNANCE permission.

Delegating to data product managers

The first step to delegating data product management is to create domains in Immuta, which can be completed by a user with GOVERNANCE permission.

Domains are containers for data sources that allow you to assign permissions scoped to the data sources in that domain. The permission for data product managers is Manage Data Products that can be assigned within a domain by a user with USER_ADMIN permission from within the Governance app.

When a user has the Manage Data Products permission and visits the Request app, they can define and publish data products. Additionally, the data sources assigned to those data products can only be sourced from a domain where they have the Manage Data Products permission.

Why domains?

The purpose of domains in Immuta is to create scoped areas of responsibility for Immuta permissions. If given a permission on a domain, that permission is scoped to and can only act upon the data sources in that domain.

This is optimal for delegation of data product management for several reasons:

1. It avoids data product managers publishing data products that contain data sources they should not be publishing.

2. It allows the organization of domains of your data into Immuta domains. For example, every data source tagged with HR could be configured to land in the HR Domain automatically, making them available for data products by the data product managers in that domain.

3. It allows you to group teams of users with different responsibilities together with permissions scoped to the same set of data sources. For example, you could give

   1. The HR users in charge of policies (subscription and data policies) Manage Policy permission in the HR Domain

   2. The HR users in charge of tagging Manage Tags permission in the HR Domain

   3. The HR users in charge of publishing data products Manage Data Products permission in the HR Domain