Povolení federace Open ID Connect (OIDC) pro příjemce OpenSharingu

Tato stránka vysvětluje, jak můžou zprostředkovatelé dat v Azure Databricks federovat ověřování u zprostředkovatele identity (IDP) a řídit přístup ke sdíleným složkám OpenSharing vytvořeným v Azure Databricks. Tento tok ověřování používá federaci OIDC, což umožňuje krátkodobé tokeny OAuth vydané poskytovatelem identity příjemce (IdP) jako tokeny JSON Web Tokens (JWT) ověřené službou Azure Databricks. Tato metoda ověřování sdílení typu Databricks-to-open je určená pro příjemce, kteří nemají přístup k pracovnímu prostoru Databricks s podporou katalogu Unity.

Ve federaci OIDC zodpovídá zprostředkovatel identity příjemce za vydávání tokenů JWT a vynucování bezpečnostních zásad, jako je vícefaktorové ověřování (MFA). Podobně se životnost tokenu JWT řídí poskytovatelem identity příjemce.

Databricks tyto tokeny negeneruje ani nespravuje. Provede pouze federaci ověřování vůči IdP příjemce a prověřuje JWT podle nakonfigurované zásady federace příjemce. Poskytovatelé dat se také mohou rozhodnout užívat federované ověřování prostřednictvím svého poskytovatele identity, když sdílí data interně s jinými uživateli nebo odděleními ve své organizaci.

Federace OIDC je alternativou k použití dlouhodobých nosných tokenů, které vydává Azure Databricks, pro připojení příjemců mimo Databricks k poskytovatelům. Umožňuje jemně odstupňované řízení přístupu, podporuje vícefaktorové ověřování a snižuje rizika zabezpečení tím, že eliminuje potřebu příjemců spravovat a zabezpečit sdílené přihlašovací údaje.

Informace o použití nosných tokenů ke správě ověřování sdílených složek najdete v tématu Vytvoření objektu příjemce pro uživatele mimo Databricks pomocí nosných tokenů (sdílení Databricks-to-Open).

Jak funguje federace OIDC v OpenSharingu?

1. Když poskytovatel dat vytvoří příjemce v OpenSharing na Azure Databricks, nakonfiguruje zásadu federace tokenů OIDC, která určuje adresu URL vydavatele poskytovatele identity příjemce, například Microsoft Entra ID nebo Okta, a definuje uživatele, skupinu, instanční objekt služby nebo aplikaci OAuth příjemce, který má mít přístup ke sdílení.

2. Azure Databricks vygeneruje adresu URL webového portálu profilu OIDC na základě zásad a poskytovatel sdílí adresu URL s příjemcem.

   Koncový uživatel zkopíruje adresu URL koncového bodu nebo stáhne soubor profilu v závislosti na preferované platformě a poskytne adresu URL nebo soubor profilu platformě, na které bude dotazovat sdílená data. Tento soubor sdíleného profilu stažený z webu portálu Databricks OIDC neobsahuje žádné citlivé informace.

   • V rámci ověřování uživatele vůči stroji (U2M) zadá příjemce koncový bod příjemce z webového portálu profilu OIDC do své aplikace U2M.
   • Pro účely autentizace mezi stroji (M2M) vývojář aplikace příjemce stáhne soubor profilu a odkazuje na něj v klientské aplikaci příjemce.

3. Když se příjemce pokusí získat přístup ke sdíleným datům pomocí své preferované platformy, ověřování je delegováno k jejich poskytovateli identity.

   Databricks negeneruje ani nespravuje žádné tokeny ani přihlašovací údaje. Místo toho poskytovatel identitních služeb příjemce vygeneruje JWT obsahující nároky na identitu. Životnost tohoto krátkodobého tokenu je vynucena poskytovatelem identity příjemce. Služba OpenSharing pak ověří JWT proti zásadám příjemce, aby se ujistila, že odpovídá očekávaným deklaracím, včetně vystavitele, cílové skupiny a předmětu. Pokud je ověření úspěšné, požadavek se ověří a přístup se udělí na základě oprávnění katalogu Unity.

Než začnete

Pokud chcete vytvořit příjemce, musíte splnit následující požadavky:

• Musíte mít CREATE RECIPIENT oprávnění pro metastore katalogu Unity, kde jsou zaregistrovaná data, která chcete sdílet.
• Musíte vytvořit příjemce pomocí pracovního prostoru Azure Databricks s připojeným metastorem katalogu Unity.
• Pokud k vytvoření příjemce použijete poznámkový blok Databricks, výpočetní prostředí musí používat Databricks Runtime ve verzi 11.3 LTS nebo vyšší a standardní nebo vyhrazený režim přístupu (dříve sdílený režim přístupu a režim přístupu jednoho uživatele).

Kterého zprostředkovatele identity použít?

Federaci OIDC můžete použít s interním nebo externím zprostředkovatelem identity v závislosti na vašem scénáři sdílení:

• Interní poskytovatel identity (Provider-Managed)

  • To je užitečné pro sdílení dat ve velkých organizacích, kde různá oddělení nemají přímý přístup k Databricks, ale sdílejí stejného zprostředkovatele identity.
  • Tento přístup umožňuje poskytovateli spravovat přístup jménem příjemce.
  • Zásady zabezpečení, jako je MFA a řízení přístupu na základě role, vynucuje poskytovatel identitních služeb poskytovatele.

• Externí zprostředkovatel identity (Recipient-Managed)

  • Poskytovatel nastaví zásadu sdílení tak, aby důvěřoval zprostředkovateli identity příjemce.
  • Organizace příjemce si zachovává plnou kontrolu nad tím, kdo má přístup ke sdíleným datům.
  • Zásady zabezpečení, jako je MFA a řízení přístupu na základě role, jsou vynucovány poskytovatelem identity příjemce.

Scénář ověřování U2M nebo M2M

Zabezpečené otevřené sdílení s OIDC Token Federation podporuje toky ověřování U2M (User-to-Machine) i M2M (Machine-to-Machine), což umožňuje širokou škálu scénářů bezpečného sdílení dat.

Ověřování uživatele k zařízení (U2M)

Uživatel z organizace příjemce se ověřuje pomocí poskytovatele identit. Pokud je vícefaktorové ověřování nakonfigurované, vynucuje se při přihlášení.

Po ověření mají uživatelé přístup ke sdíleným datům pomocí nástrojů, jako je Power BI nebo Tableau. Zprostředkovatel dat může definovat zásady přístupu, které omezují přístup k datům konkrétním uživatelům nebo skupinám v organizaci příjemce a zajišťují přesnou kontrolu nad tím, kdo má přístup ke sdíleným prostředkům. Klientská aplikace U2M (např. Power BI) používá OAuth tok udělení autorizačního kódu k získání přístupových tokenů od poskytovatele identity.

Ověřování stroj-stroj (M2M)

M2M je ideální pro automatizované úlohy, jako jsou noční úlohy nebo služby na pozadí, které vyžadují přístup bez zásahu uživatele. Příjemcovská organizace zaregistruje hlavní službu ve svém zprostředkovateli identity. Tato identita služby umožňuje aplikacím nebo skriptům bezpečný přístup k prostředkům prostřednictvím kódu programu. Mezi Databricks, poskytovatelem nebo příjemcem se neměňují žádné tajné kódy ani přihlašovací údaje. Veškerá správa tajných kódů zůstává pro každou organizaci interní. Klienti M2M, jako jsou klienti Python OpenSharing Client nebo Spark OpenSharing Client, používají tok udělení přihlašovacích údajů klienta OAuth k načtení přístupových tokenů z zprostředkovatele identity.

Vytvoření příjemce, který používá zásady federace OIDC

Krok 1. Vytvořit příjemce otevřené federace OIDC

Vytvoření příjemce, který se ověřuje pomocí OIDC:

1. V pracovním prostoru Azure Databricks klikněte na Katalog.

2. V horní části podokna Katalog klikněte na ikonu ozubeného kola a vyberte OpenSharing.

   Případně v pravém horním rohu klikněte na Sdílet > OpenSharing.

3. Na kartě Sdílí se mnou klikněte na Tlačítko Nový příjemce.

4. Zadejte jméno příjemce.

5. Pro Typ příjemcevyberte Otevřít.

6. Jako metodu otevřeného ověřování zvolte federaci OIDC.

7. Klikněte na Vytvořit.

8. (Volitelné) Vytvořte vlastní vlastnosti příjemce. Na kartě Podrobnosti příjemce klikněte na Upravit vlastnosti +Přidat vlastnost. Pak přidejte název vlastnosti (klíč) a hodnotu. Podrobnosti najdete v tématu Správa vlastností příjemce.

Krok 2. Vytvoření zásad federace OIDC

Před vytvořením zásady přístupu shromážděte od příjemce potřebné informace o poskytovateli identity, včetně uživatelů, skupin, služebních principálů nebo aplikací OAuth, které by měly mít přístup ke sdílení. Pokud pro interní sdílení používáte svého (interního) zprostředkovatele identity, načtěte tyto informace z vlastního identitního systému.

Nejprve musíte od příjemce požádat o informace o poskytovateli identity a uživatelích, skupinách, služebních objektech nebo aplikacích OAuth, které by měly mít přístup ke sdílení. Pak zadáte informace v Azure Databricks při vytváření příjemce.

1. Na stránce pro úpravy příjemce v části zásady federace OIDCklikněte na Přidat zásadu.

dialogové okno konfigurace zásad OIDC

1. Zadejte následující:

   • název zásady: Název zásady čitelný pro člověka.

   • Adresa URL vystavitele: HTTPS adresa URL IdP, který vydává token JWT.

   • Deklarace identity subjektu: Deklarace identity v JWT, která identifikuje ověřovací typ identity. V Microsoft Entra ID můžete nakonfigurovat následující hodnoty:

     • oid (ID objektu): Vyberte, jestli má uživatel přistupovat k datům prostřednictvím aplikace U2M, například PowerBI.
     • groups: Vyberte, jestli je skupina uživatelů určená pro přístup k datům prostřednictvím aplikace U2M, například PowerBI.
     • azp: Vyberte, jestli má aplikace OAuth přistupovat k datům prostřednictvím aplikace M2M, například Python klienta OpenSharing nebo klienta Spark OpenSharing.

     V některých dalších zprostředkovatele identity se můžou použít deklarace identity, jako je sub nebo jiné. Pro správný nárok pro váš případ použití se podívejte do dokumentace IdP.

   • Předmět: Konkrétní uživatel, skupina nebo aplikace mají povolený přístup ke sdílené složce.

   • Cílové skupiny: Jeden nebo více identifikátorů prostředků, kterým musí JWT odpovídat. Token se považuje za platný, pokud položka aud odpovídá kterémukoli z uvedených publik.

2. Klikněte na Uložit.

Pokud si nejste jisti, které hodnoty použít (vystavitel, deklarace subjektu, předmět, cílová skupina), podívejte se na následující příklad. Před vytvořením je potřeba určit podrobnosti o zásadách federace OIDC.

Pokud používáte externí IdP spravovaný externím příjemcem, požádejte o následující informace od příjemce, které budou sdíleny pomocí zabezpečeného kanálu. Pokud používáte interně spravovaného poskytovatele identity, tyto informace pocházejí z vašeho vlastního poskytovatele identity na základě identit, které sdílíte.

Příklad pro U2M, když IdP je Entra ID:

Jedná se o příklad konfigurace pro sdílení s konkrétním uživatelem s ID objektu 11111111-2222-3333-4444-555555555555 v tenantovi Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee.

• Emitent: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• deklarace subjektu: oid (ID objektu)
• Předmět: 11111111-2222-3333-4444-555555555555
• Cílové skupiny: 64978f70-f6a6-4204-a29e-87d74bfea138 (Toto je ID klienta vícetenantní aplikace registrované službou Databricks v Entra ID)

Jedná se například o konfiguraci pro sdílení s konkrétní skupinou s ID 66666666-2222-3333-4444-555555555555 objektu v tenantovi Entra ID. aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• Emitent: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• deklarace subjektu: groups
• Předmět: 66666666-2222-3333-4444-555555555555
• Cílové skupiny: 64978f70-f6a6-4204-a29e-87d74bfea138 (Toto je ID klienta vícetenantní aplikace registrované službou Databricks v Entra ID)

Note

Pro aplikace U2M, jako je Power BI a Tableau, by publikem měla být ID aplikace s více tenanty zaregistrované službou Databricks v Entra ID, což je 64978f70-f6a6-4204-a29e-87d74bfea138.

Další informace o aplikacích U2M a jejich zásadách federace OIDC najdete v tématu Čtení dat sdílených pomocí federace Open ID Connect (OIDC) v toku U2M.

Příklad M2M, když je IDP Entra ID:

Pro aplikaci M2M OAuth s ID aplikace (klienta) 11111111-2222-3333-4444-555555555555 v tenantovi Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee:

• Emitent: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• Žádost subjektu: azp
• subject: 11111111-2222-3333-4444-555555555555 (Toto je ID aplikace (klienta), což je ID klienta registrované aplikace OAuth a najdete ho na portálu Entra ID příjemce.
• Cílové skupiny: 66666666-2222-3333-4444-555555555555 (Může to být libovolný platný identifikátor cílové skupiny definovaný příjemcem, například ID klienta registrované aplikace OAuth.) Další informace o aplikacích M2M a jejich zásadách federace OIDC najdete v tématu Čtení dat sdílených pomocí federace Open ID Connect (OIDC) v toku M2M.

Krok 3. Udělení přístupu ke sdílené složce příjemci

Po vytvoření příjemce a vytvoření sdílených složek můžete příjemci udělit přístup k těmto sdíleným složkám.

Pokud chcete příjemcům udělit přístup ke sdílené složce, můžete použít Průzkumníka katalogu, rozhraní příkazového řádku katalogu Databricks Unity nebo GRANT ON SHARE příkaz SQL v poznámkovém bloku Azure Databricks nebo v editoru dotazů SQL Databricks.

Požadovaná oprávnění: Jedna z těchto možností:

• Správce metastoru.
• Delegovaná oprávnění nebo vlastnictví jak na sdílenou složku, tak i na objekty příjemce ((USE SHARE + SET SHARE PERMISSION) nebo vlastník sdílené složky) A (USE RECIPIENT nebo vlastník příjemce).

Pokyny najdete v tématu Správa přístupu ke sdíleným složkám dat OpenSharing (pro poskytovatele).

Sdílení s příjemcem Icebergu

Pokud váš příjemce OIDC čte sdílené datové prostředky pomocí katalogu Iceberg REST, nasdílejte odkaz na portál generování profilu Iceberg OIDC .

Odešlete odkaz po vytvoření příjemce, který používá zásady federace OIDC:

1. V pracovním prostoru Azure Databricks klikněte na Katalog.

2. V horní části podokna Katalog klikněte na ikonu ozubeného kola a vyberte OpenSharing.

   Případně v pravém horním rohu klikněte na Sdílet > OpenSharing.

3. Na kartě Sdíleno mnou klikněte na Příjemci.

4. Vyhledejte a vyberte příjemce OIDC.

5. Na pravé straně stránky v části Zásady federace OIDC klikněte na Výchozí zásady OIDC.

6. Zkopírujte odkaz na portál pro generování profilu Iceberg OIDC a sdílejte ho se svým příjemcem pomocí zabezpečené metody.

7. Odkaz obsahuje také názvy sdílených složek, které příjemce potřebuje ke čtení sdílených dat.

Pracovní postup příjemce

Informace o ověřování příjemců a přístupu ke sdíleným složkám pomocí federace tokenů OIDC najdete tady:

• Čtěte data sdílená pomocí federace Open ID Connect (OIDC) v rámci toku U2M
• Čtení dat sdílených pomocí federace Open ID Connect (OIDC) v toku M2M