SnowflakeとのOkta SCIM 統合¶

機能¶

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でユーザーを作成できます。

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

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

前提条件¶

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

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

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

構成の手順¶

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

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

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にユーザーとロールをプロビジョニングします。

次のトピック：

• SCIM API リクエストの実行