Skip to content

Authentication/Authorization

  • OCSP check is used for validating security certificate issued by Snowflake.
  • OCSP check routes to a private IP for privatelink connections to a cache managed by Snowflake
  • Even for privatelink connections, when driver retrieves large quantities of result stored in S3, it doesn't go over privatelink
  • BP configure VPC private end-point for internal stages
  • Federated authentication types offered:
  • SCIM
  • SAML
  • OAuth
  • Authentication policies allow restricting allowed authentication methods by client type (driver, web, cli etc) at user, security integration or account levels
  • authentication methods: saml, password, oauth, keypair (or all)
  • security integration names are specified when creating the policy, however user and account need to be altered to specify policy
  • External API authentication: allow calling external APIs that require authentication from within Snowflake using SECRET
  • secrets support: Basic and OAuth (code grant and client credential flows)

SCIM

  • allows provisioning Users and Roles (groups in SCIM)
  • SCIM is limited to managing users and roles, but can't grant roles to users
  • Currently supports Okta and Azure AD
  • SCIM limits:
  • tokens expire after 6 months; generating a new token does not invalidate previous token, DROP INTEGRATION is required
  • Snowflake's REST API supports 500 concurrent requests per end-point
    • User/Group: create (POST), get/find (GET), update (PATCH), delete (DEL)
  • Only 10 active SCIM integrations (ref) to prevent brute-force attacks
  • rest_event_history(rest_service_type => 'scim') to get SCIM events

Authentication

  • humans/interactive:
  • SSO using SAML v2
  • applications that are aware and can use Snowflake OAuth (eg Tableau) or external OAuth
  • external browser for desktop application without OAuth support
  • non-interactive/programmatic:
  • built-in password with secret management solution (not recommended)
  • key-pair with secret management
  • external OAuth for SSO based

  • Types of authentications (per Field CTO)

  • Username & Password

  • Username & Password + MFA (Duo)
  • Federated using SAML (SSO)
  • Key pair
  • OAuth, delegated authorization (not technically authentication)
Scenario Basic SAML OAuth Key-Pair
Human Y YY YY Y
Programmatic Y External YY

Federated and SSO

  • Supports most SAML 2.0 IdP
  • Snowflake allows using password authentication along with SSO, but is not recommended
  • if a user's password has expired, the login using SSO will fail too
  • MFA can be used with SSO. Note: IdP may have its own MFA requirement
  • Configured with SSO URL to send SAML requests to, and Certificate from IdP
  • Okta and Microsoft's on-prem AD FS support Snowflake natively. For others, customer must create a custom application for Snowflake in the IdP.
  • Multiple IdPs are supported.
  • Must enable identifier-first login flow
  • Associate users with IdPs: using
    • allowed_user_domains and allowed_email_patterns properties of a security integration associated with the IdP
    • authentication policy by attaching it to each user and specifying which security integrations are available
  • only JDBC, ODBC and Python drivers support multiple IdPs
  • Login: supports IdP or SP initiated logins
  • Logout:
  • Standard: separate logout from IdP and Snowflake; supported by all IdP
  • Global: single logout from IdP and all Snowflake sessions. IdP dependent (e.g. ADFS)
  • timeout: Snowflake timeouts require aunthenticating again for current and new sessions. IdP timeouts do not affect current sessions
  • Only Okta supports programmatic SSO (without MFA), other IdP require browser based authentication
  • Cannot be configured for both public and private facing Snowflake URL
  • SSO authentication requires user to have internet connection to reach the IdP

setup

  1. create SAML2 security integration
  2. Configure SSO login for users (for Snowflake initiated logins)

  3. Configure IdP:

    • Obtain (desc integration...) X509 self-signed (default) certificate or get CA signed one by generating CSR (SYSTEM$GENERATE_SAML_CSR)
    • upload certificate in PEM format

  4. Configure security integration (alter security integration <name> set ...) to:

    • send signed SAML requests (... saml2_sign_request = true)
    • set NameID format (... sam2_requested_nameid_format = '<format>')

  5. Optional

    • force users to reauthenticate (alter sec int ... set saml2_force_authn = true)
    • set custom logout endpoint (URL to redirect after logging out)
    • not applicable to SnowSight

SAML Flow

sequenceDiagram
 autonumber
 participant SP
 actor User
 participant IdP
 User ->> SP: Initiate connection to Snowflake
 SP ->> User: Generate SAML Request and redirect to IdP SSO
 User ->> IdP: Browser redirects to SSO URL
 IdP ->> User: Generate SAML Response, encrypt using SP's X509 Cert, and return
 User ->> SP: Send SAML Response to ACS URL
 SP ->> User: Connection established
  • ACS (Assertion Consumer) URL is same as login URL for Snowflake

Key pair authentication

  • alter user john set rsa_public_key='...'
  • supports encrypted and un-encrypted private keys
  • supports key rotation by setting rsa_public_key_2
  • key types:
  • PKCS#1 / PEM: keys cannot be encrypted, older format, used by SSH, has ----BEGIN RSA PRIVATE KEY---- as header
  • PKCS#8: keys can be encrypted, has ----BEGIN PRIVATE KEY---- as header

MFA

  • supports duo with self enrollment
  • can be push based or user can supply passcode
  • DBA
  • must allow *.duosecurity.com:443 through firewall
  • MINS_TO_BYPASS_MFA: allows users to bypass MFA for specified number of minutes
  • DISBALE_MFA: Cancel's user's MFA enrollment
  • ALLOW_CLIENT_MFA_CACHING: allows MFA tokens to be cached for authentications in quick succession
    • ALLOW_ID_TOKEN relates to SSO tokens

Delegated/OAuth

Capability Snowflake OAuth External OAuth
Role blocking Y
Switch secondary roles - Y
Network policies? Y -
PrivateLink support? only Tableau Y
OAuth flow code grant All
Browser required? Y -

  • OAuth authorizes known or custom applications. Flow:

  • Auth request: Client App -> Snowflake

  • Authentication and Consent: Snowflake -> End-user
  • Access token: Snowflake -> Client App

Snowflake OAuth

sequenceDiagram
  autonumber
  participant App as Client (Application)
  actor U as Resource Owner
  participant Auth as Auth Server
  participant Res as Resource Server
  App ->> Auth: Authorization Request
  Auth ->>+ U: User Authorization Request
  U ->> Auth: User Authorization
  Auth ->> U: User Consent Request
  U ->>- Auth: User Consent
  Auth ->> App: Authorization Code Grant
  App ->> Auth: Access Token Request
  Auth ->> App: Access Token Grant
  App ->> Res: Access Token
  Res ->> App: Resource Access
  • configure: CREATE SECURITY INTEGRATION ... TYPE = OATH OAUTH_CLIENT = <client> ...
  • refresh token is optional with customizable validity of up to 10 hours for desktop/90d for Web
  • can block certain roles, by default blocks ACCOUNTADMIN, SECURITYADMIN
  • Use SHOW DELEGATED AUTHORIZATIONS {BY USER|TO SECURITY INTEGRATION} to list active authorizations
  • TO revoke consent ALTER USER REMOVE DELEGATED AUTHORIZATION

  • Authorization for custom clients:

  • Register the client by creating SECURITY INTEGRATION that defines client ID and client secrets

  • GET on endpoint https://.../oauth/authorize, returns and supply query parameters:

  • code_challenge, a string generated via secret, and

  • redirect_uri, a URL to redirect after authorization

  • scope to limit the role permitted by the access token or specify refresh token behavior

  • redirect_uri receives authorization code in code (along with unmodified state and scope)

  • POST on end-point https://.../oauth/token-request

  • grant_type: can be either authorization_code to exchange authorization code with access code

Authorization

  • DAC (Discretionary Access Control): An owner is also considered data steward and thus can manage privileges granted to others
  • BP limit use of DAC using managed schema
  • RBAC: privileges are assigned to roles, and users are assigned roles
  • predefined roles:
  • AccountAdmin: account administration, create share
  • SysAdmin: can create databases and warehouse
  • Public: pseudo role assigned to everyone
  • UserAdmin: can create users and roles
  • SecurityAdmin: UserAdmin + MANAGE GRANTS
  • On databases: Create Schema, Modify, Monitor, Usage
  • Various levels of permissions
  • USAGE: Use the resource
  • MONITOR: Monitor performance, view definition
  • MODIFY: Modify parameters
  • OPERATE: start/stop

Privilege

  • MONITOR EXECUTION TASK_HISTORY