Instrukcje: migrowanie z usługi Azure Access Control Service

Usługa Microsoft Azure Access Control Service (ACS), usługa usługi Azure Active Directory (Azure AD) zostanie wycofana 7 listopada 2018 r. Aplikacje i usługi, które obecnie korzystają z kontroli dostępu, muszą zostać w pełni zmigrowane do innego mechanizmu uwierzytelniania. W tym artykule przedstawiono zalecenia dla obecnych klientów dotyczące planowanego wycofania się z korzystania z kontroli dostępu. Jeśli obecnie nie używasz kontroli dostępu, nie musisz podejmować żadnych działań.

Przegląd

Kontrola dostępu to usługa uwierzytelniania w chmurze, która oferuje łatwy sposób uwierzytelniania i autoryzacji użytkowników w celu uzyskania dostępu do aplikacji i usług internetowych. Umożliwia ona uwzględnianie wielu funkcji uwierzytelniania i autoryzacji poza kodem. Kontrola dostępu jest używana głównie przez deweloperów i architektów klientów platformy Microsoft .NET, ASP.NET aplikacji internetowych i usług internetowych Windows Communication Foundation (WCF).

Przypadki użycia kontroli dostępu można podzielić na trzy główne kategorie:

• Uwierzytelnianie do niektórych usług w chmurze firmy Microsoft, w tym usług Azure Service Bus i Dynamics CRM. Aplikacje klienckie uzyskują tokeny z kontroli dostępu w celu uwierzytelniania w tych usługach w celu wykonywania różnych akcji.
• Dodawanie uwierzytelniania do aplikacji internetowych, zarówno niestandardowych, jak i wstępnie spakowanych (takich jak SharePoint). Za pomocą uwierzytelniania "pasywnego" kontroli dostępu aplikacje internetowe mogą obsługiwać logowanie przy użyciu konta Microsoft (dawniej Live ID) oraz kont z usług Google, Facebook, Yahoo, Azure AD i Active Directory Federation Services (AD FS).
• Zabezpieczanie niestandardowych usług sieci Web przy użyciu tokenów wystawionych przez kontrolę dostępu. Korzystając z uwierzytelniania "aktywne", usługi sieci Web mogą zapewnić, że zezwalają na dostęp tylko do znanych klientów uwierzytelnionych za pomocą kontroli dostępu.

Każdy z tych przypadków użycia i ich zalecane strategie migracji zostały omówione w poniższych sekcjach.

Kontrola dostępu ma następujące składniki:

• Usługa bezpiecznego tokenu (STS), która odbiera żądania uwierzytelniania i wystawia tokeny zabezpieczające w zamian.
• Klasyczny portal Azure, w którym tworzysz, usuwasz i włączasz i wyłączasz przestrzenie nazw kontroli dostępu.
• Oddzielny portal zarządzania kontrolą dostępu, w którym można dostosować i skonfigurować przestrzenie nazw kontroli dostępu.
• Usługa zarządzania, której można użyć do zautomatyzowania funkcji portali.
• Silnik reguł przekształcania tokenów, który można wykorzystać do definiowania złożonej logiki manipulowania formatem wyjściowym tokenów wydawanych przez Kontrolę Dostępu.

Aby korzystać z tych składników, należy utworzyć co najmniej jedną przestrzeń nazw kontroli dostępu. Przestrzeń nazw to dedykowane wystąpienie kontroli dostępu, z którym komunikują się Twoje aplikacje i usługi. Przestrzeń nazw jest odizolowana od wszystkich innych klientów kontroli dostępu. Inni klienci kontroli dostępu używają własnych przestrzeni nazw. Przestrzeń nazw w kontroli dostępu ma dedykowany adres URL, który wygląda następująco:

https://<mynamespace>.accesscontrol.windows.net

Cała komunikacja z usługami STS i operacjami zarządzania odbywa się pod tym adresem URL. Używasz różnych ścieżek do różnych celów. Aby określić, czy aplikacje lub usługi używają kontroli dostępu, monitoruj dowolny ruch do https://< namespace.accesscontrol.windows.net>. Każdy ruch do tego adresu URL jest obsługiwany przez kontrolę dostępu i musi zostać przerwany.

Wyjątkiem od tego jest dowolny ruch do https://accounts.accesscontrol.windows.net. Ruch do tego adresu URL jest już obsługiwany przez inną usługę i nie jest objęty wycofaniem kontroli dostępu.

Aby uzyskać więcej informacji na temat kontroli dostępu, zobacz Access Control Service 2.0 (zarchiwizowana).

Dowiedz się, które z Twoich aplikacji będzie miało wpływ

Wykonaj kroki opisane w tej sekcji, aby dowiedzieć się, na które aplikacje będą wpływać wycofanie usługi ACS.

Pobieranie i instalowanie programu PowerShell usługi ACS

1. Przejdź do galerii programu PowerShell i pobierz Acs.Namespaces.

2. Zainstaluj moduł, wykonując

   Install-Module -Name Acs.Namespaces
   

3. Pobierz listę wszystkich możliwych poleceń, uruchamiając

   Get-Command -Module Acs.Namespaces
   

   Aby uzyskać pomoc dotyczącą określonego polecenia, uruchom polecenie:

    Get-Help [Command-Name] -Full
   

   gdzie [Command-Name] jest nazwą polecenia ACS.

Wymień swoje przestrzenie nazw ACS

1. Połącz się z usługą ACS przy użyciu polecenia cmdlet Connect-AcsAccount.

   Być może będzie konieczne uruchomienie Set-ExecutionPolicy -ExecutionPolicy Bypass przed wykonaniem poleceń i zarządzaniem tymi subskrypcjami jako administrator w celu wykonania poleceń.

2. Wyświetl listę dostępnych subskrypcji platformy Azure przy użyciu polecenia cmdlet Get-AcsSubscription.

3. Wyświetl listę przestrzeni nazw ACS za pomocą polecenia cmdlet Get-AcsNamespace.

Sprawdzanie, które aplikacje będą mieć wpływ

1. Użyj przestrzeni nazw z poprzedniego kroku i przejdź do https://<namespace>.accesscontrol.windows.net

   Jeśli na przykład jedna z przestrzeni nazw to contoso-test, przejdź do https://contoso-test.accesscontrol.windows.net

2. W obszarze Relacje zaufania wybierz pozycję Aplikacje korzystające aby wyświetlić listę aplikacji, które zostaną dotknięte wyłączeniem usługi ACS.

3. Powtórz kroki 1-2 dla innych przestrzeni nazw ACS, które posiadasz.

Harmonogram wycofania

Od listopada 2017 r. wszystkie składniki kontroli dostępu są w pełni obsługiwane i operacyjne. Jedynym ograniczeniem jest to, że nie można tworzyć nowych przestrzeni nazw kontroli dostępu za pośrednictwem klasycznego portalu Azure.

Oto harmonogram wycofania składników kontroli dostępu:

• Listopad 2017: Doświadczenie administratora Azure AD w klasycznym portalu Azure zostało wycofane. W tym momencie zarządzanie przestrzenią nazw dla kontroli dostępu jest dostępne pod nowym, dedykowanym adresem URL: https://manage.windowsazure.com?restoreClassic=true. Użyj tego adresu URL, aby wyświetlić istniejące przestrzenie nazw, włączyć i wyłączyć przestrzenie nazw oraz usunąć przestrzenie nazw, jeśli wybierzesz tę opcję.
• 2 kwietnia 2018 r. Klasyczny portal Azure jest całkowicie wycofany, co oznacza, że zarządzanie przestrzenią nazw kontroli dostępu nie jest już dostępne za pośrednictwem żadnego adresu URL. Na tym etapie nie możesz wyłączyć ani włączyć przestrzeni nazw kontroli dostępu, usunąć jej ani wyliczyć. Jednak portal zarządzania kontrolą dostępu będzie w pełni funkcjonalny i znajduje się w lokalizacji https://<namespace>.accesscontrol.windows.net. Wszystkie inne składniki kontroli dostępu nadal działają normalnie.
• 7 listopada 2018 r.: Wszystkie składniki kontroli dostępu zostały trwale zamknięte. Obejmuje to portal zarządzania kontrolą dostępu, usługę zarządzania, STS oraz silnik reguł przekształcania tokenu. W tym momencie wszystkie żądania wysyłane do kontroli dostępu (znajdującej się w lokalizacji <namespace>.accesscontrol.windows.net) kończą się niepowodzeniem. Przed tym razem należy przeprowadzić migrację wszystkich istniejących aplikacji i usług do innych technologii.

Strategie migracji

W poniższych sekcjach opisano ogólne zalecenia dotyczące migracji z kontroli dostępu do innych technologii firmy Microsoft.

Klienci usług w chmurze firmy Microsoft

Każda usługa w chmurze firmy Microsoft, która akceptuje tokeny wystawiane przez kontrolę dostępu, obsługuje teraz co najmniej jedną alternatywną formę uwierzytelniania. Prawidłowy mechanizm uwierzytelniania różni się w przypadku każdej usługi. Zalecamy zapoznanie się z określoną dokumentacją dla każdej usługi w celu uzyskania oficjalnych wskazówek. Dla wygody każdy zestaw dokumentacji znajduje się tutaj:

Klienci programu SharePoint

Klienci korzystający z usług SharePoint 2013, 2016 i SharePoint Online od dawna korzystają z usług ACS do celów uwierzytelniania w chmurze, lokalnie i w scenariuszach hybrydowych. Niektóre funkcje programu SharePoint i przypadki użycia będą miały wpływ na wycofanie usługi ACS, a inne nie. Poniższa tabela zawiera podsumowanie wskazówek dotyczących migracji dla niektórych najpopularniejszych funkcji programu SharePoint korzystających z usługi ACS:

Aplikacje internetowe korzystające z uwierzytelniania pasywnego

W przypadku aplikacji internetowych korzystających z kontroli dostępu do uwierzytelniania użytkowników kontrola dostępu udostępnia następujące funkcje i możliwości deweloperom i architektom aplikacji internetowych:

• Głęboka integracja z programem Windows Identity Foundation (WIF).
• Federacja z kontami Google, Facebook, Yahoo, Azure Active Directory i AD FS oraz kontami Microsoft.
• Obsługa następujących protokołów uwierzytelniania: OAuth 2.0 Draft 13, WS-Trust i Web Services Federation (WS-Federation).
• Obsługa następujących formatów tokenów: JSON Web Token (JWT), SAML 1.1, SAML 2.0 i Simple Web Token (SWT).
• Środowisko odnajdywania obszaru macierzystego zintegrowane z usługą WIF, które umożliwia użytkownikom wybranie typu konta używanego do logowania. To środowisko jest hostowane przez aplikację internetową i jest w pełni dostosowywane.
• Przekształcenie tokenu, które umożliwia zaawansowane dostosowywanie oświadczeń odebranych przez aplikację internetową z systemu kontroli dostępu, w tym:
  • Przesyłanie oświadczeń od dostawców tożsamości.
  • Dodawanie dodatkowych roszczeń niestandardowych.
  • Prosta logika if-then do tworzenia roszczeń w określonych warunkach.

Niestety, nie ma jednej usługi, która oferuje wszystkie te równoważne możliwości. Należy ocenić, które funkcje kontroli dostępu są potrzebne, a następnie wybrać między użyciem identyfikatora Microsoft Entra,usługi Azure Active Directory B2C (Azure AD B2C ) lub innej usługi uwierzytelniania w chmurze.

Migracja do Microsoft Entra ID

Ścieżka do rozważenia polega na integracji aplikacji i usług bezpośrednio z identyfikatorem Entra firmy Microsoft. Microsoft Entra ID to dostawca tożsamości oparty na chmurze dla kont służbowych firmy Microsoft. Microsoft Entra ID to dostawca tożsamości dla platformy Microsoft 365, platformy Azure i wiele innych. Zapewnia podobne funkcje uwierzytelniania federacyjnego do kontroli dostępu, ale nie obsługuje wszystkich funkcji kontroli dostępu.

Podstawowym przykładem jest federacja z dostawcami tożsamości społecznościowych, takimi jak Facebook, Google i Yahoo. Jeśli użytkownicy logują się przy użyciu tych typów poświadczeń, Microsoft Entra ID nie jest dla was rozwiązaniem.

Identyfikator Entra firmy Microsoft również nie musi obsługiwać dokładnie tych samych protokołów uwierzytelniania co kontrola dostępu. Na przykład mimo że zarówno Kontrola Dostępu, jak i Microsoft Entra ID obsługują protokół OAuth, istnieją subtelne różnice między ich implementacjami. Różne implementacje wymagają zmodyfikowania kodu w ramach migracji.

Jednak microsoft Entra ID zapewnia kilka potencjalnych korzyści dla klientów kontroli dostępu. Natywnie obsługuje konta służbowe firmy Microsoft hostowane w chmurze, które są często używane przez klientów kontroli dostępu.

Dzierżawa usługi Microsoft Entra może być również sfederowana z jedną lub więcej instancji lokalnego Active Directory poprzez AD FS. Dzięki temu aplikacja może uwierzytelniać użytkowników i użytkowników w chmurze hostowanych lokalnie. Obsługuje również protokół WS-Federation, który sprawia, że jest stosunkowo prosty w integracji z aplikacją internetową przy użyciu programu WIF.

W poniższej tabeli porównaliśmy funkcje kontroli dostępu, które są istotne dla aplikacji internetowych z funkcjami dostępnymi w usłudze Microsoft Entra ID.

Na wysokim poziomie identyfikator Entra firmy Microsoft jest prawdopodobnie najlepszym wyborem dla migracji, jeśli zezwolisz użytkownikom na logowanie się tylko przy użyciu kont służbowych Firmy Microsoft.

Jeśli zdecydujesz, że identyfikator Entra firmy Microsoft jest najlepszą ścieżką migracji dla aplikacji i usług, należy pamiętać o dwóch sposobach integracji aplikacji z identyfikatorem Entra firmy Microsoft.

Aby użyć WS-Federation lub programu WIF do integracji z identyfikatorem Entra firmy Microsoft, zalecamy zastosowanie podejścia opisanego w temacie Konfigurowanie federacyjnego logowania jednokrotnego dla aplikacji spoza galerii. W tym artykule opisano konfigurowanie identyfikatora Entra firmy Microsoft dla logowania jednokrotnego opartego na protokole SAML, ale także opisano konfigurowanie usługi WS-Federation. Zgodnie z tym podejściem wymagana jest licencja microsoft Entra ID P1 lub P2. Takie podejście ma dwie zalety:

• Otrzymujesz pełną elastyczność dostosowywania tokenu Entra firmy Microsoft. Możesz dostosować oświadczenia wydane przez firmę Microsoft Entra ID, aby dopasować je do oświadczeń wystawionych przez kontrolę dostępu. Dotyczy to zwłaszcza identyfikatora użytkownika lub twierdzenia identyfikatora nazwy. Aby zapewnić dalsze otrzymywanie spójnych identyfikatorów użytkowników po zmianie technologii, upewnij się, że identyfikatory użytkowników wystawione przez Microsoft Entra ID są zgodne z tymi wystawionymi przez kontrolę dostępu.
• Możesz skonfigurować certyfikat podpisywania tokenu specyficzny dla aplikacji oraz okres istnienia, który kontrolujesz.

Alternatywną metodą jest wykonanie tego przykładowego kodu, który zawiera nieco inne instrukcje dotyczące konfigurowania usługi WS-Federation. Ten przykładowy kod nie używa programu WIF, ale raczej oprogramowania pośredniczącego OWIN ASP.NET 4.5. Jednak instrukcje dotyczące rejestracji aplikacji są prawidłowe dla aplikacji korzystających z programu WIF i nie wymagają licencji Microsoft Entra ID P1 lub P2.

Jeśli wybierzesz to podejście, musisz zrozumieć zmianę klucza podpisywania w Microsoft Entra ID. W tym podejściu używany jest globalny klucz podpisywania firmy Microsoft do wystawiania tokenów. Domyślnie program WIF nie odświeża automatycznie kluczy podpisywania. Gdy identyfikator Entra firmy Microsoft obraca swoje globalne klucze podpisywania, implementacja programu WIF musi być przygotowana do akceptowania zmian. Aby uzyskać więcej informacji, zobacz Ważne informacje o rotacji klucza podpisywania w usłudze Microsoft Entra ID.

Jeśli możesz zintegrować się z identyfikatorem Entra firmy Microsoft za pośrednictwem protokołów OpenID Connect lub OAuth, zalecamy wykonanie tej czynności. Dysponujemy obszerną dokumentacją i wskazówkami dotyczącymi sposobu integrowania identyfikatora Entra firmy Microsoft z twoją aplikacją internetową dostępną w naszym przewodniku dewelopera firmy Microsoft Entra.

Migrowanie do usługi Azure Active Directory B2C

Inną ścieżką migracji do rozważenia jest usługa Azure AD B2C. Azure AD B2C to usługa uwierzytelniania w chmurze, która, taka jak kontrola dostępu, umożliwia deweloperom przekazywanie logiki uwierzytelniania i zarządzania tożsamościami do usługi w chmurze. Jest to płatna usługa (z warstwami Bezpłatna i Premium), która jest przeznaczona dla aplikacji przeznaczonych dla konsumentów, które mogą mieć do milionów aktywnych użytkowników.

Podobnie jak kontrola dostępu, jedną z najbardziej atrakcyjnych funkcji usługi Azure AD B2C jest to, że obsługuje wiele różnych typów kont. Za pomocą usługi Azure AD B2C możesz logować użytkowników przy użyciu konta Microsoft lub konta Facebook, Google, LinkedIn, GitHub lub Yahoo i nie tylko. Usługa Azure AD B2C obsługuje również "konta lokalne" lub nazwy użytkownika i hasła tworzone przez użytkowników specjalnie dla aplikacji. Usługa Azure AD B2C zapewnia również zaawansowaną rozszerzalność, której można użyć do dostosowywania przepływów logowania.

Jednak usługa Azure AD B2C nie obsługuje zakresu protokołów uwierzytelniania i formatów tokenów, których mogą wymagać klienci kontroli dostępu. Nie można również używać usługi Azure AD B2C do uzyskiwania tokenów i wykonywania zapytań o dodatkowe informacje o użytkowniku od dostawcy tożsamości, firmy Microsoft lub w inny sposób.

W poniższej tabeli porównaliśmy funkcje kontroli dostępu, które są istotne dla aplikacji internetowych z funkcjami dostępnymi w usłudze Azure AD B2C. Na wysokim poziomie usługa Azure AD B2C jest prawdopodobnie właściwym wyborem w przypadku migracji, jeśli aplikacja jest skierowana do konsumentów lub obsługuje wiele różnych typów kont.

Jeśli zdecydujesz, że usługa Azure AD B2C jest najlepszą ścieżką migracji dla aplikacji i usług, zacznij od następujących zasobów:

• Dokumentacja usługi Azure AD B2C
• Niestandardowe zasady usługi Azure AD B2C
• Cennik usługi Azure AD B2C

Migrowanie do usługi Ping Identity lub Auth0

W niektórych przypadkach może się okazać, że identyfikator Entra firmy Microsoft i usługa Azure AD B2C nie są wystarczające do zastąpienia kontroli dostępu w aplikacjach internetowych bez wprowadzania istotnych zmian w kodzie. Oto niektóre typowe przykłady:

• Aplikacje internetowe korzystające z programu WIF lub WS-Federation do logowania się z dostawcami tożsamości społecznościowych, takimi jak Google lub Facebook.
• Aplikacje internetowe, które wykonują bezpośrednią federację z dostawcą tożsamości przedsiębiorstwa za pośrednictwem protokołu WS-Federation.
• Aplikacje internetowe, które wymagają użycia tokenu dostępu wystawionego przez dostawcę tożsamości społecznościowych (np. Google lub Facebook) jako żądanie w tokenach wystawionych przez kontrolę dostępu.
• Aplikacje internetowe z złożonymi regułami przekształcania tokenów, których nie można odtworzyć w usłudze Microsoft Entra ID lub Azure AD B2C.
• Wielozadaniowe aplikacje internetowe, które używają usługi ACS do centralnego zarządzania federacją z wieloma różnymi dostawcami tożsamości

W takich przypadkach warto rozważyć migrację aplikacji internetowej do innej usługi uwierzytelniania w chmurze. Zalecamy zapoznanie się z następującymi opcjami. Każda z następujących opcji oferuje możliwości podobne do kontroli dostępu:

Auth0 to elastyczna usługa tożsamości w chmurze, która utworzyła ogólne wskazówki dotyczące migracji dla klientów kontroli dostępu i obsługuje prawie każdą funkcję, którą wykonuje usługa ACS.

Usługa Ping Identity oferuje dwa rozwiązania podobne do usług ACS. PingOne to usługa tożsamości w chmurze, która obsługuje wiele takich samych funkcji jak ACS, a PingFederate jest podobnym lokalnym produktem tożsamości, który oferuje większą elastyczność. Aby uzyskać więcej informacji na temat korzystania z tych produktów, zapoznaj się ze wskazówkami dotyczącymi wycofywania usług ACS firmy Ping.

Naszym celem w pracy z usługą Ping Identity i Auth0 jest zapewnienie, że wszyscy klienci kontroli dostępu mają ścieżkę migracji dla swoich aplikacji i usług, które minimalizują ilość pracy wymaganej do przejścia z kontroli dostępu.

Usługi sieci Web korzystające z aktywnego uwierzytelniania

W przypadku usług sieci Web, które są zabezpieczone za pomocą tokenów wystawionych przez kontrolę dostępu, kontrola dostępu oferuje następujące funkcje i możliwości:

• Możliwość rejestrowania co najmniej jednej tożsamości usługi w przestrzeni nazw kontroli dostępu. Tożsamości usługowe mogą służyć do żądania tokenów.
• Obsługa protokołów OAuth WRAP i OAuth 2.0 Draft 13 na potrzeby żądania tokenów przy użyciu następujących typów poświadczeń:
  • Proste hasło utworzone dla tożsamości usługi
  • Podpisana biblioteka SWT przy użyciu klucza symetrycznego lub certyfikatu X509
  • Token SAML wydany przez zaufanego dostawcę tożsamości (zazwyczaj instancja AD FS)
• Obsługa następujących formatów tokenów: JWT, SAML 1.1, SAML 2.0 i SWT.
• Proste reguły przekształcania tokenu.

Tożsamości usług w Kontroli Dostępu są zwykle używane do realizacji uwierzytelniania międzyserwerowego.

Migracja do Microsoft Entra ID

Naszym zaleceniem dla tego typu przepływu uwierzytelniania jest migracja do identyfikatora Entra firmy Microsoft. Microsoft Entra ID to dostawca tożsamości oparty na chmurze dla kont służbowych firmy Microsoft. Microsoft Entra ID to dostawca tożsamości dla platformy Microsoft 365, platformy Azure i wiele innych.

Możesz również użyć Microsoft Entra ID na potrzeby uwierzytelniania serwer-serwer, korzystając z implementacji Microsoft Entra metody uprawnień klienta OAuth. W poniższej tabeli porównaliśmy możliwości kontroli dostępu w uwierzytelnianiu serwer-serwer z tymi, które są dostępne w usłudze Microsoft Entra ID.

Aby uzyskać wskazówki dotyczące implementowania scenariuszy serwer-serwer, zobacz następujące zasoby:

• Sekcja Service-to-Service w przewodniku dla deweloperów Microsoft Entra
• Przykładowy kod dla demona używającego prostych poświadczeń klienta na bazie haseł
• Przykładowy kod demona z użyciem poświadczeń klienta w certyfikacie

Migrowanie do usługi Ping Identity lub Auth0

W niektórych przypadkach może się okazać, że poświadczenia klienta firmy Microsoft Entra i implementacja udzielania OAuth nie są wystarczające do zastąpienia kontroli dostępu w architekturze bez istotnych zmian w kodzie. Oto niektóre typowe przykłady:

• Uwierzytelnianie serwer-serwer przy użyciu formatów tokenów innych niż JWTs.
• Uwierzytelnianie serwer-serwer przy użyciu tokenu wejściowego dostarczonego przez zewnętrznego dostawcę tożsamości.
• Uwierzytelnianie serwer-serwer z regułami przekształcania tokenów, których Microsoft Entra ID nie może odtworzyć.

W takich przypadkach możesz rozważyć migrację aplikacji internetowej do innej usługi uwierzytelniania w chmurze. Zalecamy zapoznanie się z następującymi opcjami. Każda z następujących opcji oferuje możliwości podobne do kontroli dostępu:

Auth0 to elastyczna usługa tożsamości w chmurze, która utworzyła ogólne wskazówki dotyczące migracji dla klientów kontroli dostępu i obsługuje prawie każdą funkcję, którą wykonuje usługa ACS.

Ping Identity oferuje dwa rozwiązania podobne do ACS. PingOne to usługa tożsamości w chmurze, która obsługuje wiele takich samych funkcji jak ACS, a PingFederate jest podobnym lokalnym produktem tożsamości, który oferuje większą elastyczność. Aby uzyskać więcej informacji na temat korzystania z tych produktów, zapoznaj się ze wskazówkami dotyczącymi wycofywania usług ACS firmy Ping.

Naszym celem w pracy z usługą Ping Identity i Auth0 jest zapewnienie, że wszyscy klienci kontroli dostępu mają ścieżkę migracji dla swoich aplikacji i usług, które minimalizują ilość pracy wymaganej do przejścia z kontroli dostępu.

Uwierzytelnianie typu passthrough

W przypadku uwierzytelniania przekazującego z dowolną transformacją tokenu nie istnieje równoważna technologia firmy Microsoft do ACS. Jeśli to jest to, czego potrzebują twoi klienci, Auth0 może być tym, który zapewnia najbliższe przybliżenie rozwiązania.

Pytania, obawy i opinie

Rozumiemy, że wielu klientów kontroli dostępu nie znajdzie jasnej ścieżki migracji po przeczytaniu tego artykułu. Może być potrzebna pomoc lub wskazówki dotyczące określania odpowiedniego planu. Jeśli chcesz omówić scenariusze i pytania dotyczące migracji, pozostaw komentarz na tej stronie.