SnowflakeとのOkta SCIM 統合

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

機能

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

これにより、Oktaは次を実行できるようになります。

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

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

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

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

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

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

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

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

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

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

注釈

Snowflakeの場合、ユーザーの非アクティブ化は、ユーザーの DISABLED プロパティを TRUE に設定することを意味します。

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

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

同期パスワード:

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

Tip

デフォルト設定では、ユーザーにランダムなパスワードを作成して、ユーザーに 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にアクセスできるようになります。

パスワードの同期を 無効にする には、Oktaでこのオプションの設定を解除し、 合わせて Snowflake Okta SCIM セキュリティ統合 を更新して、 SYNC_PASSWORD プロパティを False に設定します。

プッシュグループ:

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

Tip

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

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

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

属性の型

SCIM ユーザー属性

Snowflakeユーザー属性

メモ

基本属性

userName

名前とlogin_name

givenName

first_name

familyName

last_name

email

email

カスタム属性

defaultRole

default_role

defaultWarehouse

default_warehouse

defaultSecondaryRoles

default_secondary_roles

値は "ALL" としてのみ指定できます。

既知の問題

  • Oktaは、アンダースコアを含む URLs をサポートしていません。Snowflakeアカウントの名前にアンダースコアが含まれている場合は、アンダースコアをハイフンに置き換える特別なアカウント URL を使用する必要があります。たとえば、アカウント名 URL 形式を使用している場合、特別な URL は https://myorg-account-name.snowflakecomputing.com の可能性があります。

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

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

制限事項

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

サポート対象外

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

    注釈

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

  • Snowflakeサービスへのプライベート接続を使用して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 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');
Copy

重要

例の SQL ステートメントは ACCOUNTADMIN システムロールを使用し、 OKTA_PROVISIONER カスタムロールが ACCOUNTADMIN ロールに付与されます。

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

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

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

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

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

  1. ACCOUNTADMIN ロールを使用します。

    use role accountadmin;
    
    Copy
  2. カスタムロール 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;
    
    Copy
  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';
    
    Copy
  4. 認証トークンを作成してクリップボードにコピーし、後で使用できるように安全に保存します。SCIM REST API リクエストごとにこのトークンを使用し、リクエストヘッダーに配置します。アクセストークンは6か月後に期限が切れます。このステートメントを使用して新しいアクセストークンを生成できます。

    select system$generate_scim_access_token('OKTA_PROVISIONING');
    
    Copy

    重要

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

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

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

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

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

Oktaの構成

このセクションでは、OktaでSnowflakeアプリケーションを作成および構成する方法について説明します。

注釈

OktaでSnowflakeアプリケーションを作成する場合、アプリケーションの SubDomain フィールドには、Snowflakeアカウントの アカウント識別子 が含まれている必要があります。Snowflakeアカウント名にアンダースコアが含まれていて、識別子のアカウント名形式を使用している場合、Oktaは URLs でアンダースコアをサポートしていないため(例: myorg-account-name)、アンダースコアをハイフンに変換する必要があります。

SubDomain フィールドには privatelink セグメントを 含めない でください。プライベート接続は サポートされておらず、このセグメントを入力すると SCIM 接続に失敗します。

Okta でSnowflakeアプリケーションを構成するには、次のステップを完了します。

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

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

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

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

  5. 属性マッピングを確認します。 defaultRole 属性、 defaultSecondaryRoles 属性、および 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 ネットワークポリシーをSnowflakeアカウント全体に適用されるネットワークポリシーと区別できます。これにより、 SCIM プロバイダーは IP アドレスを通常のユーザーのアクセスを制御するネットワークポリシーに追加することなく、ユーザーとグループをプロビジョニングできます。

SCIM 統合に適用されるネットワークポリシーは、Snowflakeアカウント全体に適用されるネットワークポリシーよりも優先されますが、ユーザーに割り当てられるネットワークポリシーのほうが優先されます。

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

alter security integration okta_provisioning set network_policy = <scim_network_policy>;
Copy

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

alter security integration okta_provisioning unset network_policy;
Copy

条件:

okta_provisioning

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

scim_network_policy

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

詳細については、 ネットワークポリシーを使用したネットワークトラフィックの制御 および ALTER SECURITY INTEGRATION をご参照ください。

SCIM でのセカンダリロールの使用

Snowflakeは、 SCIM で ユーザー プロパティ DEFAULT_SECONDARY_ROLES'ALL' に設定して、ユーザーがSnowflakeセッションで セカンダリロール を使用できるようにすることをサポートしています。

代表的な例については、 PUT scim/v2/Users/{ID} をご参照ください。

Okta SCIM セキュリティ統合の複製

Snowflakeは、 SCIM セキュリティ統合により、ソースアカウントからターゲットアカウントへの複製とフェールオーバー/フェールバックをサポートします。

詳細については、 複数のアカウントにわたるセキュリティ統合とネットワークポリシーの複製 をご参照ください。

トラブルシューティング

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

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
    Copy
  • これらの既存の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;
    
    Copy
  • プロビジョニングプロセス中に認証エラーが発生する可能性があります。考えられるエラーメッセージの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]
    
    Copy

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

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

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

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

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

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

次のトピック: