SnowflakeとのOkta SCIM 統合

このガイドでは、Snowflakeのプロビジョニング(Okta)を構成するために必要な手順を説明します。ガイドには次のセクションが含まれています。

機能

Snowflakeアプリケーションでは、ユーザーとロールの管理がサポートされています。

これにより、Oktaは次のことが可能になります。

  • Snowflakeでユーザーライフサイクル(作成、更新、削除)を管理します。

  • Snowflakeでロールのライフサイクル(作成、更新、削除)を管理します。

  • Snowflakeでのユーザーのロールへの割り当てを管理します。

次のプロビジョニング機能がサポートされています。

新しいユーザーのプッシュ

OKTA で作成された新しいユーザーが、Snowflakeでも作成されます。

プロファイル更新のプッシュ

OKTA を介してユーザーのプロファイルに加えられた更新は、Snowflakeにプッシュされます。

プッシュユーザーの非アクティブ化

ユーザーを非アクティブ化するか、 OKTA を介したSnowflakeへのユーザーのアクセスを無効にすると、Snowflakeのユーザーは非アクティブ化になります。

注釈

Snowflakeの場合、ユーザーの非アクティブ化は、ユーザーの isActive 属性をfalseに設定することを意味します。

ユーザーの再アクティブ化

ユーザーアカウントはSnowflakeを再アクティブ化できます。

同期パスワード

必要に応じて、OktaからSnowflakeにユーザーパスワードをプッシュできます。

ちなみに

デフォルト設定では、ユーザーにランダムなパスワードを作成して、ユーザーに has_Password=true の属性設定を与えます。パスワードがない場合、ユーザーはOkta SSO を介してSnowflakeにアクセスする必要があります。ユーザーのパスワードが生成されないようにするには、次のようにユーザーをプロビジョニングする前にこの設定をオフにします。

  1. Edit をクリックします。

  2. Sync Password で、設定 Generate a new random password whenever the user's Okta password changes のチェックを外します。

  3. 変更を保存します。

Oktaでこの設定を有効にすると、ユーザーがSnowflakeにアクセスするためのパスワードが作成されます。これにより、ユーザーが SSO なしでSnowflakeにアクセスできるようになります。

プッシュグループ

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.

ちなみに

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.

次のユーザー属性がサポートされています。

属性タイプ

SCIM ユーザー属性

Snowflakeユーザー属性

基本属性

userName

名前とlogin_name

givenName

first_name

familyName

last_name

email

email

カスタム属性

defaultRole

default_role

defaultWarehouse

default_warehouse

サポート対象外

  • Oktaの 強化されたグループプッシュ およびPush Now機能。

    注釈

    defaultRole および defaultWarehouse 属性はオプションであるため、マップされていません。必要がある場合は、Oktaプロファイルまたは式を使用してそれらをマップするか、すべてのユーザーに同じ値を設定できます。

  • AWS PrivateLink を使用してSnowflakeにアクセスしている場合は、統合設定に PrivateLink URL を入力していないことを確認してください。パブリックエンドポイント(つまり、 .privatelink なし)を入力し、ネットワークポリシーが こちら にリストされているOkta IP アドレスからのアクセスを許可していることを確認してください。

  • Oktaは現在、アクティブディレクトリの ネストされたグループ のインポートをサポートしていません。したがって、Okta統合が AD でネストされたグループを使用する場合、Snowflake Okta SCIM 統合を使用して、Snowflakeでネストされたグループをプロビジョニングまたは管理することはできません。OktaおよびMicrosoftに連絡して、ネストされたグループのサポートをリクエストしてください。

既知の問題

  • Snowflakeアカウントが、アンダースコアを含むアカウント名で作成された場合(例: my_account)、アンダースコアまたはハイフンを含むアカウント名(例: my-account)でSnowflakeアカウントにアクセスできます。ハイフンを含むアカウント名をOkta SAML SSO とOkta SCIM の両方に再利用する場合、アンダースコアを含むアカウント名はサポートされません。そのため、ハイフンを含むアカウント名を使用して SCIM を構成します。

  • 既存のSnowflakeユーザーは、所有権の譲渡によりOktaの管理下に置くことができます。詳細については、このトピックの トラブルシューティングのヒント をご参照ください。

前提条件

  1. ユーザーまたはグループをプロビジョニングする前に、Snowflakeの ネットワークポリシーこちら に記載されているOktaの IP アドレスからのアクセスを許可していることを確認してください。詳細については、 SCIM ネットワークポリシーの管理 をご参照ください。

  2. Snowflakeのプロビジョニングを構成する前に、Snowflakeアプリケーションの General Settings および Sign-On Options が構成されていることを確認してください。

上記の手順が完了したら、Oktaで Next をクリックして Provisioning タブに戻ります。

構成のステップ

構成プロセスでは、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 and creates an access token to use in SCIM API requests. The access token is valid for six months. Upon expiration, create a new access token manually using SYSTEM$GENERATE_SCIM_ACCESS_TOKEN as shown below.

優先するSnowflakeクライアントで、次の SQL ステートメントを実行します。

use role accountadmin;
create or replace role 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');

各 SQL ステートメントについて以下で説明します。

  1. ACCOUNTADMIN ロールを確認します。

    use role accountadmin;
    
  2. カスタムロール OKTA_PROVISIONER を作成します。Oktaによって作成されたSnowflakeのすべてのユーザーとロールは、スコープが絞られた OKTA_PROVISIONER ロールによって所有されます。

    create or replace role okta_provisioner;
    grant create user on account to role okta_provisioner;
    grant create role on account to role okta_provisioner;
    
  3. OKTA_PROVISIONER カスタムロールを使用して、 ACCOUNTADMIN ロールによるセキュリティ統合の作成を許可します。詳細については、 CREATE SECURITY INTEGRATION をご参照ください。

    create or replace security integration okta_provisioning
        type=scim
        scim_client='okta'
        run_as_role='OKTA_PROVISIONER';
    
  4. 認証トークンを作成してクリップボードにコピーし、後で使用できるように安全に保存します。SCIM REST API リクエストごとにこのトークンを使用し、リクエストヘッダーに配置します。アクセストークンは6か月後に期限が切れます。このステートメントを使用して新しいアクセストークンを生成できます。

    select system$generate_scim_access_token('OKTA_PROVISIONING');
    

    重要

    Oktaによって作成されたSnowflakeのすべてのユーザーとロールは、スコープが絞られた okta_provisioner ロールによって所有されます。

    Oktaを介して既存のSnowflakeユーザーとロールを管理する場合は、次のステップを実行します。

    1. 既存のユーザーとロールの所有権をokta_provisionerロールに転送します。

      use role accountadmin;
      grant ownership on user <user_name> to role okta_provisioner;
      grant ownership on role <role_name> to role okta_provisioner;
      
    2. これらの既存のSnowflakeユーザーがOkta SSOを使用している場合、 login_name プロパティが既存のユーザーに設定されていることを確認してください。

    3. Oktaの管理下にある既存のユーザーの名前は、Oktaのユーザー名と一致するように更新されることに注意してください。他の統合(つまり、Tableau)からSnowflakeに接続するために名前を使用している可能性があるため、この変更についてユーザーに通知します。

Oktaの構成

OktaでSnowflakeアプリケーションにアクセスし、次のステップを実行します。

  1. Settings で、左側のメニューから Integration を選択し、 Enable API Integration ボックスをオンにします。

  2. API Token には、クリップボードから上記で生成された値を入力します。 Test API Credentials ボタンをクリックし、成功したら構成を保存します。

  3. 左側のメニューから To App を選択します。

  4. 有効にする Provisioning Features を選択します。

  5. 属性マッピングを確認します。 defaultRole および defaultWarehouse 属性はオプションであるため、マップされていません。必要がある場合は、Oktaプロファイルまたは式を使用してそれらをマップするか、すべてのユーザーに同じ値を設定できます。

ユーザーをSnowflakeアプリケーションに割り当て(必要な場合)、アプリケーションのセットアップを完了できます。

注釈

Oktaは、Snowflakeユーザーの name フィールドにマップする snowflakeUserName という属性をサポートしています。

Snowflakeユーザーの name フィールドと login_name フィールドに異なる値を設定するには、次の手順に従います。

  1. Snowflakeサポートに連絡して、アカウントの個別のマッピングを有効にします。

  2. OktaでSnowflakeアプリケーションにアクセスし、 Provisioning > Attribute Mappings > Edit Mappings に移動します。

  3. 属性 snowflakeUserName を検索します。

  4. 属性が見つからない場合、Snowflakeアプリケーションは、この属性が使用可能になる前に作成されたということです。以下に示すマッピングを使用してSnowflakeアプリケーションを再作成するか、次のように属性を手動で追加します。

    • Add Attribute をクリックします。

    • 表にリストされている各フィールドに次の値を設定します。

    フィールド

    データ型

    文字列

    表示名

    Snowflakeのユーザー名

    変数名

    snowflakeUserName

    外部名

    snowflakeUserName

    外部名前空間

    urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

    説明

    Snowflakeのユーザーの name フィールドにマップします。

    スコープ

    ユーザー個人

  5. Save をクリックします。

Snowflake起動 SSO の有効化

SCIM プロビジョニングプロセスは、シングルサインオン(SSO)を自動的に有効にしません。

SCIM プロビジョニングプロセスの完了後に SSO を使用するには、 Snowflakeにより開始される SSO を有効にします。

SCIM ネットワークポリシーの管理

SCIM ネットワークポリシーには独自の設定があるため、 SCIM プロバイダーは、通常のユーザーアクセス用にこれらの IP アドレスを追加することなく、ユーザーとグループのプロビジョニングを明確に許可できます。

SCIM 統合に固有のネットワークポリシーを設定すると、 SCIM をSnowflakeアカウントに適用される他のネットワークポリシーと区別できます。 SCIM ネットワークポリシーは、アカウント上の他のネットワークポリシーに影響しません。また、他のアカウントネットワークポリシーは SCIM ネットワークポリシーに影響しません。したがって、 SCIM ネットワークポリシーにより、Snowflake SCIM 統合により、ユーザーおよびグループを意図したとおりにプロビジョニングできます。

SCIM セキュリティ統合を作成したら、次のコマンドを使用して SCIM ネットワークポリシーを作成します。

alter security integration okta_provisioning set network_policy = <SCIMネットワークポリシー>;

SCIM ネットワークポリシーを設定解除するには、次のコマンドを使用します。

alter security integration okta_provisioning unset <SCIMネットワークポリシー>;

条件:

okta_provisioning

Okta SCIM セキュリティ統合の名前を指定します。

<scim_network_policy>

SnowflakeのOkta SCIM ネットワークポリシーを指定します。

詳細については、 ネットワークポリシー および ALTER SECURITY INTEGRATION をご参照ください。

トラブルシューティングのヒント

  • 所有権の譲渡。 ユーザーの更新が失敗した場合は、Snowflakeでユーザーの所有権を確認します。 okta_provisioner ロール(またはSnowflakeでセキュリティ統合を作成するときに run_as_role パラメーターで設定されたロール)が所有していない場合、更新は失敗します。Snowflakeで次の SQL ステートメントを実行して所有権を譲渡し、再試行してください。

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
  • これらの既存のSnowflakeユーザーがOkta SSOを使用している場合、 login_name プロパティが既存のユーザーに設定されていることを確認してください。

  • OktaがSnowflakeに更新を送信していることを確認するには、SnowflakeアプリケーションのOktaのログイベントとSnowflakeの SCIM 監査ログを確認して、SnowflakeがOktaから更新を受信していることを確認します。次を使用して、Snowflake SCIM 監査ログをクエリします。

    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;
    
  • プロビジョニングプロセス中に認証エラーが発生する可能性があります。考えられるエラーメッセージの1つは次のとおりです。

    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]
    

    このエラーメッセージまたは他の認証エラーメッセージが発生した場合は、次のトラブルシューティング手順を試してください。

    1. Oktaで、現在のSnowflakeアプリケーションを削除し、新しいSnowflakeアプリケーションを作成します。

    2. Snowflakeで、新しい SCIM セキュリティ統合を作成し、新しいアクセストークンを生成します。

    3. Copy をクリックして、新しいトークンをコピーします。

    4. Oktaで、Oktaを SCIM IDプロバイダーとして構成する方法の説明に従って、新しいアクセストークンを貼り付けて検証します。

    5. Oktaの新しいSnowflakeアプリケーションを使用して、OktaからSnowflakeにユーザーとロールをプロビジョニングします。