Analyze Direct uses the Snowflake Data Warehouse platform to present your LMS data. Snowflake supports numerous connection methods to help clients secure access for their users. This article outlines available methods and provides links to relevant documentation.

Network Policy

By default, Users can connect from any computer or device IP address. A Network Policy enables you to restrict access to a predefined set of IP addresses.

To define a Network Policy, you must compile a list of IP addresses (or ranges of IP addresses) that will be allowed to connect. Optionally, you can also provide a list of IP addresses to explicitly block.

Ranges should be specified using Classless Inter-Domain Routing (CIDR) notation. You can read more about these specifications here. 

Once you have created your allowed (and optionally blocked) IP address list, email your Absorb representative to implement and test your network policy.

Key Pair Authentication

Key Pair Authentication can be used to enhance security beyond the basic authentication provided by a username and password.

Start by reviewing supported Snowflake access clients to ensure your connection provider allows for key pair authentication. More information can be found in Snowflake's Key-pair authentication and rotation article under Supported Snowflake clients.

An asymmetric key pair needs to be generated for the user account that is connecting to Snowflake. The public key is applied to the user in Snowflake, while the private key is retained by the application connecting to Snowflake.

You can learn more about key pair generation in Snowflake's key pair documentation. 

Once you have generated your public key, email your Absorb representative with the key value and name of the Snowflake user to assign and verify the public key. You can then configure your Snowflake client to use key pair authentication utilizing your private key.

Key Pair Rotation

You can associate a second active public key with a single user to prevent service interruption if your security policies require a rotation schedule for keys.  Your Absorb representative can update the user assignment with your new public key, without removing the existing public key. Once you have tested your Snowflake client with your new private key, email your Absorb representative and they will remove the old public key.

OAuth

OAuth (Open Authorization) is an open-standard protocol that allows access to protected resources without sharing or storing user login credentials. You can review Snowflake's OAuth documentation for more information.

Snowflake supports two different kinds of OAuth 2.0: Snowflake OAuth and External OAuth. Below, we've outlined a list of supported applications or servers for each protocol type. 

OAuth (Snowflake)

Snowflake OAuth uses Snowflake’s built-in OAuth service and supports the following applications:

• Tableau Desktop, Tableau Server, and Tableau Online
• Looker
• Alation
• ThoughtSpot
• Custom clients configured by your organization

OAuth (External)

External OAuth integrates with your custom OAuth 2.0 server and supports the following OAuth servers, applications, and custom clients:

• Okta
• Microsoft Azure AD
• Ping Identity PingFederate
• Microsoft Power BI
• Sigma
• External OAuth Custom Clients

To Implement OAuth, email your Absorb representative to start defining the required integration and implementation plan.

SAML 2

Snowflake supports most SAML (Security Assertion Markup Language) 2.0 compliant Identity Providers (IdP), with the following providing native Snowflake support for federated authentication and Single Sign-On (SSO):

• Okta
• Microsoft Active Directory Federation Services (ADFS)

Snowflake also supports using many popular SAML 2.0-compliant vendors such as:

• Google G Suite
• Microsoft Azure Active Directory
• OneLogin
• Ping Identity PingOne

To use an IdP other than Okta or ADFS, you must define a custom application for Snowflake in the IdP. This process requires the engagement of your internal IT department.

SSO Workflows

SSO can be used to define workflows that control logging into Snowflake, logging out of Snowflake, and system timeout due to inactivity. In addition, SSO with private connectivity is supported SAML2 failover/failback can be configured.

To implement SSO, engage your Absorb representative to define the workflow and implementation plan based on.