Globalna struktura tożsamości usługi Azure Active Directory B2C
Usługa Azure Active Directory B2C to rozwiązanie do zarządzania dostępem do tożsamości klientów (CIAM) umożliwiające obsługę milionów użytkowników i miliardów uwierzytelnień dziennie. Zajmuje się ona skalowaniem i bezpieczeństwem platformy uwierzytelniania, monitorowaniem i automatyczną obsługą zagrożeń, takich jak odmowa usługi, spray haseł lub ataki siłowe.
Usługa Azure Active Directory B2C (Azure AD B2C) jest oddzielną usługą od identyfikatora Microsoft Entra. Jest ona oparta na tej samej technologii co identyfikator Microsoft Entra, ale do innego celu. Umożliwia firmom tworzenie aplikacji przeznaczonych dla klientów, a następnie umożliwia samoobsługowe rejestrowanie aplikacji.
Azure AD B2C to globalnie rozproszona usługa składa się z kilku składników:
Directory
Podczas tworzenia rozwiązania Azure AD B2C należy podać lokalizację do hostowania usługi. Ta lokalizacja dotyczy tylko regionu, w którym będą przechowywane dane profilu użytkownika, podczas gdy pozostała część usługi, która przetwarza logowanie jest uruchamiana globalnie.
Zazwyczaj dzierżawa usługi Azure AD B2C jest wdrażana w regionie znajdującym się najbliżej bazy użytkowników. Ułatwia to zachowanie zgodności z przepisami dotyczącymi rezydencji danych, ponieważ profil użytkownika jest replikowany tylko w wybranym regionie. Zapewnia to również najlepszą wydajność podczas logowania, ponieważ opóźnienia sieci są zoptymalizowane pod kątem magazynu katalogów.
Jeśli katalog Azure AD B2C wymaga obsługi użytkowników na całym świecie, struktura regionalna stanowi wyzwanie. Należy określić lokalizację, w której ma zostać utworzona dzierżawa usługi Azure AD B2C. Wszyscy użytkownicy spoza wybranego regionu mogą nie być zgodni z wymaganiami dotyczącymi rezydencji danych i mogą również wystąpić zwiększone opóźnienia podczas weryfikowania swoich poświadczeń lub odczytywania danych profilu użytkownika.
Rozważmy na przykład aplikację, która obsługuje użytkowników w Australii i Ameryka Północna, a katalog Azure AD B2C jest tworzony w regionie Ameryka Północna. Użytkownicy, którzy logują się z Australii, mogą mieć do czynienia z dłuższym czasem przetwarzania w celu ukończenia uwierzytelniania.
Aby lepiej spełnić wymagania dotyczące rezydencji danych i rozwiązać problemy z wydajnością, należy wdrożyć wiele dzierżaw usługi Azure AD B2C. Umieszczając dzierżawę w każdym regionie, w którym działa twoja firma, operacje w katalogu są zoptymalizowane pod kątem opóźnień. Jednak dzięki temu rozwiązanie tworzy inne obciążenia związane z konfigurowaniem i ochroną poufnych zasobów dzierżawy w każdym regionie oraz zarządzanie nimi. Inne obciążenia obejmują:
Administrowanie dzierżawą
Izolacja dzierżawy, co powoduje, że środowisko użytkownika końcowego nie działa globalnie
Rozliczenia
Procesy ciągłej integracji/ciągłego wdrażania do zarządzania zasadami/rejestracjami aplikacji/kluczami
W tym dokumencie zaproponowano architektury z Azure AD B2C, które najlepiej obsługują rozwiązania dla klientów, którzy obsługują użytkowników na całym świecie. Rozwiązania spełniają następujące wymagania:
Użytkownicy mogą zachować ten sam zestaw poświadczeń, niezależnie od tego, gdzie na świecie uzyskują dostęp do aplikacji.
Spójna wydajność i opóźnienia niezależnie od tego, skąd użytkownicy się uwierzytelniają.
Ułatw klientom dostarczanie procesów, struktur lub zestawów SDK do zespołów deweloperów przy możliwie najmniejszej wymaganej konfiguracji.
Profile użytkowników można utrzymywać podczas podróży użytkowników na całym świecie. Spowoduje to utworzenie większej wartości w analizie wygenerowanej przez interakcje użytkowników w dowolnej usłudze.
Dane użytkownika klienta są przechowywane w regionalnych magazynach danych.
Poniżej przedstawiono dwa podejścia do rozważenia podczas implementowania platformy tożsamości przy użyciu dzierżaw Azure AD B2C dla globalnego modelu biznesowego.
Pierwsze podejście korzysta z regionów geograficznych, ponieważ granica i aplikacje są konfigurowane specjalnie dla regionu.
Drugie podejście ma globalną granicę dla aplikacji i używa dodatkowej dzierżawy Azure AD B2C do organizowania interakcji między dzierżawami regionalnymi.
Orkiestracja dzierżawy regionalnej
W tym modelu aplikacje są hostowane w poszczególnych regionach lub mają konfiguracje poszczególnych regionów w celu nawiązania połączenia z dzierżawą regionalną. Aplikacje bezpośrednio wysyłają użytkownika do dzierżawy specyficznej dla regionu. Komunikacja między dzierżawami służy do przeprowadzania uwierzytelniania między dzierżawami lub aktualizacji profilów między dzierżawami, gdy użytkownik mógł podróżować do innego regionu.
Orkiestracja dzierżawy lejka
W tym modelu dzierżawa usługi Azure AD B2C leje użytkowników do dzierżaw regionalnych Azure AD B2C. Dzierżawa lejka działa jako koordynator przekierowania do innych dzierżaw Azure AD B2C. Jest to obsługiwane przez globalnie rozproszony składnik usługi Azure AD B2C, dlatego nie ma to wpływu na wydajność. To przekierowanie jest wykonywane przy użyciu federacji dostawcy tożsamości OpenId Connect.
Komunikacja między dzierżawami służy do przeprowadzania uwierzytelniania między dzierżawami lub aktualizacji profilów między dzierżawami. Dzierżawa lejka udostępnia aplikacjom pojedynczy punkt końcowy do komunikowania się z.
Architektura, po której decydujesz się modelować rozwiązanie, wymaga dokonywania wyborów na podstawie kompromisów między dwoma opisanymi modelami. Na przykład model lejka umożliwia obsługę pojedynczego wystąpienia aplikacji. W poniższej sekcji opisano możliwości, kryteria wyboru i wydajność, które mogą mieć wpływ na wybrany projekt.
Możliwości i zagadnienia
W poniższej tabeli opisano możliwości zapewniane przy użyciu projektu opartego na regionie i lejku:
Możliwość | Oparte na regionie | Oparte na lejce |
---|---|---|
Obsługuje rejestrację konta lokalnego i logowanie | ||
Obsługuje rejestrację konta federacyjnego i logowanie | ||
Obsługuje uwierzytelnianie kont lokalnych dla użytkowników logujących się spoza ich zarejestrowanego regionu | ||
Obsługuje uwierzytelnianie kont federacyjnych dla użytkowników logujących się spoza ich zarejestrowanego regionu przy użyciu wyszukiwania opartego na interfejsie API między dzierżawami | ||
Zapobiega rejestrowaniu się w wielu różnych regionach | ||
Aplikacje w każdym regionie mają zestaw punktów końcowych do nawiązania połączenia z | ||
Wszystkie aplikacje łączą się z pojedynczym zestawem punktów końcowych, niezależnie od regionu, w którym są hostowane | ||
Obsługuje szczegółowe zasady dostępu warunkowego. | ||
Zoptymalizowane pod kątem kosztów. |
Na podstawie możliwości należy wziąć pod uwagę następujące kwestie:
W przypadku korzystania z podejścia opartego na regionie należy pamiętać, że podejście wymaga, aby aplikacje obejmujące wiele regionów miały odpowiednie konfiguracje dla każdej dzierżawy regionalnej Azure AD B2C.
W przypadku korzystania z podejścia opartego na lejce
Koszt podwójnego tokenu
Wprowadzono dodatkowe przekierowanie HTTP
Domeny niestandardowe są wymagane w wielu dzierżawach
Dostęp warunkowy jest stosowany na poziomie dzierżawy, a nie na poziomie aplikacji
Wylogowywanie jednokrotne za pośrednictwem wielu dostawców tożsamości może powodować wyzwania
Wybrane podejście będzie oparte na liczbie hostów aplikacji i specyficznych wymaganiach dotyczących dostępu do aplikacji.
Wydajność
Zaletą wydajności korzystania z wielu dzierżaw w konfiguracji regionalnej lub lejkowej będzie poprawa użycia jednej dzierżawy Azure AD B2C dla firm działających globalnie.
W przypadku korzystania z podejścia opartego na lejce dzierżawa lejka znajduje się w jednym konkretnym regionie i obsługuje użytkowników globalnie. Ponieważ operacja dzierżaw lejka korzysta z globalnego składnika usługi Azure AD B2C, utrzymuje spójny poziom wydajności niezależnie od tego, skąd logują się użytkownicy.
Jak pokazano na powyższym diagramie, dzierżawa Azure AD B2C w podejściu opartym na lejku będzie używać aparatu zasad tylko do wykonywania przekierowania do regionalnych dzierżaw Azure AD B2C. Składnik aparatu zasad Azure AD B2C jest globalnie dystrybuowany. W związku z tym lejek nie jest ograniczony z perspektywy wydajności, niezależnie od tego, gdzie jest aprowizowana dzierżawa lejka Azure AD B2C. Napotkano utratę wydajności z powodu dodatkowego przekierowania między lejkiem i dzierżawami regionalnymi w podejściu opartym na lejku.
W podejściu opartym na regionie, ponieważ każdy użytkownik jest kierowany do najbardziej lokalnych Azure AD B2C, wydajność jest spójna dla wszystkich użytkowników logowanych.
Dzierżawy regionalne będą wykonywać wywołania katalogów do magazynu katalogów, który jest jedynym składnikiem regionalizowanym zarówno w architekturach opartych na lejku, jak i w architekturach regionalnych.
Dodatkowe opóźnienie występuje tylko wtedy, gdy użytkownik wykonał uwierzytelnianie w innym regionie, z którego się zarejestrował. Jest to spowodowane tym, że wywołania będą wykonywane w różnych regionach, aby dotrzeć do magazynu katalogów, w którym ich profil mieszka w celu ukończenia uwierzytelniania.
Następne kroki
Azure AD weryfikacji tożsamości globalnej B2C konfiguracji opartej na regionie
Azure AD globalnej weryfikacji tożsamości B2C konfiguracji opartej na lejku
Tworzenie globalnego rozwiązania do obsługi tożsamości przy użyciu podejścia opartego na lejku
Tworzenie globalnego rozwiązania do obsługi tożsamości przy użyciu podejścia opartego na regionie