Dela via

Använd OIDC-federation (Open ID Connect) för att aktivera autentisering till Delta-delningsresurser (öppen delning)

Den här sidan förklarar hur dataleverantörer i Azure Databricks kan använda federerad autentisering till en identitetsleverantör (IdP) för att styra åtkomsten till Delta Sharing-delningar som skapats i Azure Databricks. Det här autentiseringsflödet använder OIDC-federation, vilket tillåter JSON-webbtoken (JWT) som utfärdats av mottagarens IdP som kortlivade OAuth-token autentiserade av Azure Databricks. Den här Databricks-till-öppen-delning autentiseringsmetoden är utformad för mottagare som inte har åtkomst till en Unity Catalog-aktiverad Databricks-arbetsyta.

I OIDC-federation ansvarar mottagarens IdP för att utfärda JWT-token och framtvinga säkerhetsprinciper, till exempel Multi-Factor Authentication (MFA). På samma sätt styrs livslängden för JWT-token av mottagarens IdP. Databricks genererar eller hanterar inte dessa token. Den federerar endast autentisering till mottagarens IdP och validerar JWT mot mottagarens konfigurerade federationsprincip. Dataleverantörer kan också välja att federera autentisering till sin egen IdP när de delar data internt med andra användare eller avdelningar i organisationen.

OIDC-federation är ett alternativ till att använda långlivade Azure Databricks-utfärdade ägartoken för att ansluta icke-Databricks-mottagare till leverantörer. Den möjliggör detaljerad åtkomstkontroll, stöder MFA och minskar säkerhetsriskerna genom att eliminera behovet av att mottagarna hanterar och skyddar delade autentiseringsuppgifter. Information om hur du använder ägartoken för att hantera autentisering till resurser i stället finns i Skapa ett mottagarobjekt för icke-Databricks-användare som använder ägartoken (öppen delning).

Hur fungerar OIDC-federation i Delta Sharing?

  1. När dataprovidern skapar mottagaren i Deltadelning i Azure Databricks konfigurerar de en federationsprincip för OIDC-token som anger utfärdarens URL för mottagarens IdP, till exempel Microsoft Entra ID eller Okta, och definierar mottagarens användare, grupp, tjänsthuvudnamn eller OAuth-program som ska ha åtkomst till resursen.

  2. Azure Databricks genererar en url för OIDC-profilwebbportalen baserat på principen och providern delar url:en med mottagaren.

    Slutanvändaren kopierar slutpunkts-URL:en eller laddar ned profilfilen, beroende på vilken plattform de föredrar, och tillhandahåller URL: en eller profilfilen till den plattform där de kommer att köra frågor mot delade data. Den här delade profilfilen som laddas ned från Databricks OIDC-portalens webb innehåller ingen känslig information.

    • För U2M-autentisering (användar-till-dator) matar mottagaren in mottagarslutpunkten från OIDC-profilwebbportalen till sitt U2M-program.
    • För M2M-autentisering (machine-to-machine) laddar programutvecklaren ned profilfilen och refererar till den i mottagarklientappen.

  3. När mottagaren försöker komma åt delade data med hjälp av sin föredragna plattform federeras autentiseringen till deras IdP.

    Databricks genererar eller hanterar inga token eller autentiseringsuppgifter. I stället genererar mottagarens IdP en JWT som innehåller identitetsuppgifter. Livslängden för denna kortlivade token regleras av mottagarens IdP. Deltadelningstjänsten validerar sedan JWT mot mottagarens policy för att säkerställa att det överensstämmer med de förväntade påståendena, inklusive utfärdare, målgrupp och ämne. Om valideringen lyckas autentiseras begäran och åtkomst beviljas baserat på Behörigheter för Unity-katalogen.

Innan du börjar

Om du vill skapa en mottagare måste du uppfylla följande krav:

  • Du måste vara administratör för metaarkivet eller ha behörighet för CREATE RECIPIENT metaarkivet Unity Catalog där de data som du vill dela är registrerade.
  • Du måste skapa mottagaren med hjälp av en Azure Databricks-arbetsyta som har Unity Catalog-metaarkivet kopplat.
  • Om du använder en Databricks-notebook-fil för att skapa mottagaren måste din beräkning använda Databricks Runtime 11.3 LTS eller senare och antingen standard- eller dedikerat åtkomstläge (tidigare delade och enstaka användaråtkomstlägen).

Vilken identitetsprovider ska användas?

Du kan använda OIDC-federation med antingen en intern eller extern identitetsprovider, beroende på ditt delningsscenario:

  • intern identitetsleverantör (Provider-Managed)

    • Detta är användbart för att dela data inom stora organisationer där olika avdelningar inte har direkt Databricks-åtkomst men delar samma IdP.
    • Med den här metoden kan providern hantera åtkomst för mottagarens räkning.
    • Säkerhetsprinciper, till exempel MFA och rollbaserad åtkomstkontroll, tillämpas av providerns IdP.

  • extern identitetsleverantör (Recipient-Managed)

    • Providern konfigurerar delningsprincipen för att lita på mottagarens IdP.
    • Mottagarorganisationen behåller fullständig kontroll över vem som kan komma åt delade data.
    • Säkerhetsprinciper, till exempel MFA och rollbaserad åtkomstkontroll, tillämpas av mottagarens IdP.

Autentiseringsscenario U2M eller M2M

Säker öppen delning med OIDC-tokenfederation stöder både användar-till-dator-autentiseringsflöden (U2M) och M2M-autentiseringsflöden (Machine-to-Machine), vilket möjliggör en mängd olika säkra scenarier för datadelning.

Användar-till-dator-autentisering (U2M)

En användare från mottagarorganisationen autentiserar med sitt IdP. Om MFA har konfigurerats framtvingas det under inloggningen.

När de har autentiserats kan användarna komma åt delade data med hjälp av verktyg som Power BI eller Tableau. Dataleverantören kan definiera åtkomstprinciper som begränsar dataåtkomsten till specifika användare eller grupper i mottagarorganisationen, vilket ger exakt kontroll över vem som har åtkomst till delade resurser. U2M-klientprogrammet (t.ex. Power BI) använder flödet OAuth Authorization Code Grant för att hämta åtkomsttoken från IdP.

Maskin-till-dator-autentisering (M2M)

M2M är perfekt för automatiserade arbetsbelastningar, till exempel nattjobb eller bakgrundstjänster, som kräver åtkomst utan användarinteraktion. Mottagarorganisationen registrerar ett tjänsthuvudnamn i sin IdP. Den här tjänstidentiteten gör det möjligt för program eller skript att på ett säkert sätt komma åt resurser programmatiskt. Inga hemligheter eller autentiseringsuppgifter utbyts mellan Databricks, providern eller mottagaren. All hemlig hantering förblir intern för varje organisation. M2M-klienter, till exempel Python Delta Sharing Client eller Spark Delta Sharing Client, använder flödet OAuth Client Credentials Grant för att hämta åtkomsttoken från IdP.

Skapa en mottagare som använder en OIDC-federationspolicy

Steg 1. Skapa en öppen OIDC-federationsmottagare

Så här skapar du en mottagare som autentiserar med OIDC:

  1. På din Azure Databricks-arbetsyta klickar du på dataikonen.Katalog.

  2. Längst upp i fönstret Katalog klickar du på kugghjulsikonen. kugghjulsikonen och väljer Deltadelning.

    Alternativt, från sidan Snabb åtkomst, klicka på knappen Delta Sharing >.

  3. På fliken Delat av mig klickar du på Ny mottagare.

  4. Ange mottagarnamn.

  5. För mottagartypväljer du Öppna.

  6. Välj OIDC-federation som metoden för öppen -autentisering.

  7. Klicka på Skapa.

  8. (Valfritt) Skapa anpassade egenskaper för mottagare. På fliken Information om mottagare klickar du på Redigera egenskaper > +Lägg till egenskap. Lägg sedan till ett egenskapsnamn (nyckel) och värde. Mer information finns i Hantera mottagaregenskaper.

Steg 2. Skapa OIDC-federationspolicy

Innan du skapar principen samlar du in nödvändig information från mottagaren om deras IdP, inklusive de användare, grupper, tjänsthuvudnamn eller OAuth-program som ska ha åtkomst till resursen. Om du använder din egen (interna) IdP för intern delning hämtar du den här informationen från ditt eget identitetssystem.

Du måste först begära information från mottagaren om deras IdP och de användare, grupper, tjänsthuvudnamn eller OAuth-program som ska ha åtkomst till resursen. Du anger sedan den informationen i Azure Databricks när du skapar mottagaren.

På sidan för mottagarredigering under OIDC-federationsprinciperklickar du på Lägg till princip.

dialogrutan OIDC-policykonfiguration

Ange följande:

  • Principnamn: Läsbart namn för principen.

  • Utfärdar-URL: HTTPS-URL:en för den IdP som utfärdar JWT-token.

  • Ämnesanspråk: Anspråket i JWT som identifierar den autentiserande identitetstypen. I Microsoft Entra-ID kan du konfigurera följande värden:

    • oid (Objekt-ID): Välj om en användare är avsedd att komma åt data via ett U2M-program, till exempel PowerBI.
    • groups: Välj om en grupp användare ska komma åt data via ett U2M-program, till exempel PowerBI.
    • azp: Välj om ett OAuth-program är avsett att komma åt data via ett M2M-program, till exempel Python Delta Sharing Client eller Spark Delta Sharing Client.

    I vissa andra IP-adresser kan anspråk som sub eller andra användas. Se IdP-dokumentationen för att fastställa rätt anspråk för ditt användningsfall.

  • Ämne: Den specifika användare, grupp eller app som tillåts komma åt resursen.

  • Målgrupper: En eller flera resursidentifierare som JWT måste matcha. En token anses giltig om dess aud-krav matchar någon av de listade målgrupperna.

Om du är osäker på vilka värden som ska användas (utfärdare, ämnesanspråk, ämne, målgrupp) kan du läsa följande exempel. Du måste fastställa detaljerna för OIDC:s federationsprincip innan du skapar den.

Om du använder en extern IdP hanterad för mottagare, begär följande information från mottagaren, delad via en säker kanal. Om du använder din interna leverantörshanterade IdP kommer den här informationen från din egen IdP baserat på de identiteter som du delar med.

Exempel för U2M när IdP är Entra-ID:

Det här är exempelkonfiguration för delning med en specifik användare med objekt-ID 11111111-2222-3333-4444-555555555555 i Entra ID-klientorganisation aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

  • Utfärdare: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
  • ämnesanspråk: oid (objekt-ID)
  • Ämne: 11111111-2222-3333-4444-555555555555
  • Målgrupper: 64978f70-f6a6-4204-a29e-87d74bfea138 (det här är klient-ID:t för appen för flertjänstmiljöer som registrerats av Databricks i Entra ID)

Det här är exempelkonfiguration för delning med en specifik grupp med objekt-ID 66666666-2222-3333-4444-555555555555 i Entra ID-klientorganisation aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

  • Utfärdare: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
  • ämnesanspråk: groups
  • Ämne: 66666666-2222-3333-4444-555555555555
  • Målgrupper: 64978f70-f6a6-4204-a29e-87d74bfea138 (det här är klient-ID:t för appen för flertjänstmiljöer som registrerats av Databricks i Entra ID)

Anmärkning

För U2M-applikationer som Power BI och Tableau ska målgruppen vara det multi-tenant-app-ID som registrerats av Databricks i Entra ID, vilket är 64978f70-f6a6-4204-a29e-87d74bfea138.

Mer information om U2M-applikationer och deras OIDC-federationsprinciper finns i Mottagning av Delta Sharing-aktier genom OIDC-federation (Open ID Connect) i ett användar-till-dator-flöde (öppen delning).

Exempel för M2M när IdP är Entra ID:

För en M2M OAuth-applikation med applikation (klient) ID 11111111-2222-3333-4444-555555555555 i Entra ID-klientorganisation aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee:

Steg 3. Bevilja mottagaren åtkomst till en delad resurs

När du har skapat mottagaren och skapat resurser kan du ge mottagaren åtkomst till dessa resurser.

Om du vill bevilja delningsåtkomst till mottagare kan du använda Catalog Explorer, Databricks Unity Catalog CLI eller GRANT ON SHARE SQL-kommandot i en Azure Databricks-anteckningsbok eller Databricks SQL-frågeredigeraren.

Behörigheter som krävs: Något av följande:

  • Metastore-administratör.
  • Delegerade behörigheter eller ägarskap för både resursen och mottagarobjekten ((USE SHARE + SET SHARE PERMISSION) eller resursägaren) OCH (USE RECIPIENT eller mottagarens ägare).

Anvisningar finns i Hantera åtkomst till deltadelningsdataresurser (för leverantörer).

Arbetsflöde för mottagare

Mer information om hur mottagare autentiserar och kommer åt resurser med hjälp av OIDC-tokenfederation finns i: