SAML2 JIT user provisioning¶
Just-in-time (JIT) user provisioning automatically creates Snowflake user accounts when a user successfully authenticates through a SAML2 security integration for the first time. Instead of requiring administrators to pre-create accounts for every federated user, Snowflake extracts the user’s attributes and role assignments from the SAML assertion and creates the user on demand.
How JIT provisioning works¶
When a user authenticates through a SAML2 security integration that has JIT provisioning enabled, Snowflake checks whether a user with the asserted login name already exists:
- First login: Snowflake creates a new user account using attributes from the SAML assertion, then grants any roles specified in the assertion. The login name is determined by the SAML NameID value.
- Subsequent logins: Snowflake locates the existing user and returns it without modification. Role grants from the previous login aren’t changed.
JIT provisioning runs within the authentication flow. If provisioning fails — for example, because the login name cannot be resolved from the assertion — Snowflake logs the error and the login attempt fails.
Attribute mapping¶
JIT provisioning maps claim values from the SAML assertion to Snowflake user properties using an attribute mapping configuration. You can specify a built-in preset for common identity providers, define custom mappings, or combine both. When a preset and a custom mapping are both specified, the custom mapping overrides individual preset entries.
Attribute mapping presets¶
A preset provides pre-configured claim name defaults for a specific identity provider.
Each preset maps the LOGIN_NAME, EMAIL, DISPLAY_NAME, FIRST_NAME, and LAST_NAME
properties to the claim names that the IdP sends by default:
| Preset | Identity provider |
|---|---|
OKTA | Okta |
ENTRA_ID | Microsoft Entra ID (Azure AD) |
ONELOGIN | OneLogin |
GENERIC_SAML | Any SAML 2.0-compliant identity provider |
Presets do not include mappings for ROLE, PRIMARY_ROLE, or ALLOWED_INTERFACES.
Configure these separately using ATTRIBUTE_MAPPING.
Custom attribute mappings¶
Use ATTRIBUTE_MAPPING to define mappings for individual properties. Each property entry
specifies one or both of the following fields:
ATTRIBUTE: the name of the SAML claim that contains the value.DEFAULT: a static fallback value used when the claim is absent or the property has noATTRIBUTEconfigured.
The following properties can be mapped:
| Property | Description |
|---|---|
LOGIN_NAME | The login name for the Snowflake user. If mapping not specified, SAML NameID is used as the login name. |
EMAIL | The user’s email address. |
DISPLAY_NAME | The display name shown in the Snowflake UI. |
FIRST_NAME | The user’s first name. |
LAST_NAME | The user’s last name. |
ROLE | Roles to grant to the user. The claim can be multivalued. Snowflake flattens both multiple AttributeValue elements and comma-separated values within a single element. Set DEFAULT to grant a fallback role when the claim is absent or empty. Set only DEFAULT (no ATTRIBUTE) to grant a fixed role to every provisioned user. |
PRIMARY_ROLE | The role Snowflake grants and sets as the user’s default role. Map to a claim or use DEFAULT for a static value. |
ALLOWED_INTERFACES | Snowflake interfaces the provisioned user is permitted to access. See Interface access provisioning. |
Role provisioning¶
When the SAML assertion contains a claim mapped to ROLE, Snowflake grants each value
in that claim as a role to the newly created user. Role grants are issued using the
integration owner role as the grantor, so only roles within that role’s privilege hierarchy
can be granted. If any role in the claim doesn’t exist in Snowflake, or if the integration
owner role can’t grant it, provisioning fails and the user isn’t created.
Snowflake matches claim values to role names, not group IDs. The value in the SAML assertion must exactly match the name of an existing Snowflake role. Identity providers that send group object IDs (for example, Microsoft Entra ID by default) must be configured to send display names instead.
The ROLE claim can be multivalued. Snowflake handles both multiple AttributeValue
elements in the SAML assertion and comma-separated values within a single element.
Unquoted role name values are uppercased to match Snowflake’s default identifier
semantics. To match a case-sensitive role name, the claim value must include double
quotes — for example, "analyst" matches the role analyst.
DEFAULT behavior on ROLE¶
DEFAULT on the ROLE mapping is a fallback: it’s used only when the claim is absent
or empty. When the assertion includes the mapped claim with values, those values are used
and the default is ignored.
To grant a role to every provisioned user regardless of the assertion, omit ATTRIBUTE
and use only DEFAULT. Because there is no claim to check, the default always applies.
PRIMARY_ ROLE¶
PRIMARY_ROLE names a single role that Snowflake grants to the user and sets as the
user’s default role. It is independent of the ROLE list. If PRIMARY_ROLE is also
present in the ROLE list, Snowflake grants it once. If the role doesn’t exist or can’t
be granted, provisioning fails.
Interface access provisioning¶
The ALLOWED_INTERFACES mapping controls which Snowflake interfaces the provisioned user
can access. Map it to a claim or use DEFAULT to set a static value. For valid values,
see ALLOWED_INTERFACES
in the CREATE USER reference.
If the property is not configured or the claim is absent, access defaults to ALL.
Note
Using ALLOWED_INTERFACES in JIT provisioning requires ENABLE_USER_ALLOWED_INTERFACES
to be enabled for your account separately from the base JIT provisioning feature. Contact
Snowflake Support
to enable it.
Considerations¶
- JIT provisioning creates users on first login only. It doesn’t update user attributes or role grants on subsequent logins, and it doesn’t deprovision users when they are removed from the IdP. To update or remove users, use SQL commands or SCIM.
- If
LOGIN_NAMEcannot be resolved from the assertion, the user isn’t provisioned and authentication fails. - Role grants issued by JIT provisioning use the integration owner role as grantor. Grants made manually by other roles are not affected by JIT provisioning.
- JIT provisioning is per security integration. Multiple integrations in the same account can each have independent JIT configurations.