One of our fundamental principles at Satori is preserving your existing access control configurations and tools. Leveraging the identity context as defined in your Identity Access Management (IAM) is essential in upholding this value. In this post, we explain how to connect Azure Active Directory with Snowflake to Satori as well as how to enrich Satori with predefined AzureAD groups for the purpose of delivering identity contextualized analytics and granular access control policies.
When using AzureAD SSO to access Snowflake, organizations must update their SSO configuration in AzureAD to point to the Satori generated hostname.
Prerequisites
There are two required prerequisites for this process:
- Permissions to update the Enterprise Application settings in AzureAD
- ACCOUNTADMINor SECURITYADMIN role in SnowFlake
What to Expect?
Completing the following procedure will cause all access to Snowflake with AzureAD SSO to pass through Satori. All data access will then be audited, classified, and subject to access control policies as defined in Satori.
Configuring Satori and Azure AD
Follow these 12 steps in order to configure the SAML integration:
- Go to the Satori management console
- Select the Identity Providers section, click Add, and then select AzureAD
- Select the Snowflake data store for which you would like to configure the integration
- In a new browser window, navigate to your AzureAD console and access the Enterprise Application view
- Select the application you use to enable access to a Satori-protected data store
- Select the Single sign-on view and click Edit in the Basic SAML Configuration section
- Change the Identifier (Entity ID) field to match the Satori Identifier (Entity ID), as displayed in the Satori management console. For example, change the ID From: https://xxx.snowflakecomputing.com To: https://xxx.us-west-1.a.p0.satoricyber.net
- Change the Reply URL (Assertion Consumer Service URL) field to match the Satori Reply URL (Assertion Consumer Service URL) as shown in the Satori management console. For example, change the field From: https://xxx.snowflakecomputing.com/fed/login To: https://xxx.us-west-1.a.p0.satoricyber.net/fed/login
- In the SAML Signing Certificate section, download the Certificate (Base64) file
- In the Satori Management Console, upload the certificate file from the previous step to the SAML Signing Certificate (Azure) field
- Copy the Login URL and AzureAD Identifier fields from the Setup section in AzureAD
- Update the Login URL and AzureAD Identifier fields in the Satori management console with the inputs you copied in the previous step
Configuring Snowflake
In order for Snowflake to accept authentication requests from AzureAD using the Satori-generated hostname, you need to update the saml_identity_provider account parameter. Copy the entire content of the Snowflake Statement to Execute from the Satori management console and run it as ACCOUNTADMIN in Snowflake.
Enriching Satori Identity with Azure Groups
Satori can utilize the identity context, as defined and modeled in your Azure Active Directory, for analytics and access control policies.
Follow these five steps in order to transfer identity context information about your data users from AzureAD to Satori:
- Go to your AzureAD console and access the Enterprise Application view.
- Select the application you use to enable access to a Satori-protected data store.
- Select the Single sign-on view and click Edit in the User Attributes & Claims section.
- Select Add a Group Claim and, in the Group Claims panel, choose which groups associated with the user to send in the claim.
In the Advanced options section, check the “Customize the name of the group claim” checkbox and enter groups in the Name field.
AzureAD groups are shown in Satori by their unique ID, for example: 1053707e-fdac-4af7-8d98-2347dfd79052.
After following these straightforward steps, you are all set. From now on, you can access your Snowflake with AzureAD as well as use your existing group ID as an attribute in the Satori Universal Audit reports, for analytics purposes, or as an identity context tag for defining new data access policies.
