Managing/Using Federated Authentication

This topic describes how to manage and use federated authentication once it has been configured.

In this Topic:

Managing Users with Federated Authentication Enabled

Managing Snowflake User Passwords

With federated authentication enabled for your account, Snowflake still allows maintaining and using Snowflake user credentials (login name and password). In other words:

  • Account and security administrators can still create users with passwords maintained in Snowflake.

  • Users can still log into Snowflake using their Snowflake credentials.

However, if federated authentication is enabled for your account, Snowflake does not recommend maintaining user passwords in Snowflake. Instead, user passwords should be maintained solely in your IdP.

If you create a user with no password (or alter an existing user and remove their password), this effectively disables Snowflake authentication for the user. Without a password in Snowflake, a user cannot log in using Snowflake authentication and must use federated authentication instead. Note that you cannot use the Snowflake web interface to create users with no passwords or remove passwords from existing users. You must use CREATE USER or ALTER USER.

Specifically, we recommend that you disable Snowflake authentication for all non-administrator users.

Important

The MUST_CHANGE_PASSWORD user property does not apply for federated authentication and should not be used. In particular, if you choose to not maintain passwords in Snowflake for users, ensure this property is set to FALSE for these users.

Also, you must maintain at least one Snowflake account administrator with a Snowflake password. This ensures that an account administrator can access Snowflake at all times to manage federated authentication and troubleshoot any issues that occur.

Disabling and Dropping Users

As an account or security administrator in Snowflake, you may find it necessary to drop or, more likely, disable a user. Users who are dropped or disabled in Snowflake are still able to log into their Okta accounts, but they will receive an error message when they attempt to connect to Snowflake. You must recreate or enable the user before they can log in.

You can drop/create and disable/enable users using either the Snowflake web interface or the equivalent SQL commands.

Using SSO with Client Applications That Connect to Snowflake

With an IdP (Okta, ADFS, or any of the other supported SAML 2.0-compliant services/applications) configured for your account, Snowflake supports using SSO to connect and authenticate with the following Snowflake-provided clients:

SnowSQL

v1.1.43 or higher

Python Connector

v1.4.8 or higher

JDBC Driver

v3.2.7 or higher

ODBC Driver

v2.13.11 or higher

Snowflake supports two methods of authenticating:

  • Browser-based SSO

  • Programmatic SSO (only for Okta)

Important

When using SSO with client applications that connect to Snowflake, users must enter their login credentials when prompted; however, for security reasons, these credentials are never processed through the client. Instead, the credentials are sent to the IdP for authentication and the IdP sends back a valid SAML response which enables the client to initiate a Snowflake session.

Browser-based SSO

If users have the required version (or higher) of the Snowflake-provided clients installed, they can use browser-based SSO to log into Snowflake.

How Browser-based SSO Works

When a client application is configured to use browser-based SSO, the application uses the following workflow for user authentication:

  1. The application launches the default web browser in the user’s operating system or opens a new browser tab/window, displaying the authentication page for the IdP.

  2. The user enters their IdP credentials (username and password).

  3. If the user is enrolled in MFA (multi-factor authentication) in Snowflake, they are prompted to type the MFA passcode (sent from another device) or confirm the authentication (on the other device).

  4. After the IdP has authenticated the user’s credentials, the browser displays a success message. The user can then close the browser tab/window (it does not need to be open after authentication), return to the the application, and use the Snowflake session that has been initiated.

Requirements For Using Browser-based SSO

With browser-based SSO, the Snowflake-provided client (for example, the Snowflake JDBC driver) needs to be able to open the user’s web browser. For this reason, the Snowflake-provided client and the client application that uses it need to be installed on the user’s machine. Browser-based SSO does not work if the Snowflake-provided client is used by code that runs on a server.

Setting Up Browser-based SSO

To set up browser-based SSO for authentication, set the authenticator login parameter/option to externalbrowser for the client.

Client

Instructions

SnowSQL

Specify the command line flag --authenticator externalbrowser when starting the client.

Python

Pass authenticator='externalbrowser' to the snowflake.connector.connect() function.

JDBC

Set authenticator=externalbrowser in the connection string for the driver.

ODBC (Linux/macOS)

Set authenticator=externalbrowser in the odbc.ini file.

ODBC (Windows)

Use regedit to set the value in the Windows Registry.

.NET

Set authenticator=externalbrowser in the connection string for the driver.

(Optional) Using Connection Caching to Minimize the Number of Prompts for Authentication

Whenever a client application establishes a new connection to Snowflake, the user is prompted for authentication. This can result in multiple prompts for authentication if the client application establishes a connection multiple times.

To minimize the number of times that a user is prompted for authentication, the account administrator can enable connection caching.

When connection caching is enabled, the client application stores a connection token for use in subsequent connections. For security, the connection token is stored in the keystore for the operating system. Before you enable connection caching, consult with your security team to determine if this complies with your security policies.

Note

Connection caching is optional and is not required for using browser-based SSO.

Snowflake supports connection caching with the following drivers and connectors on macOS and Windows (currently, this feature is not supported on Linux):

  • ODBC driver version 2.21.2 (or later)

  • JDBC driver version 3.12.8 (or later)

  • Snowflake Connector for Python 2.2.8 (or later)

To enable connection caching:

  1. Set the account-level parameter ALLOW_ID_TOKEN to true:

    alter account set allow_id_token = true;
    

    Note

    You must be an account administrator (i.e. a user with the ACCOUNTADMIN role) to enable connection caching.

  2. If you are using the Snowflake Connector for Python, install the optional keyring package by running:

    pip install "snowflake-connector-python[secure-local-storage]"
    

    You must enter the square brackets ([ and ]) as shown in the command. The square brackets specify the extra part of the package that should be installed.

    Use quotes around the name of the package (as shown) to prevent the square brackets from being interpreted as a wildcard.

    If you need to install other extras (for example, pandas for using the Python Connector APIs for Pandas), use a comma between the extras:

    pip install "snowflake-connector-python[secure-local-storage,pandas]"
    

Native SSO — Okta Only

If Okta is your IdP, Snowflake also supports authenticating natively through Okta. This authentication method is useful when you are using SSO with a client that doesn’t have access to a web browser (e.g. connecting programmatically through the Python connector or either the JDBC or ODBC driver).

To enable native SSO through Okta, set the authenticator login parameter/option for the client to the Okta URL endpoint (provided by Okta), typically in the form of https://<your_okta_account_name>.okta.com:

Client

Instructions

SnowSQL

Specify the command line flag --authenticator https://<your_okta_account_name>.okta.com when starting the client.

Python

Pass authenticator='https://<your_okta_account_name>.okta.com' to the snowflake.connector.connect() function.

JDBC

Set authenticator=https://<your_okta_account_name>.okta.com in the connection string for the driver.

ODBC (Linux/macOS)

Set authenticator=https://<your_okta_account_name>.okta.com in the odbc.ini file.

ODBC (Windows)

Use regedit to set the value in the Windows Registry.

.NET

Set authenticator=https://<your_okta_account_name>.okta.com in the connection string for the driver.

Using SSO with MFA

Snowflake supports using MFA in conjunction with SSO to provide additional levels of security:

  • Individual users in Snowflake can enroll in MFA. If a Snowflake user is enrolled in MFA and uses SSO to connect, the MFA login workflow is initiated within the SSO workflow and is required to successfully complete the authentication. For more information about MFA in Snowflake, see Multi-Factor Authentication (MFA).

    Note

    To connect through Okta SSO with MFA, Snowflake requires using browser-based SSO. If you are using native SSO for Okta, MFA is not supported.

  • In addition, your IdP may also support MFA, but this is separate from MFA in Snowflake and must be configured separately through your IdP. If MFA is enabled for your IdP, the IdP determines the workflow. To determine whether your IdP supports MFA and how it is implemented, see the documentation for your IdP.

Using SSO with Multiple Audience Values

Snowflake supports multiple audience values (i.e. Audience or Audience Restriction Fields) in the SAML 2.0 assertion from the identity provider to Snowflake.

This functionality allows customers to include URLs for more than one account, such as an AWS PrivateLink URL and a non-AWS PrivateLink URL. Snowflake accepts the account domain names for the audience values.

Currently, Snowflake supports and accepts up to four different audience values. No configuration is necessary in Snowflake. If it is necessary to include more than four audience values, please contact Snowflake Support.

For help in configuring SAML 2.0 audience values, please contact your organization’s identity provider administrator.