Okta SCIM integration with Snowflake¶

Features¶

User and Role Administration is supported for the Snowflake application.

This enables Okta to:

• Manage the user lifecycle (i.e. create, update, and delete) in Snowflake.

• Manage the role lifecycle (i.e. create, update, and delete) in Snowflake.

• Manage user to role assignments in Snowflake.

The following provisioning features are supported:

Push New Users:

New users created through OKTA will also be created in Snowflake.

Push Profile Updates:

Updates made to the user’s profile through OKTA will be pushed to Snowflake.

Push User Deactivation:

Deactivating the user or disabling the user’s access to Snowflake through OKTA will deactivate the user in Snowflake.

Note

For Snowflake, deactivating a user means setting the DISABLED property for the user to TRUE.

Reactivate Users:

User accounts can be reactivated Snowflake.

Sync Password:

User password can be pushed from Okta into Snowflake, if required.

Tip

The default setting is to create a random password for users giving the user an attribute setting of has_Password=true. Without a password, users must access Snowflake through Okta SSO. To prevent a password being generated for users, turn this setting off before provisioning users as follows:

1. Click Edit.

2. Under Sync Password, uncheck the setting Generate a new random password whenever the user’s Okta password changes.

3. Save the change.

Enabling this setting in Okta creates a password for the user to access Snowflake. This could result in a pathway for users to access Snowflake without SSO.

To disable password synchronization, unset this option in Okta and update the Snowflake Okta SCIM security integration to set the SYNC_PASSWORD property to False.

Push Groups:

The Push Groups feature creates roles in Snowflake and facilitates role management. The roles created in Snowflake using Okta Push Groups have the same names in Okta and Snowflake. Always create roles in Okta first and use Push Groups to update Snowflake to ensure Okta and Snowflake can synchronize. Okta and the OKTA_PROVISIONER custom role in Snowflake cannot manage manually created roles in Snowflake. Push Groups do not create users in Snowflake.

Tip

Okta can create users in Snowflake if the Snowflake application in Okta is assigned to a user in Okta.

For more information, see Assign an application to a user.

The following user attributes are supported:

Prerequisites¶

1. Before provisioning users or groups, ensure that the network policy in Snowflake allows access from Okta’s IP addresses documented here. For more information, see Managing SCIM Network Policies.

2. Before you configure provisioning for Snowflake, make sure you have configured the General Settings and any Sign-On Options for the Snowflake application in Okta.

Once the above steps are complete, click Next in Okta to take you back to the Provisioning tab.

Configuration steps¶

The configuration process requires completing steps in Snowflake and in Okta.

use role accountadmin;
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;
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
    type = scim
    scim_client = 'okta'
    run_as_role = 'OKTA_PROVISIONER';
select system$generate_scim_access_token('OKTA_PROVISIONING');

Enabling Snowflake-initiated SSO¶

The SCIM provisioning process does not automatically enable single sign-on (SSO).

To use SSO after the SCIM provisioning process is complete, enable Snowflake-initiated SSO.

Managing SCIM network policies¶

Applying a network policy to a SCIM security integration allows the SCIM network policy to be distinct from network policies that apply to the entire Snowflake account. It allows the SCIM provider to provision users and groups without adding IP addresses to a network policy that controls access for normal users.

A network policy applied to a SCIM integration overrides a network policy applied to the entire Snowflake account, but is overridden by a network policy assigned to a user.

After creating the SCIM security integration, create the SCIM network policy using this command:

alter security integration okta_provisioning set network_policy = <scim_network_policy>;

Copy

To unset the SCIM network policy, use this command:

alter security integration okta_provisioning unset network_policy;

Copy

Where:

okta_provisioning

Specifies the name of the Okta SCIM security integration.

scim_network_policy

Specifies the Okta SCIM network policy in Snowflake.

For more information, see Controlling network traffic with network policies and ALTER SECURITY INTEGRATION.

Using secondary roles with SCIM¶

Snowflake supports setting the user property DEFAULT_SECONDARY_ROLES to 'ALL' with SCIM to allow users to use secondary roles in a Snowflake session.

For a representative example, see Update a user.

Replicating the Okta SCIM security integration¶

Snowflake supports replication and failover/failback with the SCIM security integration from the source account to the target account.

For details, see Replication of security integrations & network policies across multiple accounts.

Troubleshooting¶

• Transferring ownership. If the user update fails, check the ownership of the user in Snowflake. If it is not owned by the okta_provisioner role (or the role set in the run_as_role parameter when creating the security integration in Snowflake), then the update will fail. Transfer the ownership by running the following SQL statement in Snowflake and try again.

  grant ownership on user <username> to role OKTA_PROVISIONER;
  

  Copy

• Ensure login_name property is set for existing users which should already be set if these existing Snowflake users are using Okta SSO.

• To verify that Okta is sending updates to Snowflake, check the log events in Okta for the Snowflake application and the SCIM audit logs in Snowflake to ensure Snowflake is receiving updates from Okta. Use the following to query the Snowflake SCIM audit logs.

  use role accountadmin;
  use database demo_db;
  use schema information_schema;
  select * from table(rest_event_history('scim'));
  select *
      from table(rest_event_history(
          'scim',
          dateadd('minutes',-5,current_timestamp()),
          current_timestamp(),
          200))
      order by event_timestamp;
  

  Copy

• It is possible that an authentication error may occur during the provisioning process. One possible error message is as follows:

  Error authenticating: Forbidden. Errors reported by remote server: Invalid JSON: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@4c76ba04; line: 1, column: 2]
  

  Copy

  If this error message or other authentication error messages occur, try this troubleshooting procedure:

  1. In Okta, remove the current Snowflake application and create a new Snowflake application.

  2. In Snowflake, create a new SCIM security integration and generate a new access token.

  3. Copy the new token by clicking Copy.

  4. In Okta, paste and verify the new access token as described in how to configure Okta as a SCIM identity provider.

  5. Provision users and roles from Okta to Snowflake using the new Snowflake application in Okta.

Next topics:

• SCIM API references