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)
1. Username & Password
2. Username & Password + MFA (Duo)
3. Federated using SAML (SSO)
4. Key pair
5. 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 ¶

create SAML2 security integration
Configure SSO login for users (for Snowflake initiated logins)
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
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>')
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:
1. Auth request: Client App -> Snowflake
2. Authentication and Consent: Snowflake -> End-user
3. Access token: Snowflake -> Client App

Snowflake OAuth¶

sequenceDiagram
    autonumber
    participant App as Client (Application)
    actor U as Res 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:
1. Register the client by creating SECURITY INTEGRATION that defines client ID and client secrets
2. 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
3. redirect_uri receives authorization code in code (along with unmodified state and scope)
4. 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
  - not-grantable permissions: kill session/query, network policies, replication configuration
- 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

Authentication/Authorization¶

SCIM¶

Authentication¶

Federated and SSO¶

setup¶

SAML Flow¶

Key pair authentication¶

MFA¶

Delegated/OAuth¶

Snowflake OAuth¶

Authorization¶

Privilege¶

setup ¶