SCIM Provisioning in Snowflake: Integrations, Provisioner Roles and Monitoring

1.What SCIM does for Snowflake

SCIM 2.0 lets your organization's identity provider (IdP) act as the single source of truth for who can reach Snowflake. The IdP pushes users and groups into Snowflake, and Snowflake acts as the service provider. Snowflake has dedicated integrations for Okta and Microsoft Entra ID (formerly Azure AD). Any other IdP uses a custom integration. In Snowflake terms, an IdP group becomes a role, and both users and roles are mapped one-to-one.

The SCIM API covers three use cases: managing users, managing groups (roles), and auditing the SCIM API requests the IdP sends. The first two cover the full lifecycle. The third is how you confirm that provisioning is actually happening.

Ownership holds all of this together. Each IdP has its own provisioner role in Snowflake, and that role must own whatever SCIM creates. If the SCIM role does not own an imported user or role, the IdP's updates stop reaching that object. Exam questions that describe changes in Okta not showing up in Snowflake usually come down to this.

Sources12

2.Enabling and configuring the SCIM security integration

Setup happens in four stages. First, choose the IdP. Then create a SCIM security integration in Snowflake, which is the interface between Snowflake and the IdP. Next, set up authentication for SCIM requests. Finally, have the IdP send requests. The integration is a normal security integration with type = scim. Two properties matter most: scim_client, which names the IdP, and run_as_role, which names the provisioner role that will own everything created.

use role accountadmin;
create role if not exists okta_provisioner;
grant create user on account to role okta_provisioner;
grant create role on account to role okta_provisioner;
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
    type = scim
    scim_client = 'okta'
    run_as_role = 'OKTA_PROVISIONER';

The provisioner role gets only CREATE USER and CREATE ROLE on the account, so it is scoped down on purpose. A less-privileged role than ACCOUNTADMIN can run the setup, but the documentation warns this can cause errors when SCIM tries to manage roles in the resulting hierarchy. It lists three options, in order of preference: use ACCOUNTADMIN, use a role with the global MANAGE GRANTS privilege, or use a custom role that has OWNERSHIP on every role SCIM will manage. For Microsoft Entra ID, create a new enterprise application in Entra rather than reusing an existing one. The SCIM integration also supports replication and failover/failback from a source account to a target account.

use role accountadmin;
create role if not exists aad_provisioner;
grant create user on account to role aad_provisioner;
grant create role on account to role aad_provisioner;
grant role aad_provisioner to role accountadmin;
create or replace security integration aad_provisioning
    type = scim
    scim_client =  ? 
    run_as_role = 'AAD_PROVISIONER';

Sources342

3.Managing users and groups through the IdP

With Okta, provisioning covers the user lifecycle (create, update, delete), the role lifecycle, and user-to-role assignments. Push New Users creates users in Snowflake. Push Profile Updates sends profile changes. Push User Deactivation deactivates the user in Snowflake, which means setting the user's DISABLED property to TRUE. Push Groups creates roles with the same names as in Okta, but it does not create users. Users are created when the Snowflake app is assigned to them in Okta. Always create roles in Okta first: OKTA_PROVISIONER cannot manage roles created by hand in Snowflake.

To bring an existing user under Okta, transfer its ownership (grant ownership on user <user_name> to role okta_provisioner;) and make sure login_name is set. The user's name will then be changed to match the Okta username, which can break integrations that connect with the old name. Passwords need attention too. Okta's Sync Password feature can create a random Snowflake password by default, which gives users a way in without SSO. To stop this, turn the setting off in Okta and set SYNC_PASSWORD to False on the integration. Both IdP integrations also support the allowedInterfaces attribute, which blocks a provisioned user from specific interfaces.

Entra ID is stricter. It is the authoritative source for its users and groups, and existing Snowflake users and groups cannot be transferred to it. By default, users it provisions get no Snowflake password, so they sign in through SAML SSO if that is configured. SAML SSO is not required to use SCIM, though.

Sources34

4.Monitoring and running SCIM day to day

To check whether provisioning is working, query the rest_event_history table. It shows whether the IdP is actually sending SCIM API requests. Snowflake allows at most 500 concurrent requests per account per SCIM endpoint, such as /Users or /Groups. Past that, it returns HTTP 429. This normally only happens during initial provisioning of very large numbers of users or groups. The SCIM endpoint is the account URL followed by /scim/v2/. Use the public endpoint, without .privatelink.

Network access is a common reason provisioning fails. The IdP's IP addresses must be allowed; for Entra ID, that means all Azure IP addresses. You don't need to add those addresses to the account-wide policy. Instead, attach a network policy to the SCIM integration itself (alter security integration okta_provisioning set network_policy = <scim_network_policy>;). A network policy on the SCIM integration overrides the account-level policy.

A few other behaviours are worth knowing. SCIM does not turn on SSO; you enable Snowflake-initiated SSO separately. By default, Snowflake sends invitation emails to SCIM-created users within 24–48 hours, and only Snowflake Support can turn this off. SCIM can set DEFAULT_SECONDARY_ROLES to 'ALL'. The snowflakeTags attribute can apply tags, provided the tag already exists and the provisioner role has USAGE on the tag's schema and APPLY on the tag. Entra ID can add and update tags but cannot remove them; remove them with ALTER USER <user_name> UNSET TAG <database_name>.<schema_name>.<tag_name>;. If you need a user's name and login_name to differ, enable this account parameter:

ALTER ACCOUNT SET MAP_SCIM_USERNAME_TO_ENTERPRISE_ATTR = TRUE;

Once this is enabled, every SCIM POST and PUT must include snowflakeUserName in the enterprise extension schema. Requests without it fail.

Sources134

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Okta Push Groups creates both the role and its member users in Snowflake.Why is that wrong?

   Push Groups only creates and manages roles. A user is created only when the Snowflake application is assigned to that user in Okta.

   Covered in Managing users and groups through the IdP

2. 2.Setting SYNC_PASSWORD on a Microsoft Entra ID SCIM integration controls whether Entra passwords sync to Snowflake.Why is that wrong?

   Entra ID does not sync passwords to Snowflake, whatever SYNC_PASSWORD is set to. This is an Entra limitation; the property only has an effect for Okta.

   Covered in Managing users and groups through the IdP

3. 3.Once SCIM provisioning works, users can sign in with SSO automatically.Why is that wrong?

   SCIM only provisions identities. Snowflake-initiated SSO has to be enabled separately.

   Covered in Monitoring and running SCIM day to day