- Mar 22, 2022
- 7 min read

Federated Authentication And SSO Using OKTA

Updated: Mar 16

Authors: Lakkireddy Venkata Sita Rami Reddy & Arvind Chaudhary

This blog provides information about implementing federated authentication in Snowflake using OKTA. It also briefly explains creating users, creating roles, and assigning roles to users in Snowflake through OKTA.

Introduction:

SSO:

Single Sign-On will enable the users to access the application within one domain.

FEDERATED AUTHENTICATION:

Federated Authentication will enable the users to use the same identity to access all their applications. It enables Single Sign-On to multiple applications across different domains.

Federated Authentication uses external entities for authentication. Using this, users can access the Snowflake web interface without providing Snowflake account credentials. In the login screen, the user needs to select an option - Sign In using OKTA and authenticate. Once that is done, users will be granted access to Snowflake.

OKTA SCIM INTEGRATION WITH SNOWFLAKE:

SCIM(System for Cross-domain Identity Management) helps in the automated management of user groups (roles) in cloud applications. We can manage Snowflake users and roles through OKTA. Through OKTA, users and roles can be created, updated, and deleted in Snowflake. Roles can also be assigned to users in Snowflake through OKTA.

Supported features:

Push New Users: New users that are created in OKTA will also get created in Snowflake.

Push Profile Updates: Any changes made to the user profile through OKTA will be pushed to Snowflake.

Push User Deactivation: If a user is deactivated through OKTA they will get deactivated in Snowflake also.

Reactivate Users: Accounts of users can be reactivated in Snowflake through OKTA.

Sync Password: If required, Passwords can be pushed into Snowflake from Okta,

Push Groups: This feature can be used to create roles in Snowflake and manage them. If a group is created in OKTA, a role will be created in Snowflake with the same name. OKTA can’t manage existing roles in Snowflake, which OKTA does not create. So it is better to create roles using OKTA and push them to Snowflake.

OKTA Account set up:

1. Use the link given below to create an OKTA account.

https://www.okta.com/free-trial/customer-identity/

2. Provide the Work Email, First Name, Last Name, and Country details in respective fields. Now click on Get Started.

3. A mail will be sent for activating the OKTA account. Click on the Activate Button and set a password for your account.

4. Once you are logged into OKTA, click on Dashboard. You will be redirected to the screen shown in the image below.

Adding Snowflake as an SSO app in OKTA:

1. Now we have to add an SSO app. For that, click on the SSO Apps option, which can be seen in the dashboard. Next, click on Browse App Catalog.

2. Search for Snowflake there and click add.

3. You will be redirected to the general settings tab. Here you have to enter the subdomain of the snowflake account and click on next.

4. In the “Sign-On options” page select SAML 2.0 and uncheck disable force authentication. Open the “preview SAML” and “View Setup Instructions” links we will use in further steps. Now click on “Done”.

Configure Snowflake Account for OKTA:

1. Let us configure Snowflake for using federated authentication. For that, log in to Snowflake account using Account Admin Role or Security Admin Role.

2. Open the worksheet in Snowflake and follow the steps mentioned below

To enable an IdP(OKTA) for federated authentication, Snowflake requires an Authentication certificate and URL endpoint for SAML requests from IDP.

use role accountadmin;

show parameters like 'SAML_IDENTITY_PROVIDER';

--The code given below sets OKTA as IDP for our Snowflake account.

/*You can get the details of the certificate, issuer, ssoUrl from the setup instructions link that we opened previously*/

alter account set saml_identity_provider ='{

"certificate": "paste certificate here",

"issuer": "paste entity id here",

"ssoUrl": "paste sso url here",

"type : "OKTA",

"label" : "LoginusingOKTA"

}';

/* In snowflake, there is a parameter named sso_login_page. By setting this value to true, users will be able to see the button for logging in through OKTA.*/

use role accountadmin;

alter account set sso_login_page=true;

/*For configuring the integration, users have to use the command CREATE SECURITY INTEGRATION with ACCOUNT ADMIN role*/

use role accountadmin;

CREATE SECURITY INTEGRATION OKTAINTEGRATION

TYPE = SAML2

ENABLED = TRUE

SAML2_ISSUER ="paste entity id here"

SAML2_SSO_URL ="paste sso url here"

SAML2_PROVIDER = OKTA

SAML2_X509_CERT = "paste certificate here"

SAML2_SP_INITIATED_LOGIN_PAGE_LABEL ="OKTA SSO"

SAML2_ENABLE_SP_INITIATED = TRUE;

/*setup ACS and issuer URL

Edit the integration object that was created previously to add Snowflake ACS URL and Snowflake SAML2 Issuer URL.*/

use role accountadmin;

alter security integration my_integration set saml2_snowflake_acs_url = 'https://<organization name>-<account name>.snowflakecomputing.com/fed/login';

alter security integration my_integration set saml2_snowflake_issuer_url = 'https://<organization name>-<account name>.snowflakecomputing.com';

3. For working with external IDP, we have to make sure that the login name in Snowflake matches the login name in OKTA. If they don't match, change the login name for users in snowflake.

Configuring Snowflake for SCIM

1. Use ACCOUNTADMIN role. use role accountadmin;

2. Create a custom role OKTA_PROVISIONER. All the roles and users created by OKTA in Snowflake will be owned by the OKTA_PROVISIONER role.

create role if not exists okta_provisioner;

grant create user on account to role okta_provisioner;

grant create role on account to role okta_provisioner;

3. Granting okta_provisioner role to Account Admin role and creating security integration through it.

grant role okta_provisioner to role accountadmin;

create or replace security integration okta_provisioning

type = scim

scim_client = 'okta'

run_as_role = 'OKTA_PROVISIONER';

4. Copy the authorization token that we get by running the command below.

Select system$generate_scim_access_token('OKTA_PROVISIONING');

Run all the scripts given in the below image in your Snowflake worksheet.

All roles and users created by OKTA in Snowflake will be owned by the okta_provisioner role.

For managing existing Snowflake users:

1. Transfer ownership to the okta_provisioner role. use role accountadmin;

grant ownership on user <user_name> to role okta_provisioner;

2. For existing users, make sure the login_name property is set, which should be already set if these existing Snowflake users are using OKTA SSO.

OKTA Configuration for SCIM

In OKTA, from the dashboard, click on apps and select Snowflake application. Perform the steps given below

1. In the provisioning tab, select Integration

2. Click on Configure API Integration, check the enable API integration box, and paste the API token that we copied previously. Save it.

3. Select the option “To App” from the left-hand menu and edit the Provisioning Features you want. Enable all of them and save them.

4. In Attribute Mappings, The defaultSecondaryRoles, default role, and default warehouse attributes are unmapped. If you need, you can map them using OKTA profile or expression or set the same value for all users.

Creating Users in OKTA and assigning Snowflake:

1. Move to the Dashboard in OKTA and click on users.

2. You will be redirected to the screen shown in the image below.

3. Click on the “Add person” option to add users. Fill in all the details. Let the user set the password, so give the option ”Set by user” for the password. Check the box “send user activation email now” and save it.

4. Now users will be receiving an email to activate the OKTA account. They activate their account and set a new password.

5. Follow the same steps and add other users.

6. From the Dashboard in OKTA and click SSO apps-> select Snowflake. You will be redirected to the screen shown in the image below.

7. We have to assign the snowflake app to users. For that, click on assign and select assign to people. Let’s assign it to the first-person now.

8. Click on Assign, which is present on the right side of the first name. It will now ask to enter the Default role and warehouse. You can give it if you want to. Now click on save and go back. In the same way, you can do it for other users. I’ll show other ways to assign Snowflake to users in the next concept.

Creating Roles in OKTA and adding users, and applications:

1. Move to the Dashboard in OKTA and click on groups.

2. Click “Add Group” and give the name of the role that you want to create. Save it.

3. Open the Dev_Role and assign people by clicking on the “Assign people” option. Here I assigned one user. Save it after adding as many users as needed. Adding users to a group(Dev_Role) means granting the role(Dev_Role) to the users who are added to this group.

4. After Saving, Click on the Applications tab. Click on assign applications.

5. Select Snowflake from the list and click Assign. You will be asked to enter the Default role and warehouse. It is optional to add those details. Click “Save and go back” and “Done”. By doing this, we gave access to Snowflake application to all the users who are added to the “Dev_Role” group.

6. In the same way, I created one group with the name Analyst_Role and added two users to it. I also added Snowflake application to this group.

Group push:

Group Push is used to push existing OKTA groups and their memberships to third-party applications for which the provisioning is enabled.

1. Click on Applications -> Applications from the home screen.

2. Click the Snowflake application in the list.

3. Click on the Push Groups tab.

4. Select the option “ find groups by name” and search for a group name. Save and add other groups as well.

5. You can see the push status as active once they are pushed to Snowflake.

6. You can find different options by clicking on the dropdown next to Active.

Deactivate group push: This option is used to pause synchronization. Even if new members are added to the group, they won't appear in the Snowflake.
Unlink pushed group: This option permanently removes the group from the app and OKTA.
Delete the group in the target app: Selecting this option will delete the group and all its memberships. Click Unlink.
Leave the group in the target app: This will stop pushing new memberships but keeps the group in the target app. Click Unlink.
Push Now: Select this to push memberships immediately and synchronize OKTA and the target app.

7. In our snowflake application, we will be able to see all the users and roles that we created using OKTA.

Logging into Snowflake Using SSO:

1. We have triggered emails to activate the OKTA account for all the users. Once users activate accounts and log in to OKTA they can access the Snowflake web interface by clicking on the Snowflake application.

2. If users try to log in using their Snowflake account URL, they will be able to see an option “Sign in using OKTA”

3. They can click on that option and log in using OKTA credentials.

The next time, users can directly access the Snowflake web interface without providing credentials just by clicking on sign-in using OKTA. Users will also be assigned roles, Default roles, and Default warehouse if any of them are assigned in OKTA.