SnowflakeとのOkta SCIM 統合

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

機能

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にアクセスできるようになります。

プッシュグループ

グループのプッシュ機能は、Snowflakeでロールを作成し、ロール管理を容易にします。Okta Push Groupsを使用してSnowflakeで作成されたロールは、OktaとSnowflakeで同じ名前を持っています。常にOktaで最初にロールを作成し、プッシュグループを使用してSnowflakeを更新し、OktaとSnowflakeが同期できるようにします。Oktaと、Snowflakeの OKTA_PROVISIONER カスタムロールは、Snowflakeで手動により作成されたロールを管理できません。プッシュグループは、Snowflakeにユーザーを作成 しません

ちなみに

OktaのSnowflakeアプリケーションがOktaのユーザーに割り当てられている場合、OktaはSnowflakeでユーザーを作成できます。

詳細については、 アプリケーションをユーザーに割り当てる をご参照ください。

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

属性タイプ

SCIM ユーザー属性

Snowflakeユーザー属性

基本属性

userName

名前とlogin_name

givenName

first_name

familyName

last_name

email

email

カスタム属性

defaultRole

default_role

defaultWarehouse

default_warehouse

既知の問題

  • Snowflake アカウント URL の作成時にアンダースコアが含まれていた場合は、アンダースコアまたはハイフンを含むアカウント URL でSnowflakeアカウントにアクセスできます。

    SCIM プロバイダーが SAML SSO と SCIM の両方に同じアカウント URLs を再利用する場合、アンダースコアを含む URL はサポートされません。そのため、ハイフンを含むアカウント URL を使用して SCIM を構成します。

    アンダースコアを含まないSnowflakeアカウント URLs は、この制限による制約を受けません。

  • 所有権の譲渡を介して既存のSnowflakeロールをOktaの管理下に置くことはできません。Oktaを介して作成できるのは新しいロールのみです。

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

制限事項

  • Snowflakeは、SCIMエンドポイント(例えば、 /Users エンドポイント、 /Groups エンドポイント)ごとに、アカウントにつき最大500の同時リクエストをサポートします。アカウントがこのしきい値を超えると、Snowflakeは 429 HTTP ステータスコード(つまり、リクエストが多すぎる)を返します。このリクエスト制限は通常、ユーザーまたはグループをプロビジョニングするために比較的多数のリクエスト(つまり、1万以上)が発生する初期プロビジョニング中にのみ発生することに注意してください。

サポート対象外

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

    注釈

    defaultRole および defaultWarehouse 属性はオプションであるため、マップされていません。Oktaでこれらの属性をマップするには、プロファイル、式を使用するか、すべてのユーザーにデフォルト値を設定します。詳細については、 プロファイルの管理(Okta内) をご参照ください。

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

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

前提条件

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

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

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

構成のステップ

構成プロセスでは、SnowflakeとOktaでステップを完了する必要があります。

Snowflakeの構成

Snowflakeの構成プロセスでは、 SCIM のセキュリティ統合を作成して、Oktaで作成されたユーザーとロールをSnowflakeの OKTA_PROVISIONER SCIM ロールが所有できるようにし、 SCIM API リクエストで使用するアクセストークンを作成します。アクセストークンは6か月間有効です。有効期限が切れたら、以下に示すように手動で SYSTEM$GENERATE_SCIM_ACCESS_TOKEN を使用して、新しいアクセストークンを作成します。

注釈

SCIM 統合の既存のアクセストークンを無効にするには、 DROP INTEGRATION ステートメントを実行します。

Snowflakeで SCIM を引き続き使用するには、SCIM 統合を CREATE SECURITY INTEGRATION ステートメントで再作成し、 SYSTEM$GENERATE_SCIM_ACCESS_TOKEN を使用して新しいアクセストークンを生成します。

優先するSnowflakeクライアントで、次の SQL ステートメントを実行します。各 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 ステートメントは ACCOUNTADMIN システムロールを使用し、 OKTA_PROVISIONER カスタムロールが ACCOUNTADMIN ロールに付与されます。

権限の少ないロールを優先するために、 ACCOUNTADMIN ロールを使用しないようにすることもできます。権限の少ないロールを使用すると、最小権限のアクセスに関連するコンプライアンスの懸念に対処するのに役立ちますが、 SCIM の構成および管理プロセス中に予期しないエラーが発生する可能性があります。

これらのエラーは、ロールの作成方法と結果のロール階層が理由で、権限の少ないロールが SCIM までのすべてのロールを管理するための十分な権限を持っていないことに起因している可能性があります。したがって、構成および管理プロセスのエラーを回避するために、次のいずれかのオプションを選択してください。

  1. SQL ステートメントの例に示されているように ACCOUNTADMIN ロールを使用。

  2. グローバル MANAGE GRANTS 権限を持つロールを使用。

  3. 最初にある2つのオプションのいずれも望ましくない場合は、 SCIM を使用して管理されるすべてのロールに対して OWNERSHIP 権限を持つ、カスタムロールを使用してください。

  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 をご参照ください。

    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. 認証トークンを作成してクリップボードにコピーし、後で使用できるように安全に保存します。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;
      
    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にユーザーとロールをプロビジョニングします。

次のトピック: