Freigeben über

Verwenden des OIDC-Verbunds (Open ID Connect) zum Aktivieren der Authentifizierung für Delta Sharing-Freigaben (offene Freigabe)

Auf dieser Seite wird erläutert, wie Datenanbieter in Azure Databricks die Authentifizierung mit einem Identitätsanbieter (IdP) verbinden können, um den Zugriff auf delta-Freigabefreigaben zu steuern, die in Azure Databricks erstellt wurden. Dieser Authentifizierungsfluss nutzt eine OIDC-Föderation, die JSON-Webtoken (JWTs) zulässt, die vom IdP des Empfängers als kurzlebige OAuth-Token agieren und von Azure Databricks authentifiziert werden. Diese Authentifizierungsmethode der Databricks-to-open-Freigabe richtet sich an Empfänger, die keinen Zugriff auf einen Unity Catalog-aktivierten Databricks-Arbeitsbereich haben.

Im OIDC-Verbund ist der IdP des Empfängers für die Ausgabe von JWT-Token und das Erzwingen von Sicherheitsrichtlinien verantwortlich, wie zum Beispiel die Mehr-Faktor-Authentifizierung (MFA, Multi-Factor Authentication). Ebenso unterliegt die Lebensdauer des JWT-Tokens dem IdP des Empfängers. Databricks generiert oder verwaltet diese Token nicht. Es führt nur die Verbundauthentifizierung zum IdP des Empfängers durch und überprüft das JWT anhand der konfigurierten Verbundrichtlinie des Empfängers. Datenanbieter können auch eine Verbundauthentifizierung mit ihrem eigenen IDP auswählen, wenn Sie Daten intern für andere Benutzer oder Abteilungen innerhalb ihrer Organisation freigeben.

Die OIDC-Föderation ist eine Alternative zur Verwendung langlebiger, von Azure Databricks ausgestellter Bearer-Token, um Nicht-Databricks-Empfänger mit Anbietern zu verbinden. Es ermöglicht eine feingranulare Zugriffssteuerung, unterstützt MFA und reduziert Sicherheitsrisiken, indem die Notwendigkeit für Empfänger entfällt, geteilte Anmeldeinformationen zu verwalten und zu sichern. Weitere Informationen zum alternativen Verwenden von Bearertoken zum Verwalten der Authentifizierung für Freigaben finden Sie unter Erstellen eines Empfängerobjekts für Nicht-Databricks-Benutzende, die Bearertoken (offene Freigabe) verwenden.

Wie funktioniert der OIDC-Partnerverbund in Delta Sharing?

  1. Wenn der Datenanbieter den Empfänger in Delta Sharing für Azure Databricks erstellt, konfigurieren sie eine OIDC-Tokenverbundrichtlinie, die die Aussteller-URL des Empfänger-IDP angibt, z. B. Microsoft Entra-ID oder Okta, und definiert den Empfängerbenutzer, die Gruppe, den Dienstprinzipal oder die OAuth-Anwendung, die Zugriff auf die Freigabe haben soll.

  2. Azure Databricks generiert eine OIDC-Profilwebportal-URL basierend auf der Richtlinie, und der Anbieter teilt diese URL mit dem Empfänger.

    Der Endbenutzer kopiert die Endpunkt-URL oder lädt die Profildatei je nach bevorzugter Plattform herunter und stellt die URL oder Profildatei auf die Plattform bereit, auf der sie die freigegebenen Daten abfragen. Diese freigegebene Profildatei, die aus dem Databricks OIDC-Portalweb heruntergeladen wurde, enthält keine vertraulichen Informationen.

    • Für die Benutzer-zu-Computer-Authentifizierung (U2M) gibt der Empfänger den Empfängerendpunkt aus dem OIDC-Profilwebportal in seine U2M-Anwendung ein.
    • Für die Computer-zu-Computer-Authentifizierung (M2M) lädt der Empfängeranwendungsentwickler die Profildatei herunter und verweist in der Empfängerclient-App darauf.

  3. Wenn der Empfänger versucht, auf freigegebene Daten über seine bevorzugte Plattform zuzugreifen, wird die Authentifizierung mit ihrem IdP verbunden.

    Databricks generiert oder verwaltet keine Token oder Anmeldeinformationen. Stattdessen generiert der Identitätsanbieter des Empfängers ein JWT mit Identitätsansprüchen. Die Lebensdauer dieses kurzlebigen Tokens wird vom Identitätsanbieter des Empfängers erzwungen. Der Delta Sharing-Dienst überprüft das JWT dann anhand der Empfängerrichtlinie, um sicherzustellen, dass es den erwarteten Ansprüchen entspricht, z. B. Aussteller, Zielgruppe und Betreff. Wenn die Überprüfung erfolgreich ist, wird die Anforderung authentifiziert, und der Zugriff wird basierend auf Unity-Katalogberechtigungen gewährt.

Bevor Sie beginnen

Zum Erstellen eines Empfängers müssen Sie die folgenden Anforderungen erfüllen:

  • Sie müssen ein Metastore-Administrator sein oder über die CREATE RECIPIENT Berechtigung für den Unity-Katalogmetastore verfügen, in dem die Daten, die Sie freigeben möchten, registriert sind.
  • Sie müssen den Empfänger mithilfe eines Azure Databricks-Arbeitsbereichs erstellen, der mit einem Unity-Katalog-Metastore verbunden ist.
  • Wenn Sie ein Databricks-Notizbuch verwenden, um den Empfänger zu erstellen, muss Ihr Rechner Databricks Runtime 11.3 LTS oder höher sowie entweder den Standard- oder den dedizierten Zugriffsmodus (vormals freigegebene und Einzelbenutzer-Zugriffsmodi) verwenden.

Welcher Identitätsanbieter soll verwendet werden?

Abhängig vom Freigabeszenario können Sie den OIDC-Verbund mit einem internen oder externen Identitätsanbieter verwenden:

  • Interner Identitätsanbieter (Provider-Managed)

    • Dies ist nützlich für das Freigeben von Daten in großen Organisationen, in denen unterschiedliche Abteilungen keinen direkten Databricks-Zugriff haben, aber denselben IdP nutzen.
    • Dieser Ansatz ermöglicht es dem Anbieter, den Zugriff im Auftrag des Empfängers zu verwalten.
    • Sicherheitsrichtlinien wie MFA und rollenbasierte Zugriffssteuerung werden vom IdP des Anbieters erzwungen.

  • Externer Identitätsanbieter (Recipient-Managed)

    • Der Anbieter richtet die Freigaberichtlinie ein, um dem Identitätsanbieter des Empfängers zu vertrauen.
    • Die Empfängerorganisation behält die volle Kontrolle darüber, wer auf die freigegebenen Daten zugreifen kann.
    • Sicherheitsrichtlinien, z. B. MFA und rollenbasierte Zugriffssteuerung, werden vom IDP des Empfängers erzwungen.

Authentifizierungsszenario U2M oder M2M

Secure Open Sharing with OIDC Token Federation unterstützt sowohl User-to-Machine (U2M) als auch Machine-to-Machine (M2M)-Authentifizierungsflüsse, wodurch eine vielzahl sicherer Datenfreigabeszenarien ermöglicht werden.

Benutzer-zu-Computer-Authentifizierung (U2M)

Ein Benutzer aus der Empfängerorganisation authentifiziert sich mithilfe seines IdP. Wenn MFA konfiguriert ist, wird sie während der Anmeldung erzwungen.

Nach der Authentifizierung können Benutzer mithilfe von Tools wie Power BI oder Tableau auf freigegebene Daten zugreifen. Der Datenanbieter kann Zugriffsrichtlinien definieren, die den Datenzugriff auf bestimmte Benutzer oder Gruppen innerhalb der Empfängerorganisation einschränken und eine präzise Kontrolle darüber gewährleisten, wer auf freigegebene Ressourcen zugreifen kann. Die U2M-Clientanwendung (z. B. Power BI) verwendet den OAuth Authorization Code Grant-Fluss, um Zugriffstoken vom IdP abzurufen.

Computer-zu-Computer-Authentifizierung (M2M)

M2M eignet sich ideal für automatisierte Workloads, z. B. Nachtaufträge oder Hintergrunddienste, die ohne Benutzerinteraktion Zugriff erfordern. Die Empfängerorganisation registriert einen Dienstprinzipal in seinem IdP. Diese Dienstidentität ermöglicht Anwendungen oder Skripts, programmgesteuert auf Ressourcen zuzugreifen. Es werden keine Geheimnisse oder Anmeldeinformationen zwischen Databricks, dem Anbieter oder dem Empfänger ausgetauscht. Alle geheimen Verwaltungen bleiben für jede Organisation intern. M2M-Clients, z. B. der Python Delta Sharing Client oder der Spark Delta Sharing Client, verwenden den OAuth-Client-Credentials-Grant-Prozess, um Zugriffstoken vom IdP abzurufen.

Erstellen eines Empfängers, der eine OIDC-Verbundrichtlinie verwendet

Schritt 1. Erstellen eines Empfängers für einen offenen OIDC-Verbund

So erstellen Sie einen Empfänger, der sich mit OIDC authentifiziert:

  1. Klicken Sie im Azure Databricks-Arbeitsbereich auf das Datensymbol.Katalog.

  2. Klicken Sie oben im Bereich Katalog auf das Zahnradsymbol Zahnrad-Symbol, und wählen Sie Delta Sharing aus.

    Klicken Sie alternativ auf der Seite Schnellzugriff auf die Schaltfläche Delta Sharing >.

  3. Klicken Sie auf der Registerkarte " Von mir freigegeben " auf "Neuer Empfänger".

  4. Geben Sie den Namen des Empfängers ein.

  5. Wählen Sie für den Empfängertyp"Öffnen" aus.

  6. Wählen Sie den OIDC-Verbund als Open Authentication-Methode aus.

  7. Klicken Sie auf Erstellen.

  8. (Optional) Erstellen sie benutzerdefinierte Empfängereigenschaften. Klicken Sie auf der Registerkarte " Empfängerdetails " auf "Eigenschaften > bearbeiten+Eigenschaft hinzufügen". Fügen Sie dann einen Eigenschaftsnamen (Key) und einen Wert hinzu. Ausführliche Informationen finden Sie unter "Verwalten von Empfängereigenschaften".

Schritt 2. Erstellen einer OIDC-Verbundrichtlinie

Bevor Sie die Richtlinie erstellen, sammeln Sie die notwendigen Informationen vom Empfänger über deren IdP, einschließlich der Benutzer, Gruppen, Dienstprinzipale oder OAuth-Anwendungen, die auf die Freigabe zugreifen sollten. Wenn Sie Ihren eigenen (internen) IdP für die interne Freigabe verwenden, rufen Sie diese Informationen aus Ihrem eigenen Identitätssystem ab.

Sie müssen zuerst Informationen vom Empfänger über deren IdP und die Benutzer, Gruppen, Dienstprinzipale oder OAuth-Anwendungen anfordern, die auf die Freigabe zugreifen sollen. Anschließend geben Sie diese Informationen in Azure Databricks an, wenn Sie den Empfänger erstellen.

Klicken Sie auf der Seite "Empfängerbearbeitung" unter den OIDC-Verbundrichtlinien auf "Richtlinie hinzufügen".

Dialogfeld

Geben Sie Folgendes ein:

  • Richtlinienname: Lesbarer Name für die Richtlinie.

  • Aussteller-URL: Die HTTPS-URL des IdP, der das JWT-Token ausgibt.

  • Antragstelleranspruch: Der Anspruch im JWT, der den Authentifizierungsidentitätstyp identifiziert. In Microsoft Entra ID können Sie die folgenden Werte konfigurieren:

    • oid (Objekt-ID): Wählen Sie aus, ob ein Benutzer über eine U2M-Anwendung wie PowerBI auf die Daten zugreifen soll.
    • groups: Wählen Sie aus, ob eine Gruppe von Benutzern über eine U2M-Anwendung wie PowerBI auf die Daten zugreifen soll.
    • azp: Wählen Sie aus, ob eine OAuth-Anwendung für den Zugriff auf die Daten über eine M2M-Anwendung vorgesehen ist, z. B. Python Delta Sharing Client oder Spark Delta Sharing Client.

    In einigen anderen IdPs können Ansprüche wie sub oder Andere verwendet werden. In der IdP-Dokumentation können Sie den richtigen Anspruch für Ihren Anwendungsfall ermitteln.

  • Betreff: Der spezifische Benutzer, die Gruppe oder die Anwendung, die auf die Freigabe zugreifen darf.

  • Zielgruppen: Mindestens ein Ressourcenbezeichner, dem JWT entsprechen muss. Ein Token gilt als gültig, wenn sein AUD-Anspruch mit einer der aufgeführten Zielgruppen übereinstimmt.

Wenn Sie unsicher sind, welche Werte Sie verwenden sollen (Aussteller, Subjektanspruch, Subjekt, Zielgruppe), konsultieren Sie das folgende Beispiel. Sie müssen die Details der OIDC-Verbundrichtlinie ermitteln, bevor Sie sie erstellen.

Wenn Sie einen externen, vom Empfänger verwalteten IdP verwenden, fordern Sie die folgenden Informationen an, die über einen sicheren Kanal vom Empfänger freigegeben wurden. Wenn Sie Ihren internen vom Anbieter verwalteten IdP verwenden, stammen diese Informationen von Ihrem eigenen IdP, basierend auf den Identitäten, mit denen Sie Daten teilen.

Beispiel für U2M, wenn IdP entra-ID ist:

Dies sind Beispielkonfigurationen für die Freigabe mit einer bestimmten benutzenden Person mit der Objekt-ID 11111111-2222-3333-4444-555555555555 im Entra ID-Mandanten aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

  • Aussteller: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
  • Anspruchstitel: oid (Object ID)
  • Betreff: 11111111-2222-3333-4444-555555555555
  • Zielgruppe: 64978f70-f6a6-4204-a29e-87d74bfea138 (Dies ist die Client-ID der von Databricks in Entra ID registrierten Mehrinstanzen-App)

Dies sind Beispielkonfigurationen für die Freigabe mit einer bestimmten Gruppe mit der Objekt-ID 66666666-2222-3333-4444-555555555555 im Entra ID-Mandanten aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

  • Aussteller: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
  • Antragstelleranspruch: groups
  • Betreff: 66666666-2222-3333-4444-555555555555
  • Zielgruppe: 64978f70-f6a6-4204-a29e-87d74bfea138 (Dies ist die Client-ID der von Databricks in Entra ID registrierten Mehrinstanzen-App)

Hinweis

Für U2M-Anwendungen wie Power BI und Tableau sollte die Zielgruppe die von Databricks in Entra ID registrierte mehrmandantenfähige App-ID sein, das heißt 64978f70-f6a6-4204-a29e-87d74bfea138.

Weitere Informationen zu U2M-Anwendungen und deren OIDC-Verbundrichtlinien finden Sie unter Empfangen von Delta Sharing-Aktien mit Open ID Connect (OIDC) Federation in einem Benutzer-zu-Maschine-Ablauf (offenes Teilen).

Beispiel für M2M, wenn IdP entra-ID ist:

Für eine M2M OAuth-Anwendung mit der Application (Client)-ID „11111111-2222-3333-4444-555555555555“ im Entra ID-Mandant „aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee“:

Schritt 3. Zuweisen des Empfängerzugriffs auf eine Freigabe

Nachdem Sie den Empfänger erstellt und Freigaben erstellt haben, können Sie dem Empfänger Zugriff auf diese Freigaben gewähren.

Wenn Sie Empfängern Zugriff auf eine Freigabe gewähren möchten, können Sie hierzu den Katalog-Explorer, die Databricks Unity Catalog-Befehlszeilenschnittstelle oder den SQL-Befehl GRANT ON SHARE in einem Azure Databricks-Notebook oder im Databricks SQL-Abfrage-Editor verwenden.

Erforderliche Berechtigungen: Eine der folgenden Berechtigungen:

  • Metastore-Administrator.
  • Delegierte Berechtigungen oder Besitz sowohl für die Freigabe als auch für die Empfängerobjekte ((USE SHARE + SET SHARE PERMISSION) oder Person im Besitz der Freigabe) UND (USE RECIPIENT oder Person im Besitz des Empfängers).

Anweisungen finden Sie unter Verwalten des Zugriffs auf Delta Sharing-Datenfreigaben (für Anbieter).

Workflow für Empfänger

Informationen dazu, wie sich Empfänger mithilfe des OIDC-Tokenverbunds authentifizieren und auf Freigaben zugreifen können, finden Sie unter:

  • Last updated on