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.

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-managed 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-managed roles. It discovers them when the Snowflake data source is synchronized and links them to the corresponding IdP groups.

Controlling group

A group that is linked to a role. Its members determine who has the role in Snowflake.
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, and provisioning works. Data Access does not set up or monitor SCIM.
Permissions are configured.

The credentials that connect Data Access to your IdP can read groups and have write permissions for 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 Snowflake data source that the application provisions groups to. Without this mapping, groups are still synchronized, but they are not linked to corresponding Snowflake roles.
(Optional) Group editing is enabled.

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

You need this only if you want to manage groups in Data Access and apply your changes to the IdP.

Provisioning a group through the application access control

Instead of assigning a group to the Snowflake application in your IdP, you can add the group as a beneficiary of the application access control in Data Access. Data Access then assigns the group to the application in your IdP, either through the Snowflake application in Entra ID or through Group Push in Okta. Your IdP provisions the group to Snowflake through SCIM.

Prerequisites

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

Behavior
Tip 

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 role with the same name as the group.
In Data Access
  1. Data Access synchronizes with your IdP, importing groups. A group is eligible for linking if it is provisioned to an IdP application that is specified in the Application data source mapping field.
  2. Data Access synchronizes with the Snowflake data source, importing roles.
  3. Data Access compares the name of each eligible group with the names of the roles 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.
  4. When a match is found, Data Access links the role to the group, establishing the group as the role's controlling group.

The two synchronizations can run in either order. If the group is synchronized first, Data Access establishes the link automatically after the role is synchronized.

After Data Access links a role to a group, you cannot change the role's beneficiaries, inheritance, or name, and you cannot delete the role. To change who has the role, change the members of its controlling group in your IdP. If group editing is enabled in the IdP configuration, you can also change the members in Data Access.

Requesting access

Users request access to a SCIM-managed role in the same way as to any other role. The access request is then routed through the role's controlling group, which is the IdP group that is linked to the role.

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

The requested beneficiaries become members of the controlling 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 on its own SCIM schedule. Data Access does not monitor this step. If the updated permissions do not appear in Snowflake after the synchronization, check the SCIM provisioning logs in your IdP.

Example: Granting a Snowflake role through an Okta group

This example shows how an access request for a SCIM-managed role gives a requester the role in Snowflake through the role's controlling group.

Scenario

Suppose that Okta provisions groups to Snowflake through SCIM Group Push. Data Access has linked the Okta group Analysts to the Snowflake role ANALYSTS, so Analysts is the role's controlling group.

Roxanne, a data consumer, requests access to the CUSTOMER table (an asset), which is linked to the ANALYSTS role.

Behavior

Roxanne now has the ANALYSTS role in Snowflake.

Note Roxanne also gets any access that is granted to the Analysts group through other roles, because she is now a member of that group.

Related topics