# Replication of Security Integrations & Network Policies Across Multiple Accounts¶

This topic provides information on how to replicate security integrations, along with using failover/failback with each of these objects, and assumes familiarity with replication and failover/failback with other account-level objects (e.g. users, roles, warehouses).

For details, see Account Replication and Failover.

These objects and services are supported across regions and across cloud platforms.

In this Topic:

## Overview¶

Snowflake supports replicating network policies and security integrations for federated SSO (i.e. SAML2), OAuth, and SCIM along with enabling failover/failback for each network policy and integration.

The general approach to test replication and failover/failback with each network policy and security integration is as follows:

1. Identify the source account and target account for replication, and identify the connection URL.

2. Complete steps in the source account.

3. Complete steps in the target account.

4. Test failover/failback.

Note that because network policies and security integrations have different use cases, the exact steps for the source account and target account with respect to each object differ slightly.

For details, see:

## SAML2 Security Integrations¶

Replicating a SAML2 security integration links the source account and the target account to the identity provider by specifying the connection URL in the SAML2 security integration definition.

It is important to update the identity provider to specify the connection URL and that users exist in the source account. Without these updates, user verification cannot occur, which will result in the inability of the user to access the target account.

Current Limitation

For SAML SSO to Snowflake, replicating a SAML2 security integration that specifies the connection URL is only supported on the current primary connection and not supported on the secondary connection. Note that for failover, the result is promoting a secondary connection to serve as the primary connection. After failover, SAML SSO works on the new primary connection.

If SAML SSO is needed for both primary and secondary connections, then create and manage SAML2 security integrations independently on both Snowflake accounts.

For this procedure, assume the following:

• Source account: https://example-northamericawest.snowflakecomputing.com/

• Target account: https://example-northamericaeast.snowflakecomputing.com/

• Connection URL: https://example-global.snowflakecomputing.com

• A secondary connection does not exist in the target account.

The following steps are a representative example to show how do to the following:

• Replicate a SAML2 security integration from the source account to the target account.

• Test failover.

• Promote the secondary connection in the source account to serve as the primary connection.

Source account steps (includes IdP steps):

1. If the source account is already configured for Database Failover/Failback and Client Redirect, skip to the next step.

Otherwise, enable failover using an ALTER CONNECTION command:

alter connection global
enable failover to accounts example.northamericaeast;

2. Using Okta as a representative example for the identity provider, create a Snowflake application in Okta that specifies the connection URL. Update the Okta fields as follows:

• Label: Snowflake

• Subdomain: example-global

• Browser plugin auto-submit: Check the box to enable automatic login when a user lands on the login page.

3. In the source account, update the SAML2 security integration to specify the connection URL for the saml2_snowflake_issuer_url and saml2_snowflake_acs_url security integration properties.

create or replace security integration my_idp
type = saml2
enabled = true
saml2_issuer = 'http://www.okta.com/exk6e8mmrgJPj68PH4x7'
saml2_sso_url = 'https://example.okta.com/app/snowflake/exk6e8mmrgJPj68PH4x7/sso/saml'
saml2_provider = 'OKTA'
saml2_x509_cert='MIIDp...'
saml2_enable_sp_initiated = true
saml2_snowflake_issuer_url = 'https://example-global.snowflakecomputing.com'

4. In Okta, assign the Snowflake application to users. For details, see Assign an app integration to a user.

5. Verify that SSO to the source account works for users that are specified in the Snowflake application in Okta and users in the source account.

Note that SSO should work for both IdP-initiated and Snowflake-initiated SSO flows. For details, see Supported SSO Workflows.

6. In the source account, if a failover group does not already exist, create a failover group to include security integrations. Note that this example is representative and includes other account objects that might or might not be necessary to replicate.

If a failover group already exists, alter the failover group to include integrations.

create failover group FG
object_types = users, roles, warehouses, resource monitors, integrations
allowed_integration_types = security integrations
allowed_accounts = example.northamericaeast
replication_schedule = '10 MINUTE';


Target Account Steps:

1. Prior to replication, verify the number of users and security integrations that are present in the target account by executing the SHOW USERS and SHOW INTEGRATIONS commands, respectively.

2. Create a secondary connection. For details, see CREATE CONNECTION.

create connection GLOBAL as replica of example.northamericawest.global;

3. Create a secondary failover group in the target account. For details, see CREATE FAILOVER GROUP.

create failover group fg
as replica of example.northamericawest.fg;

4. When creating a secondary failover group, an initial refresh is automatically executed.

To manually refresh a secondary failover group in the target account, execute the following statement. For details, see ALTER FAILOVER GROUP command.

alter failover group fg refresh;

5. If the refresh operation was successful, the target account should include new users that were added to the source account and not previously present in the target account. Similarly, the target account should include the SAML2 security integration that specifies the connection URL.

Verify the refresh operation was successful by executing the following commands:

6. Promote the secondary connection in the target account to serve as the primary connection. After executing the following command, users can use SAML SSO to authenticate to the new target account.

alter connection global primary;


## SCIM Security Integrations¶

Replicating a SCIM security integration allows the target account to incorporate SCIM updates that are made to the source account (e.g. adding new users, adding new roles) after refreshing the target account.

After replicating the SCIM security integration, both Snowflake accounts have the ability to receive SCIM updates from the identity provider. However, Snowflake allows specifying only one account as the primary (i.e. source) account and it is the primary account that receives SCIM updates from the identity provider.

You can optionally designate a different account as the primary account to receive SCIM updates after replicating the SCIM integration. Note that the target account can receive SCIM updates from the source account only after refreshing the target account.

For this procedure, assume the following:

• Source account: https://example-northamericawest.snowflakecomputing.com/

• Target account: https://example-northamericaeast.snowflakecomputing.com/

• Connection URL: https://example-global.snowflakecomputing.com

• A secondary connection exists in the target account (i.e. only refresh operations are needed).

The following steps are a representative example to show how do to the following:

• Replicate a SCIM security integration from the source account to the target account.

• Add a new user in Okta, push the new user to the source account, and replicate the new user to the target account.

• Refresh the failover group.

• Promote the secondary connection in the target account to serve as the primary connection.

Source account steps:

1. Execute SHOW CONNECTIONS to verify that the connection in the source account is the primary connection. If it is not the primary connection, use the ALTER CONNECTION command to promote the connection in the source account to serve as the primary connection.

2. If an Okta SCIM security integration is already configured in the source account, skip to the next step.

Otherwise, configure an Okta SCIM security integration in the source account.

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');


Be sure to update the Okta SCIM application for Snowflake. For details, see Okta Configuration.

3. In Okta, create a new user in the Okta application for Snowflake.

Verify the user is pushed to Snowflake by executing a SHOW USERS command in Snowflake.

4. If the failover group already specifies security integrations, skip to the next step. This would be true if you have already configured the failover group for the purposes of SAML SSO in the target account (in this topic).

Otherwise, modify the existing failover group using an ALTER FAILOVER GROUP command to specify security integrations.

alter failover group fG set
object_types = users, roles, warehouses, resource monitors, integrations
allowed_integration_types = security integrations;

5. At this point, you can optionally refresh the secondary failover group as shown in the target account steps for SCIM to ensure the new user in the source account is in the target account.

Choosing to refresh the secondary failover group now allows for an easy check to make sure that the change to the source account, adding a new user in this sequence, is visible in the target account.

However, if you need or prefer to do additional work in the identity provider, such as modifying other users or updating role assignments, you can continue doing that work now and then refresh the secondary failover group in one operation later.

Target account steps:

1. Prior to replication, verify the number of users and security integrations that are present in the target account by executing the SHOW USERS and SHOW INTEGRATIONS commands, respectively.

2. Refresh the secondary failover group to update the target account to include the new user (and any other changes that were made in Okta and the source account).

alter failover group fg refresh;

3. Verify that the new user is added to the target account by executing a SHOW USERS command.

4. Optionally, promote the secondary failover group and the secondary connection in the target account to primary. This will promote the target account to serve as the new source account.

Failover group:

alter failover group fg primary;


Connection:

alter connection global primary;


## OAuth Security Integrations¶

Replicating OAuth security integrations includes both Snowflake OAuth security integrations and External OAuth security integrations.

Note the following:

Snowflake OAuth

After replication and configuring failover/failback, a user connecting to either the source account or target account via an OAuth client does not need to re-authenticate to the target account.

External OAuth

After replication and configuring failover/failback, a user connecting to either the source account or target account via an OAuth client might need to re-authenticate to the target account.

Re-authentication is likely to be necessary if the OAuth authorization server is not configured to issue a refresh token. Therefore, ensure that the OAuth authorization server issues refresh tokens so that the OAuth client can connect to the source and target Snowflake accounts.

For this procedure, assume the following:

• Source account: https://example-northamericawest.snowflakecomputing.com/

• Target account: https://example-northamericaeast.snowflakecomputing.com/

• Connection URL: https://example-global.snowflakecomputing.com

• A secondary connection exists in the target account (i.e. only refresh operations are needed).

• The Snowflake OAuth or External OAuth security integrations already exist in the source account.

The following steps are a representative example to show how do to the following:

• Replicate an OAuth security integration.

• Refresh the failover group.

• Promote the secondary connection in the target account to serve as the primary connection.

Source account steps:

1. If the failover group already specifies security integrations, skip to the next step. This would be true if you have already configured the failover group for the purposes of SAML SSO in the target account (in this topic) or SCIM (also in this topic).

Otherwise, modify the existing failover group using an ALTER FAILOVER GROUP command to specify security integrations.

alter failover group fG set
object_types = users, roles, warehouses, resource monitors, integrations
allowed_integration_types = security integrations;


Target account steps:

1. Refresh the secondary failover group to update the target account to include the OAuth security integration objects.

alter failover group fg refresh;

2. Verify connecting to each Snowflake account using the OAuth client of your choice.

3. Optionally, promote the secondary failover group and the secondary connection in the target account to primary. This will promote the target account to serve as the new source account.

Failover group:

alter failover group fg primary;


Connection:

alter connection global primary;

4. If you completed the previous step, reverify that you can connect to each Snowflake account using the OAuth client of your choice.

## Network Policies¶

Replicating a network policy from the source account to the target account allows administrators to restrict access to the target account based on the user IP address when connecting to Snowflake.

Replicating the network policy replicates the network policy object and any network policy references/assignments. For example, if a network policy is assigned to a user and the user exists in both the source and target accounts, replicating the network policy assigns the network policy to the user in the target account.

Network policy replication also applies to network policies that are specified in Snowflake OAuth and SCIM security integrations, provided that the replication operation specifies security integrations and network policies. After replicating the network policy and the security integrations that specify a network policy, the security integrations in the target account specify the same network policy.

Tip

Network policy replication requires the replication group to specify NETWORK POLICIES and ACCOUNT PARAMETERS as OBJECT_TYPES when the network policy is set on the account. If there are user-level network policies, the replication group must also specify USERS in OBJECT_TYPES.

If you do not specify these object types properly and a dangling reference occurs, Snowflake fails the refresh operation in the target account.

For this procedure, assume the following:

• Source account: https://example-northamericawest.snowflakecomputing.com/

• Target account: https://example-northamericaeast.snowflakecomputing.com/

• Connection URL: https://example-global.snowflakecomputing.com

• A secondary connection exists in the target account (i.e. only refresh operations are needed).

• Network policies exist in the source account.

• The Snowflake OAuth and/or SCIM security integration already exists in the source account and the integration specifies a network policy.

The following procedure is a representative example to do the following:

• Replicate network policies and a security integration that specifies a network policy.

• Refresh the failover group.

• Verify the network policy activation.

• Promote the secondary connection in the source account to serve as the primary connection.

Source account steps:

1. Verify that network policies exist in the source Snowflake account by executing a SHOW NETWORK POLICIES command.

2. Verify the Snowflake OAuth and/or SCIM security integrations include a network policy by executing a SHOW INTEGRATIONS command to identify the security integration and then execute a DESCRIBE INTEGRATION command on the Snowflake OAuth security integration.

3. Update the failover group to include network policies and account parameters using an ALTER FAILOVER GROUP command.

alter failover group fG set
object_types = users, roles, warehouses, resource monitors, integrations, network policies, account parameters
allowed_integration_types = security integrations;


Target account steps:

1. Refresh the secondary failover group to update the target account to include the network policy objects and the Snowflake OAuth security integration that specifies the network policy.

alter failover group fg refresh;

2. Verify the network policy object exists by executing a SHOW NETWORK POLICIES command, and verify the Snowflake OAuth security integration specifies the replicated network policy by executing a DESCRIBE SECURITY INTEGRATION command on the security integration.

3. Verify the network policy activation as shown in Identifying a Network Policy Activated at the Account or User Level.

4. Verify connecting to each Snowflake account using the Snowflake OAuth client of your choice.

5. Optionally promote the secondary failover group and the secondary connection in the target account to primary. This will promote the target account to serve as the new source account.

Failover group:

alter failover group fg primary;


Connection:

alter connection global primary;

6. If you completed the previous step, reverify that you can connect to each Snowflake account using the Snowflake OAuth client of your choice.