Using SCIM with Data Access

Many organizations manage access by assigning identities to groups in an identity provider (IdP) and provisioning these groups to data sources through System for Cross-domain Identity Management (SCIM).

Data Access can manage Microsoft Entra ID and Okta groups that are SCIM-managed to Snowflake. It works alongside your existing SCIM setup without replacing it. You manage the groups in Data Access, and Data Access applies the changes to the groups in your IdP. Your IdP then passes the changes to the corresponding roles in Snowflake through SCIM.

Key terms

Some of the key terms that are used in this topic are described in the following table.

Term Description
Identity provider (IdP) The source of your identities and groups: Entra ID or Okta.
System for Cross-domain Identity Management (SCIM)

An open standard that your IdP uses to provision groups to Snowflake as roles.

When your IdP provisions a group through SCIM, a role with the same name is created in Snowflake. This happens in your IdP and Snowflake, not in Data Access.

SCIM role

A Snowflake role that is created through SCIM provisioning and that Data Access has linked to an IdP group with the same name (case-insensitive).

Data Access does not create SCIM roles. It discovers them when the Snowflake data source is synchronized and links them to the corresponding IdP groups.

SCIM group

A group that is linked to a role. Its members determine who has the role in Snowflake. A SCIM group is the controlling group of a SCIM role.
Application access control

An access control in Data Access that represents a Snowflake application in your IdP. It lists the users and groups that are assigned to that application in the IdP.

Groups that you add as beneficiaries of the access control in Data Access are assigned to the application in the IdP. The IdP then provisions those groups to Snowflake through SCIM.

Prerequisites for SCIM support in Data Access

Before Data Access can work alongside your existing SCIM setup, ensure that the following prerequisites are met.

Prerequisite Description
SCIM provisioning is set up.

Your IdP (Entra ID or Okta) provisions groups to Snowflake through SCIM. Data Access does not set up or monitor this downstream SCIM provisioning.
Permissions are configured.

The credentials that connect Data Access to your IdP have write permissions on groups and group members.

For Entra ID, the credentials are granted to the application registration. For Okta, they are granted to the account that owns the API token.

Application data source mapping is configured.

In the IdP configuration in Data Access, the Application data source mapping field is completed.

This mapping pairs an IdP application that provisions groups through SCIM with the target Snowflake data source. Without this mapping, groups are still synchronized, but they are not linked to corresponding Snowflake roles.
Applications are enabled.

In the IdP configuration in Data Access, the Enable applications option is enabled. This allows Data Access to import Snowflake applications from your IdP as access controls.

This is required only if you want to assign groups to the application directly in Data Access, for example, adding an IdP group as a beneficiary of the Snowflake application access control in Data Access.
Group editing is enabled.

In the IdP configuration in Data Access, the Enable group editing option is enabled.

This is required only if you want to manage group memberships in Data Access and push changes back to your IdP.

Example: Provision a group with application access control

Instead of manually assigning groups to the Snowflake application in your IdP, you can manage assignments directly in Data Access. This example shows how to provision an Okta group to Snowflake by using an application access control.

Prerequisites

In the Okta data source configuration, the Application data source mapping field is completed, and the Enable applications and Enable group editing options are enabled.

Steps

  1. In Data Access, create a group named UK-Dealers for the Okta data source.
    Image of the group page
  2. Open the Snowflake application access control named Snowflake, and then add the UK-Dealers group as its beneficiary.
    Image of a Snowflake application role in Data Access

Result

  1. During the next sync with your Okta data source, Data Access assigns the UK-Dealers group to the Snowflake application.
  2. Outside Data Access:
    1. Okta provisions the UK-Dealers group to Snowflake through SCIM.
    2. Snowflake creates a corresponding role named UK-DEALERS.
  3. During the next sync with your Snowflake data source, Data Access imports the new UK-DEALERS role and automatically links it to the UK-Dealers group.
    Image of a SCIM role

How Data Access links a role to a group

Data Access links a Snowflake role to a group by matching their names. The process occurs in two phases.

In your IdP and Snowflake
  1. Your IdP (Entra ID or Okta) provisions a group to Snowflake through SCIM.
  2. Snowflake creates a corresponding role with the same name as the group.

Data Access is not involved in these steps and does not create the role.

In Data Access
  1. Data Access synchronizes with your IdP, importing groups.
  2. Data Access synchronizes with the Snowflake data source, importing roles.
  3. Data Access compares the name of each eligible group with the role names in the synchronized Snowflake data source. The comparison is not case-sensitive. For example, a group named Analysts matches a role named ANALYSTS, but not ANALYSTS_ROLE.
    Tip To be eligible for linking, a group must be provisioned to an IdP application. That application must also be specified in the Application data source mapping field and mapped to the Snowflake data source.
  4. When a match is found, Data Access links the role to the group, establishing the group as the role's SCIM group.

The two syncs can run in either order. If the group is synchronized first, the link is established after the role is synchronized.

Note After Data Access links a role to a group, you cannot directly modify the role. To change the role's beneficiaries, you need to change the membership of its SCIM group in your IdP or in Data Access (if group editing is enabled).

Requesting access

Users can request access to a SCIM role in the same way as any other role. The access request is routed through the role's SCIM group.

The implementation task is assigned to the owners of the SCIM group, not to the owners of the SCIM role. When an assignee implements the request, the requested beneficiaries are added to the SCIM group, not to the SCIM role. Data Access then pushes the group change back to your IdP.

The requested beneficiaries become members of the SCIM group, so they inherit all the access that the group already has, not only the access that they requested.

Your IdP passes the change to Snowflake according to its own SCIM schedule. Data Access does not monitor this step. If the updated permissions do not appear in Snowflake after sync, check the SCIM provisioning logs in your IdP.

Example: Grant a Snowflake role through an Okta group

This example shows how an access request for a SCIM role grants a user the corresponding role in Snowflake.

Suppose that Okta provisions groups to Snowflake through SCIM. Data Access has linked the Okta group UK-Dealers to the Snowflake role UK-DEALERS, making UK-Dealers the role's SCIM group.

  1. Roxanne, a data consumer, requests access to the UK Dealer Sales Port asset, which is linked to the UK-DEALERS role.
    Image of the "Request access" dialog box
  2. The access request is assigned to the owners of the UK-Dealers group.
    Image of the access request page
  3. When an owner of the UK-Dealers group implements the request, Roxanne is added to the UK-Dealers group in Data Access.
  4. Data Access pushes the group change back to Okta.
  5. Okta passes the change to Snowflake through SCIM. Roxanne now has the UK-DEALERS role in Snowflake.

Related topics