Databricks Identity Federation徹底整理: SSO・SCIM・組織統合

Databricksを組織全体で運用する場合、ユーザー管理は「Databricksに直接ユーザーを作成する」方式では破綻します。 社内のIdP（Entra ID、Okta、Google Workspaceなど）でユーザーとグループを一元管理し、 Databricksにはそのアイデンティティ情報をフェデレーション（連携）する設計が標準です。

この記事では、SSO（SAML 2.0/OIDC）による認証連携、SCIMによるID自動プロビジョニング、 Account ConsoleとWorkspaceの関係、そしてUnity Catalog時代のID管理ベストプラクティスを整理します。

SSOの仕組み: SAML 2.0とOIDC

SSO（Single Sign-On）は、ユーザーがIdPで1回認証するだけでDatabricksにもログインできる仕組みです。 Databricksは2つのSSOプロトコルをサポートしています。

SAML 2.0は長年の実績がありますが、XMLベースで設定がやや複雑です。 OIDCはJWTベースで軽量かつモダンなプロトコルで、Databricksは新規セットアップではOIDCを推奨しています。 既存のSAML構成を強制的に移行する必要はありません。

SSO認証フロー

SAML 2.0でのSSO認証フローは以下のステップで構成されます。

1. ユーザーがDatabricksワークスペースのURLにアクセス
2. DatabricksがSAML AuthnRequestを生成し、IdPにリダイレクト
3. ユーザーがIdPで認証（パスワード＋MFAなど）
4. IdPがSAML Responseを生成し、Databricksにリダイレクト
5. Databricksがアサーションを検証し、ユーザーセッションを作成

OIDC（Authorization Code Flow）の場合は、SAMLアサーションの代わりにID Token（JWT）が使われます。 ユーザーから見た操作は同じで、IdPの認証画面で認証するとDatabricksに自動的にログインされます。

SCIMによる自動プロビジョニング

SCIM（System for Cross-domain Identity Management）は、IdP側のユーザー・グループの変更を Databricksに自動同期するプロトコルです。SSOが「認証（ログイン）」を統合するのに対し、 SCIMは「IDライフサイクル（作成・更新・無効化・削除）」を統合します。

SCIMなしでSSOだけを使う場合、IdP側でユーザーを無効化してもDatabricksのユーザーレコードは残り続けます。 PATが有効であればAPI経由のアクセスが可能なままになるリスクがあるため、 本番運用ではSSO＋SCIMの両方を構成するのが必須です。

Account Console vs Workspace: ID管理の二層構造

Databricksには「Account」と「Workspace」の2つのレベルがあり、ID管理もこの2層に対応しています。

Unity Catalog以降の推奨構成は、Account-level SCIMでIdPと同期し、 アカウント内のユーザー・グループを一元管理する方式です。各ワークスペースにはAccountレベルの ユーザー・グループを「割り当て（assign）」する形になります。Workspace-level SCIMは レガシー構成として引き続きサポートされますが、新規構成ではAccount-level SCIMを推奨します。

Identity Federationの全体フロー

典型的な企業でのIdentity Federation構成のフローを整理します。

1. IdPでDatabricksアプリケーションを登録: Entra IDやOktaでSAML/OIDCアプリケーションを作成し、Databricks側のACS URL/Redirect URIを設定
2. DatabricksでSSOを設定: Account ConsoleでIdPのメタデータ（Entity ID、Login URL、証明書）を登録
3. SCIMプロビジョニングを設定: IdP側でSCIMコネクタを有効にし、DatabricksのSCIM APIエンドポイントとBearerトークンを設定
4. グループマッピングを構成: IdP側のグループ（data-engineers, ml-teamなど）をDatabricksに同期するよう設定
5. ワークスペースにユーザーを割り当て: Account ConsoleからユーザーやグループをワークスペースにAssign
6. 動作検証: テストユーザーでSSOログインし、SCIM同期でユーザーが正しく作成されることを確認

グループ管理のベストプラクティス

Identity Federationでのグループ管理は、Unity Catalogの権限管理と直結するため重要です。

• IdPのグループ＝Databricksのグループ: IdP側でdata-engineers、data-scientists、 platform-adminsなどのグループを定義し、SCIM経由でDatabricksに同期する
• Databricksローカルグループは最小限に: SCIMで同期されないローカルグループは管理が分散するため、 特殊な用途（workspace adminsなど）に限定する
• ネストグループの制限に注意: SCIMプロバイダによってはネストグループの同期に制限がある。 フラットなグループ構造を推奨
• Unity Catalogの権限はグループベースで付与: 個人ユーザーではなくグループにGRANT文で権限を付与し、 メンバーの入れ替えをIdP側で完結させる

主要IdPごとの設定ポイント

試験で問われるポイント

• 「IdPのユーザーを無効化した場合のDatabricks側の挙動」→ SCIMが設定されていればactive=falseに自動更新
• 「SSOを設定したがユーザーがDatabricksに自動作成されない」→ SSO JITプロビジョニングまたはSCIMの設定が必要
• 「複数ワークスペースのユーザーを一元管理するには」→ Account-level SCIM
• 「SSOの認証プロトコルとして正しいのは」→ SAML 2.0またはOIDC
• 「グループベースのアクセス制御のメリット」→ メンバーの入れ替えがIdP側で完結し、権限の個別管理が不要

問題で確認

よくある質問