Użyj federacji Open ID Connect (OIDC), aby włączyć uwierzytelnianie w udziałach Delta Sharing (otwarte udostępnianie).

Na tej stronie wyjaśniono, jak dostawcy danych w usłudze Azure Databricks mogą federować uwierzytelnianie za pomocą dostawcy tożsamości (IdP) w celu zarządzania dostępem do udziałów w Delta Sharing utworzonych w usłudze Azure Databricks. Ten przepływ uwierzytelniania używa federacji OIDC, umożliwiając użycie tokenów sieci Web JSON (JWTs) wydanych przez dostawcę tożsamości odbiorcy jako krótkotrwałe tokeny OAuth, które są uwierzytelniane przez usługę Azure Databricks. Ta metoda uwierzytelniania Databricks-to-open sharing jest przeznaczona dla odbiorców, którzy nie mają dostępu do workspace Databricks z włączonym Unity Catalog.

W federacji OIDC dostawca tożsamości odbiorcy jest odpowiedzialny za wydawanie tokenów JWT i wymuszanie zasad zabezpieczeń, takich jak Multi-Factor Authentication (MFA). Jednocześnie czas istnienia tokenu JWT jest określany przez IdP odbiorcy. Usługa Databricks nie generuje tych tokenów ani nie zarządza nimi. Funkcja jedynie przekazuje uwierzytelnianie do dostawcy tożsamości odbiorcy i weryfikuje JWT zgodnie z zasadami federacji skonfigurowanymi przez odbiorcę. Dostawcy danych mogą również zdecydować się na użycie własnego dostawcy tożsamości do uwierzytelniania, gdy udostępniają dane wewnętrznie innym użytkownikom lub działom w organizacji.

Federacja OIDC jest alternatywą dla używania długoterminowych tokenów uwierzytelniających wystawianych przez Azure Databricks, aby połączyć użytkowników spoza Databricks z usługodawcami. Umożliwia szczegółową kontrolę dostępu, obsługuje uwierzytelnianie wieloskładnikowe i zmniejsza zagrożenia bezpieczeństwa, eliminując konieczność zarządzania i zabezpieczania poświadczeń udostępnionych przez adresatów. Aby uzyskać informacje na temat używania tokenów uwierzytelniających do zarządzania uwierzytelnianiem udziałami, zobacz Create a recipient object for non-Databricks users using bearer tokens (open sharing).

Jak działa federacja OIDC w Delta Sharing?

1. Gdy dostawca danych tworzy odbiorcę w usłudze Delta Sharing na platformie Azure Databricks, konfiguruje politykę federacji tokenów OIDC, które określają adres URL wystawcy tożsamości odbiorcy, na przykład Microsoft Entra ID lub Okta, i definiuje użytkownika odbiorcy, grupę, jednostkę usługi lub aplikację OAuth, która powinna mieć dostęp do udziału.

2. Usługa Azure Databricks generuje adres URL portalu internetowego profilu OIDC na podstawie zasad, a dostawca udostępnia ten adres URL adresatowi.

   Użytkownik końcowy kopiuje adres URL punktu końcowego lub pobiera plik profilu w zależności od preferowanej platformy i udostępnia adres URL lub plik profilu do platformy, na której będą wykonywać zapytania dotyczące udostępnionych danych. Ten udostępniony plik profilu pobrany z sieci Web portalu OIDC usługi Databricks nie zawiera żadnych poufnych informacji.

   • W przypadku uwierzytelniania typu użytkownik-komputer (U2M) odbiorca wprowadza punkt końcowy odbiorcy z portalu internetowego profilu OIDC do aplikacji U2M.
   • W przypadku uwierzytelniania typu maszyna-maszyna (M2M) deweloper aplikacji odbiorcy pobiera plik profilu i odwołuje się do niego w aplikacji klienckiej odbiorcy.

3. Gdy odbiorca próbuje uzyskać dostęp do udostępnionych danych przy użyciu preferowanej platformy, uwierzytelnianie jest przeprowadzane przez ich dostawcę tożsamości.

   Usługa Databricks nie generuje ani nie zarządza żadnymi tokenami ani poświadczeniami. Zamiast tego dostawca tożsamości odbiorcy generuje JWT zawierający oświadczenia tożsamości. Okres istnienia tego krótkotrwałego tokenu jest wymuszany przez dostawcę tożsamości odbiorcy. Następnie usługa Delta Sharing weryfikuje JWT względem zasad odbiorcy, aby upewnić się, że pasuje do oczekiwanych oświadczeń, w tym wystawcy, odbiorcy i podmiotu. Jeśli weryfikacja zakończy się pomyślnie, żądanie zostanie uwierzytelnione, a dostęp zostanie udzielony na podstawie uprawnień Unity Catalog.

Zanim rozpoczniesz

Aby utworzyć adresata, musisz spełnić następujące wymagania:

• Musisz być administratorem magazynu metadanych lub mieć CREATE RECIPIENT uprawnienia do magazynu metadanych Unity Catalog, w którym zarejestrowane są dane, które chcesz udostępnić.
• Musisz utworzyć odbiorcę, używając obszaru roboczego Azure Databricks, do którego jest dołączony metasklep wykazu Unity Catalog.
• Jeśli używasz notesu Databricks do utworzenia adresata, twój system obliczeń musi używać Databricks Runtime 11.3 LTS lub nowszego oraz standardowego lub dedykowanego trybu dostępu (dawniej tryby współdzielonego i pojedynczego użytkownika).

Którego dostawcy tożsamości używać?

W zależności od scenariusza udostępniania można użyć federacji OIDC z wewnętrznym lub zewnętrznym dostawcą tożsamości:

• Wewnętrzny dostawca tożsamości (Provider-Managed)

  • Jest to przydatne w przypadku udostępniania danych w dużych organizacjach, w których różne działy nie mają bezpośredniego dostępu do Databricks, ale korzystają z tego samego IdP.
  • Takie podejście umożliwia dostawcy zarządzanie dostępem w imieniu adresata.
  • Zasady zabezpieczeń, takie jak uwierzytelnianie wieloskładnikowe i kontrola dostępu oparta na rolach, są egzekwowane przez system dostawcy tożsamości.

• Dostawca tożsamości zewnętrznej (Recipient-Managed)

  • Dostawca konfiguruje zasady udostępniania, aby ufać dostawcy tożsamości adresata.
  • Organizacja adresata zachowuje pełną kontrolę nad tym, kto może uzyskiwać dostęp do udostępnionych danych.
  • Zasady zabezpieczeń, takie jak uwierzytelnianie wieloskładnikowe i kontrola dostępu oparta na rolach, są wymuszane przez dostawcę tożsamości odbiorcy.

Scenariusz uwierzytelniania U2M lub M2M

Bezpieczne otwarte udostępnianie za pomocą federacji tokenów OIDC obsługuje zarówno przepływy uwierzytelniania użytkownik do maszyny (U2M), jak i maszyna do maszyny (M2M), co umożliwia szeroką gamę bezpiecznych scenariuszy udostępniania danych.

Uwierzytelnianie użytkownika do maszyny (U2M)

Użytkownik z organizacji adresata uwierzytelnia się przy użyciu swojego dostawcy tożsamości. Jeśli uwierzytelnianie wieloskładnikowe jest skonfigurowane, jest wymuszane podczas logowania.

Po uwierzytelnieniu użytkownicy mogą uzyskiwać dostęp do udostępnionych danych przy użyciu narzędzi takich jak Power BI lub Tableau. Dostawca danych może zdefiniować zasady dostępu ograniczające dostęp do danych określonym użytkownikom lub grupom w organizacji odbiorcy, zapewniając dokładną kontrolę nad tym, kto może uzyskiwać dostęp do zasobów udostępnionych. Aplikacja kliencka U2M (np. Power BI) używa przepływu udzielania autoryzacji za pomocą kodu OAuth w celu uzyskania tokenów dostępu od dostawcy tożsamości.

Uwierzytelnianie maszyny do maszyny (M2M)

M2M jest idealnym rozwiązaniem dla zautomatyzowanych obciążeń, takich jak nocne zadania lub usługi w tle, które wymagają dostępu bez interakcji z użytkownikiem. Organizacja adresata rejestruje jednostkę usługi w swoim dostawcy tożsamości. Tożsamość tej usługi umożliwia aplikacjom lub skryptom programowy dostęp do zasobów. Żadne wpisy tajne ani poświadczenia nie są wymieniane między usługą Databricks, dostawcą lub adresatem. Zarządzanie tajne pozostaje wewnętrzne w każdej organizacji. Klienci M2M, tacy jak klient udostępniania Delta dla Pythona lub klient udostępniania Delta dla Sparka, używają przepływu udzielania poświadczeń klienta OAuth, aby pobrać tokeny dostępu z IdP.

Utwórz odbiorcę korzystającego z polityki federacyjnej OIDC

Krok 1. Tworzenie adresata federacji Open OIDC

Aby utworzyć adresata uwierzytelnianego przy użyciu OIDC:

1. W obszarze roboczym usługi Azure Databricks kliknij Wykaz.

2. Na górze okienka Wykaz kliknij i wybierz pozycję Delta Sharing.

   Alternatywnie na stronie Szybki dostęp kliknij przycisk Delta Sharing >.

3. Na karcie Udostępnione przeze mnie kliknij pozycję Nowy adresat.

4. Wprowadź nazwę adresata .

5. W polu Typ odbiorcy wybierz pozycję Otwórz.

6. Wybierz Federację OIDC jako metodę uwierzytelniania Open.

7. Kliknij pozycję Utwórz.

8. (Opcjonalnie) Utwórz niestandardowe właściwości adresata. Na karcie Szczegóły adresata kliknij pozycję Edytuj właściwości > +Dodaj właściwość. Następnie dodaj nazwę właściwości (klucz) i wartość. Aby uzyskać szczegółowe informacje, zobacz Zarządzanie właściwościami adresatów.

Krok 2. Tworzenie zasad federacyjnych OIDC

Przed utworzeniem zasad zbierz niezbędne informacje od adresata o swoim dostawcy tożsamości, w tym użytkowników, grup, jednostek usług lub aplikacji OAuth, które powinny mieć dostęp do udziału. Jeśli używasz własnego (wewnętrznego) dostawcy tożsamości do udostępniania wewnętrznego, te informacje należy pobrać z własnego systemu tożsamości.

Musisz najpierw zażądać informacji od odbiorcy o jego dostawcy tożsamości oraz użytkownikach, grupach, pryncypałach usługi lub aplikacjach OAuth, które mają mieć dostęp do zasobu. Następnie podasz te informacje w usłudze Azure Databricks podczas tworzenia adresata.

Na stronie edycji adresata w obszarze Zasady federacji OIDC kliknij pozycję Dodaj zasady.

Wprowadź następujące informacje:

• Nazwa zasad: czytelna dla człowieka nazwa zasad.

• Adres URL wystawcy: Adres HTTPS dostawcy tożsamości wystawiającego token JWT.

• Oświadczenie podmiotu: oświadczenie w JWT identyfikujące typ tożsamości uwierzytelniania. W usłudze Microsoft Entra ID można skonfigurować następujące wartości:

  • oid (Identyfikator obiektu): wybierz, czy użytkownik ma uzyskać dostęp do danych za pośrednictwem aplikacji U2M, takiej jak PowerBI.
  • groups: wybierz, czy grupa użytkowników ma uzyskiwać dostęp do danych za pośrednictwem aplikacji U2M, takiej jak PowerBI.
  • azp: Wybierz, czy aplikacja OAuth ma uzyskiwać dostęp do danych za pośrednictwem aplikacji M2M, takiej jak klient Delta Sharing dla Pythona lub klient Delta Sharing dla Sparka.

  W niektórych IdP mogą być używane oświadczenia, takie jak sub lub inne. Zapoznaj się z dokumentacją IdP, aby określić prawidłowe oświadczenie dla Państwa przypadku użycia.

• Temat: Określony użytkownik, grupa lub aplikacja dozwolona do uzyskiwania dostępu do udziału.

• Odbiorcy: co najmniej jeden identyfikator zasobu, który musi być zgodny z zestawem JWT. Token jest uznawany za prawidłowy, jeśli jego oświadczenie aud pasuje do dowolnego z wymienionych odbiorców.

Jeśli nie masz pewności co do wartości do użycia (wystawca, oświadczenie podmiotu, podmiot, odbiorcy), zapoznaj się z poniższym przykładem. Przed utworzeniem należy określić szczegóły zasad federacyjnych OIDC.

Jeśli używasz zewnętrznego zarządzanego dostawcy tożsamości adresata, poproś o następujące informacje od adresata udostępnionego przy użyciu bezpiecznego kanału. Jeśli korzystasz z wewnętrznego dostawcy tożsamości zarządzanego przez dostawcę, te informacje pochodzą z twojego własnego dostawcy tożsamości i są oparte na tożsamościach, z którymi się dzielisz.

Przykład dla U2M, gdy dostawcą tożsamości (IdP) jest Entra ID:

Są to przykładowe konfiguracje udostępniania dla określonego użytkownika z identyfikatorem obiektu 11111111-2222-3333-4444-555555555555 w dzierżawie Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• Emitenta: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• oświadczenie podmiotu: oid (identyfikator obiektu)
• Temat: 11111111-2222-3333-4444-555555555555
• Odbiorcy: 64978f70-f6a6-4204-a29e-87d74bfea138 (jest to identyfikator klienta aplikacji wielodostępnej zarejestrowanej przez Databricks w Entra ID)

Są to przykładowe konfiguracje udostępniania określonej grupy z identyfikatorem 66666666-2222-3333-4444-555555555555 obiektu w dzierżawie Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• Emitenta: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• roszczenie podmiotu: groups
• Temat: 66666666-2222-3333-4444-555555555555
• Odbiorcy: 64978f70-f6a6-4204-a29e-87d74bfea138 (jest to identyfikator klienta aplikacji wielodostępnej zarejestrowanej przez Databricks w Entra ID)

Aby uzyskać więcej informacji na temat aplikacji U2M i ich zasad federacji OIDC, zobacz Odbieranie udziałów w Delta Sharing przy użyciu federacji Open ID Connect (OIDC) w przepływie użytkownik-komputer (otwarte udostępnianie).

Przykład dla M2M, gdy IdP to Entra ID:

W przypadku aplikacji OAuth M2M z identyfikatorem 11111111-2222-3333-4444-555555555555 aplikacji (klienta) w dzierżawie aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeeeEntra ID:

• Emitenta: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• Oświadczenie podmiotu: azp
• temat: 11111111-2222-3333-4444-555555555555 (Jest to identyfikator aplikacji (klienta), który jest identyfikatorem klienta zarejestrowanej aplikacji OAuth i można go znaleźć w portalu Entra ID odbiorcy)
• Odbiorcy: 66666666-2222-3333-4444-555555555555 (Może to być dowolny prawidłowy identyfikator odbiorców zdefiniowany przez odbiorcę, taki jak identyfikator klienta zarejestrowanej aplikacji OAuth). Aby uzyskać więcej informacji na temat aplikacji M2M i ich zasad federacji OIDC, zobacz Odbieranie danych udostępnianych za pomocą klienta Python i federacji Open ID Connect (OIDC) w przepływie między maszynami (otwarte udostępnianie).

Krok 3. Nadaj adresatowi dostęp do zasobu

Po utworzeniu adresata i utworzeniu udziałów możesz udzielić adresatowi dostępu do tych udziałów.

Aby udzielić dostępu do zasobów adresatom, możesz użyć Eksploratora katalogów, interfejsu wiersza polecenia usługi Databricks Unity Catalog lub polecenia SQL w notesie usługi Azure Databricks lub edytorze zapytań SQL usługi Databricks.

Wymagane uprawnienia: jeden z następujących elementów:

• Administrator magazynu metadanych.
• Delegowane uprawnienia lub własność zarówno w przypadku udziału, jak i obiektów odbiorcy ((USE SHARE + SET SHARE PERMISSION) lub właściciel udziału) oraz (USE RECIPIENT lub właściciel odbiorcy).

Aby uzyskać instrukcje, zobacz Zarządzanie dostępem do udziałów danych usługi Delta Sharing (dla dostawców).

Przepływ pracy adresata

Aby dowiedzieć się, jak adresaci uwierzytelniają udziały i uzyskują dostęp przy użyciu federacji tokenów OIDC, zobacz:

• Odbieranie udziałów Delta Sharing przy użyciu federacji Open ID Connect (OIDC) w przepływie użytkownik-maszyna (otwarte udostępnianie)
• Odbieranie udziałów Delta Sharing przy użyciu klienta języka Python i federacji Open ID Connect (OIDC) w przepływie komunikacji między maszynami (udostępnianie otwarte)