Tworzenie globalnego rozwiązania do obsługi tożsamości przy użyciu podejścia opartego na regionie
W tym artykule opisano scenariusze podejścia do projektowania opartego na regionie. Przed rozpoczęciem projektowania zaleca się zapoznanie się z możliwościami i wydajnością podejścia projektowego opartego na lejce i regionie.
Projekty są uwzględniane w następujących celach:
- Tworzenie konta lokalnego i logowanie się
- Tworzenie konta federacyjnego i logowanie się
- Uwierzytelnianie kont lokalnych dla użytkowników logujących się spoza ich zarejestrowanego regionu obsługiwanego przez uwierzytelnianie oparte na interfejsie API między dzierżawami.
- Uwierzytelnianie kont federacyjnych dla użytkowników logujących się spoza ich zarejestrowanego regionu, obsługiwane przez wyszukiwanie oparte 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
Uwierzytelnianie konta lokalnego
Następujące przypadki użycia są typowe w globalnym środowisku Azure AD B2C. Przypadki użycia konta lokalnego obejmują również konta, w których użytkownik podróżuje. Każdy z nich zawiera diagram i kroki przepływu pracy dla każdego przypadku użycia.
Rejestracja użytkownika lokalnego
W tym przypadku użycia pokazano, jak użytkownik z kraju/regionu macierzystego wykonuje rejestrację przy użyciu konta lokalnego usługi Azure AD B2C.
Użytkownik z Europy, Bliskiego Wschodu i Afryki (EMEA) próbuje zarejestrować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik próbuje się zarejestrować. Proces rejestracji sprawdza globalną tabelę odnośników, aby określić, czy użytkownik istnieje w dowolnej z regionalnych dzierżaw usługi Azure AD B2C.
Użytkownik nie znajduje się w globalnej tabeli odnośników. Konto użytkownika jest zapisywane w Azure AD B2C, a rekord jest tworzony w globalnej tabeli odnośników w celu śledzenia regionu, w którym użytkownik się zarejestrował.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Istniejący użytkownik lokalny próbuje zarejestrować się
W tym przypadku użycia pokazano, jak użytkownik ponownie rejestruje tę samą wiadomość e-mail z własnego kraju/regionu lub innego regionu, jest blokowany.
Użytkownik z EMEA próbuje zarejestrować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik próbuje się zarejestrować. Proces rejestracji sprawdza globalną tabelę odnośników, aby określić, czy użytkownik istnieje w dowolnej z regionalnych dzierżaw usługi Azure AD B2C.
Adres e-mail użytkownika znajduje się w globalnej tabeli odnośników, wskazując, że użytkownik zarejestrował tę wiadomość e-mail w rozwiązaniu w pewnym poprzednim momencie.
Użytkownik jest wyświetlany z błędem wskazującym, że jego konto istnieje.
Logowanie użytkownika lokalnego
W tym przypadku użycia pokazano, jak użytkownik z kraju/regionu macierzystego wykonuje logowanie przy użyciu konta lokalnego usługi Azure AD B2C.
Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wprowadza swoje poświadczenia w dzierżawie regionalnej.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Użytkownik jest zalogowany do aplikacji.
Logowanie użytkownika podczas podróży
W tym przypadku użycia pokazano, jak użytkownik może podróżować między regionami i utrzymywać swój profil użytkownika oraz poświadczenia przechowywane w dzierżawie regionalnej odpowiadającej rejestracji.
Użytkownik z Ameryka Północna (NOAM) próbuje zalogować się na myapp.fr, ponieważ są na wakacjach we Francji. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wprowadza swoje poświadczenia w dzierżawie regionalnej.
Dzierżawa regionalna wykonuje wyszukiwanie w globalnej tabeli odnośników, ponieważ wiadomość e-mail użytkownika nie została znaleziona w katalogu EMEA Azure AD B2C.
Adres e-mail użytkownika znajduje się w celu zarejestrowania się w dzierżawie NOAM Azure AD B2C.
Dzierżawa Azure AD EMEA B2C wykonuje Microsoft Entra przepływ ROPC względem dzierżawy NOAM Azure AD B2C w celu zweryfikowania poświadczeń.
Uwaga
To wywołanie spowoduje również pobranie tokenu dla użytkownika w celu wykonania wywołania interfejs Graph API. Dzierżawa Azure AD EMEA B2C wykonuje interfejs Graph API wywołanie dzierżawy NOAM Azure AD B2C w celu pobrania profilu użytkownika. To wywołanie jest uwierzytelniane przez token dostępu dla interfejs Graph API uzyskanych w ostatnim kroku.
Dzierżawa regionalna wystawia aplikację zaplecza tokenu.
Użytkownik lokalny zapomniał hasła
W tym przypadku użycia pokazano, jak użytkownik może zresetować swoje hasło, gdy znajdują się w swoim kraju/regionie.
Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik przybywa do dzierżawy emea Azure AD B2C i wybiera zapomniane hasło. Użytkownik wprowadza i weryfikuje swój adres e-mail.
Email wyszukiwanie jest wykonywane w celu określenia, w której dzierżawie regionalnej istnieje użytkownik.
Użytkownik udostępnia nowe hasło.
Nowe hasło jest zapisywane w dzierżawie Azure AD EMEA B2C.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Podróżny użytkownik zapomniał hasła
W tym przypadku użycia pokazano, jak użytkownik może zresetować swoje hasło podczas podróży z dala od regionu, w którym zarejestrował swoje konto.
Użytkownik noAM próbuje zalogować się na myapp.fr, ponieważ są na wakacjach we Francji. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik przybywa do dzierżawy emea Azure AD B2C i wybiera zapomniane hasło. Użytkownik wprowadza i weryfikuje swój adres e-mail.
Email wyszukiwanie jest wykonywane w celu określenia, w której dzierżawie regionalnej istnieje użytkownik.
Adres e-mail znajduje się w dzierżawie NOAM Azure AD B2C. Użytkownik udostępnia nowe hasło.
Nowe hasło jest zapisywane w dzierżawie NOAM Azure AD B2C za pośrednictwem wywołania interfejs Graph API.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Zmiana hasła użytkownika lokalnego
W tym przypadku użycia pokazano, jak użytkownik może zmienić swoje hasło po zalogowaniu się do regionu, w którym zarejestrował swoje konto.
Użytkownik z EMEA próbuje zmienić hasło po zalogowaniu się do myapp.fr.
Użytkownik przybywa do dzierżawy emea Azure AD B2C, a zestaw plików cookie Single-Sign On (SSO) umożliwia użytkownikowi natychmiastowe zmianę hasła.
Nowe hasło jest zapisywane na koncie użytkowników w dzierżawie Azure AD B2C w regionie EMEA.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Zmiana hasła użytkownika podczas podróży
W tym przypadku użycia pokazano, jak użytkownik może zmienić swoje hasło po zalogowaniu się z dala od regionu, w którym zarejestrował swoje konto.
Użytkownicy z noAM próbują wybrać zmianę hasła po zalogowaniu się do myapp.fr.
Użytkownik przybywa do dzierżawy EMEA Azure AD B2C, a zestaw plików cookie logowania jednokrotnego umożliwia użytkownikowi natychmiastowe zmianę hasła.
Adres e-mail użytkowników znajduje się w dzierżawie NOAM po sprawdzeniu globalnej tabeli odnośników.
Nowe hasło jest zapisywane na koncie użytkowników w dzierżawie NOAM Azure AD B2C przez połączenie MS interfejs Graph API.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Uwierzytelnianie dostawcy tożsamości federacyjnej
W poniższych przypadkach użycia pokazano przykłady używania tożsamości federacyjnych do rejestracji lub logowania się jako klient usługi Azure AD B2C.
Rejestracja lokalnego identyfikatora federacyjnego
W tym przypadku użycia pokazano, jak użytkownik z regionu lokalnego zarejestruje się w usłudze przy użyciu identyfikatora federacyjnego.
Użytkownik z EMEA próbuje zarejestrować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wybiera opcję logowania się przy użyciu dostawcy tożsamości federacyjnej.
Wykonaj wyszukiwanie w globalnej tabeli odnośników.
Jeśli łączenie kont jest w zakresie: kontynuuj, jeśli identyfikator federacyjnego dostawcy tożsamości ani wiadomość e-mail, która wróciła z federacyjnego dostawcy tożsamości, nie istnieje w tabeli odnośników.
Jeśli łączenie kont nie znajduje się w zakresie: kontynuuj, jeśli identyfikator federacyjnego dostawcy tożsamości, który wrócił z federacyjnego dostawcy tożsamości, nie istnieje w tabeli odnośników.
Zapisz konto użytkowników w dzierżawie Azure AD B2C w regionie EMEA.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Logowanie lokalnego użytkownika federacyjnego
W tym przypadku użycia pokazano, jak użytkownik z regionu lokalnego loguje się do usługi przy użyciu identyfikatora federacyjnego.
Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wybiera opcję logowania się przy użyciu dostawcy tożsamości federacyjnej.
Wykonaj wyszukiwanie w globalnej tabeli odnośników i upewnij się, że identyfikator federacyjny użytkownika jest zarejestrowany w regionie EMEA.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Logowanie użytkowników federacyjnych
W tym scenariuszu pokazano, jak użytkownik znajduje się z dala od regionu, w którym się zarejestrował, wykonuje logowanie do usługi przy użyciu federacyjnego dostawcy tożsamości.
Użytkownik z NOAM próbuje zalogować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wybiera opcję logowania się przy użyciu dostawcy tożsamości federacyjnej.
Uwaga
Użyj tego samego identyfikatora aplikacji z rejestracji aplikacji w dostawcy tożsamości społecznościowych we wszystkich dzierżawach regionalnych usługi Azure AD B2C. Dzięki temu identyfikator wracający z social idP jest zawsze taki sam.
Wykonaj wyszukiwanie w globalnej tabeli odnośników i określ, czy identyfikator federacyjny użytkownika jest zarejestrowany w usłudze NOAM.
Odczytywanie danych konta z dzierżawy NOAM Azure AD B2C przy użyciu interfejs Graph API MS.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Łączenie konta z kryteriami dopasowania
W tym scenariuszu pokazano, jak użytkownicy będą mogli łączyć konta, gdy kryterium dopasowania jest spełnione (zazwyczaj adres e-mail).
Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wybiera opcję logowania się przy użyciu dostawcy tożsamości federacyjnej/dostawcy tożsamości społecznościowej.
Wyszukiwanie jest wykonywane w globalnej tabeli odnośników dla identyfikatora zwróconego z federacyjnego dostawcy tożsamości.
Jeśli identyfikator nie istnieje, ale wiadomość e-mail od federacyjnego dostawcy tożsamości istnieje w regionie EMEA Azure AD B2C, jest to scenariusz łączenia kont.
Przeczytaj użytkownika z katalogu i określ, które metody uwierzytelniania są włączone na koncie. Przedstawia ekran logowania użytkownika przy użyciu istniejącej metody uwierzytelniania na tym koncie.
Gdy użytkownik udowodni, że jest właścicielem konta w usłudze Azure AD B2C, dodaj nowy identyfikator społecznościowy do istniejącego konta i dodaj identyfikator społecznościowy do konta w globalnej tabeli odnośników.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.
Łączenie konta użytkownika podróży z kryteriami dopasowania
W tym scenariuszu pokazano, jak użytkownicy będą mogli łączyć konta, gdy nie znajdują się w regionie.
Użytkownik z NOAM próbuje zalogować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do nazwy hosta lokalnego, usługa Traffic Manager będzie wymuszać przekierowanie.
Użytkownik trafia do dzierżawy EMEA.
Użytkownik wybiera opcję logowania się przy użyciu dostawcy tożsamości federacyjnej/dostawcy tożsamości społecznościowej.
Wyszukiwanie jest wykonywane w globalnej tabeli odnośników dla identyfikatora zwróconego z federacyjnego dostawcy tożsamości.
Jeśli identyfikator nie istnieje, a adres e-mail z federacyjnego dostawcy tożsamości istnieje w innym regionie, jest to scenariusz łączenia konta użytkownika podróży.
Utwórz link id_token_hint potwierdzenia aktualnie zebranych oświadczeń przez użytkowników. Bootstrap podróż do dzierżawy NOAM Azure AD B2C przy użyciu federacji. Użytkownik udowodni, że jest właścicielem konta za pośrednictwem dzierżawy NOAM Azure AD B2C.
Uwaga
Ta metoda służy do ponownego używania istniejącej logiki łączenia kont w dzierżawie głównej i zmniejszenia liczby wywołań zewnętrznych interfejsów API w celu manipulowania kolekcją tożsamości. Przykład niestandardowych zasad korzystających z id_token_hint można znaleźć tutaj.
Gdy użytkownik udowodni, że jest właścicielem konta w usłudze Azure AD B2C, dodaj nowy identyfikator społecznościowy do istniejącego konta, wykonując wywołanie interfejs Graph API do dzierżawy NOAM Azure AD B2C. Dodaj identyfikator społecznościowy do konta w globalnej tabeli odnośników.
Dzierżawa regionalna wystawia token z powrotem do aplikacji.