Instrukcje: migrowanie z usługi Azure Access Control Service
Ostrzeżenie
Ta zawartość dotyczy starszego punktu końcowego Azure AD w wersji 1.0. Użyj Platforma tożsamości Microsoft dla nowych projektów.
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 Access Control, muszą zostać w pełni zmigrowane do innego mechanizmu uwierzytelniania. W tym artykule opisano zalecenia dotyczące bieżących klientów, ponieważ planujesz wycofać korzystanie z Access Control. Jeśli obecnie nie używasz Access Control, nie musisz podejmować żadnych działań.
Omówienie
Access Control 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. Access Control 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 Access Control można podzielić na trzy główne kategorie:
- Uwierzytelnianie w niektórych usługach w chmurze firmy Microsoft, w tym Azure Service Bus i Dynamics CRM. Aplikacje klienckie uzyskują tokeny z Access Control 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" Access Control 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 internetowych przy użyciu tokenów wystawionych przez Access Control. Korzystając z uwierzytelniania "aktywne", usługi sieci Web mogą zagwarantować, że zezwalają na dostęp tylko do znanych klientów uwierzytelnionych za pomocą Access Control.
Każdy z tych przypadków użycia i ich zalecane strategie migracji zostały omówione w poniższych sekcjach.
Ostrzeżenie
W większości przypadków do migrowania istniejących aplikacji i usług do nowszych technologii wymagane są znaczące zmiany kodu. Zalecamy natychmiastowe rozpoczęcie planowania i wykonywania migracji, aby uniknąć potencjalnych przestojów lub przestojów.
Access Control 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 wyłączasz Access Control przestrzeni nazw.
- Oddzielny portal zarządzania Access Control, w którym można dostosowywać i konfigurować Access Control przestrzenie nazw.
- Usługa zarządzania, której można użyć do zautomatyzowania funkcji portali.
- Aparat reguł przekształcania tokenu, którego można użyć do zdefiniowania złożonej logiki do manipulowania formatem wyjściowym tokenów, które Access Control problemy.
Aby użyć tych składników, należy utworzyć co najmniej jedną Access Control przestrzeni nazw. Przestrzeń nazw to dedykowane wystąpienie Access Control, z którymi komunikują się aplikacje i usługi. Przestrzeń nazw jest odizolowana od wszystkich innych Access Control klientów. Inne Access Control klienci używają własnych przestrzeni nazw. Przestrzeń nazw w Access Control ma dedykowany adres URL, który wygląda następująco:
https://<mynamespace>.accesscontrol.windows.net
Cała komunikacja z usługą STS i operacjami zarządzania odbywa się pod tym adresem URL. Różne ścieżki są używane do różnych celów. Aby określić, czy aplikacje lub usługi używają Access Control, monitoruj dowolny ruch do https://< namespace.accesscontrol.windows.net>. Każdy ruch do tego adresu URL jest obsługiwany przez Access Control 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 ma na nią wpływu wycofanie Access Control.
Aby uzyskać więcej informacji na temat Access Control, zobacz Access Control Service 2.0 (zarchiwizowane).
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 ACS PowerShell
Przejdź do Galeria programu PowerShell i pobierz pozycję Acs.Namespaces.
Zainstaluj moduł, uruchamiając polecenie
Install-Module -Name Acs.NamespacesPobierz listę wszystkich możliwych poleceń, uruchamiając polecenie
Get-Command -Module Acs.NamespacesAby uzyskać pomoc dotyczącą określonego polecenia, uruchom polecenie:
Get-Help [Command-Name] -Fullgdzie
[Command-Name]to nazwa polecenia ACS.
Wyświetlanie listy przestrzeni nazw usługi ACS
Połącz się z usługą ACS przy użyciu polecenia cmdlet Connect-AcsAccount .
Może być konieczne uruchomienie
Set-ExecutionPolicy -ExecutionPolicy Bypasspolecenia, zanim będzie można wykonywać polecenia i być administratorem tych subskrypcji, aby wykonać polecenia.Wyświetl listę dostępnych subskrypcji platformy Azure przy użyciu polecenia cmdlet Get-AcsSubscription .
Wyświetl listę przestrzeni nazw usługi ACS przy użyciu polecenia cmdlet Get-AcsNamespace .
Sprawdzanie, na które aplikacje będą wpływać
Użyj przestrzeni nazw z poprzedniego kroku i przejdź do
https://<namespace>.accesscontrol.windows.netJeśli na przykład jedna z przestrzeni nazw to contoso-test, przejdź do
https://contoso-test.accesscontrol.windows.netW obszarze Relacje zaufania wybierz pozycję Aplikacje jednostki uzależnionej , aby wyświetlić listę aplikacji, które będą mieć wpływ na wycofanie usługi ACS.
Powtórz kroki 1–2 dla innych przestrzeni nazw ACS, które masz.
Harmonogram wycofania
Od listopada 2017 r. wszystkie składniki Access Control są w pełni obsługiwane i operacyjne. Jedynym ograniczeniem jest to, że nie można tworzyć nowych przestrzeni nazw Access Control za pośrednictwem klasycznego portalu Azure.
Oto harmonogram wycofania Access Control składników:
- Listopad 2017: Środowisko administratora Azure AD w klasycznym portalu Azure zostało wycofane. W tym momencie zarządzanie przestrzenią nazw dla Access Control 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 Access Control nie jest już dostępne za pośrednictwem żadnego adresu URL. W tym momencie nie można wyłączyć ani włączyć, usunąć ani wyliczyć Access Control przestrzeni nazw. Jednak portal zarządzania Access Control będzie w pełni funkcjonalny i zlokalizowany w lokalizacji
https://<namespace>.accesscontrol.windows.net. Wszystkie inne składniki Access Control nadal działają normalnie. - 7 listopada 2018 r.: Wszystkie składniki Access Control są trwale zamykane. Obejmuje to portal zarządzania Access Control, usługę zarządzania, usługę STS i aparat reguł przekształcania tokenu. W tym momencie wszystkie żądania wysyłane do Access Control (znajdujące się w lokalizacji )
<namespace>.accesscontrol.windows.netkończą się niepowodzeniem. Przed tym razem należy przeprowadzić migrację wszystkich istniejących aplikacji i usług do innych technologii.
Uwaga
Zasady wyłączają przestrzenie nazw, które nie zażądały tokenu przez pewien czas. Od początku września 2018 r. ten okres jest obecnie w ciągu 14 dni braku aktywności, ale zostanie to skrócone do 7 dni braku aktywności w najbliższych tygodniach. Jeśli masz Access Control przestrzenie nazw, które są obecnie wyłączone, możesz pobrać i zainstalować program ACS PowerShell, aby ponownie włączyć przestrzenie nazw.
Strategie migracji
W poniższych sekcjach opisano ogólne zalecenia dotyczące migracji z Access Control do innych technologii firmy Microsoft.
Klienci usług w chmurze firmy Microsoft
Każda usługa w chmurze firmy Microsoft, która akceptuje tokeny wystawione przez Access Control 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 konkretną dokumentacją każdej usługi, aby uzyskać oficjalne wskazówki. Dla wygody każdy zestaw dokumentacji jest udostępniany tutaj:
| Usługa | Wskazówki |
|---|---|
| Usługa Azure Service Bus | Migrowanie do sygnatur dostępu współdzielonego |
| Azure Service Bus Relay | Migrowanie do sygnatur dostępu współdzielonego |
| Azure Managed Cache | Migrowanie do usługi Azure Cache for Redis |
| Azure DataMarket | Migrowanie do interfejsów API usług AI platformy Azure |
| BizTalk Services | Migrowanie do funkcji usługi Logic Apps Azure App Service |
| Azure Media Services | Migrowanie do uwierzytelniania Azure AD |
| Azure Backup | Uaktualnianie agenta Azure Backup |
Klienci programu SharePoint
Klienci programu 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 i przypadki użycia programu SharePoint 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:
| Cecha | Wskazówki |
|---|---|
| Uwierzytelnianie użytkowników z Azure AD | Wcześniej Azure AD nie obsługiwały tokenów SAML 1.1 wymaganych przez program SharePoint do uwierzytelniania, a usługa ACS była używana jako pośrednik, który uczynił program SharePoint zgodnym z formatami tokenów Azure AD. Teraz możesz połączyć program SharePoint bezpośrednio z Azure AD przy użyciu aplikacji lokalnej w galerii aplikacji Azure AD App Gallery. |
| Uwierzytelnianie aplikacji & uwierzytelnianie serwer-serwer w programie SharePoint lokalnie | Nie ma to wpływu na emeryturę ACS; brak niezbędnych zmian. |
| Autoryzacja o niskim zaufaniu dla dodatków programu SharePoint (dostawca hostowany i hostowany w programie SharePoint) | Nie ma to wpływu na emeryturę ACS; brak niezbędnych zmian. |
| Wyszukiwanie hybrydowe w chmurze programu SharePoint | Nie ma to wpływu na emeryturę ACS; brak niezbędnych zmian. |
Aplikacje internetowe korzystające z uwierzytelniania pasywnego
W przypadku aplikacji internetowych, które używają Access Control do uwierzytelniania użytkowników, Access Control udostępnia następujące funkcje i możliwości deweloperom aplikacji internetowych i architektom:
- 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 wybieranie typu konta, którego używają do logowania. To środowisko jest hostowane przez aplikację internetową i jest w pełni dostosowywane.
- Przekształcanie tokenu, które umożliwia rozbudowane dostosowywanie oświadczeń odebranych przez aplikację internetową z Access Control, w tym:
- Przekazywanie oświadczeń od dostawców tożsamości.
- Dodawanie dodatkowych oświadczeń niestandardowych.
- Prosta logika if-then do wystawiania oświadczeń 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 możliwości Access Control potrzebujesz, 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.
Migrowanie do identyfikatora Microsoft Entra
Ścieżka do rozważenia polega na integracji aplikacji i usług bezpośrednio z identyfikatorem Microsoft Entra. Microsoft Entra id to dostawca tożsamości oparty na chmurze dla kont służbowych firmy Microsoft. Microsoft Entra identyfikator to dostawca tożsamości dla platformy Microsoft 365, platformy Azure i wiele innych. Zapewnia ona podobne możliwości uwierzytelniania federacyjnego do Access Control, ale nie obsługuje wszystkich funkcji Access Control.
Podstawowym przykładem jest federacja z dostawcami tożsamości społecznościowych, takimi jak Facebook, Google i Yahoo. Jeśli użytkownicy logujesz się przy użyciu tych typów poświadczeń, identyfikator Microsoft Entra nie jest dla Ciebie rozwiązaniem.
identyfikator Microsoft Entra również nie musi obsługiwać dokładnie tych samych protokołów uwierzytelniania co Access Control. Na przykład zarówno Access Control, jak i identyfikator Microsoft Entra obsługują protokół OAuth, istnieją subtelne różnice między poszczególnymi implementacjami. Różne implementacje wymagają zmodyfikowania kodu w ramach migracji.
Jednak Microsoft Entra ID zapewnia kilka potencjalnych korzyści dla klientów Access Control. Natywnie obsługuje konta służbowe firmy Microsoft hostowane w chmurze, które są często używane przez klientów Access Control.
Dzierżawa Microsoft Entra może być również federacyjna do co najmniej jednego wystąpienia lokalna usługa Active Directory za pośrednictwem usług AD FS. Dzięki temu aplikacja może uwierzytelniać użytkowników w chmurze i użytkowników hostowanych lokalnie. Obsługuje również protokół WS-Federation, który sprawia, że jest stosunkowo prosty do zintegrowania z aplikacją internetową przy użyciu programu WIF.
W poniższej tabeli porównaliśmy funkcje Access Control, które są istotne dla aplikacji internetowych z funkcjami dostępnymi w identyfikatorze Microsoft Entra.
Na wysokim poziomie identyfikator Microsoft Entra jest prawdopodobnie najlepszym wyborem do migracji, jeśli zezwolisz użytkownikom na logowanie się tylko przy użyciu kont służbowych Firmy Microsoft.
| Możliwość | obsługa Access Control | Obsługa identyfikatorów Microsoft Entra |
|---|---|---|
| Typy kont | ||
| Konta służbowe firmy Microsoft | Obsługiwane | Obsługiwane |
| Konta z usług Windows Server Active Directory i AD FS | — Obsługiwane za pośrednictwem federacji z dzierżawą Microsoft Entra - Obsługiwane za pośrednictwem bezpośredniej federacji z usługami AD FS |
Obsługiwane tylko za pośrednictwem federacji z dzierżawą Microsoft Entra |
| Konta z innych systemów zarządzania tożsamościami przedsiębiorstwa | - Możliwe za pośrednictwem federacji z dzierżawą Microsoft Entra - Obsługiwane za pośrednictwem federacji bezpośredniej |
Możliwe za pośrednictwem federacji z dzierżawą Microsoft Entra |
| Konta Microsoft do użytku osobistego | Obsługiwane | Obsługiwane za pośrednictwem protokołu OAuth Microsoft Entra w wersji 2.0, ale nie za pośrednictwem innych protokołów |
| Facebook, Google, konta Yahoo | Obsługiwane | Nieobsługiwane w ogóle |
| Protokoły i zgodność zestawu SDK | ||
| WIF | Obsługiwane | Obsługiwane, ale dostępne są ograniczone instrukcje |
| WS-Federation | Obsługiwane | Obsługiwane |
| OAuth 2.0 | Obsługa wersji roboczej 13 | Obsługa specyfikacji RFC 6749 |
| WS-Trust | Obsługiwane | Nieobsługiwane |
| Formaty tokenów | ||
| JWT | Obsługiwane w wersji beta | Obsługiwane |
| SAML 1.1 | Obsługiwane | Wersja zapoznawcza |
| SAML 2.0 | Obsługiwane | Obsługiwane |
| SWT | Obsługiwane | Nieobsługiwane |
| Dostosowania | ||
| Dostosowywanie odnajdywania obszaru macierzystego/interfejsu użytkownika wybierania konta | Kod do pobrania, który można włączyć do aplikacji | Nieobsługiwane |
| Przekazywanie niestandardowych certyfikatów podpisywania tokenów | Obsługiwane | Obsługiwane |
| Dostosowywanie oświadczeń w tokenach | — Przekazywanie oświadczeń wejściowych od dostawców tożsamości — Uzyskiwanie tokenu dostępu od dostawcy tożsamości jako oświadczenia — Wystawianie oświadczeń wyjściowych na podstawie wartości oświadczeń wejściowych — Wystawianie oświadczeń wyjściowych z wartościami stałymi |
— Nie można przekazać oświadczeń od dostawców tożsamości federacyjnych — Nie można pobrać tokenu dostępu od dostawcy tożsamości jako oświadczenia — Nie można wystawiać oświadczeń wyjściowych na podstawie wartości oświadczeń wejściowych — Może wystawiać oświadczenia wyjściowe z wartościami stałymi — Może wystawiać oświadczenia wyjściowe na podstawie właściwości użytkowników zsynchronizowanych z identyfikatorem Microsoft Entra |
| Automatyzacja | ||
| Automatyzowanie zadań konfiguracji i zarządzania | Obsługiwane za pośrednictwem usługi zarządzania Access Control | Obsługiwane przy użyciu interfejs Graph API firmy Microsoft |
Jeśli zdecydujesz, że identyfikator Microsoft Entra jest najlepszą ścieżką migracji dla aplikacji i usług, należy pamiętać o dwóch sposobach integracji aplikacji z identyfikatorem Microsoft Entra.
Aby użyć WS-Federation lub programu WIF do integracji z identyfikatorem Microsoft Entra, zalecamy zastosowanie podejścia opisanego w temacie Konfigurowanie federacyjnego logowania jednokrotnego dla aplikacji spoza galerii. W tym artykule opisano konfigurowanie identyfikatora Microsoft Entra 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 o identyfikatorze P1 lub P2. Takie podejście ma dwie zalety:
- Możesz uzyskać pełną elastyczność dostosowywania tokenu Microsoft Entra. Oświadczenia wystawione przez identyfikator Microsoft Entra można dostosować do oświadczeń wystawionych przez Access Control. Dotyczy to zwłaszcza identyfikatora użytkownika lub oświadczenia identyfikatora nazwy. Aby nadal otrzymywać spójne identyfikatory użytkowników dla użytkowników po zmianie technologii, upewnij się, że identyfikatory użytkowników wystawione przez identyfikator Microsoft Entra są zgodne z identyfikatorami wystawionymi przez Access Control.
- Możesz skonfigurować certyfikat podpisywania tokenu specyficzny dla aplikacji i z okresem istnienia, który kontrolujesz.
Uwaga
Takie podejście wymaga licencji Microsoft Entra ID P1 lub P2. Jeśli jesteś klientem Access Control i potrzebujesz licencji Premium na skonfigurowanie logowania jednokrotnego dla aplikacji, skontaktuj się z nami. Z przyjemnością udostępnimy licencje deweloperów do użycia.
Alternatywną metodą jest wykonanie tego przykładowego kodu, który zawiera nieco inne instrukcje dotyczące konfigurowania federacji WS-Federation. Ten przykładowy kod nie używa programu WIF, ale ASP.NET 4.5 oprogramowania pośredniczącego OWIN. Jednak instrukcje dotyczące rejestracji aplikacji są prawidłowe dla aplikacji korzystających z programu WIF i nie wymagają licencji Microsoft Entra o identyfikatorze P1 lub P2.
Jeśli wybierzesz to podejście, musisz zrozumieć przerzucanie klucza podpisywania w identyfikatorze Microsoft Entra. Takie podejście używa Microsoft Entra klucza globalnego podpisywania do wystawiania tokenów. Domyślnie program WIF nie odświeża automatycznie kluczy podpisywania. Gdy identyfikator Microsoft Entra obraca swoje globalne klucze podpisywania, implementacja programu WIF musi być przygotowana do zaakceptowania zmian. Aby uzyskać więcej informacji, zobacz Ważne informacje o przerzucaniu klucza podpisywania w identyfikatorze Microsoft Entra.
Jeśli możesz zintegrować się z identyfikatorem Microsoft Entra za pośrednictwem protokołów OpenID Connect lub OAuth, zalecamy to. Mamy obszerną dokumentację i wskazówki dotyczące integrowania identyfikatora Microsoft Entra z aplikacją internetową dostępnego w naszym przewodniku dla deweloperów Microsoft Entra.
Migrowanie do usługi Azure Active Directory B2C
Inną ścieżką migracji do rozważenia jest Azure AD B2C. Azure AD B2C to usługa uwierzytelniania w chmurze, która, na przykład Access Control, 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ć maksymalnie miliony aktywnych użytkowników.
Podobnie jak Access Control, jedną z najbardziej atrakcyjnych funkcji Azure AD B2C jest to, że obsługuje wiele różnych typów kont. Za pomocą usługi Azure AD B2C można logować użytkowników przy użyciu konta Microsoft lub Facebook, Google, LinkedIn, GitHub lub konta Yahoo itd. Azure AD B2C obsługuje również "konta lokalne" lub nazwy użytkownika i hasła tworzone przez użytkowników specjalnie dla aplikacji. Azure AD B2C zapewnia również bogatą rozszerzalność, której można użyć do dostosowywania przepływów logowania.
Jednak Azure AD B2C nie obsługuje zakresu protokołów uwierzytelniania i formatów tokenów, które mogą wymagać Access Control klientów. Nie można również użyć Azure AD B2C, aby uzyskać tokeny i wykonać zapytanie o dodatkowe informacje o użytkowniku od dostawcy tożsamości, firmy Microsoft lub w inny sposób.
Poniższa tabela porównuje funkcje Access Control, które są istotne dla aplikacji internetowych z tymi, które są dostępne w Azure AD B2C. Na wysokim poziomie Azure AD B2C jest prawdopodobnie właściwym wyborem do migracji, jeśli aplikacja jest w obliczu konsumentów lub czy obsługuje wiele różnych typów kont.
| Możliwość | obsługa Access Control | obsługa usługi Azure AD B2C |
|---|---|---|
| Typy kont | ||
| Konta służbowe firmy Microsoft | Obsługiwane | Obsługiwane za pośrednictwem zasad niestandardowych |
| Konta z usług Windows Server Active Directory i AD FS | Obsługiwane za pośrednictwem bezpośredniej federacji z usługami AD FS | Obsługiwane za pośrednictwem federacji SAML przy użyciu zasad niestandardowych |
| Konta z innych systemów zarządzania tożsamościami przedsiębiorstwa | Obsługiwane za pośrednictwem federacji bezpośredniej za pośrednictwem WS-Federation | Obsługiwane za pośrednictwem federacji SAML przy użyciu zasad niestandardowych |
| Konta Microsoft do użytku osobistego | Obsługiwane | Obsługiwane |
| Facebook, Google, konta Yahoo | Obsługiwane | Facebook i Google obsługiwane natywnie, Yahoo obsługiwane za pośrednictwem federacji OpenID Connect przy użyciu zasad niestandardowych |
| Protokoły i zgodność zestawu SDK | ||
| Windows Identity Foundation (WIF) | Obsługiwane | Nieobsługiwane |
| WS-Federation | Obsługiwane | Nieobsługiwane |
| OAuth 2.0 | Obsługa wersji roboczej 13 | Obsługa specyfikacji RFC 6749 |
| WS-Trust | Obsługiwane | Nieobsługiwane |
| Formaty tokenów | ||
| JWT | Obsługiwane w wersji beta | Obsługiwane |
| SAML 1.1 | Obsługiwane | Nieobsługiwane |
| SAML 2.0 | Obsługiwane | Nieobsługiwane |
| SWT | Obsługiwane | Nieobsługiwane |
| Dostosowania | ||
| Dostosowywanie odnajdywania obszaru macierzystego/interfejsu użytkownika wybierania konta | Kod do pobrania, który można włączyć do aplikacji | W pełni dostosowywalny interfejs użytkownika za pomocą niestandardowego kodu CSS |
| Przekazywanie niestandardowych certyfikatów podpisywania tokenów | Obsługiwane | Niestandardowe klucze podpisywania, a nie certyfikaty, obsługiwane za pomocą zasad niestandardowych |
| Dostosowywanie oświadczeń w tokenach | — Przekazywanie oświadczeń wejściowych od dostawców tożsamości — Uzyskiwanie tokenu dostępu od dostawcy tożsamości jako oświadczenia — Wystawianie oświadczeń wyjściowych na podstawie wartości oświadczeń wejściowych — Wystawianie oświadczeń wyjściowych z wartościami stałymi |
- Może przekazywać oświadczenia od dostawców tożsamości; zasady niestandardowe wymagane dla niektórych oświadczeń — Nie można pobrać tokenu dostępu od dostawcy tożsamości jako oświadczenia — Może wystawiać oświadczenia wyjściowe na podstawie wartości oświadczeń wejściowych za pośrednictwem zasad niestandardowych — Może wystawiać oświadczenia wyjściowe z wartościami stałymi za pośrednictwem zasad niestandardowych |
| Automatyzacja | ||
| Automatyzowanie zadań konfiguracji i zarządzania | Obsługiwane za pośrednictwem usługi zarządzania Access Control | — Tworzenie użytkowników dozwolonych przy użyciu usługi Microsoft interfejs Graph API — Programowe tworzenie dzierżaw, aplikacji lub zasad B2C |
Jeśli zdecydujesz, że 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
- Zasady niestandardowe 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 Microsoft Entra i Azure AD B2C nie wystarczają do zastąpienia Access Control w aplikacjach internetowych bez wprowadzania istotnych zmian w kodzie. Oto kilka typowych przykładów:
- 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ą federację bezpośrednią z dostawcą tożsamości przedsiębiorstwa za pośrednictwem protokołu WS-Federation.
- Aplikacje internetowe wymagające tokenu dostępu wystawionego przez dostawcę tożsamości społecznościowych (np. Google lub Facebook) jako oświadczenie w tokenach wystawionych przez Access Control.
- Aplikacje internetowe z złożonymi regułami przekształcania tokenów, których nie można odtworzyć Microsoft Entra identyfikatora lub Azure AD B2C.
- Wielodostępne aplikacje internetowe, które używają usługi ACS do centralnego zarządzania federacją dla wielu różnych dostawców 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 Access Control:
Auth0 to elastyczna usługa tożsamości w chmurze, która utworzyła ogólne wskazówki dotyczące migracji dla klientów Access Control 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 zapewnia większą elastyczność. Aby uzyskać więcej informacji na temat korzystania z tych produktów, zapoznaj się ze wskazówkami dotyczącymi wycofywania usługi Ping z usługą ACS.
Naszym celem w pracy z usługą Ping Identity i Auth0 jest upewnienie się, że wszyscy klienci Access Control mają ścieżkę migracji dla swoich aplikacji i usług, które minimalizują ilość pracy wymaganej do przejścia z Access Control.
Usługi sieci Web korzystające z aktywnego uwierzytelniania
W przypadku usług internetowych zabezpieczonych tokenami wystawionymi przez Access Control Access Control oferuje następujące funkcje i możliwości:
- Możliwość rejestrowania co najmniej jednej tożsamości usługi w Access Control przestrzeni nazw. Tożsamości usług 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 wystawiony przez zaufanego dostawcę tożsamości (zazwyczaj wystąpienie usług 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 Access Control są zwykle używane do implementowania uwierzytelniania między serwerami.
Migrowanie do identyfikatora Microsoft Entra
Naszym zaleceniem dla tego typu przepływu uwierzytelniania jest migracja do identyfikatora Microsoft Entra. Microsoft Entra identyfikatorem jest oparty na chmurze dostawca tożsamości dla kont służbowych firmy Microsoft. Microsoft Entra id to dostawca tożsamości dla platformy Microsoft 365, platformy Azure i wiele innych.
Identyfikator Microsoft Entra można również użyć do uwierzytelniania serwer-serwer przy użyciu implementacji Microsoft Entra przyznawania poświadczeń klienta OAuth. W poniższej tabeli porównaliśmy możliwości Access Control w uwierzytelnianiu serwer-serwer z tymi, które są dostępne w identyfikatorze Microsoft Entra.
| Możliwość | obsługa Access Control | Obsługa identyfikatora Microsoft Entra |
|---|---|---|
| Jak zarejestrować usługę internetową | Tworzenie jednostki uzależnionej w portalu zarządzania Access Control | Tworzenie aplikacji internetowej Microsoft Entra w Azure Portal |
| Jak zarejestrować klienta | Tworzenie tożsamości usługi w portalu zarządzania Access Control | Tworzenie innej aplikacji internetowej Microsoft Entra w Azure Portal |
| Używany protokół | - Protokół OAuth WRAP - OAuth 2.0 Draft 13 client credentials grant (Przyznawanie poświadczeń klienta OAuth 2.0 w wersji roboczej 13) |
Przyznawanie poświadczeń klienta OAuth 2.0 |
| Metody uwierzytelniania klienta | - Proste hasło - Podpisany SWT — Token SAML od dostawcy tożsamości federacyjnej |
- Proste hasło - Podpisany JWT |
| Formaty tokenów | -JWT - SAML 1.1 - SAML 2.0 -SWT |
Tylko JWT |
| Przekształcanie tokenu | — Dodawanie oświadczeń niestandardowych - Prosta logika wystawiania oświadczeń if-then |
Dodawanie oświadczeń niestandardowych |
| Automatyzowanie zadań konfiguracji i zarządzania | Obsługiwane za pośrednictwem usługi zarządzania Access Control | Obsługiwane przy użyciu usługi Microsoft interfejs Graph API |
Aby uzyskać wskazówki dotyczące implementowania scenariuszy serwer-serwer, zobacz następujące zasoby:
- Sekcja service-to-Service przewodnika dla deweloperów Microsoft Entra
- Przykładowy kod demona przy użyciu prostych poświadczeń klienta haseł
- Przykład kodu demona przy użyciu poświadczeń klienta certyfikatu
Migrowanie do usługi Ping Identity lub Auth0
W niektórych przypadkach może się okazać, że poświadczenia klienta Microsoft Entra i implementacja przyznawania OAuth nie wystarczają do zastąpienia Access Control w architekturze bez istotnych zmian w kodzie. Oto kilka typowych przykładów:
- 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 nie można odtworzyć Microsoft Entra identyfikatora.
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 Access Control:
Auth0 to elastyczna usługa tożsamości w chmurze, która utworzyła ogólne wskazówki dotyczące migracji dla klientów Access Control i obsługuje prawie każdą funkcję, którą wykonuje usługa ACS.
ping tożsamości 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 zapewnia większą elastyczność. Aby uzyskać więcej informacji na temat korzystania z tych produktów, zapoznaj się ze wskazówkami dotyczącymi wycofywania usługi Ping z usługą ACS.
Naszym celem w pracy z usługą Ping Identity i Auth0 jest upewnienie się, że wszyscy klienci Access Control mają ścieżkę migracji dla swoich aplikacji i usług, które minimalizują ilość pracy wymaganej do przejścia z Access Control.
Uwierzytelnianie przekazywane
W przypadku uwierzytelniania przekazywanego z dowolną transformacją tokenu nie ma równoważnej technologii firmy Microsoft z usługą 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, wątpliwości i opinie
Rozumiemy, że wielu klientów Access Control 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.