Delta Sharingの受信者向けにOpenID Connect(OIDC)フェデレーションを有効にする
このページでは、Databricks のデータ プロバイダーが ID プロバイダー (IdP) に認証をフェデレーションして、Databricks で作成された Delta Sharing 共有へのアクセスを制御する方法について説明します。この認証フローでは OIDC フェデレーションを使用し、受信者のJSON IdP によって発行された Web トークン (JWT) を によって認証された短命のOAuth トークンとして許可します。Databricksこの Databricks から Open への共有 認証方法は、Unity Catalog 対応の Databricks ワークスペースにアクセスできない受信者向けに設計されています。
OIDC フェデレーションでは、受信者の IdP が JWT トークンの発行と、多要素認証 (MFA) などのセキュリティポリシーの適用を担当します。同様に、JWT トークンの有効期間は、受信者の IdP によって管理されます。Databricks では、これらのトークンは生成または管理されません。認証を受信者のIdPにフェデレートし、受信者が設定したフェデレーションポリシーに対してJWTを検証するだけです。データプロバイダーは、組織内の他のユーザーや部門と内部的にデータを共有するときに、認証を独自のIdPにフェデレーションすることもできます。
OIDC フェデレーションは、Databricks が発行した長期間有効なベアラー トークンを使用して、Databricks 以外の受信者をプロバイダーに接続する代替手段です。きめ細かなアクセス制御を可能にし、MFAをサポートし、受信者が共有資格情報を管理して保護する必要性を排除することでセキュリティリスクを軽減します。ベアラー トークンを使用して共有への認証を管理する方法については、「 ベアラー トークンを使用して非Databricks ユーザーの受信者オブジェクトを作成する (オープン共有)」を参照してください。
Delta Sharing では OIDC フェデレーションはどのように機能しますか?
-
データ プロバイダーは、 Delta Sharing on の Databricksで受信者を作成するときに、受信者 IdP の発行者 URL ( Microsoft Entra ID や Okta など) を指定し、共有にアクセスする必要がある受信者のユーザー、グループ、サービスプリンシパル、または OAuth アプリケーションを定義する OIDC トークン フェデレーション ポリシーを構成します。
-
Databricks は、ポリシーに基づいて OIDC プロファイル Web ポータル URL を生成し、プロバイダーはその URL を受信者と共有します。
エンドユーザーは、優先するプラットフォームに応じてエンドポイントURLをコピーするか、プロファイルファイルをダウンロードし、共有データをクエリするプラットフォームにURLまたはプロファイルファイルを提供します。Databricks OIDC ポータル Web からダウンロードしたこの共有プロファイル ファイルには、機密情報は含まれていません。
- ユーザーマシン間 (U2M) 認証の場合、受信者は OIDC プロファイル Web ポータルから受信者エンドポイントを U2M アプリケーションに入力します。
- マシン間 (M2M) 認証の場合、受信者アプリケーションの開発者はプロファイル ファイルをダウンロードし、受信者クライアント アプリで参照します。
-
受信者が優先プラットフォームを使用して共有データにアクセスしようとすると、認証はIdPにフェデレーションされます。
Databricks は、トークンや資格情報を生成または管理しません。代わりに、受信者の IdP は ID クレームを含む JWT を生成します。この有効期間の短いトークンの有効期間は、受信者の IdP によって強制されます。その後、Delta Sharing サービスは、JWT を受信者のポリシーに照らして検証し、JWT が発行者、対象ユーザー、サブジェクトなどの予想される要求と一致することを確認します。検証が成功すると、要求が認証され、Unity Catalog のアクセス許可に基づいてアクセスが許可されます。
始める前に
受信者を作成するには、次の要件を満たす必要があります。
- 共有するデータが登録されているUnity Catalogメタストアに対する
CREATE RECIPIENT権限が必要です。 - 受信者は、その Unity Catalog メタストアがアタッチされている Databricks ワークスペースを使用して作成する必要があります。
- Databricks ノートブックを使用して受信者を作成する場合、コンピュートは Databricks Runtime 11.3 LTS 以降を使用し、標準または専用アクセス モード (以前の共有およびシングル ユーザー アクセス モード) を使用する必要があります。
どのIDプロバイダーを使用するか?
OIDC フェデレーションは、共有シナリオに応じて、内部または外部の ID プロバイダーと共に使用できます。
-
内部 ID プロバイダ (プロバイダ管理)
- これは、異なる部門が Databricks に直接アクセスせず、同じ IdP を共有している大規模な組織内でデータを共有する場合に便利です。
- このアプローチにより、プロバイダーは受信者に代わってアクセスを管理できます。
- MFA や役割ベースのアクセス制御などのセキュリティ ポリシーは、プロバイダーの IdP によって適用されます。
-
外部 ID プロバイダ (受信者管理)
- プロバイダーは、受信者の IdP を信頼するように共有ポリシーを設定します。
- 受信者の組織は、共有データにアクセスできるユーザーを完全に制御できます。
- MFA や役割ベースのアクセス制御などのセキュリティポリシーは、受信者の IdP によって適用されます。
認証シナリオ U2M または M2M
OIDC トークン フェデレーションを使用した Secure Open Sharing は、ユーザーマシン間 (U2M) 認証フローとマシン間 (M2M) 認証フローの両方をサポートし、さまざまな安全なデータ共有シナリオを可能にします。
ユーザーマシン間(U2M)認証
受信者組織のユーザーは、IdP を使用して認証されます。MFA が設定されている場合は、ログイン時に適用されます。
認証されると、ユーザーは Power BI や Tableau などのツールを使用して共有データにアクセスできます。データプロバイダは、データアクセスを受信者組織内の特定のユーザーまたはグループに制限するアクセスポリシーを定義できるため、共有リソースにアクセスできるユーザーを正確に制御できます。U2M クライアント アプリケーション (Power BI など) は、OAuth 認証コード付与フローを使用して IdP からアクセス トークンを取得します。
マシンツーマシン(M2M)認証
M2Mは、夜間のジョブやバックグラウンドサービスなど、ユーザーの操作なしでアクセスする必要がある自動化されたワークロードに最適です。The recipient organization 登録する a サービスプリンシパル in its IdP. このサービス ID により、アプリケーションまたはスクリプトはプログラムによってリソースに安全にアクセスできます。Databricks、プロバイダー、または受信者の間でシークレットや資格情報が交換されることはありません。すべてのシークレット管理は、各組織の内部に残ります。Python Delta Sharing Client や Spark Delta Sharing Client などの M2M クライアントは、OAuth Client Credentials Grant フローを使用して IdP からアクセストークンを取得します。
OIDC フェデレーション ポリシーを使用する受信者を作成する
ステップ1.Open OIDC フェデレーション受信者の作成
OIDC を使用して認証する受信者を作成するには、次のようにします。
-
Databricks ワークスペースで、
カタログ をクリックします。
-
[カタログ ] ウィンドウの上部にある [
] 歯車アイコンをクリックし、[ Delta Sharing ] を選択します。
または、右上隅の 「共有」> Delta Sharing をクリックします。
-
[ 自分が共有] タブで、[ 新しい受信者 ] をクリックします。
-
受信者名 を入力します。
-
[受信者の種類] で、[ 開く] を選択します。
-
オープン 認証方式 として「OIDC Federation」を選択します。
-
作成 をクリックします。
-
(オプション)カスタム 受信者プロパティ を作成します。受信者 の「詳細 」タブで、「 プロパティを編集」>「+プロパティを追加」 をクリックします。次に、プロパティ名 ( キー ) と 値 を追加します。詳細については、「 受信者のプロパティの管理」を参照してください。
ステップ2.OIDC フェデレーション ポリシーの作成
ポリシーを作成する前に、共有にアクセスする必要があるユーザー、グループ、サービスプリンシパル、OAuthアプリケーションなど、IdPに関する必要な情報を受信者から収集します。内部共有に独自の (内部) IdP を使用している場合は、独自の ID システムからこの情報を取得します。
まず、受信者に IdP と共有にアクセスできるユーザー、グループ、サービスプリンシパル、または OAuth アプリケーションに関する情報を要求する必要があります。 その後、受信者を作成するときに、その情報を Databricks で提供します。
受信者の編集ページの OIDC フェデレーション ポリシー で、[ ポリシーの追加 ] をクリックします。

次の項目を入力します。
-
ポリシー名 : 人間が判読できるポリシーの名前。
-
発行者URL : JWTトークンを発行するIdPのHTTPS URL。
-
サブジェクト要求 : 認証 ID の種類を識別する JWT 内の要求。Microsoft Entra ID では、次の値を構成できます。
oid(オブジェクト ID): ユーザーが PowerBI などの U2M アプリケーションを介してデータにアクセスすることを意図している場合に選択します。groups: ユーザーのグループが PowerBI などの U2M アプリケーションを介してデータにアクセスする場合に選択します。azp: OAuth アプリケーションが Python Delta Sharing Client や Spark Delta Sharing Client などの M2M アプリケーションを介してデータにアクセスする場合に選択します。
他の一部の IdP では、sub などのクレームが使用される場合があります。IdP のドキュメントを参照して、ユースケースに適したクレームを判断してください。
-
件名 : 共有へのアクセスが許可されている特定のユーザー、グループ、またはアプリケーション。
-
対象ユーザー : JWT が一致する必要がある 1 つ以上のリソース識別子。トークンは、その aud 要求がリストされた対象ユーザーのいずれかと一致する場合に有効と見なされます。
使用する値 (issuer、subject claim、subject、audience) がわからない場合は、次の例を参照してください。OIDC フェデレーション ポリシーを作成する前に、その詳細を決定する必要があります。
外部の受信者が管理するIdPを使用している場合は、安全なチャンネルを使用して共有された受信者に次の情報をリクエストしてください。内部プロバイダーが管理する IdP を使用している場合、この情報は、共有している ID に基づいて独自の IdP から取得されます。
IdP が Entra ID の場合の U2M の例:
これらは、Entra ID テナントのオブジェクト ID 11111111-2222-3333-4444-555555555555 を持つ特定のユーザーと共有するための構成例です aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee
- 発行者:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - サブジェクト要求:
oid(オブジェクト ID) - 件名:
11111111-2222-3333-4444-555555555555 - 対象ユーザー:
64978f70-f6a6-4204-a29e-87d74bfea138(これは、Databricks によって Entra ID に登録されたマルチテナント アプリのクライアント ID です)
これらは、Entra ID テナントのオブジェクト ID 66666666-2222-3333-4444-555555555555 を持つ特定のグループと共有するための構成例です aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee
- 発行者:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - サブジェクトクレーム:
groups - 件名:
66666666-2222-3333-4444-555555555555 - 対象ユーザー:
64978f70-f6a6-4204-a29e-87d74bfea138(これは、Databricks によって Entra ID に登録されたマルチテナント アプリのクライアント ID です)
Power BI や Tableau などの U2M アプリケーションの場合、対象ユーザーは Databricks によって Entra ID に登録されたマルチテナント アプリ ID ( 64978f70-f6a6-4204-a29e-87d74bfea138) である必要があります。
U2M アプリケーションとその OIDC フェデレーション ポリシーの詳細については、「U2M フローでの Open ID Connect (OIDC) フェデレーションを使用して共有されたデータの読み取り」を参照してください。
IdPがEntra IDの場合のM2Mの例:
Entra ID テナント aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeeeにアプリケーション (クライアント) ID 11111111-2222-3333-4444-555555555555 がある M2M OAuth アプリケーションの場合:
- 発行者:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - 対象クレーム:
azp - subject:
11111111-2222-3333-4444-555555555555(これはアプリケーション (クライアント) ID で、登録済みの OAuth アプリケーションのクライアント ID であり、受信者の Entra ID ポータルで確認できます) - オーディエンス:
66666666-2222-3333-4444-555555555555(これは、受信者によって定義された有効なオーディエンス識別子であれば何でも構いません。例えば、登録済みのOAuthアプリケーションのクライアントIDなどです。)M2M アプリケーションとその OIDC フェデレーション ポリシーの詳細については、「M2M フローで Open ID Connect (OIDC) フェデレーションを使用して共有されたデータを読み取る」を参照してください。
ステップ3.受信者に共有へのアクセス権を付与する
受信者を作成し、 共有を作成したら、その共有へのアクセス権を受信者に付与できます。
受信者に共有アクセス権を付与するには、カタログエクスプローラ、Databricks Unity Catalog CLI、または Databricks ノートブックまたは Databricks SQL クエリエディターの GRANT ON SHARE SQL コマンドを使用できます。
必要な権限 : 次のいずれかです。
- メタストア管理者。
- 共有オブジェクトと受信者オブジェクト ((
USE SHARE+SET SHARE PERMISSION) または共有の所有者) および (USE RECIPIENTまたは受信者の所有者) の両方に対する委任されたアクセス許可または所有権。
手順については、「 Delta Sharing データ共有へのアクセスを管理する (プロバイダー向け)」を参照してください。
受信者のワークフロー
受信者が OIDC トークン フェデレーションを使用して共有を認証し、アクセスする方法については、以下を参照してください。