Snowflake SCIM Provisioning Implementation Guide: Designing and Operating Automated User Sync

SCIM (System for Cross-domain Identity Management) 2.0 is the standard protocol for automatically provisioning and deprovisioning users and groups from an IdP (Identity Provider) into Snowflake. Once a SCIM integration is configured, user additions, changes, and deactivations on the IdP side are automatically reflected in Snowflake, eliminating the need for manual CREATE USER / DROP USER operations.

SCIM Integration Architecture

In a SCIM integration, the IdP acts as the SCIM client and sends HTTP requests to Snowflake's SCIM API endpoint. Snowflake acts as the SCIM server and creates, updates, or disables users and groups in response to those requests. Authentication uses a Bearer Token (an OAuth token generated when the SCIM Security Integration is created).

Creating the SCIM Security Integration

-- Run as the ACCOUNTADMIN role
USE ROLE ACCOUNTADMIN;

-- Create a custom role for SCIM provisioning
CREATE ROLE IF NOT EXISTS scim_provisioner;
GRANT CREATE USER ON ACCOUNT TO ROLE scim_provisioner;
GRANT CREATE ROLE ON ACCOUNT TO ROLE scim_provisioner;

-- SCIM Security Integration for Okta
CREATE SECURITY INTEGRATION okta_scim_integration
  TYPE = SCIM
  SCIM_CLIENT = 'OKTA'
  RUN_AS_ROLE = 'SCIM_PROVISIONER';

-- SCIM Security Integration for Azure AD
CREATE SECURITY INTEGRATION azure_scim_integration
  TYPE = SCIM
  SCIM_CLIENT = 'AZURE'
  RUN_AS_ROLE = 'SCIM_PROVISIONER';

-- Generic SCIM (e.g., PingFederate)
CREATE SECURITY INTEGRATION generic_scim_integration
  TYPE = SCIM
  SCIM_CLIENT = 'GENERIC'
  RUN_AS_ROLE = 'SCIM_PROVISIONER';

Generating the SCIM Token

-- Retrieve the SCIM API endpoint and token
-- Check it with SELECT after creating the integration
SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('OKTA_SCIM_INTEGRATION');

-- SCIM endpoint URL
-- https://<account>.snowflakecomputing.com/scim/v2/

-- Enter the token in the IdP's SCIM provisioning settings

Setup Flow by IdP

Okta Setup Steps

1. From Okta App Integrations, add the "Snowflake" app
2. Provisioning tab → enable Configure API Integration
3. Enter the SCIM token generated in Snowflake into the API Token field
4. Enter https://<account>.snowflakecomputing.com/scim/v2/ as the Base URL
5. Under Provisioning to App, enable Create Users / Update Attributes / Deactivate Users
6. Assign the target groups/users for sync on the Assignments tab

Azure AD Setup Steps

1. Azure Portal → Enterprise Applications → add Snowflake
2. Provisioning → select Automatic
3. Enter https://<account>.snowflakecomputing.com/scim/v2/ as the Tenant URL
4. Enter the SCIM token generated in Snowflake into the Secret Token field
5. Verify connectivity with Test Connection
6. Review and customize user and group attribute mappings under Mappings
7. Configure Scope (Sync assigned users and groups only) under Settings
8. Set Provisioning Status to On and save

Sync Targets and Behavior

Designing RUN_AS_ROLE

RUN_AS_ROLE on a SCIM Security Integration is the role that SCIM provisioning uses when it performs operations inside Snowflake. Provisioning runs only within the privileges granted to this role.

-- Example custom role design for RUN_AS_ROLE
CREATE ROLE scim_provisioner;

-- Privileges to create users and roles
GRANT CREATE USER ON ACCOUNT TO ROLE scim_provisioner;
GRANT CREATE ROLE ON ACCOUNT TO ROLE scim_provisioner;

-- If you want ACCOUNTADMIN to manage roles created by SCIM
GRANT ROLE scim_provisioner TO ROLE ACCOUNTADMIN;

-- Note: assigning ACCOUNTADMIN as RUN_AS_ROLE is
-- not recommended for security reasons. Use a least-privilege custom role.

Troubleshooting

• Users are not being synced: the SCIM token on the IdP side may have expired. Generate a new token with SYSTEM$GENERATE_SCIM_ACCESS_TOKEN and reconfigure it on the IdP.
• Groups sync but roles are not created: RUN_AS_ROLE has not been granted CREATE ROLE. Run GRANT CREATE ROLE ON ACCOUNT TO ROLE <run_as_role>.
• Synced user conflicts with an existing user: if a user with the same LOGIN_NAME already exists in Snowflake, SCIM will update that user. Check for duplicate LOGIN_NAMEs in advance to prevent unintended overwrites.
• Checking SCIM logs: the REST_EVENT_HISTORY view lets you trace successes and failures of SCIM API calls.

-- Audit SCIM API calls
SELECT *
FROM TABLE(INFORMATION_SCHEMA.REST_EVENT_HISTORY(
  DATE_RANGE_START => DATEADD(DAY, -7, CURRENT_DATE()),
  DATE_RANGE_END => CURRENT_DATE()
))
WHERE event_type = 'SCIM'
ORDER BY event_timestamp DESC;

Check Your Understanding

Frequently Asked Questions