Udostępnij za pośrednictwem

Tworzenie globalnego rozwiązania do obsługi tożsamości przy użyciu podejścia opartego na lejce

  • Artykuł

W tym artykule opisano scenariusze podejścia projektowego opartego na lejkach. Przed rozpoczęciem projektowania zaleca się zapoznanie się z możliwościami i wydajnością podejścia projektowego opartego na lejce i regionie. Ten artykuł pomoże dokładniej określić, który projekt może być najlepszy dla Twojej organizacji.

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ą jeden punkt końcowy do nawiązania połączenia z

Przypadki użycia logowania 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. Udostępniamy 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.

Zrzut ekranu przedstawiający przepływ rejestracji użytkownika lokalnego.

  1. 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 lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do dzierżawy globalnej lejka Azure AD B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie zdefiniowanych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. 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.

  4. 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ł.

  5. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  6. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawiający istniejący przepływ rejestracji konta.

  1. Użytkownik z EMEA próbuje zarejestrować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do dzierżawy globalnej lejka Azure AD B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. 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.

  4. 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.

  5. 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.

Zrzut ekranu przedstawiający przepływ logowania użytkownika lokalnego.

  1. Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. Użytkownik wprowadza swoje poświadczenia w dzierżawie regionalnej.

  4. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  5. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawiający przepływ logowania użytkownika podróży.

  1. Użytkownik z Ameryka Północna (NOAM) próbuje zalogować się na myapp.fr podczas wakacji we Francji. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. Użytkownik wprowadza swoje poświadczenia w dzierżawie regionalnej.

  4. 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.

  5. Adres e-mail użytkownika znajduje się w celu zarejestrowania się w dzierżawie NOAM Azure AD B2C.

  6. 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.

  7. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  8. Dzierżawa lejka wystawia token aplikacji.

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.

Zrzut ekranu przedstawiający przepływ zapomnianych haseł przez użytkownika lokalnego.

  1. Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. 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.

  4. Email wyszukiwanie jest wykonywane w celu określenia, w której dzierżawie regionalnej istnieje użytkownik.

  5. Użytkownik udostępnia nowe hasło.

  6. Nowe hasło jest zapisywane w dzierżawie Azure AD EMEA B2C.

  7. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  8. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawiający przepływ zapomnianych haseł użytkownika podróży.

  1. Użytkownik noAM próbuje zalogować się w myapp.fr , ponieważ jest na wakacjach we Francji. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. 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.

  4. Email wyszukiwanie jest wykonywane w celu określenia, w której dzierżawie regionalnej istnieje użytkownik.

  5. Adres e-mail znajduje się w dzierżawie NOAM Azure AD B2C. Użytkownik udostępnia nowe hasło.

  6. Nowe hasło jest zapisywane w dzierżawie NOAM Azure AD B2C za pośrednictwem wywołania interfejs Graph API.

  7. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  8. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawia przepływ zmiany hasła użytkownika lokalnego.

  1. Użytkownik z EMEA próbuje zmienić hasło po zalogowaniu się do myapp.fr.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. 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.

  4. Nowe hasło jest zapisywane na koncie użytkowników w dzierżawie Azure AD B2C w regionie EMEA.

  5. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  6. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawiający przepływ zmiany hasła użytkownika podróży.

  1. Użytkownik z NOAM próbuje zmienić hasło po zalogowaniu się do myapp.fr.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. 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.

  4. Adres e-mail użytkownika znajduje się w dzierżawie NOAM po sprawdzeniu globalnej tabeli odnośników.

  5. Nowe hasło jest zapisywane na koncie użytkowników w dzierżawie NOAM Azure AD B2C przez połączenie MS interfejs Graph API.

  6. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  7. Dzierżawa lejka wystawia token 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 może zarejestrować się w usłudze z regionu lokalnego przy użyciu identyfikatora federacyjnego.

Zrzut ekranu przedstawiający przepływ rejestracji federacyjnego identyfikatora.

  1. Użytkownik z EMEA próbuje zarejestrować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być odnośnik oparty na identyfikatorze clientId aplikacji.

  3. Użytkownik wybierze opcję zalogowania się przy użyciu dostawcy tożsamości federacyjnej (IdP).

  4. 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.

  5. Zapisz konto użytkowników w dzierżawie Azure AD B2C w regionie EMEA.

  6. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  7. Dzierżawa lejka wystawia token 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.

Zrzut ekranu przedstawia przepływ logowania lokalnego użytkownika federacyjnego.

  1. Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. Użytkownik wybierze opcję zalogowania się przy użyciu dostawcy tożsamości federacyjnej.

  4. Wykonaj wyszukiwanie w globalnej tabeli odnośników i upewnij się, że identyfikator federacyjny użytkownika jest zarejestrowany w regionie EMEA.

  5. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  6. Dzierżawa lejka wystawia token aplikacji.

Logowanie użytkowników federacyjnych

W tym przypadku użycia pokazano, jak użytkownik może zalogować się na swoje konto przy użyciu federacyjnego dostawcy tożsamości, znajdując się poza regionem, w którym się zarejestrował.

Zrzut ekranu przedstawia przepływ logowania użytkowników federacyjnych.

  1. Użytkownik z NOAM próbuje zalogować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. Użytkownik wybierze opcję zalogowania 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.

  4. Wykonaj wyszukiwanie w globalnej tabeli odnośników i określ, czy identyfikator federacyjny użytkownika jest zarejestrowany w usłudze NOAM.

  5. Odczytywanie danych konta z dzierżawy NOAM Azure AD B2C przy użyciu interfejs Graph API MS.

  6. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  7. Dzierżawa lejka wystawia token aplikacji.

Łączenie konta z kryteriami dopasowania

W tym przypadku użycia pokazano, jak użytkownicy mogą wykonywać łączenie kont w przypadku spełnienia kryteriów dopasowania. Kryteria dopasowania są zazwyczaj adresem e-mail użytkowników. Gdy kryteria dopasowania logowania z nowego dostawcy tożsamości mają taką samą wartość dla istniejącego konta w Azure AD B2C, proces łączenia kont może się rozpocząć.

Zrzut ekranu przedstawiający przepływ umożliwiający scalenie konta federacyjnego.

  1. Użytkownik z EMEA próbuje zalogować się na myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do globalnego lejka Azure AD dzierżawy B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. Użytkownik wybierze opcję zalogowania się przy użyciu dostawcy tożsamości federacyjnej/dostawcy tożsamości społecznościowej.

  4. Wyszukiwanie jest wykonywane w globalnej tabeli odnośników dla identyfikatora zwróconego z federacyjnego dostawcy tożsamości.

  5. Jeśli identyfikator nie istnieje, ale adres e-mail z federacyjnego dostawcy tożsamości istnieje w regionie EMEA Azure AD B2C — jest to przypadek użycia łączenia konta.

  6. 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.

  7. 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.

  8. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  9. Dzierżawa lejka wystawia token aplikacji.

Łączenie konta użytkownika podróży z kryteriami dopasowania

W tym przypadku użycia pokazano, jak użytkownicy nielokalni mogą wykonywać łączenie kont w przypadku spełnienia kryteriów dopasowania. Kryteria dopasowania są zazwyczaj adresem e-mail użytkowników. Gdy kryteria dopasowania logowania z nowego dostawcy tożsamości mają taką samą wartość dla istniejącego konta w Azure AD B2C, proces łączenia kont może się rozpocząć.

Zrzut ekranu przedstawiający przepływ umożliwiający scalenie użytkownika federacyjnego.

  1. Użytkownik z NOAM próbuje zalogować się w myapp.fr. Jeśli użytkownik nie jest wysyłany do lokalnego wystąpienia aplikacji, usługa Traffic Manager wymusza przekierowanie.

  2. Użytkownik dociera do dzierżawy globalnej lejka Azure AD B2C. Ta dzierżawa jest skonfigurowana do przekierowywania do dzierżawy regionalnej Azure AD B2C na podstawie niektórych kryteriów przy użyciu federacji OpenId. Może to być wyszukiwanie oparte na identyfikatorze clientId aplikacji.

  3. Użytkownik wybierze opcję zalogowania się przy użyciu dostawcy tożsamości federacyjnej/dostawcy tożsamości społecznościowej.

  4. Wyszukiwanie jest wykonywane w globalnej tabeli odnośników dla identyfikatora zwróconego z federacyjnego dostawcy tożsamości.

  5. Jeśli identyfikator nie istnieje, a wiadomość e-mail z federacyjnego dostawcy tożsamości istnieje w innym regionie — jest to podróżny przypadek użycia łączący konto użytkownika.

  6. Utwórz link id_token_hint z potwierdzeniem 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ń interfejsu API zewnętrznego w celu manipulowania kolekcją tożsamości. Przykład zasad niestandardowych korzystający z id_token_hint można znaleźć tutaj.

  7. 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.

  8. Dzierżawa regionalna wystawia token z powrotem do dzierżawy lejka.

  9. Dzierżawa lejka wystawia token aplikacji.

Następne kroki