【Databricks】Oktaと自動ID管理（AIM）でSCIM不要のユーザー・グループ同期を試してみた
はじめに
データ事業本部のueharaです。
DatabricksからIDプロバイダーのユーザーとグループを同期するには、これまでSCIMプロビジョニングが一般的でした。
SCIMプロビジョニングでは、IDプロバイダー側にプロビジョニング用のコネクタを設定し、IDプロバイダーからDatabricksへユーザー情報をプッシュします。
OktaからSCIMでDatabricksへプロビジョニングする場合、Okta側の契約として有料機能である Lifecycle Management を別途契約している必要があります。
2026年7月3日に、Databricksの自動ID管理（Automatic Identity Management, AIM）のOkta対応がGAになりました。
AIMはSCIMプロビジョニングなしで、OktaのユーザーとグループをDatabricksへ同期できる機能です（Okta側に特別なライセンスは不要です）。
今回はこのAIMによるユーザーとグループの同期を検証してみたいと思います。
自動ID管理とは
自動ID管理は、IDプロバイダーを記録のソース（source of record）として、Databricksがユーザーとグループの情報をIDプロバイダーから取得する仕組みです。
SCIMプロビジョニングがIDプロバイダーからDatabricksへのプッシュ型であるのに対し、AIMはDatabricksがIDプロバイダーのAPIを読み取るプル型です。
Okta連携の場合、DatabricksはOktaに作成したAPI ServicesアプリのクライアントIDと秘密鍵を使い、 okta.users.read と okta.groups.read のスコープでOktaのAPIを呼び出します。
同期の動作は次のようになっています。
- AIMを有効にすると、ジャストインタイム（JIT）プロビジョニングが常に有効になり、ユーザーは初回ログイン時にDatabricksへ自動作成される
- ログイン前のユーザーやグループは、共有ダイアログやワークスペース管理者設定の検索から見つけられる
- グループは、ワークスペースへの追加やアセットの共有で利用された時点で、アカウントレベルに自動作成される
- グループメンバーシップは、ユーザーのアクティビティを契機に更新される
- IDプロバイダーで削除されたユーザーは、次回のID同期でDatabricks側も自動的に無効化される
SCIMプロビジョニングとの比較
公式ドキュメントの比較表を踏まえ、SCIMプロビジョニングとの違いを整理すると以下の通りになります。
| 機能 | 自動ID管理 | SCIMプロビジョニング |
|---|---|---|
| ユーザーの同期 | 対応 | 対応 |
| グループの同期 | 対応 | 対応 |
| ネストされたグループの同期 | Microsoft Entra IDのみ | 非対応 |
| サービスプリンシパルの同期 | Microsoft Entra IDのみ | 非対応 |
| Databricks内でデフォルトで利用可能 （IdPのユーザー・グループを事前作成なしで検索可能） |
対応 | 非対応 |
| IDフェデレーションが必要 | 必須 | 不要 |
動作モデルの違いは次の通りです。
| 観点 | 自動ID管理 | SCIMプロビジョニング |
|---|---|---|
| 同期方式 | DatabricksがIDプロバイダーからプル | IDプロバイダーからDatabricksへプッシュ |
| ユーザー作成のタイミング | 初回ログイン時のJITプロビジョニング | コネクタによるプロビジョニング時 |
| グループメンバーシップの更新 | ユーザーのアクティビティを契機に随時 | コネクタのスケジュールに従う |
| Okta側のライセンス | 不要 | Lifecycle Managementが必要 |
AIMでは、ユーザーはログインしないとDatabricksに実体化しません。
その代わり、Databricks側でユーザーやグループを個別にプロビジョニングする運用が不要になり、IDプロバイダー側の変更がログインのたびに反映される状態を保てます。
構成
今回の構成は次の通りです。
Okta側には2つのアプリケーションを作成します。
- SSO用のOIDCアプリケーション（Web Application）
- AIMがOkta APIを呼び出すためのAPI Servicesアプリケーション
DatabricksはAPI ServicesアプリケーションのクライアントIDと秘密鍵を使い、Oktaからユーザーとグループの情報を取得します。
次章から実際に設定を行います。
（Okta）テスト用グループの作成
Okta管理コンソールの『ディレクトリ』から『グループ』を開き、テスト用のグループを作成します。
これは、Databricksへのログインを許可するユーザーを定義するためのグループになります。
今回は『databricks-test-group』という名前にしました。
作成したグループにテスト用のユーザーを所属させておきます。
Databricksアカウント用のOkta SSOの構成
最初に、AIMの前提条件であるOkta SSOを構成します。
（Databricks）リダイレクトURLを確認
Databricksのアカウントコンソールへアクセスし、『Security』の『Authentication』タブを開きます。
『Manage』を選択し、『Single sign-on with my identity provider』を選びます。
IDプロトコルに『OpenID Connect』を選択すると、『Databricks Redirect URL』が表示されるためコピーします。
値はアカウント共通で次のようになっています。
https://accounts.cloud.databricks.com/oidc/consume
Client IDやClient secretはOktaの設定後に指定する必要があるため、Databricksの画面はこのまま、Oktaの設定に戻ります。
（Okta）OIDCアプリケーションを作成
Okta管理コンソールで『アプリケーション』から『アプリ統合を作成』を選択します。
サインイン方法に『OIDC』、アプリケーションタイプに『Webアプリケーション』を選択します。
アプリ統合名は『Databricks』とし、Sign-in redirect URIに先ほどコピーしたDatabricksのリダイレクトURLを設定します。
設定できたら『保存』を選択します。
すると、以下の通りアプリケーションが作成されるかと思います。
アプリケーションが作成できたら、クライアントIDおよびクライアントシークレットをコピーしておきます（Databricks側の設定作業に必要となります）。
また、冒頭で作成したグループをアプリケーションに割り当てておきます。
（Databricks）SSOを有効化
Databricksの『Authentication』画面に戻り、以下の設定値を作成したOktaアプリケーションの情報を元に入力します。
- Client ID
- Client secret
- OpenID issuer URL（Okta orgのURL）
issuer URLには、Okta orgのURLを指定します。
※管理コンソールのURLは https://xxxx-admin.okta.com の形式ですが、ここで指定するのは -admin を除いた https://xxxx.okta.com です。
値を『Save』した後、『Test SSO』を実行します（この Test SSO は同一ブラウザの別ウィンドウで実施する必要があります）。
ウィンドウでURLを開くと、Oktaでのサインインを求められます。
テストが成功すると『Enable SSO』が押せるようになるため、クリックして有効化します。
これでSSOの有効化は完了です。
※以下のようになっていると思います。
（Okta）AIM用のAPI Servicesアプリケーションの作成
次に、DatabricksがOktaのユーザーとグループ情報を読み取るためのアプリケーションを作成します。
先ほどと同様Okta管理コンソールで『アプリケーション』を開き、『アプリ統合を作成』を選択します。
サインイン方法に『APIサービス』を選択します。
アプリ統合名は『Databricks AIM』としました。
作成したアプリケーションに対し、次の設定を行います。
クライアント認証方法の変更
『一般』タブの『クライアント資格情報』を編集で開き、『公開鍵/秘密鍵』に変更します。
デフォルトは『クライアントシークレット』になっているため、変更を忘れやすい箇所です。
鍵ペアの生成
『一般』タブの『公開鍵』を編集で開き『キーを追加』を選択すると、Okta上で鍵ペアを生成できます。
秘密鍵は一度だけ表示されるため、JSON形式でコピーして安全な場所に保存します。
APIスコープの付与
『Okta APIのスコープ』タブで、次のスコープを付与します。
okta.users.readokta.groups.read
管理者ロールの付与
『管理者ロール』タブから『読み取り専用管理者』のロールを付与します。
DPoPの無効化
『一般』タブの『一般設定』を編集で開き、DPoPのチェックを外します。
※APIサービスアプリケーションでは、この設定がデフォルトで有効になっています。
（Databricks）AIMを有効化
Databricksのアカウントコンソールで『Security』の『User provisioning』タブを開きます。
Automatic identity managementの横にある『Configure』を選択し、次の値を入力します。
- Okta組織のURL：
-adminを除いたOkta orgのURL - クライアントID：
Databricks AIMアプリケーションのClient ID - クライアント秘密鍵：生成した秘密鍵のPEM（JSON形式）
『Test connection』を実行し、成功を確認してから『Enable AIM』を選択します。
完了すると以下の通りAIMが有効化され、今後SCIMが不要な旨のメッセージが表示されます。
設定画面からもAIMが有効化になっていることを確認できます。
動作確認
初回ログインでのJITプロビジョニング
AIMを有効化すると、JITプロビジョニングが常に有効になります。
databricks-test-group に所属するテストユーザーで、Okta SSO経由の初回ログインを行います。
Databricksのワークスペースに接続すると、以下の通りSSOでログインできることが確認できます。
Oktaで認証を実施すると、以下の通りワークスペースに接続することができました。
※ログイン前の段階ではユーザーはDatabricksに実体化しておらず、初回ログインを契機にユーザーが作成されます。
グループの追加と同期
AIMを有効化したからといって、OktaのグループがDatabricksのグループ一覧に自動で作成されるわけではありません。
グループは、ワークスペース管理者設定の『Add group』の検索から見つけて、ワークスペースへ追加します。
確認のため、試しにOkta側のグループに同期したいグループを作成し、ユーザーを追加します（このユーザーは databricks-test-group グループにも属している、Databricksへログイン可能なユーザーです）。
ここではグループ名を manager_group_test としました。
検索で表示されるか確認するため、ワークスペース管理者設定の『Add group』を選択します。
検索では、Databricksに未作成のOktaのグループもin Okta として候補で表示されることが分かります。
ワークスペースへ追加した時点で、アカウントレベルにグループが自動作成されます。
Databricks上のグループメンバーシップにも、所属しているユーザーが反映されることを確認しました。
補足：監査ログでの追跡
AIMが実行した操作は、 system.access.audit テーブルで追跡できます。
AIMによるユーザーの作成は、次のクエリで確認できます。
SELECT request_params.targetUserName, event_time
FROM system.access.audit
WHERE action_name = "add"
AND request_params.endpoint = "autoUserCreation";
IDプロバイダーから同期されたグループメンバーシップは、次のクエリで確認できます。
SELECT request_params.targetGroupName, request_params.targetUserName, event_time
FROM system.access.audit
WHERE action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
AND request_params.groupMembershipType = "IdentityProvider";
最後に
OktaとDatabricksの自動ID管理を連携し、SCIMプロビジョニングなしでユーザーとグループの同期を検証しました。
Okta側はLifecycle Managementの契約が不要となります。
SCIMプロビジョニングではIDプロバイダー側のコネクタ設定が必要でしたが、AIMではDatabricks側にOktaのクライアントIDと秘密鍵を登録するだけで同期が開始できます。
グループメンバーシップがユーザーのログインを契機に同期されるなど、SCIMとは動作モデルが異なる点はありますが、IDプロバイダーをソースとして一元管理できる構成は運用しやすいと感じました。
参考になりましたら幸いです。
