Zastąp profile nazw głównych usługi nazwami głównymi usługi

Jeśli Twoje rozwiązanie korzysta z profili jednostek usługi (SPP), a ich ograniczenia dotyczące tożsamości, nadzoru, interfejsu API lub działania ograniczają Twoje wymagania, ten przewodnik pomaga ocenić i wdrożyć rozwiązanie zastępcze oparte na dedykowanych nazwach głównych usług Microsoft Entra. Jeśli istniejące rozwiązanie oparte na profilu spełnia Twoje wymagania, możesz nadal z niego korzystać.

W przypadku klientów, którzy zdecydują się przeprowadzić migrację, w tym przewodniku zaleca się użycie tożsamości zarządzanej i poświadczeń federacyjnych, gdy spełnione są wymagania dotyczące hostingu i zaufania. Bezpośrednie uwierzytelnianie nazwy głównej usługi pozostaje alternatywą. Obie ścieżki zapewniają dedykowane tożsamości klientów na potrzeby nadzoru nad katalogiem, niezależnego monitorowania logowania i dostępu do obsługiwanych usług poza interfejsami obsługującymi profile.

Note

Jeśli tworzysz nową aplikację, zacznij od wieloorganizacyjności z dedykowanymi nazwami głównymi usługi, a następnie postępuj zgodnie ze wzorcem tożsamości i przewodnikiem implementacji. Etapy tworzenia spisu profilów i wycofywania z eksploatacji mają zastosowanie tylko do istniejących aplikacji opartych na profilach.

Dlaczego warto przeprowadzić migrację z profilów

Rozważ zastąpienie profili, gdy następujące ograniczenia ograniczają rozwiązanie:

  • Profile nie są zgodne z najlepszymi rozwiązaniami Microsoft Entra ID dotyczącymi tożsamości obciążeń, którymi można zarządzać. Profil nie jest reprezentowany w Microsoft Entra ID. Nie generuje niezależnych dzienników logowania, nie może mieć własnej zasady dostępu warunkowego i nie może być zarządzany przez narzędzia używane w pozostałej części środowiska tożsamości.

Na przykład nie można skonfigurować profilu jako tożsamości połączenia Direct Lake z modelu semantycznego do lakehouse lub magazynu. Nie można też przyznać jej dostępu jako niezależnej tożsamości Microsoft Entra do innych usług podrzędnych, do których aplikacja lub jej obciążenia muszą uzyskać dostęp. Dedykowana jednostka usługi głównej może otrzymać te uprawnienia tam, gdzie usługa to obsługuje.

Nie można używać profilów z interfejsami API REST Fabric. Profile są obsługiwane tylko przez interfejs API REST obsługujący profile, jego zestaw SDK .NET i obsługiwane interfejsy XMLA/TOM. Interfejsy API REST Fabric nie obsługują profilów, a wsparcie nie jest planowane. Użyj obsługiwanej tożsamości dla tych wywołań interfejsu API zamiast profilu. Utworzenie dedykowanej nazwy głównej usługi spełnia wymagania dotyczące tożsamości, ale każdy interfejs API i operacja muszą nadal obsługiwać tę tożsamość i udzielać jej niezbędnych uprawnień.

  • Uwierzytelnianie pozostaje powiązane z tożsamością nadrzędną. Gdy element nadrzędny używa sekretu lub certyfikatu, należy chronić i rotować to poświadczenie. Zalecany wzorzec zastępczy pozwala uniknąć przechowywania poświadczeń aplikacji klienta. Profile mogą również używać nadrzędnej tożsamości zarządzanej, więc samo uwierzytelnianie bez wpisów tajnych nie wymaga zastępowania profili. Element nadrzędny tożsamości zarządzanej nie zapewnia profilom niezależnych tożsamości katalogowych ani szerszej obsługi interfejsu API.

Profile rozwiązują problem skali, a nie problem niezależnej tożsamości. Jedna nazwa główna usługi może utworzyć maksymalnie 100 000 profilów, a każdy profil może uzyskiwać dostęp do maksymalnie 1000 obszarów roboczych lub utworzyć maksymalnie 1000 obszarów roboczych. Nazwa główna usługi może należeć do co najwyżej 1000 obszarów roboczych w tym modelu. Zamiast tego dedykowane tożsamości klientów wykorzystują obiekty katalogu Microsoft Entra. Przed zatwierdzeniem migracji zweryfikuj odpowiednie limity względem liczby klientów u klienta.

Note

Granica zabezpieczeń: Profil nie jest kryptograficzną granicą bezpieczeństwa klienta: jego nadrzędna nazwa główna usługi może działać za pośrednictwem dowolnego z jego profilów. Zalecany wzorzec umożliwia również tożsamości zarządzanej środowiska uruchomieniowego uwierzytelnianie się jako dowolna aplikacja klienta, która jej ufa. Uprawnienia obszaru roboczego i zasobu pozostają wymuszaną granicą autoryzacji. Chroń środowisko uruchomieniowe i mapowanie typu klient-tożsamość w dowolnym z modeli.

Inne ograniczenia profilu do rozważenia

Limitation Skutki migracji
Brak niezależnego audytu lub tożsamości zasad Profil nie ma niezależnego rekordu logowania Microsoft Entra ani obiektu docelowego zasad dostępu warunkowego tożsamości obciążenia. Dedykowane jednostki usługi zapewniają te możliwości, z zastrzeżeniem zgodności z zasadami i licencjonowania.
Stałe powiązanie profilu z elementem nadrzędnym Nie można przenieść profilów do innej nadrzędnej nazwy głównej usługi. Zastąpienie elementu nadrzędnego wymaga nowych profili, nowych uprawnień obszaru roboczego i zaktualizowania mapowań klientów.
Brak portalu do administrowania tożsamością Profile są dostępne tylko przez interfejs API i nie są reprezentowane w narzędziach administracji Microsoft Entra. Dedykowane aplikacje i jednostki usługi głównej mają obszary widoczności katalogu i zarządzania.

Wzorzec użycia tożsamości zarządzanej i poświadczeń federacyjnych

Użyj tego wzorca dla nowego rozwiązania z dedykowaną nazwą główną lub gdy zdecydujesz się zastąpić profile, pod warunkiem, że środowisko uruchomieniowe spełnia wymagania hostingu tożsamości zarządzanej.

Wzorzec

Nadaj każdemu klientowi rzeczywistą jednostkę usługi głównej Microsoft Entra i użyj tożsamości zarządzanej aplikacji jako źródła asercji. To podejście zastępuje zarówno współdzielone poświadczenie aplikacji, jak i abstrakcję profilu. Możesz rejestrować, zarządzać i stosować każdą tożsamość klienta w dostępie warunkowym dla tożsamości obciążenia, i może ona wywoływać obsługiwane interfejsy API REST Fabric.

Ta metoda jest zalecaną ścieżką migracji, gdy wymagania dotyczące hostingu w Azure i zaufania pasują do rozwiązania. Usuwa przechowywane poświadczenia aplikacji klienta i ich procesy rotacji bez zmiany miejsca, w którym egzekwowane jest uwierzytelnianie obszaru roboczego i autoryzacja zasobów.

Architektura przedstawia operacje środowiska uruchomieniowego aplikacji, trzy tożsamości aplikacji klienta i odpowiadające im zaufania oraz relacje jeden do jednego obszaru roboczego klienta. Reprezentuje domyślny układ współużytkowanego środowiska uruchomieniowego, a nie nową granicę izolacji.

Diagram przedstawiający aplikację niezależnego dostawcy oprogramowania uzyskującą token tożsamości zarządzanej, wymieniając go na wybrany token aplikacji klienta i wywołując docelowe interfejsy API. Oddzielne nazwy główne usług klientów A, B i C mają federacyjne zaufanie do tożsamości zarządzanej aplikacji i uzyskują dostęp tylko do odpowiednich obszarów roboczych klientów.

Rysunek 1. Jedna tożsamość zarządzana aplikacji uwierzytelnia się jako dedykowane jednostki usługi klienta.

Jak to działa

  1. Tożsamość zarządzana aplikacji. Przypisz tożsamość zarządzaną przypisaną przez użytkownika do aplikacji niezależnego dostawcy oprogramowania działającej w obsługiwanych usługach obliczeniowych platformy Azure, takich jak App Service, Container Apps, odpowiednio skonfigurowane obciążenie usługi AKS lub maszyna wirtualna. Użyj jednej tożsamości zarządzanej dla aplikacji, a nie jednej na klienta. Nie ma własnych uprawnień obszaru roboczego klienta ani usługi docelowej; jego rolą jest jedynie dostarczenie asercji.

  2. Jednostki usługi dla klienta, użytkownika lub grupy. Dla każdego istniejącego klienta lub authorization boundary utwórz rejestrację aplikacji Microsoft Entra i jednostkę usługi głównej w dzierżawie katalogowej niezależnego dostawcy oprogramowania. Logiczny klient nie musi oznaczać oddzielnej dzierżawy Microsoft Entra, a tożsamość dla każdego użytkownika końcowego nie jest wymagana, chyba że wymaga tego istniejący model dostępu.

  3. Poświadczenie tożsamości federacyjnej. Skonfiguruj poświadczenie tożsamości federacyjnej w każdej rejestracji aplikacji klienta tak, aby ufała tożsamości zarządzanej aplikacji. Środowisko uruchomieniowe może następnie użyć tokenu tożsamości zarządzanej jako asercji w celu uzyskania tokenu dostępu dla tej aplikacji klienta bez klucza tajnego klienta lub certyfikatu.

  4. Wymiana tokenów w czasie wykonywania. Gdy użytkownik A lub zadanie specyficzne dla klienta wywołuje aplikację, ustal klienta A za pomocą zaufanego mapowania po stronie serwera. Uzyskaj token tożsamości zarządzanej z określoną wartością audience api://AzureADTokenExchange; wymień go na token dostępu jako SP-A, a następnie wywołaj docelowe interfejsy API przy użyciu tokenu SP-A w celu zarządzania obszarami roboczymi, wykonywania operacji na zasobach lub żądania tokenów specyficznych dla aplikacji, jeśli jest to wymagane.

    W przypadku wymiany w poprzednim kroku .NET Azure Identity ClientAssertionCredential akceptuje token tożsamości zarządzanej jako asercja klienta. Jest to typ poświadczeń Azure Identity, a nie klasa MSAL. Token dostępu musi być przeznaczony dla wartości aud interfejsu API zasobu, a nie dla wartości aud wymiany tokenów.

  5. Dostęp do obszaru roboczego. Przyznaj każdej jednostce usługi dostęp członka lub administratora tylko do wyznaczonych obszarów roboczych, gdy te role są potrzebne, lub rolę o najmniejszych uprawnieniach obsługiwaną dla wymaganych operacji. To uprawnienie określa zakres dostępu do zasobów. Ponieważ tożsamość zarządzana aplikacji może uwierzytelniać się jako każda aplikacja klienta, która jej ufa, traktuj ją i jej hosty obliczeniowe jako tożsamości i infrastrukturę o wysokiej wartości.

  • Mniej długoterminowych poświadczeń. Nie musisz przechowywać, pobierać ani rozpowszechniać żadnego klucza tajnego aplikacji klienta ani klucza prywatnego certyfikatu w środowisku uruchomieniowym.

  • Mniej pracy przy obracaniu. Azure zarządza poświadczeniami tożsamości zarządzanej i wystawia krótkotrwałe tokeny. Nie potrzebujesz oddzielnego procesu odnawiania klucza tajnego ani certyfikatu dla każdej aplikacji klienta korzystającej z tej relacji zaufania.

  • Spójne wdrażanie. Aprowizuj aplikację klienta i jednostkę usługi głównej, zdefiniuj jawne zaufanie i przyznaj klientowi dostęp do zasobów. Nowi klienci nie wymagają nowych poświadczeń długotrwałych.

Te korzyści nie usuwają potrzeby administrowania zaufaniem, autoryzacji klienta, monitorowania audytów ani planowania pojemności katalogu.

Alternatywa: Bezpośrednie uwierzytelnianie nazwy głównej usługi

Jeśli nie chcesz używać tożsamości zarządzanej i poświadczeń federacyjnych, utwórz analogiczne dedykowane rejestracje aplikacji klienta i nazwy główne usług, ale uwierzytelnij je bezpośrednio przy użyciu certyfikatów lub innego obsługiwanego poświadczenia aplikacji. Preferuj certyfikaty zamiast kluczy tajnych klienta, jeśli jest to obsługiwane. Ochrona kluczy prywatnych i sekretów, ograniczanie dostępu do nich i automatyzowanie rotacji.

Uwierzytelnianie bezpośrednie zachowuje widoczność katalogu, dzienniki logowania dla każdego podmiotu zabezpieczeń i dostęp do obsługiwanych interfejsów API. Nie wymaga ona hostowania tożsamości zarządzanej ani relacji zaufania, ale nie eliminuje przechowywanych poświadczeń klienta.

Podstawowe pojęcia

Odróżnij poświadczenie ustanawiające zaufanie od tokenów używanych w czasie wykonywania.

Poświadczenia federacyjnej tożsamości

Skonfiguruj poświadczenie tożsamości federacyjnej (FIC) w rejestracji aplikacji Microsoft Entra, która stanowi podstawę jednostki usługi klienta. Definiuje relację zaufania z wystawcą tokenu i określa, którą asercję aplikacja akceptuje zamiast klucza tajnego klienta lub certyfikatu.

W tej architekturze tożsamość docelowa to aplikacja klienta i nazwa główna usługi; tożsamość zarządzana aplikacji jest źródłem asercji. Dlatego należy skonfigurować poświadczenia klienta w rejestracji aplikacji, a nie w obiekcie nazwy głównej usługi lub źródłowej tożsamości zarządzanej.

Note

Rozróżnienie konfiguracji: Poświadczenia tożsamości federacyjnej są również obsługiwane w przypadku tożsamości zarządzanych przypisanych przez użytkownika w innych scenariuszach federacji. Nie zmienia to tutaj schematu postępowania: skonfiguruj relację zaufania dla każdej rejestracji aplikacji klienta. Tylko tożsamość zarządzana przypisana przez użytkownika jest obsługiwana jako źródło asercji tożsamości zarządzanej we wzorcu zaufania aplikacji opisanym w tym przewodniku.

Pole zaufane Wartość w chmurze globalnej
Issuer https://login.microsoftonline.com/{directory-tenant-id}/v2.0
Temat Identyfikator jednostki głównej (obiektu) przypisanej przez użytkownika tożsamości zarządzanej. Nie używaj identyfikatora klienta.
Grupy odbiorców api://AzureADTokenExchange

Gdy aplikacja przedstawia token tożsamości zarządzanej i żąda tokenu dostępu dla aplikacji klienta, Microsoft Entra ID weryfikuje asercję względem poświadczenia federacyjnego. Wystawca, podmiot i odbiorcy muszą się zgadzać. Jeśli walidacja zakończy się pomyślnie, wystawia token dostępu reprezentujący docelową jednostkę usługi dla żądanego zasobu.

Tożsamość zarządzana i rejestracja ufającej aplikacji muszą znajdować się w tym samym tenancie Microsoft Entra. Grupa odbiorców zasobu jest oddzielnym wyborem od grupy odbiorców asercji. W przypadku Azure Identity zakres wymiany tokenów w chmurze globalnej to api://AzureADTokenExchange/.default; docelowy zakres interfejsu API jest zwykle identyfikatorem zasobu, po którym następuje /.default.

Przepływ wymiany tokenów: poświadczenia klienta z asercją federacyjną

Ten przepływ obejmuje trzech uczestników i sześć kroków. SP-A to aplikacja i service principal klienta A. Token asercji tożsamości zarządzanej i zwrócony SP-A token dostępu do zasobów służą różnym celom.

Diagram sekwencji przedstawiający aplikację Azure żądającą i odbierającą token tożsamości zarządzanej, wysyłającą żądanie poświadczeń klienta z identyfikatorem klienta SP-A i tokenem tożsamości zarządzanej jako asercją, Microsoft Entra ID weryfikujący federacyjne zaufanie, zwracający token dostępu SP-A oraz aplikację wywołującą docelowy interfejs API jako SP-A.

Rysunek 2. Wymiana tokenów poświadczeń klienta obsługiwana przy użyciu asercji tożsamości zarządzanej.

  1. Zażądaj tokenu tożsamości zarządzanej. Aplikacja na Azure żąda tokenu tożsamości zarządzanej z wartością audience api://AzureADTokenExchange.

  2. Zwróć token asercji. Microsoft Entra ID wystawia token tożsamości zarządzanej, który aplikacja odbiera za pośrednictwem mechanizmu tożsamości zarządzanej środowiska hostingu Azure.

  3. Prześlij żądanie tokenu klienta. Wyślij żądanie do punktu końcowego dzierżawy katalogu /oauth2/v2.0/token z użyciem grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token> i scope=<target-resource>/.default. Pełne żądanie OAuth zawiera również parametr client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer; biblioteka tożsamości obsługuje ten parametr.

  4. Zweryfikuj asercję. Microsoft Entra ID weryfikuje token tożsamości zarządzanej względem poświadczenia federacyjnego w rejestracji aplikacji SP-A.

  5. Zwróć token dostępu klienta. Microsoft Entra ID zwraca token dostępu dla SP-A z zasobem docelowym jako odbiorcy.

  6. Wywołaj docelowe interfejsy API REST. Aplikacja wysyła token dostępu SP-A do docelowego interfejsu API. Nie używa tokenu asercji jako tokenu okaziciela zasobu i nie wybiera profilu.

Porównanie architektury

Kolumna zastępcza obejmuje zazwyczaj dedykowane nazwy główne usługi. Tożsamość zarządzana i federacja są zalecaną metodą uwierzytelniania, ale możliwe jest również bezpośrednie uwierzytelnianie certyfikatem lub uwierzytelnianie przy użyciu innych obsługiwanych poświadczeń.

Aspect Profile nazw głównych usługi Dedykowane jednostki usługi głównej
Tożsamość dla każdego klienta Profil logiczny, a nie obiekt Microsoft Entra. Rejestracja aplikacji i jednostka usługi aplikacji reprezentująca granicę autoryzacji klienta.
Wymuszona granica Uprawnienia obszaru roboczego i zasobu. Uprawnienia obszaru roboczego i zasobu.
Zasięg głównej tożsamości Nadrzędna jednostka usługi może działać jako dowolny ze swoich profili. Środowisko uruchomieniowe może przyjmować wszystkie tożsamości, dla których ma poświadczenia lub zaufane asercje; tożsamość zarządzana może uwierzytelniać się jako dowolna aplikacja, która jej ufa.
Rotacja sekretów Wymagane, gdy element nadrzędny używa sekretu lub certyfikatu. Nie jest wymagane w przypadku poświadczeń tożsamości zarządzanej; wymagane w przypadku przechowywanych certyfikatów lub kluczy tajnych klienta na ścieżce bezpośredniej.
Górna granica skalowania Maksymalnie 100 000 profilów na nadrzędny SP; każdy profil do 1000 obszarów roboczych. Plan nadrzędnego dostawcy usług jest ograniczony do 1000 przestrzeni roboczych. Rejestracja aplikacji i główna jednostka usługi dla każdego klienta, z uwzględnieniem limitów przydziałów obiektów katalogu i limitów zasobów każdej usługi docelowej.
Ślad audytu Identyfikatory profilów mogą być wyświetlane w dziennikach zasobów, ale profile nie mają niezależnego rekordu logowania w usłudze Microsoft Entra. Microsoft Entra rekordy logowania dla nazwy głównej usługi skorelowane z dziennikami inspekcji aplikacji i zasobów.
Dostęp warunkowy Brak zasad tożsamości obciążeń dla poszczególnych profilów. Dostępne dla kwalifikujących się nazw głównych usług z Tożsamość obciążeń Microsoft Entra Premium; zasady muszą być skierowane bezpośrednio do każdej nazwy głównej usługi.
Widoczność portalu Nie są uwzględnione w Microsoft Entra ID. Rejestracja aplikacji w Rejestracje aplikacji; nazwa główna usługi w aplikacjach dla przedsiębiorstw.
Obsługa interfejsu API REST Fabric Nieobsługiwane; obsługa nie jest planowana. Obsługiwane, gdy określony interfejs API i operacja akceptują jednostki usługi z wymaganymi uprawnieniami.
Transfer poświadczeń uwierzytelniających i powiązanie z elementem nadrzędnym Nie można przenieść profilu między nadrzędnymi jednostkami usługi. Można ponownie skonfigurować relację zaufania federacyjnego; Bezpośrednie poświadczenia można zastąpić bez ponownego tworzenia abstrakcji profilu.

Jak odczytać tę tabelę: żadna z konfiguracji nie zapewnia kryptograficznej izolacji klientów. Uprawnienia do zasobów wymuszają kontrolę dostępu, a środowisko uruchomieniowe może mieć pośredni zasięg między klientami. Profile zapewniają lekką skalowalność tożsamości. Dedykowane jednostki zabezpieczeń zwiększają ład katalogu, widoczność logowania i zgodność interfejsu API. Zalecana ścieżka tożsamości zarządzanej i federacji również usuwa przechowywane poświadczenia aplikacji klienta.

Ścieżka migracji

Poniższa ścieżka zastępuje profile dedykowanymi podmiotami zabezpieczeń obsługi klienta. Podejmuj decyzje dotyczące migracji i wycofania oddzielnie dla każdego klienta.

Z profilów do tożsamości zarządzanej i poświadczeń federacyjnych

Użyj następujących faz migracji z małą kohortą pilotażową i przełącznikiem wdrażania dla każdego klienta. Zachowaj dostępną ścieżkę profilu do momentu zakończenia walidacji i uzgodnionego okresu wycofania.

Faza 0: Utwórz tożsamość zarządzaną aplikacji

  • Utwórz tożsamość zarządzaną przypisaną przez użytkownika dla aplikacji i przypisz ją do zasobu obliczeniowego. W przewodniku implementacji przedstawiono polecenia tworzenia i przypisywania.

  • Zarejestruj swój identyfikator jednostki głównej (obiektu). Każde poświadczenie federacyjne aplikacji klienta używa tej wartości jako podmiotu. Rejestruj również identyfikator klienta, identyfikator dzierżawy katalogu i Azure identyfikator zasobu.

Użyj jednej tożsamości zarządzanej dla aplikacji, a nie jednej na klienta. Oddzielna tożsamość zarządzana dla każdego klienta jest niepotrzebna w tym wzorcu: tożsamość klienta jest jednostką główną usługi, a tożsamość zarządzana dostarcza asercję. W przypadku większych wdrożeń lub mniejszego zakresu naruszenia zabezpieczeń należy podzielić klientów na niewielką liczbę tożsamości środowiska uruchomieniowego, z których każda jest zaufana tylko przez przypisany podzbiór aplikacji klienta.

Faza 1: Inwentaryzacja

Wyświetl listę wszystkich istniejących profilów za pomocą interfejsu API zarządzania profilami:

GET {profile-api-base}/v1.0/myorg/profiles

Dla każdego profilu zapisz:

  • Identyfikator profilu i nazwa wyświetlana, nadrzędna jednostka usługi i mapowanie klienta.

  • Skojarzone obszary robocze i przypisania ról.

  • Skojarzone semantyczne modele lub zestawy danych, raporty i inne zasoby.

  • Połączenia, poświadczenia źródła danych, zależności własności, zadania w tle i operacje interfejsu API, które zależą od profilu.

Przed zmianą konfiguracji klienta zarejestruj istniejące role obszaru roboczego, bieżącą własność modelu semantycznego, bieżące tożsamości połączeń, bieżącą konfigurację poświadczeń oraz mapowanie klient–profil potrzebne do wycofania zmian. Rejestruj bezpieczne odwołania do poświadczeń, a nie wartości sekretów.

Zarejestruj łączną liczbę klientów i porównaj wymagane obiekty aplikacji i obiekty jednostki usługi z limitem przydziału obiektów katalogu Microsoft Entra przed kontynuowaniem. Zweryfikuj również limit członkostwa dla 1000 obszarów roboczych i wszelkie limity specyficzne dla zasobów. Jeśli populacja przekroczy limit przydziału pojedynczego katalogu, zaplanuj obsługiwane zwiększenie limitu przydziału lub celowo zarządzany projekt wielu katalogów; tego problemu ten wzorzec nie rozwiązuje automatycznie.

Note

Notacja endpointu:{profile-api-base} oznacza istniejący podstawowy adres URL interfejsu API REST obsługujący profil, który jest już używany przez rozwiązanie. Zachowaj ten adres URL w konfiguracji wdrożenia. Te przykłady zachowują ścieżki operacji; zastąp każdy symbol zastępczy przed ich wykonaniem. Termin uwzględniający profil opisuje obsługę interfejsu API, a nie stan wycofania.

Faza 2. Utwórz nowe tożsamości

Dla każdego profilu lub grupy profilów należących do tej samej granicy uprawnień klienta:

  1. Utwórz rejestrację aplikacji i nazwę główną usługi. Rejestruj identyfikator klienta aplikacji, identyfikator obiektu aplikacji i identyfikator obiektu nazwy głównej usługi oddzielnie.

  2. Skonfiguruj poświadczenie tożsamości federacyjnej w rejestracji aplikacji klienta, która ufa tożsamości zarządzanej aplikacji utworzonej w fazie 0.

  3. Przyznaj nowej nazwie głównej usługi dostęp do tych samych obszarów roboczych i zasobów klienta. Użyj roli Członek, jeśli wymagają tego operacje wymienione w wykazie, lub roli o najmniejszych obsługiwanych uprawnieniach. Przyznaj uprawnienie Admin tylko wtedy, gdy jest to konieczne.

Zachowaj istniejące identyfikatory obszarów roboczych i zasobów wszędzie tam, gdzie są obsługiwane. Przyznanie obszaru roboczego nie powoduje automatycznego transferu własności zasobów, tożsamości połączeń ani poświadczeń źródła danych. Przed rozpoczęciem przełączenia wykonaj te aktualizacje specyficzne dla usługi.

Faza 3. Aktualizowanie kodu aplikacji

  • Zastąp nagłówek wyboru profilu i konfigurację profilu zestawu SDK wymianą tokenów opartą na tożsamości zarządzanej dla wybranej aplikacji klienta.

  • Zaktualizuj mapowanie klienta na tożsamość w bazie danych aplikacji.

przed Po
customerId -> profileId z jednym udostępnionym poświadczeniem SP i nagłówkiem profilu. customerId -> spClientId z uwierzytelnianiem SP dla poszczególnych klientów za pośrednictwem wymiany tokenów tożsamości zarządzanej. Zachowaj również identyfikator dzierżawy katalogu, konfigurację uwierzytelniania i dozwolone identyfikatory zasobów.

Identyfikatory klientów to identyfikatory logiczne klientów niezależnego dostawcy oprogramowania, niekoniecznie identyfikatory dzierżawy klienta Microsoft Entra. Przed wybraniem tożsamości zweryfikuj członkostwo klienta uwierzytelnionego użytkownika. Pamięć podręczna tokenów jest kluczowana według dzierżawy katalogu, identyfikatora klienta i zasobu lub zakresu.

  • Zaktualizuj generowanie tokenów specyficznych dla aplikacji, aby używać tokenu dostępu nazwy głównej usługi klienta. Jeśli rozwiązanie osadza raporty lub inną zawartość, zaktualizuj również to generowanie tokenów; osadzanie to istniejący scenariusz do migracji, a nie wymaganie wstępne dla tego przewodnika.

  • Zaktualizuj zarządzanie obszarem roboczym, połączenia downstream, prowizjonowanie, zaplanowane zadania i każdy inny punkt wejścia przy użyciu starej konfiguracji profilu.

Faza 4. Weryfikacja

Dla każdego klienta sprawdź:

  • Dostęp do obszaru roboczego i zasobu jest możliwy za pośrednictwem nowej jednostki usługi/service principal.

  • Uzyskiwanie tokenu tożsamości zarządzanej i wymiana tokenów federacyjnych powiodły się dla docelowej aplikacji klienckiej.

  • Tokeny specyficzne dla aplikacji są generowane pomyślnie, jeśli są używane, a istniejące raporty lub inna osadzona zawartość są wyświetlane poprawnie, jeśli ma to zastosowanie.

  • Nowe logowania jednostki usługi aplikacji są wyświetlane w Microsoft Entra ID i mogą być skorelowane z dziennikami inspekcji aplikacji i zasobów.

  • Dostęp między klientami jest zabroniony: obiekt wywołujący nie może wybrać tożsamości aplikacji lub identyfikatorów zasobów innego klienta.

Przed przełączeniem produkcyjnym należy udokumentować i przetestować procedurę wycofywania dla klienta pilotażowego. Uwzględnij przywrócenie wszelkich własności modelu semantycznego, tożsamości połączeń, poświadczeń źródła danych i uprawnień zmienionych podczas migracji. Sprawdź, czy poprzedni profil może wykonywać wymagane operacje po wycofaniu, w tym odświeżanie konfiguracji i aktualizacje parametrów.

Przełącz trasę aplikacji klienta tylko dopiero po spełnieniu kryteriów akceptacji. Monitoruj awarie, wydajność i uprawnienia przed rozszerzeniem wdrożenia.

Jeśli walidacja nie powiedzie się, wstrzymaj zadania w tle, których to dotyczy, i przywróć poprzednią konfigurację przy użyciu obsługiwanych procedur dla każdej usługi. Przełączenie trasy aplikacji z powrotem na trasę wyłącznie profilu może nie spowodować przywrócenia operacji, które zależą od własności lub poświadczeń. Po przywróceniu wymaganej konfiguracji wróć do ścieżki opartej na profilu i sprawdź dostęp do zasobów i operacje zależne przed wznowieniem zadań. Zachowaj oryginalne profile i wymagane uprawnienia w okresie przywracania.

Faza 5: Likwidacja profili

  • Po okresie wycofywania usuń przestarzałe uprawnienia do obszaru roboczego original-parent i profilu po potwierdzeniu, że dedykowane jednostki usługi klienta mają wymagany dostęp.

Usuń każdy zmigrowany profil za pomocą interfejsu API zarządzania profilami:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}
  • Opcjonalnie usuń oryginalną rejestrację aplikacji udostępnionej i główną jednostkę usługi, jeśli żaden klient, zadanie lub niepowiązane obciążenie nadal ich używa. Wycofaj przestarzałe poświadczenia i zachowaj mapowania migracji i rejestry audytu zgodnie z wymaganiami dotyczącymi przechowywania.

Note

Alternatywna migracja bez MI ani federacji: Tożsamość zarządzana i poświadczenia federacyjne są zalecane, ale nie obowiązkowe. Jeśli nie chcesz ich używać, pomiń fazę 0. W fazie 2 skonfiguruj certyfikat lub inne obsługiwane poświadczenie dla każdej aplikacji klienta zamiast federacyjnego poświadczenia. W fazach 3 i 4 uzyskaj i zweryfikuj tokeny dostępu bezpośrednio jako tę aplikację. Zachowaj ten sam spis, granty zasobów, autoryzację klienta, etapy wdrażania i wycofywania z eksploatacji oraz obsługuj bezpieczne przechowywanie poświadczeń i ich rotację.

Przewodnik implementacji

Ten przewodnik opisuje zalecane podejście oparte na tożsamości zarządzanej i poświadczeniach federacyjnych. Alternatywa uwierzytelniania bezpośredniego opiera się na tej samej konfiguracji tożsamości i uprawnień i jest opisana po głównych krokach. Przykłady interfejsu wiersza polecenia platformy Azure używają składni powłoki Bash; przed uruchomieniem zastąp symbole zastępcze i zaloguj się do docelowego katalogu i subskrypcji.

Prerequisites

  • Subskrypcja platformy Azure oraz uprawnienia do tworzenia i przypisywania tożsamości zarządzanych dla zalecanej ścieżki.

  • Uprawnienia w Microsoft Entra ID do tworzenia rejestracji aplikacji i nazw głównych usług oraz aktualizowania poświadczeń aplikacji. Azure uprawnienia zasobów i uprawnienia katalogu są oddzielne.

  • Aplikacja hostowana w obsługiwanych usługach obliczeniowych platformy Azure, takich jak App Service, Container Apps, odpowiednio skonfigurowane obciążenie usługi AKS lub maszyna wirtualna. Źródło asercji oparte na usłudze MI w tym wzorcu zależy od tej konfiguracji hostingu na platformie Azure.

  • Uprawnienia administracyjne w celu udzielenia dostępu do obszaru roboczego i zasobu klienta, skonfigurowania wymaganych ustawień usługi oraz udzielenia uprawnień interfejsu API lub zgody, gdy usługa docelowa ich wymaga.

  • Zainstalowano Azure CLI i zalogowano się do właściwej dzierżawy katalogowej. Przed utworzeniem Azure zasobów potwierdź kontekst subskrypcji.

Ustawienia dzierżawy dla deweloperów

Przejrzyj odpowiednie ustawienia w interfejsie administracyjnym usługi w obszarze ustawienia dzierżawy i ustawienia dewelopera. Ogranicz dostęp jednostki usługi do dozwolonej grupy zabezpieczeń zawierającej jednostki usługi klienta. Aby uzyskać dokładne etykiety i bieżące zachowanie, zobacz ustawienia dzierżawy dewelopera.

Dla każdego ustawienia w zakresie grupy wymaganego przez rozwiązanie dodaj każdą zastępczą jednostkę usługi do dozwolonej grupy zabezpieczeń przed rozpoczęciem testowania lub przełączenia. Dostęp udzielony oryginalnej nazwie głównej usługi nie autoryzuje automatycznie zastępczych nazw głównych. Ustawienie dostępu publicznego interfejsu API ma zastosowanie zarówno do istniejących interfejsów API REST obsługujących profil, jak i interfejsów API REST Fabric; migracja tylko tożsamości nie usuwa tego wymagania wstępnego.

Następujące ustawienie publicznego interfejsu API używa etykiety neutralnej od produktu; interfejs administracyjny może zawierać nazwę usługi.

Setting Domyślnie opublikowane Wymagane, gdy
jednostki usługi mogą wywoływać publiczne interfejsy API Włączone dla nowych klientów. Nazwy główne usług wywołują istniejące interfejsy API REST obsługujące profile lub interfejsy API REST usługi Fabric. Uwzględnij każdy podmiot zastępczy w dozwolonej grupie zabezpieczeń, gdy ustawienie ma zakres grupy.
Podmioty usługowe mogą tworzyć obszary robocze, połączenia i potoki wdrażania Wyłączone dla nowych klientów. Aplikacja udostępnia te zasoby.
Osadzanie zawartości w aplikacjach Włączone w istniejących konfiguracjach; zweryfikuj dzierżawcę. Istniejąca aplikacja osadza zawartość za pośrednictwem odpowiednich interfejsów API REST.
Zezwalaj jednostkom usługi na tworzenie i używanie profilów Nie zakładaj ustawienia domyślnego. Tylko wtedy, gdy klienci nadal korzystają ze ścieżki profilu; nie jest to wymagane w przypadku zmigrowanych klientów.

Sprawdź rzeczywiste wartości zamiast zakładać wartości domyślne. Nowe i istniejące tenanty mogą się różnić, a administratorzy mogą zmieniać ustawienia. Zachowaj ustawienie profilu do momentu migracji każdego powiązanego klienta i zadania zależnego. Nie włączaj ustawień osadzania dla obciążenia niezwiązanego z osadzaniem.

Krok 1. Tworzenie i przypisywanie tożsamości zarządzanej przypisanej przez użytkownika

Ta tożsamość zarządzana reprezentuje aplikację niezależnego dostawcy oprogramowania, a nie indywidualnego klienta. Użyj istniejącej grupy zasobów:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Rejestruj identyfikator klienta, identyfikator podmiotu zabezpieczeń (obiektu), identyfikator dzierżawy katalogu i identyfikator zasobu Azure. Przypisz go do zasobu obliczeniowego. W przypadku istniejącej aplikacji usługi App Service:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Użyj odpowiedniej procedury przypisywania tożsamości dla innych usług obliczeniowych. Jawnie wybierz tę tożsamość przypisaną przez użytkownika w czasie wykonywania. Ponieważ tożsamość jest niezależna od zasobu hosta, ponowne wdrożenie hosta nie musi zastępować wszystkich relacji zaufania klientów.

Krok 2. Tworzenie nazwy głównej usługi dla każdego klienta

Dla każdego klienta, użytkownika lub granicy grupy reprezentowanej przez istniejące profile utwórz rejestrację aplikacji i jej jednostkę usługi (service principal). W tym przykładzie utworzono aplikację z pojedynczą dzierżawą w katalogu niezależnego dostawcy oprogramowania:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)
Identyfikator Używanie
Identyfikator klienta aplikacji Zidentyfikuj aplikację klienta podczas żądania tokenu dostępu.
Identyfikator obiektu aplikacji Skonfiguruj poświadczenia federacyjne w rejestracji aplikacji.
Identyfikator obiektu jednostki usługi Udziel ról obszaru roboczego lub zasobu, gdy interfejs API wymaga identyfikatora obiektu jednostki zabezpieczeń.

Note

Poświadczenia dla zalecanej ścieżki: Nie twórz klucza tajnego klienta ani certyfikatu dla tej trasy uwierzytelniania. Zaufanie federacyjne aplikacji klienta dostarcza mechanizm uwierzytelniania.

Krok 3. Konfigurowanie poświadczeń tożsamości federacyjnej

Pobierz identyfikator jednostki usługi tożsamości zarządzanej i identyfikator dzierżawy katalogu. Użyj dzierżawcy tożsamości, a nie zakładaj, że inna bieżąca subskrypcja ma tego samego dzierżawcę:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Dodaj poświadczenie tożsamości federacyjnej do każdej rejestracji aplikacji klienta. Następujące polecenie global-cloud używa identyfikatora obiektu aplikacji z kroku 2 i właśnie pobranych wartości MI:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

Alternatywnie zapisz ten sam kod JSON z zastąpionymi wartościami w pliku lokalnym credential.json i przekaż polecenie --parameters credential.json. Powtórz zaufanie dla każdej aplikacji klienta. Odczekaj na propagację konfiguracji przed walidacją wymiany tokenów.

Krok 4. Udziel każdej jednostce usługi dostępu do obszaru roboczego

Dodaj jednostkę usługi klienta jako członka lub administratora tylko do wyznaczonych obszarów roboczych, w których ta rola jest wymagana. Preferuj niższą obsługiwaną rolę, jeśli spełnia ona wymagania dotyczące operacji. To uprawnienie określa zakres dostępu do zasobów klienta.

Użyj interfejsu administracyjnego obszaru roboczego lub operacji REST przypisywania ról obszaru roboczego. W poniższym przykładzie użyto konfigurowalnego interfejsu API i identyfikatorów zasobów. Wymaga ona autoryzowanej tożsamości inicjującej; sama tożsamość zarządzana środowiska uruchomieniowego nie ma przyznanych uprawnień do zasobów klienta na potrzeby wymiany tokenów.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Użyj punktu końcowego i kształtu żądania udokumentowanych dla usługi, do której należy istniejący obszar roboczy. Wyświetlana operacja ma zastosowanie do interfejsu API obszaru roboczego uwzględniającego profile; inne interfejsy API mogą używać różnych schematów przypisania ról. Nie należy zastępować identyfikatora klienta, gdy operacja oczekuje identyfikatora obiektu nazwy głównej usługi. Unikaj rejestrowania tokenów bearer i zezwalaj na propagację uprawnień.

Krok 5. Uwierzytelnij i wywołuj interfejsy API w czasie wykonywania

  1. Ustal identyfikator klienta aplikacji uwierzytelnionego klienta i dozwolone zasoby z konfiguracji zaufanej po stronie serwera.

  2. Uzyskaj token asercji przy użyciu wybranej tożsamości zarządzanej przypisanej przez użytkownika i api://AzureADTokenExchange/.default zakresu w chmurze globalnej.

  3. Użyj tokenu MI jako asercji klienta dla aplikacji klienta. Zażądaj tokenu dostępu z zakresem aplikacji interfejsu API zasobu, a nie parametrem audience asercji.

  4. Wywołaj docelowy interfejs API przy użyciu tokenu dostępu aplikacji klienta i bez konfiguracji wyboru profilu. Zarządzaj obszarami roboczymi, żądaj wszystkich wymaganych tokenów specyficznych dla aplikacji i wykonuj inne zinwentaryzowane operacje za pośrednictwem tożsamości klienta.

W przypadku platformy .NET użyj Azure Identity ClientAssertionCredential z tokenem tożsamości zarządzanej jako wywołaniem zwrotnym asercji. Przepływ sześcioetapowy i oficjalne przykłady konfiguracji pokazują wymianę bez konieczności użycia przykładowego kodu aplikacji specyficznego dla osadzania.

Automatyzacja wdrażania i wycofywania użytkowników

Uwzględnij cztery operacje dołączania w potoku aprowizacji: utwórz rejestrację aplikacji, utwórz jednostkę usługi/service principal, skonfiguruj zaufanie federacyjne i przyznaj rolę obszaru roboczego. Utwórz jednocześnie odpowiadającą jej ścieżkę offboardingu: usuń uprawnienia do zasobów, unieważnij przestarzałe relacje zaufania lub poświadczenia i usuń tożsamości aplikacji dopiero po sprawdzeniu zależności.

Implementacja alternatywna: Uwierzytelnianie nazw głównych usługi bezpośrednio

Jeśli nie chcesz używać MI i federacji, pomiń kroki 1 i 3. Wykonaj krok 2 dla każdego dzierżawcy i skonfiguruj obsługiwane poświadczenie aplikacji zamiast federacyjnego zaufania.

Tam, gdzie jest to obsługiwane, użyj certyfikatu i postępuj zgodnie ze wskazówkami dotyczącymi konfiguracji poświadczeń aplikacji. Prześlij certyfikat publiczny, chroń klucz prywatny w odpowiednim magazynie poświadczeń i zautomatyzuj odnawianie. Jeśli klucz tajny klienta jest niezbędny, należy go chronić i odnawiać przed wygaśnięciem.

Ukończ krok 4 z tymi samymi minimalnymi uprawnieniami klienta. W kroku 5 użyj identyfikatora klienta klienta i jego poświadczeń, aby bezpośrednio zażądać tokenu dostępu uzyskanego w przepływie client credentials. Zachowaj te same mechanizmy sterujące routingiem klienta, separacją pamięci podręcznej tokenów, walidacją i czyszczeniem migracji.

Zabezpieczenia, ograniczenia i zagadnienia

Zastosuj następujące mechanizmy kontrolne do wybranej ścieżki uwierzytelniania i zaplanuj limity operacyjne.

Zalecenia dotyczące zabezpieczeń

  • Użyj stabilnej tożsamości zarządzanej przypisanej przez użytkownika. Pozwala to uniknąć utraty relacji opartych na zaufaniu z klientami tylko dlatego, że zasób obliczeniowy jest zastępowany. Nie używaj tożsamości przypisanej przez system jako źródła asercji dla tego wzorca app-trust.

  • Traktuj tożsamość zarządzaną aplikacji jako wysoce uprzywilejowaną tożsamość. Może uwierzytelniać się jako każda aplikacja klienta, która mu ufa. Ogranicz prawa do wdrażania zasobów obliczeniowych, przypisywania tożsamości zarządzanej, właścicieli aplikacji i administrowania poświadczeniami. W razie potrzeby podziel tożsamości środowiska uruchomieniowego, aby zmniejszyć zakres naruszenia zabezpieczeń.

  • Nie nadaj MI żadnych własnych uprawnień obsługi klienta. Jest to źródło asercji; podmioty zabezpieczeń obsługi klienta otrzymują uprawnienia do obszaru roboczego i usług podrzędnych.

  • Określ zakres ustawień dzierżawcy przy użyciu grupy zabezpieczeń. Uwzględnij każdą odpowiednią jednostkę usługi klienta w dozwolonej grupie zamiast włączyć dostęp dla jednostek usługi w całej organizacji.

  • Monitorowanie i zgłaszanie alertów dotyczących logowań poszczególnych nazw głównych usług. Skoreluj z dziennikami aplikacji i zasobów. Zbieranie dzienników bez badania specyficznego dla klienta i generowania alertów nie zapewnia korzyści operacyjnej.

  • Zautomatyzuj onboarding i offboarding razem. Usuwanie ról obszaru roboczego, wycofywanie poświadczeń lub relacji zaufania oraz usuwanie przestarzałych jednostek usługi musi być tak kontrolowane i powtarzalne, jak ich aprowizacja.

Zachowaj mapowania klienta po stronie serwera, zweryfikuj członkostwo przed wybraniem tożsamości i odrzuć dowolne identyfikatory tożsamości lub zasobów dostarczone przez klienta. Ponowne użycie tokenu oznacza, że jeden rekord logowania nie jest rekordem każdego wywołania interfejsu API. Nie rejestruj sekretów, asercji, tokenów dostępu ani kluczy prywatnych certyfikatów.

Ograniczenia i wymagania operacyjne

Rozważenie Co zaplanować
Skalowanie pułapu w porównaniu z profilami Profile umożliwiają utworzenie 100 000 profili na nadrzędną jednostkę usługi, z maksymalnie 1000 obszarami roboczymi na profil. Dedykowane rejestracje aplikacji i nazwy główne usług wykorzystują obiekty katalogowe. Przed zatwierdzeniem sprawdź limity przydziału katalogu, limity obszaru roboczego nazwy głównej usługi i przepustowość aprowizacji.
Limit poświadczeń federacyjnych Rejestracja aplikacji obsługuje co najwyżej 20 poświadczeń tożsamości federacyjnej. Zazwyczaj ta architektura wymaga jednej tożsamości zarządzanej na zaufane środowisko uruchomieniowe w każdej aplikacji klienta, a nie jednej na klienta w aplikacji współdzielonej.
Wymaganie tego samego dzierżawcy Tożsamość zarządzana i każda zaufana rejestracja aplikacji muszą należeć do tego samego dzierżawcy Microsoft Entra. Dostęp do zasobów w innym tenantcie dodatkowo wymaga obsługiwanej konfiguracji aplikacji, zgody i uprawnień do zasobów.
Brak wymiany tokenów między chmurami Nie wymieniaj tokenów między różnymi chmurami Azure, takimi jak chmura globalna i chmura dla instytucji rządowych USA. Użyj prawidłowych punktów końcowych odbiorców i urzędu uwierzytelniania w chmurze docelowej.
Wymagania dotyczące mocy obliczeniowej Azure Przepływ asercji opartej na tożsamości zarządzanej wymaga mechanizmu tożsamości zarządzanej obsługiwanego środowiska hostingu Azure. Jeśli aplikacja działa w innym miejscu lub nie chcesz używać tego wzorca, użyj alternatywy uwierzytelniania bezpośredniego lub innego obsługiwanego projektu federacji.
Dostęp warunkowy Do tworzenia lub modyfikowania zasad dostępu warunkowego dla tożsamości obciążenia roboczego jest wymagany Tożsamość obciążeń Microsoft Entra Premium. Zasady obejmują kwalifikujące się nazwy główne usług pojedynczej dzierżawy należące do organizacji i muszą być kierowane bezpośrednio do nich. Nie obejmują one tożsamości zarządzanych ani nie mają zastosowania wyłącznie poprzez członkostwo w grupach.
Ustawienia dzierżawy dla deweloperów Każda jednostka usługi używająca ustawienia o zakresie grupy musi znajdować się w dozwolonej grupie zabezpieczeń. Przejrzyj cztery ustawienia w wymaganiach wstępnych implementacji; nie zakładaj wartości domyślnych.
Automation Ręczne zarządzanie setkami lub tysiącami tożsamości klientów jest niepraktyczne. Automatyzowanie aprowizacji, zmiany uprawnień, monitorowanie, rotacja lub aktualizacje relacji zaufania oraz odłączanie. Obsługa limitowania z użyciem ograniczonej liczby ponowień i opóźnienia między próbami.
Funkcje wyłącznie delegowane pozostają poza zakresem Zastępowanie profilów nie umożliwia uwierzytelniania tylko aplikacji, w przypadku gdy obciążenie robocze wymaga delegowanych tokenów użytkownika. W wersji zapoznawczej osadzania pulpitu nawigacyjnego Real-Time obsługiwany jest tylko ten typ elementu i uwierzytelnianie delegowane użytkownika; Tokeny typu app-only i app-owns-data nie są obsługiwane. Do osadzania istniejących raportów używany jest odpowiedni mechanizm specyficzny dla danej usługi.

Przed sfinalizowaniem pojemności i uprawnień zapoznaj się z limitami usług Microsoft Entra i obsługą tożsamości interfejsu API usługi docelowej.

Aby zapoznać się z bieżącymi limitami zaufania i zachowaniem propagacji, zobacz Zagadnienia dotyczące poświadczeń tożsamości federacyjnej.

Aby uzyskać informacje o bieżących zasadach kwalifikowalności i licencjonowaniu, zobacz Dostęp warunkowy dla tożsamości obciążenia.

Użyj odpowiednio elementu audience api://AzureADTokenExchangeglobal-cloud token-exchange, elementu audience api://AzureADTokenExchangeUSGovUS Government lub elementu audience api://AzureADTokenExchangeChinaChina. Dopasuj punkt końcowy instancji uwierzytelniania do chmury. W przykładach w tym artykule użyto chmury globalnej.

Użyj obsługiwanych bibliotek uwierzytelniania i tożsamości na potrzeby buforowania i odświeżania tokenów. Zezwalaj na propagację zaufania i uprawnień, ponawianie prób przejściowych niepowodzeń z ograniczonym opóźnieniem ponawiania oraz badanie utrzymujących się niezgodności wartości issuer, subject lub audience. W przypadku uwierzytelniania bezpośredniego należy wymieniać certyfikaty i klucze tajne z okresem nakładania się oraz monitorować wygaśnięcie.

Nie zakładaj, że usunięcie profilu, usunięcie poświadczeń lub zmiana poziomu zaufania powoduje natychmiastowe unieważnienie wystawionych wcześniej tokenów. Uwzględnij okres ważności tokenu oraz zachowanie autoryzacji i odwoływania poszczególnych usług zasobów podczas planowania przełączenia i odłączania.

Treści powiązane

Skorzystaj z tych materiałów referencyjnych dotyczących uprawnień specyficznych dla interfejsu API, bieżących ograniczeń tożsamości i istniejącej konfiguracji obciążenia roboczego.

Profile, nazwy główne usługi i istniejące obciążenia robocze

Federacja tożsamości obciążenia i tożsamość zarządzana

Zestawy SDK, interfejsy API i limity usług

  • Ostatnia aktualizacja o