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:

PresetIdentity provider
OKTAOkta
ENTRA_IDMicrosoft Entra ID (Azure AD)
ONELOGINOneLogin
GENERIC_SAMLAny 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 no ATTRIBUTE configured.

The following properties can be mapped:

PropertyDescription
LOGIN_NAMEThe login name for the Snowflake user. If mapping not specified, SAML NameID is used as the login name.
EMAILThe user’s email address.
DISPLAY_NAMEThe display name shown in the Snowflake UI.
FIRST_NAMEThe user’s first name.
LAST_NAMEThe user’s last name.
ROLERoles 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_ROLEThe role Snowflake grants and sets as the user’s default role. Map to a claim or use DEFAULT for a static value.
ALLOWED_INTERFACESSnowflake 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_NAME cannot 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.