Okta SCIM 与 Snowflake 集成¶

本指南提供了在 Okta 中为 Snowflake 配置预置所需的步骤，包括以下部分：

功能

Snowflake 应用程序支持用户和角色管理。

这使 Okta 能够：

管理 Snowflake 中的用户生命周期（即创建、更新和删除）。
管理 Snowflake 中的角色生命周期（即创建、更新和删除）。
管理 Snowflake 中用户到角色的分配。

支持以下预置功能：

Push New Users:

New users created through OKTA are also created in Snowflake. You can use the allowedInterfaces custom attribute to prevent a provisioned user from using certain interfaces to access Snowflake.

Push Profile Updates:

通过 OKTA 对用户配置文件进行的更新将被推送到 Snowflake。

Push User Deactivation:

通过 OKTA 停用用户或禁用其对 Snowflake 的访问后，该用户在 Snowflake 中也将被停用。

Note

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

Reactivate Users:

可以重新激活 Snowflake 用户账户。

Sync Password:

如果需要，可以将用户密码从 Okta 推送到 Snowflake。

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:

Click Edit.
Under Sync Password, uncheck the setting Generate a new random password whenever the user’s Okta password changes.
保存更改。

在 Okta 中启用此设置将为用户创建能够访问 Snowflake 的密码。这可能会导致用户在没有 SSO 的情况下访问 Snowflake。

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 中的 Snowflake 应用程序被分配给 Okta 中的用户，则 Okta 可以在 Snowflake 中创建用户。

For more information, see Assign an application to a user (https://help.okta.com/en/prod/Content/Topics/Provisioning/lcm/lcm-assign-app-user.htm).

已知问题

Okta does not support URLs that contain underscores. If the name of the Snowflake account contains an underscore, then you need to use a special account URL that replaces the underscore with a hyphen. For example, if you are using the account name URL format, the special URL might be https://myorg-account-name.snowflakecomputing.cn.
不能通过所有权转移将现有 Snowflake 角色纳入 Okta 的管理。只有新的角色可以通过 Okta 创建。
Existing Snowflake users can be brought under Okta’s management through a transfer of ownership. For more information, see Troubleshooting (in this topic).

限制

Snowflake supports a maximum of 500 concurrent requests per account per SCIM endpoint (e.g. the /Users endpoint, the /Groups endpoint). After your account exceeds this threshold, Snowflake returns a 429 HTTP status code (i.e. too many requests). Note that this request limit usually only occurs during the initial provisioning when relatively large numbers of requests (i.e. more than 10 thousand) occur to provision users or groups.

不支持

Okta’s Enhanced Group Push (https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-enable-group-push.htm) and Push Now features.

Note
The defaultRole, defaultSecondaryRoles, and defaultWarehouse attributes are unmapped as they are optional. To map these attributes in Okta, use profiles, expressions, or set a default value for all users. For more information, see Manage profiles (in Okta) (https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-user-profiles-main.htm).
If you are using private connectivity to the Snowflake service to access Snowflake, ensure that you are not entering these URLs in the integration settings. Enter the public endpoint (i.e. without .privatelink), and ensure that the network policy allows access from the Okta IP address listed here (https://help.okta.com/en-us/Content/Topics/Security/ip-address-allow-listing.htm), otherwise you cannot use this integration.
Okta does not currently support importing Active Directory nested groups (https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-import-groups.htm). Therefore, if your Okta integration uses nested groups in AD, you cannot use the Snowflake Okta SCIM integration to provision or manage nested groups in Snowflake. Please contact Okta and Microsoft to request the support of nested groups.

先决条件

Before provisioning users or groups, ensure that the network policy in Snowflake allows access from Okta’s IP addresses documented here (https://help.okta.com/en-us/Content/Topics/Security/ip-address-allow-listing.htm). For more information, see Managing SCIM Network Policies.
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.

配置步骤

配置过程需要完成 Snowflake 和 Okta 中的相应步骤。

Snowflake 配置¶

The Snowflake configuration process creates a SCIM security integration to allow users and roles created in Okta to be owned by the OKTA_PROVISIONER SCIM role in Snowflake.

在首选的 Snowflake 客户端中执行以下 SQL 语句。下文对每个 SQL 语句进行了解释。

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

Important

示例 SQL 语句使用 ACCOUNTADMIN 系统角色，OKTA_PROVISIONER 自定义角色被授予 ACCOUNTADMIN 角色。

可以不使用 ACCOUNTADMIN 角色而使用权限较低的角色。使用权限较低的角色有助于解决与权限最低的访问相关的合规性问题，但是，使用较低权限的角色可能会在 SCIM 配置和管理过程中导致意外错误。

这些错误可能是由于权限较低的角色没有足够的权限通过 SCIM 管理所有角色，这是由于角色的创建方式和由此产生的角色层次结构造成的。因此，为了避免配置和管理过程中出现错误，请选择以下选项之一：

使用示例 SQL 语句中所示的 ACCOUNTADMIN 角色。
使用具有全局 MANAGE GRANTS 权限的角色。
如果前两个选项都不合适，请使用自定义角色，该角色对将使用 SCIM 管理的所有角色拥有 OWNERSHIP 权限。

使用 ACCOUNTADMIN 角色。
```
use role accountadmin;
```
创建自定义角色 OKTA_PROVISIONER。Okta 在 Snowflake 中创建的所有用户和角色都将归范围缩小的 OKTA_PROVISIONER 角色所有。
```
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;
```
Let the ACCOUNTADMIN role create the security integration using the OKTA_PROVISIONER custom role. For more information, see CREATE SECURITY INTEGRATION.
```
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
 type = scim
 scim_client = 'okta'
 run_as_role = 'OKTA_PROVISIONER';
```

After creating the security integration, set up authentication for your SCIM requests. For more information, see Authenticating SCIM API requests.

Important

All users and roles in Snowflake created by Okta will be owned by the scoped down okta_provisioner role.

如果您想通过 Okta 管理现有的 Snowflake 用户，请完成以下步骤：

将现有用户的所有权转移到 okta_provider 角色。
```
use role accountadmin;
grant ownership on user <user_name> to role okta_provisioner;
```
Ensure the login_name property is set for existing users, which should already be set if these existing Snowflake users are using Okta SSO.
Be advised that the name for existing users brought under Okta’s management will be updated to match with Okta’s username. Inform your users about this change as they might be using the name to connect to Snowflake from other integrations (for example, Tableau).

Okta 配置¶

本部分讨论如何在 Okta 中创建和配置 Snowflake 应用程序。

Note

When creating the Snowflake application in Okta, the SubDomain field for the application must contain the account identifier of your Snowflake account. If the Snowflake account name contains an underscore and you are using the account name format of the identifier, you must convert the underscore to a hyphen because Okta does not support underscores in URLs (e.g. myorg-account-name).

Do not include a privatelink segment in the SubDomain field because private connectivity is not supported and entering this segment causes the SCIM connection to fail.

要在 Okta 中配置 Snowflake 应用程序，请完成以下步骤。

In Settings, select Integration from the left hand menu and then check the Enable API Integration box.
For API Token, enter the value generated above from the clipboard. Click Test API Credentials button, and, if successful, save the configuration.
Select To App from the left hand menu.
Select the Provisioning Features you want to enable.
Verify the Attribute Mappings. The defaultRole, defaultSecondaryRoles, and defaultWarehouse attributes are unmapped as they are optional. If there’s a need, you can map them using Okta profile or expression or set the same value for all users.

您现在可以将用户分配给 Snowflake 应用程序（如果需要）并完成应用程序设置。

Note

Okta supports an attribute called snowflakeUserName which maps to the name field of the Snowflake user.

If you want the name and login_name fields for the Snowflake user to have different values, follow this procedure.

Enable separate mappings for your account by running:
```
ALTER ACCOUNT SET MAP_SCIM_USERNAME_TO_ENTERPRISE_ATTR = TRUE;
```
When this parameter is enabled, all SCIM POST and PUT requests must include the snowflakeUserName attribute in the enterprise extension schema. Requests that omit this attribute will fail.

For more information, see MAP_SCIM_USERNAME_TO_ENTERPRISE_ATTR.
In Okta, access the Snowflake application and navigate to Provisioning > Attribute Mappings > Edit Mappings.
Search for the attribute snowflakeUserName.

如果未找到该属性，则 Snowflake 应用程序是在该属性可用之前就已创建。使用如下所示的映射重新创建 Snowflake 应用程序，或按如下所示手动添加属性：

Click Add Attribute.
为表中列出的各个字段设置以下值。

Field	Value
Data type	string
Display name	Snowflake Username
Variable name	`snowflakeUserName`
External name	`snowflakeUserName`
External namespace	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`
Description	Maps to the `name` field of the user in Snowflake.
Scope	User personal
1. Click Save.

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.

管理 SCIM 网络策略¶

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.

创建 SCIM 安全集成后，使用以下命令创建 SCIM 网络策略：

alter security integration okta_provisioning set network_policy = <scim_network_policy>;

要取消设置 SCIM 网络策略，请使用以下命令：

alter security integration okta_provisioning unset network_policy;

其中：

okta_provisioning: 指定 Okta SCIM 安全集成的名称。
scim_network_policy: 在 Snowflake 中指定 Okta SCIM 网络策略。

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

将次要角色与 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.

Populating Snowflake tags with SCIM integrations¶

You can populate tags by using the snowflakeTags attribute when you ingest user information into the SCIM security integration. The exact request input can be found in Create a user.

For more information about adding custom attributes to an Okta user profile, see the Okta documentation (https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-custom-user-attributes.htm)

To enable support for this feature:

Create the tag before you run the SCIM integration.
Grant proper privileges on each tag and tag schema to the OKTA_PROVISIONER role.

Here is an example of creating a tag and assigning the proper role privileges:

-- Create the tag.
CREATE TAG my_database_name.my_schema_name.my_tag_name;

-- Assign the proper privileges to the SCIM integration.
GRANT USAGE ON SCHEMA my_database_name.my_schema_name TO ROLE OKTA_PROVISIONER;
GRANT APPLY ON TAG my_database_name.my_schema_name.my_tag_name TO ROLE OKTA_PROVISIONER;

You must grant USAGE ON SCHEMA and APPLY ON TAG to all tags and tag schemas that you plan to assign through your SCIM security integration.

复制 Okta SCIM 安全集成¶

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.

故障排除

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;
```
Ensure login_name property is set for existing users which should already be set if these existing Snowflake users are using Okta SSO.
若要验证 Okta 正在向 Snowflake 发送更新，请检查 Okta 中有关 Snowflake 应用程序的日志事件和 Snowflake 中的 SCIM 审计日志，以确保 Snowflake 正在从 Okta 接收更新。使用以下命令查询 Snowflake SCIM 审核日志。
```
USE ROLE ACCOUNTADMIN;
USE SCHEMA snowflake.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;
```

在预置过程中可能会发生身份验证错误。错误消息可能如下所示：

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]

如果出现此错误消息或其他身份验证错误消息，请尝试以下故障排除过程：

在 Okta 中，移除当前的 Snowflake 应用程序并创建一个新的 Snowflake 应用程序。
在 Snowflake 中，创建新的 SCIM 安全集成并生成新的访问令牌。
Copy the new token by clicking Copy.
在 Okta 中，粘贴并验证新的访问令牌，如“如何将 Okta 配置为 SCIM 身份提供商”中所述。
使用 Okta 中的新 Snowflake 应用程序将 Okta 的用户和角色预置到 Snowflake。

后续主题：