This section is for understanding Marketplace and data products.

How-to guides

• Manage data products: Publish and manage new data products in Marketplace.

• View and respond to access requests: Approve and deny access requests from users trying to access your data products.

Reference guides

• Data products reference guide: This reference guide describes data products and their features.

• Marketplace permissions matrix: This reference guide describes Immuta permission and the actions users with those permissions can take in the Governance and Marketplace app.

• Understanding access provisioning and underlying policies: This reference guide describes how Marketplace data products and actions work to create policies to govern access in the data platform.

• Integrating with existing catalogs: This reference guide describes how to connect data products in your existing catalogs with data products in Marketplace with automated deep links.

Data stewards are able to make determinations on access requests.

Requirement: Immuta permission GOVERNANCE or Manage Data Product in the domain where the data product was published from.

View access requests

With the UI

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Opt to filter by status or sort the table by data product, status, or date.

With the API

Ensure you set the correct global segment and use a Marketplace-specific personal access token (PAT) when using the Marketplace API. See the Marketplace API docs for additional guidance or to download the OpenAPI YAML for your own client generation.

View the access requests of a specific data product

With the UI

In the Marketplace app,

1. Navigate to the Data product you want to view requests for.

2. Click the Access requests tab.

3. Opt to filter by status or sort the table by data product, status, or date.

With the API

Ensure you set the correct global segment and use a Marketplace-specific personal access token (PAT) when using the Marketplace API. See the Marketplace API docs for additional guidance or to download the OpenAPI YAML for your own client generation.

View the approval record for a request

With the UI

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Click the request you want the details for.

With the API

Ensure you set the correct global segment and use a Marketplace-specific personal access token (PAT) when using the Marketplace API. See the Marketplace API docs for additional guidance or to download the OpenAPI YAML for your own client generation.

Respond to an access request

With the UI

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Click the request you want to approve or deny.

3. Review the request details, data sources, and data use agreement.

4. Select Deny or Approve:

   1. Deny: Enter your reason to deny access to the data product and click Confirm denial.

   2. Approve: Enter your reason to approve access to the data product and click Confirm approval.

With the API

Ensure you set the correct global segment and use a Marketplace-specific personal access token (PAT) when using the Marketplace API. See the Marketplace API docs for additional guidance or to download the OpenAPI YAML for your own client generation.

To ensure Marketplace functions seamlessly with your Governance app, there are some setup requirements.

1. The private preview of Marketplace has been enabled by your Immuta representative.

2. Users registered in Immuta to ensure users can log in to the Marketplace app, request access, and be provisioned access in the data platform.

   1. If the configured identity manager (IAM) to Immuta is syncing attributes (groups don't matter) from it, the checkbox to allow Immuta attributes to be applied to the IAM's users and groups must be enabled. To enable this setting, edit the IAM from the Governance app settings page.

3. An integration configured and data sources registered in Immuta: Tables, views, and files registered as data sources in the Governance app can be used in data products from the Marketplace app. These registered data sources within the data products are what are provisioned to the data consumers in the data platform when approved for access:

   1. Snowflake: Use connections to register your data and integration.

   2. Databricks Unity Catalog: Use connections to register your data and integration.

   3. Databricks Spark: Configure your integration and register data sources.

   4. Starburst (Trino): Configure your integration and register data sources.

   5. Redshift: Configure your integration and register data sources.

   6. Azure Synapse Analytics: Configure your integration and register data sources.

   7. Amazon S3: Configure your integration and register data sources.

   8. Google BigQuery: Configure your integration and register data sources.

4. Data sources assigned to domains: Each data product is comprised of data sources from a single domain, allowing you to segment your organization's data and delegate permissions to specific users that are knowledgeable about the data.

Data products are what are published to the Data Marketplace by data product managers. They are typically highly curated and ready for consumption by the business.

They contain the following metadata:

• Name

• Description (optional)

• Subject matter expert (optional)

• Data use agreement (optional)

• Questions that must be answered by the requestor

• A collection of data sources

Data sources

Data sources represent any type of data that could be provided by a data product and registered in Immuta. These are currently tables and views from your data platform and objects from S3 storage. What data sources are available for the data product manager to add are dependent on the domain specified when publishing the data product.

Editing the data product

Note that all data product settings and metadata are point-in-time of when the access request was made and approved. For example, if you change the data use agreement for a data product after it was approved for five users, those five users would remain approved under the previous data use agreement. Said another way: Immuta only updates the data product with the changes for new requests, not approved or pending requests.

Anything a Data Steward can do -> a Data Product Manager can do; anything a Data Product Manager can do -> a user with GOVERNANCE permission can do.

And the scope of their permissions grow as you move up the layers:

See the table below for the full breakdown of what Marketplace actions require which Immuta permissions:

One of the key benefits of using the Immuta Marketplace app is that access provisioning is automatic: if you're approved access, Immuta is able to automatically provision the access to the data sources in the data product natively in the data platform(s) using existing Immuta Governance 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, 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 that Immuta has perfected since its inception.

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

Before any data products are published

Immuta creates a single policy that is on standby, ready to service data product access approvals. With just this single policy, all access requests can be provisioned. That policy has the following logic:

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

On data sources tagged Immuta Marketplace Data Product

The Share Responsibility option is also checked in the policy.

This policy is 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 user is approved to a data product

The user that was approved access has the below attribute added to them, which cannot be removed unless the user is manually revoked access from the Marketplace or the data product is deleted:

Immuta Marketplace: Immuta Marketplace Data Product.[data product ID]

More explicitly, the attribute key = Immuta Marketplace and the attribute value = Immuta Marketplace Data Product.[data product ID]

The attribute key Immuta Marketplace is 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, please review the integration documentation for the specific data platform.

Understanding the 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's two additional pieces worth understanding:

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

1. Share Responsibility means that if this policy is merged with existing birthright policies, it will be OR'ed together with the existing policy. Should the policy, the one being merged with, have Always Required then it will be AND'ed with this policy, 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.

Integration is made possible through deep link URLs provided by the Marketplace app that direct the user to the request access screen for any given data product. At a high level the workflow looks like this:

• The consumer discovers data product in your catalog

Mirroring data products

Right now you must separately publish the data product in your catalog, but once Marketplace supports webhooks, it will be possible to listen to those to automate publishing in your catalog when published in the Marketplace app.

Redirecting in order to request access

To support redirects, Marketplace exposes deep link URLs to the request access page for each data product. That URL can be built two ways:

Data product name URL option

• https://app.immutacloud.com/marketplace/data-product/{data product name}/request-access

Data product ID URL option

• https://app.immutacloud.com/marketplace/data-product/{data product id}/request-access

• https://app.immutacloud.com/marketplace/data-product/{data product name}/request-access?accountId={account identifier}

• https://app.immutacloud.com/marketplace/data-product/{data product id}/request-access?accountId={account identifier}

Make sure that if you use the data product name URL option that if you change the data product name in the Marketplace app, you also change it in the URL/catalog. Note that in Marketplace all data product names must be unique.

Catalog redirect approach recommendations

The following are only recommendations for popular catalogs, you can do this however you feel appropriate and can reuse some of these approaches in different catalogs or custom marketplace applications you may have built yourselves.

Collibra

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. The most common approach we've seen customers take with Collibra is the following:

• Domain (which contains the data product(s)) = Collibra Collection

• Data product (which contains the data source(s)) = Collibra Data Set

• Data source = Collibra Data Asset

A Collibra custom workflow can be leveraged to redirect to the Marketplace app to request access. We have a sample workflow created you can download. This workflow was exported in a way that allows you to see its workflow "code" in the Collibra Workflow designer should you want to make changes.

Once you are happy with the workflow "code" you must deploy it (top right of the Collibra workflow designer) and then configure Collibra:

• Uncheck "Show in global create"

• This workflow "attaches" to a Data Set by configuring the "Applies To" in Collibra to a Data Set. You can change this to whatever object you represent data products with in Collibra.

• Ensure the variables are empty

• For the "Start Events" choose "Workflow Started"

• Under "Other" ensure "Any user can start the workflow"

• Save

Alation

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. There is not an obvious approach to this in Alation; the best we've seen is:

• Domain (which contains the data product(s)) = Alation Glossary

• Data product (which contains the data source(s)) = Alation Domain

• Data source = Alation Data

We hope to work closely with Alation to make this smoother in the future - ask them about it!

Atlan

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. Thankfully, Atlan's object mapping is very close to the marketplace app:

• Domain (which contains the data product(s)) = Atlan Domain

• Data product (which contains the data source(s)) = Atlan Data Product

• Data source = Atlan Data Asset

We hope to work closely with Atlan to make this smoother in the future - ask them about it!

Always request/approve in the Marketplace app

While you are able to create request and approval flows in some catalogs and even other tools, we do not recommend you do this. Doing data request and approval flows in Immuta has various benefits and future benefits:

• When approved, the access is automatically provisioned in the data platform

• Provides full audit and reporting (coming soon) of requests/approvals

• • In the future, we intend to provide even more details to make the access determination as accurate and meaningful as possible:

    • More details about the requestor (attributes and groups)

    • What is in the data

    • Existing queries and types of questions asked of the data

    • Existing access/denials and why

• Request policies will be able to be dynamically configured based on the risk level of the data product (coming soon). For example, if the data product contains PII and the requestor is a contractor: require x approvers and y data use agreement. Conversely, if the data does not contain PII and the employee is an internal employee: grant automatic access, etc.

• Access requests can be temporarily approved which can avoid recertifications (coming soon)

• Access requests to data can be as granular as you need, even down to column and row (coming soon)