This is the third and last installment of the three-part series on SSO, SAML and user provisioning in general. Today, we’ll focus on SAML and setting up SSO between Snowflake and Azure AD / ADFS.

What Is SAML, ADFS, Azure AD, Okta, Etc.?

​It is useful to understand what SAML is in the context of security, specifically with what we’re trying to do when setting up SSO. In searching for an analogy, I stumbled upon an excellent and surprisingly apt explainer blog on SAML (and IdP, and other related stuff) from Greg Seador at Duo Security here.
​
TL;DR: SAML stands for Security Assertion Markup Language and is a protocol (pre-agreed-upon structure) that Identity Provider (e.g., Azure AD) uses to communicate user access / permissions (digitally signed, XML-based assertions) to the service provider (application user wants to access e.g., Snowflake).
​
Azure AD is a software implementation of that protocol, as is Duo, Okta, ADFS and others.

Why This Blog Post?

​You might be wondering, why on earth – considering there are a few (hundred) resources on the topic especially some written by Snowflake and Microsoft themselves – does this post exist?
​
Fair question.
​
The reason for this blog post’s existence is that, by following the above tutorials step-by-step, I found a couple of gotchas worth mentioning. Moreover, I included a few relevant bits of explanation along the way to help readers better understand the topic, not just to mindlessly and functionally execute steps as directed.
​
To put simply, I’m hoping this blog post adds value to the reader beyond what’s already mentioned in the two tutorials above. Let’s GOOO!

Overview and What You Will Need

​Before you proceed, you’ll need to have the following:

1. Your snowflake instance URL – something like https://company.region.cloud.snowflakecomputing.com or similar
2. You (or your friend) should have accountadmin role granted to them in Snowflake

Broadly, the steps are:

1. Add Snowflake Application on Azure AD
2. Grab certificates and identifiers generated by Azure app
3. Create security integration in Snowflake and populate with values from point above
4. Test integration​

Add Snowflake Application on Azure AD

​Head over to Azure portal, Enterprise applications section, and in the search box search for Snowflake. If you’ve added it previously, it should pop up on the list of the applications already enabled on your account. You may have been following along at home and added application as described in the SCIM blog post; no worries if not, just go ahead and click on the application to open up its properties.
​
If you do not have Snowflake entered into your enabled applications, click on the + button, search for Snowflake and click add.
​
You should be dropped into properties / overview of the application. On the left-hand side click on the Single sign-on section.
​

​
Once on the page above, in the Basic SAML Configuration, hit the pencil button to edit. A new window will slide from the right with the parameters for you to configure basic SAML.

Once you filled the appropriate values in, click Save.
​

Download and Share Certificates and Identifiers with Snowflake

Your screen should look something like below, here you will need to:

1. Download base64 encoded certificate
2. Copy your Login URL (=SAML2_SSO_URL)
3. Copy Azure AD Identifier (=SAML2_ISSUER)
4. (Optional but highly recommended) Logout URL (=SAML2_POST_LOGOUT_REDIRECT_URL)

The latter (logout URL) is optional on the Snowflake side but is recommended to be set. This is because when you log out of one SSO-authenticated application, you rarely then go and log out of all application you logged on to before. This leaves a bunch of orphaned services you’ve logged on to, but not logged out of, something that can potentially be exploited.
​
With the logout URL, not only are you telling Snowflake that your session is finished and you want all your Snowflake-related tokens destroyed, you are also telling your IDP to initiate log out from all services providers connected to that IdP.

Login URL and Azure AD Identifier are basically the reverse of what we’d just configured for Snowflake. Login URL is where Snowflake should redirect users that need logging in, and Identifier is the name of the authority granting access. The same principle as above applies – both these (and certificate, too) should be exactly as Azure specified them. Take care copy/pasting these between applications (I know MS Teams is notorious for adding invisible characters where they don’t belong).
​
Head over to Snowflake UI, open up worksheets,and paste the code below:

use role accountadmin;
​
create security integration my_security_integration_name if not exists
  type = saml2
  enabled = true
  saml2_issuer = '<Azure AD Identifier copied from Azure portal>'
  saml2_sso_url = '<Login URL copied from Azure portal>'
  saml2_provider = '<CUSTOM or ADFS -- should not make practical difference>'
  saml2_x509_cert = '<Paste the content of downloaded certificate from Azure portal>'
  saml2_enable_sp_initiated = true -- set this to false if you don't want to make "login with SSO" button to appear on the login page immediately
  saml2_post_logout_redirect_url = '<Paste Logout URL copied from Azure portal>'
  
;

Test SAML Integration Works Correctly

If you have set saml2_enable_sp_initiated = false above, when you log out of Snowflake and get redirected back to Snowflake login page, you likely would not notice any difference.
​
To test the SP-initiated login process, add console/login?fedpreview=true to the path of your URL, like so: https://company.region.cloud.snowflakecomputing.com/console/login?fedpreview=true.
​
You now should see new button appear at the top of the login box prompting you to sign in with SSO. You can add a custom message to the button if you like, using:

alter security integration my_security_integration_name 
  set SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'Button text goes here'
;

​
If you have followed along at home, have already setup SCIM integration, and have checked that your AD users and groups are syncing with Snowflake fine, you can now try clicking that button and using SSO to connect.
​
Don’t forget to set saml2_enable_sp_initiated parameter on your security integration if you haven’t already:

alter security integration my_security_integration_name
  set saml2_enable_sp_initiated = true
;
​
alter account set sso_login_page = true;

Et Voilà

​And there it is folks: You should now have a fully working SAML-based SSO authentication path to Snowflake as your Service Provider using Azure AD as your Identity Provider. Together with SCIM, you should have a holistic approach to creating and managing users and roles, as well as authenticating users against a single source of identity.