Authentication policies¶

Use cases¶

The following list describes non-exhaustive use cases for authentication policies:

• You want to control whether a user, all users in an account, or specific authentication methods require MFA.

• You want to control the user login flows when there are multiple login options.

• You want to control the authentication methods, specific client types, and security integrations available for specific users or all users.

• You have customers building services on top of Snowflake using Snowflake drivers, but the customers do not want their users accessing Snowflake through Snowsight or the Classic Console.

• You want to offer multiple identity providers as authentication options for specific users.

Limitations¶

• The CLIENT_TYPES property of an authentication policy is a best effort method to block user logins based on specific clients. It should not be used as the sole control to establish a security boundary.

Considerations¶

• Ensure authentication methods and security integrations listed in your authentication policies do not conflict. For example, if you add a SAML2 security integration in the list of allowed security integrations, and you only allow OAuth as an allowed authentication method, then you cannot create an authentication policy.

• Use an additional non-restrictive authentication policy for administrators in case users are locked out. For an example, see Preventing a lockout.

Security policy precedence¶

When more than one type of security policy is activated, precedence between the policies occur. For example, network policies take precedence over authentication policies, so if the IP address of a request matches an IP address in the blocked list of the network policy, then the authentication policy is not checked, and evaluation stops at the network policy.

The following list describes the order in which security policies are evaluated:

1. Network policies: Allow or deny IP addresses, VPC IDs, and VPCE IDs.

2. Authentication policies - Allow or deny clients, authentication methods, and security integrations.

3. Password policies (For local authentication only): Specify password requirements such as character length, characters, password age, retries, and lockout time.

4. Session policies: Require users to re-authenticate after a period of inactivity

If a policy is assigned to both the account and the user authenticating, the user-level policy is enforced.

Combining identifier-first login with authentication policies¶

By default, Snowsight or the Classic Console provide a generic login experience that provides several options for logging in, regardless if the options are relevant to users. This means that authentication is attempted regardless of whether the login option is a valid option for the user.

You can alter this behavior to enable a identifier-first login flow for Snowsight or the Classic Console. In this flow, Snowflake prompts the user for an email address or username before presenting authentication options. Snowflake uses the email address or username to identify the user, and then only displays the login options that are relevant to the user, and are allowed by the authentication policy set on the account or user.

For instructions for enabling the identifier-first login flow, see Identifier-first login.

The following table provides example configuration on how the identifier-first login and authentication policies can be combined to control the login experience of the user.

Creating an authentication policy¶

An administrator can use the CREATE AUTHENTICATION POLICY command to create a new authentication policy, specifying which clients can connect to Snowflake, which authentication methods can be used, and which security integrations are available to users. By default, all client types, authentication methods, and security integrations can be used to connect to Snowflake. The CLIENT_TYPES property of an authentication policy is a best effort method to block user logins based on specific clients. It should not be used as the sole control to establish a security boundary.

For example, you can use the following commands to create a custom policy_admin role and an authentication policy that only allows authentication using Snowsight or the Classic Console, only allowing an account or user to authenticate using OAuth or a password:

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE DATABASE my_database;
USE DATABASE my_database;

CREATE OR REPLACE SCHEMA my_schema;
USE SCHEMA my_schema;

CREATE ROLE policy_admin;

GRANT USAGE ON DATABASE my_database TO ROLE policy_admin;
GRANT USAGE ON SCHEMA my_database.my_schema TO ROLE policy_admin;
GRANT CREATE AUTHENTICATION POLICY ON SCHEMA my_database.my_schema TO ROLE policy_admin;
GRANT APPLY AUTHENTICATION POLICY ON ACCOUNT TO ROLE policy_admin;

USE ROLE policy_admin;

CREATE AUTHENTICATION POLICY my_example_authentication_policy
  CLIENT_TYPES = ('SNOWFLAKE_UI')
  AUTHENTICATION_METHODS = ('OAUTH', 'PASSWORD');

For detailed examples, see Example login configurations.

Setting an authentication policy on an account or user¶

When you set an authentication policy on an account or user, the restrictions specified in the authentication policy apply to the account or user. You can use the ALTER ACCOUNT or ALTER USER commands to set an authentication policy on an account or user.

In a Snowsight worksheet, use either of the following commands to set an authentication policy on an account or user:

ALTER ACCOUNT SET AUTHENTICATION POLICY my_example_authentication_policy;

ALTER USER example_user SET AUTHENTICATION POLICY my_example_authentication_policy;

Only a security administrator (a user with the SECURITYADMIN role) or users with a role that has the APPLY AUTHENTICATION POLICY privilege can set authentication policies on accounts or users. To grant this privilege to a role so users can set an authentication policy on an account or user, execute one of the following commands:

GRANT APPLY AUTHENTICATION POLICY ON ACCOUNT TO ROLE my_policy_admin

GRANT APPLY AUTHENTICATION POLICY ON USER example_user TO ROLE my_policy_admin

For detailed examples, see Example login configurations.

Hardening user or account authentication using MFA¶

To improve the security of user logins, you can create an authentication policy that requires users to enroll in MFA, and then apply the authentication policy to individual users or the account.

For example, if your users can use SSO or passwords to authenticate, you can harden user logins by creating the following authentication policy and applying it to all users on your account:

CREATE AUTHENTICATION POLICY require_mfa_authentication_policy
  AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
  CLIENT_TYPES = ('SNOWFLAKE_UI', 'SNOWSQL', 'DRIVERS')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD', 'SAML')
  MFA_ENROLLMENT = REQUIRED;

ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_authentication_policy;

Tracking authentication policy usage¶

Use the Information Schema table function POLICY_REFERENCES to return a row for each user that is assigned to the specified authentication policy and a row for the authentication policy assigned to the Snowflake account.

The following syntax is supported for authentication policies:

POLICY_REFERENCES( POLICY_NAME => '<authentication_policy_name>' )

POLICY_REFERENCES( REF_ENTITY_DOMAIN => 'USER', REF_ENTITY_NAME => '<username>')

POLICY_REFERENCES( REF_ENTITY_DOMAIN => 'ACCOUNT', REF_ENTITY_NAME => '<accountname>')

Where authentication_policy_name is the fully qualified name of the authentication policy.

For example, execute the following query to return a row for each user that is assigned the authentication policy named authentication_policy_prod_1, which is stored in the database named my_db and the schema named my_schema:

SELECT *
FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      POLICY_NAME => 'my_db.my_schema.authentication_policy_prod_1'
  )
);

Preventing a lockout¶

In situations where the authentication policy governing an account is strict, you can create a non-restrictive authentication policy for an administrator to use as a recovery option in case of a lockout caused by a security integration. For example, you can include the PASSWORD authentication method for the administrator only. The user-level authentication policy overrides the more restrictive account-level policy.

CREATE AUTHENTICATION POLICY admin_authentication_policy
  AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
  CLIENT_TYPES = ('SNOWFLAKE_UI', 'SNOWSQL', 'DRIVERS')
  SECURITY_INTEGRATIONS = ('EXAMPLE_OKTA_INTEGRATION');

You can then assign this policy to an administrator:

ALTER USER <administrator_name> SET AUTHENTICATION POLICY admin_authentication_policy

Replication of authentication policies¶

You can replicate authentication policies using failover and replication groups. For details, see Replication and security policies.

Example login configurations¶

This section provides examples of how you can use and combine authentication policies and SAML2 security integrations to control login flow and security.

CREATE AUTHENTICATION POLICY restrict_client_type_policy
  CLIENT_TYPES = ('SNOWFLAKE_UI')
  COMMENT = 'Only allows access through the web interface';

ALTER USER example_user SET AUTHENTICATION POLICY restrict_client_type_policy;

CREATE SECURITY INTEGRATION example_okta_integration
  TYPE = SAML2
  SAML2_SSO_URL = 'https://okta.example.com';
  ...

CREATE SECURITY INTEGRATION example_entra_integration
  TYPE = SAML2
  SAML2_SSO_URL = 'https://entra-example_acme.com';
  ...

CREATE AUTHENTICATION POLICY multiple_idps_authentication_policy
  AUTHENTICATION_METHODS = ('SAML')
  SECURITY_INTEGRATIONS = ('EXAMPLE_OKTA_INTEGRATION', 'EXAMPLE_ENTRA_INTEGRATION');

ALTER ACCOUNT SET AUTHENTICATION POLICY multiple_idps_authentication_policy;

Privileges and commands¶