Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Op deze pagina wordt uitgelegd hoe gegevensproviders in Azure Databricks verificatie kunnen federeren aan een id-provider (IdP) om de toegang te beheren tot OpenSharing-shares die zijn gemaakt in Azure Databricks. Deze verificatiestroom maakt gebruik van OIDC-federatie, waardoor JSON-webtokens (JWT's) die zijn uitgegeven door de IdP van de ontvanger, worden toegestaan als kortdurende OAuth-tokens die worden geverifieerd door Azure Databricks. Deze databricks-to-open-verificatiemethode voor delen is ontworpen voor ontvangers die geen toegang hebben tot een Databricks-werkruimte met Unity Catalog-functionaliteit.
In OIDC Federation is de IdP van de ontvanger verantwoordelijk voor het uitgeven van JWT-tokens en het afdwingen van beveiligingsbeleid, zoals MFA (Multi-Factor Authentication). Op dezelfde manier wordt de levensduur van het JWT-token bepaald door de IdP van de ontvanger.
Databricks genereert of beheert deze tokens niet. Het federatieert alleen authenticatie naar de IdP van de ontvanger en valideert de JWT tegen het federatiebeleid zoals geconfigureerd voor de ontvanger. Gegevensproviders kunnen er ook voor kiezen om verificatie te federeren met hun eigen IdP bij het intern delen van gegevens met andere gebruikers of afdelingen binnen hun organisatie.
OIDC-federatie is een alternatief voor het gebruik van langlopende bearer-tokens van Azure Databricks om ontvangers die geen gebruik maken van Databricks met providers te verbinden. Het maakt fijnmazige toegangsbeheer mogelijk, ondersteunt MFA en vermindert beveiligingsrisico's door de noodzaak te elimineren voor ontvangers om gedeelde inloggegevens te beheren en te beveiligen.
Zie Een ontvangerobject aanmaken voor niet-Databricks-gebruikers met bearer-tokens (Databricks-naar-Open-sharing) voor informatie over het gebruik van bearer-tokens om in plaats daarvan de authenticatie voor shares te beheren.
Hoe werkt OIDC-federatie in OpenSharing?
Wanneer de gegevensprovider de geadresseerde in OpenSharing maakt op Azure Databricks, configureren ze een OIDC-tokenfederatiebeleid dat de URL van de ontvanger-IDP opgeeft, zoals Microsoft Entra ID of Okta, en definieert de ontvangergebruiker, groep, service-principal of OAuth-toepassing die toegang moet hebben tot de share.
Azure Databricks genereert een webportal-URL van het OIDC-profiel op basis van het beleid en de provider deelt die URL met de ontvanger.
De eindgebruiker kopieert de eindpunt-URL of downloadt het profielbestand, afhankelijk van het gewenste platform, en levert de URL of het profielbestand naar het platform waarop ze een query uitvoeren op de gedeelde gegevens. Dit gedeelde profielbestand dat is gedownload van de Databricks OIDC-portalweb bevat geen gevoelige informatie.
- Voor U2M-verificatie (gebruiker-naar-machine) voert de ontvanger het ontvangerseindpunt vanuit de portal van het OIDC-profiel in hun U2M-toepassing in.
- Voor machine-to-machine (M2M) authenticatie downloadt de ontwikkelaar van de toepassingsontvanger het profielbestand en verwijst hiernaar in de client-app van de ontvanger.
Wanneer de ontvanger probeert toegang te krijgen tot gedeelde gegevens via het voorkeursplatform, wordt de verificatie gefedereerd aan hun IdP.
Databricks genereert of beheert geen tokens of referenties. In plaats daarvan genereert de IdP van de ontvanger een JWT met identiteitsclaims. De beperkte levensduur van dit token wordt afgedwongen door de IdP van de ontvanger. De OpenSharing-service valideert vervolgens de JWT op basis van het beleid van de ontvanger om ervoor te zorgen dat deze overeenkomt met de verwachte claims, inclusief verlener, doelgroep en onderwerp. Als de validatie is geslaagd, wordt de aanvraag geverifieerd en wordt de toegang verleend op basis van Unity Catalog-machtigingen.
Voordat u begint
Als u een geadresseerde wilt maken, moet u voldoen aan de volgende vereisten:
- U moet over de
CREATE RECIPIENTbevoegdheid beschikken voor de Unity Catalog-metastore waar de gegevens die u wilt delen, zijn geregistreerd. - U moet de ontvanger maken met behulp van een Azure Databricks-werkruimte waaraan de Unity Catalog-metastore is gekoppeld.
- Als u een Databricks-notebook gebruikt om de ontvanger te maken, moet uw berekening gebruikmaken van Databricks Runtime 11.3 LTS of hoger en de standaard- of toegewezen toegangsmodus (voorheen gedeelde en modus voor toegang tot één gebruiker).
Welke id-provider moet worden gebruikt?
U kunt OIDC-federatie gebruiken met een interne of externe id-provider, afhankelijk van uw scenario voor delen:
Interne identiteitsprovider (Beheerd door Provider)
- Dit is handig voor het delen van gegevens binnen grote organisaties waarbij verschillende afdelingen geen directe Databricks-toegang hebben, maar dezelfde IdP delen.
- Met deze methode kan de provider de toegang namens de ontvanger beheren.
- Beveiligingsbeleid, zoals MFA en op rollen gebaseerd toegangsbeheer, worden afgedwongen door de IdP van de provider.
Externe identiteitsprovider (Recipient-Managed)
- De provider stelt het verdelingsbeleid in om de IdP van de ontvanger te vertrouwen.
- De organisatie van de geadresseerde behoudt volledige controle over wie toegang heeft tot de gedeelde gegevens.
- Beveiligingsbeleid, zoals MFA en op rollen gebaseerd toegangsbeheer, worden afgedwongen door de IdP van de ontvanger.
Verificatiescenario U2M of M2M
Beveiligd delen met OIDC-tokenfederatie ondersteunt zowel U2M-verificatiestromen (User-to-Machine) als M2M-verificatiestromen (Machine-to-Machine), waardoor een breed scala aan veilige scenario's voor het delen van gegevens mogelijk is.
Authenticatie van gebruiker naar machine (U2M)
Een gebruiker van de organisatie van de ontvanger verifieert zich met behulp van hun IdP. Als MFA is geconfigureerd, wordt deze afgedwongen tijdens de aanmelding.
Na verificatie hebben gebruikers toegang tot gedeelde gegevens met behulp van hulpprogramma's zoals Power BI of Tableau. De gegevensprovider kan toegangsbeleid definiëren waarmee de toegang tot gegevens wordt beperkt tot specifieke gebruikers of groepen binnen de organisatie van de ontvanger, zodat u nauwkeurig kunt bepalen wie toegang heeft tot gedeelde resources. De U2M-clienttoepassing (bijvoorbeeld Power BI) gebruikt de stroom OAuth Authorization Code Grant om toegangstokens van de IdP te verkrijgen.
Machine-to-Machine (M2M) authenticatie
M2M is ideaal voor geautomatiseerde workloads, zoals nachttaken of achtergrondservices, die toegang vereisen zonder tussenkomst van de gebruiker. De organisatie van de ontvanger registreert een service-principal in zijn IdP. Met deze service-identiteit kunnen toepassingen of scripts veilig en programmatisch toegang krijgen tot resources. Er worden geen geheimen of referenties uitgewisseld tussen Databricks, de provider of de ontvanger. Alle geheime beheer blijft intern voor elke organisatie. M2M-clients, zoals de Python OpenSharing-client of Spark OpenSharing-client, gebruiken de OAuth Client Credentials Grant-flow om toegangstokens bij de IdP op te halen.
Een ontvanger maken die gebruikmaakt van een OIDC-federatiebeleid
Stap 1. Een Open OIDC-federatieontvanger creëren
Om een geadresseerde aan te maken die met OIDC geauthenticeerd wordt:
Klik in uw Azure Databricks werkruimte op
Catalog.
Klik bovenaan het deelvenster Catalogus op het
en selecteer OpenSharing.
U kunt ook in de rechterbovenhoek op OpenSharing delen >klikken.
Klik op het tabblad Gedeeld door mij op Nieuwe geadresseerde.
Voer de naam van de ontvanger in.
Selecteer Openenvoor ontvangertype.
Kies OIDC Federation als open authentication-methode.
Klik op Create.
(Optioneel) Maak aangepaste eigenschappen voor geadresseerden. Klik op het tabblad van de geadresseerde Details
op Eigenschappen bewerken Voeg vervolgens een eigenschapsnaam (sleutel) en waarde toe. Zie Eigenschappen van geadresseerden beheren voor meer informatie.+Eigenschap toevoegen.
Stap 2. OIDC-federatiebeleid maken
Voordat u het beleid maakt, moet u de benodigde informatie verzamelen van de ontvanger over hun IdP, inclusief de gebruikers, groepen, service-principals of OAuth-toepassingen die toegang moeten hebben tot de share. Als u uw eigen (interne) IdP gebruikt voor intern delen, haalt u deze informatie op uit uw eigen identiteitssysteem.
U moet eerst informatie aanvragen van de ontvanger over hun IdP en de gebruikers, groepen, service-principals of OAuth-toepassingen die toegang moeten hebben tot de share. Vervolgens geeft u die informatie op in Azure Databricks wanneer u de ontvanger maakt.
- Klik op de bewerkingspagina van ontvangers onder OIDC-federatiebeleiden klik op Beleid toevoegen.
Voer het volgende in:
beleidsnaam: leesbare naam voor het beleid.
URL van verlener: de HTTPS-URL van de IdP die het JWT-token uitgeeft.
Onderwerpclaim: de claim in de JWT die het verificatie-identiteitstype identificeert. In Microsoft Entra-id kunt u de volgende waarden configureren:
-
oid(Object-id): selecteer of een gebruiker toegang heeft tot de gegevens via een U2M-toepassing, zoals PowerBI. -
groups: Selecteer of een groep gebruikers toegang heeft tot de gegevens via een U2M-toepassing, zoals PowerBI. -
azp: Selecteer of een OAuth-toepassing is bedoeld voor toegang tot de gegevens via een M2M-toepassing, zoals Python OpenSharing-client of Spark OpenSharing-client.
In sommige andere IdP's kunnen claims zoals sub of andere claims worden gebruikt. Raadpleeg de IdP-documentatie om de juiste claim voor uw use-case te bepalen.
-
Onderwerp: De specifieke gebruiker, groep of toepassing die toegang heeft tot de share.
Doelgroepen: een of meer resource-id's die de JWT's moeten overeenkomen. Een token wordt als geldig beschouwd als de "aud"-claim overeenkomt met een van de vermelde doelgroepen.
Klik op Opslaan.
Als u niet zeker weet welke waarden moeten worden gebruikt (uitgever, onderwerpclaim, onderwerp, doelgroep), raadpleegt u het volgende voorbeeld. U moet de details van het OIDC-federatiebeleid bepalen voordat u het maakt.
Als u een door een externe ontvanger beheerde IdP gebruikt, vraagt u de volgende informatie aan van de ontvanger die is gedeeld via een beveiligd kanaal. Als u uw interne provider beheerde IdP gebruikt, is deze informatie afkomstig van uw eigen IdP op basis van de identiteiten waarmee u deelt.
Voorbeeld voor U2M wanneer IdP entra-id is:
Dit zijn voorbeeldconfiguraties voor delen met een specifieke gebruiker met object-id 11111111-2222-3333-4444-555555555555 in entra-id-tenant aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee
- Uitgevende instelling:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - onderwerpclaim:
oid(Object-ID) - Onderwerp:
11111111-2222-3333-4444-555555555555 - Doelgroepen:
64978f70-f6a6-4204-a29e-87d74bfea138(Dit is de client-id van de app met meerdere tenants die is geregistreerd door Databricks in Entra ID)
Dit zijn voorbeelden van configuratie voor delen met een specifieke groep met object-id 66666666-2222-3333-4444-555555555555 in entra-id-tenant aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee
- Uitgevende instelling:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - onderwerp van claim:
groups - Onderwerp:
66666666-2222-3333-4444-555555555555 - Doelgroepen:
64978f70-f6a6-4204-a29e-87d74bfea138(Dit is de client-id van de app met meerdere tenants die is geregistreerd door Databricks in Entra ID)
Note
Voor U2M-toepassingen zoals Power BI en Tableau moet de doelgroep de multi-tenant app-ID zijn die door Databricks in Entra ID is geregistreerd, wat is 64978f70-f6a6-4204-a29e-87d74bfea138.
Zie Lezen welke gegevens worden gedeeld via Open ID Connect (OIDC)-federatie in een U2M-flow voor meer informatie over U2M-toepassingen en hun OIDC-federatiebeleid.
Voorbeeld voor M2M wanneer IdP entra-id is:
Voor een M2M OAuth-toepassing met Application (client) ID 11111111-2222-3333-4444-555555555555 in Entra ID-tenant aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee:
- Uitgevende instelling:
https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0 - Claim inzake onderwerp:
azp - onderwerp:
11111111-2222-3333-4444-555555555555(Dit is de toepassings-id (client), de client-id van de geregistreerde OAuth-toepassing en kan worden gevonden in de Entra ID-portal van de geadresseerde) - Doelgroepen:
66666666-2222-3333-4444-555555555555(Dit kan elke geldige doelgroep-id zijn die is gedefinieerd door de ontvanger, zoals de client-id van de geregistreerde OAuth-toepassing.) Zie Voor meer informatie over M2M-toepassingen en hun OIDC-federatiebeleid gegevens lezen die worden gedeeld met behulp van Open ID Connect (OIDC)-federatie in een M2M-stroom.
Stap 3. De ontvanger toegang verlenen tot een gedeeld bestand
Nadat u de ontvanger hebt gemaakt en shares hebt gemaakt, kunt u de ontvanger toegang verlenen tot deze shares.
Als u sharetoegang wilt verlenen aan ontvangers, kunt u Catalog Explorer, de Databricks Unity Catalog CLI of de GRANT ON SHARE SQL-opdracht gebruiken in een Azure Databricks-notebook of de Databricks SQL-queryeditor.
Vereiste machtigingen: een van de volgende:
- Metastore-beheerder.
- Gedelegeerde machtigingen of eigendom voor zowel de share- als de ontvangerobjecten ((
USE SHARE+SET SHARE PERMISSION) of de eigenaar van de share) EN (USE RECIPIENTof de eigenaar van de ontvanger).
Zie Toegang tot OpenSharing-gegevensdelen beheren (voor aanbieders) voor instructies.
Deel met Iceberg-ontvanger
Als uw OIDC-ontvanger gedeelde data-assets leest met behulp van een Iceberg REST-catalogus, deel dan de koppeling naar het portaal voor het genereren van Iceberg OIDC-profielen.
Verzend de koppeling nadat u een ontvanger hebt gemaakt die gebruikmaakt van een OIDC-federatiebeleid:
Klik in uw Azure Databricks werkruimte op
Catalog.
Klik bovenaan het deelvenster Catalogus op het
en selecteer OpenSharing.
U kunt ook in de rechterbovenhoek op OpenSharing delen >klikken.
Klik op het tabblad Gedeeld door mij op Ontvangers.
Zoek en selecteer de OIDC-ontvanger.
Klik aan de rechterkant van de pagina onder OIDC-federatiebeleid op Standaard-OIDC-beleid.
Kopieer de koppeling voor het genereren van iceberg OIDC-profielen en deel deze met uw ontvanger met behulp van een veilige methode.
De koppeling bevat ook de namen van de shares, die de ontvanger nodig heeft om gedeelde gegevens te lezen.
Werkstroom voor ontvangers
Zie voor meer informatie over hoe ontvangers shares verifiëren en openen met behulp van OIDC-tokenfederatie: