Создание глобального решения для идентификации с использованием подхода на основе регионов
В этой статье описаны сценарии для подхода к проектированию на основе регионов. Прежде чем приступить к проектированию, рекомендуется ознакомиться с возможностями и производительностью воронки и подхода к проектированию на основе регионов.
В проектах учитываются следующие функции:
- Регистрация и вход в локальную учетную запись
- Регистрация и вход в федеративную учетную запись
- Проверка подлинности локальных учетных записей для пользователей, входящего из-за пределов зарегистрированного региона, поддерживается проверкой подлинности на основе API между клиентами.
- Проверка подлинности федеративных учетных записей для пользователей, входящих из-за пределов зарегистрированного региона, поддерживается поиском на основе API между арендаторами
- Запрещает регистрацию из нескольких разных регионов
- Приложения в каждом регионе имеют набор конечных точек для подключения.
Проверка подлинности локальной учетной записи
Следующие варианты использования являются типичными в глобальной среде Azure AD B2C. Варианты использования локальных учетных записей также охватывают учетные записи, в которых перемещается пользователь. Каждый из них содержит схему и шаги рабочего процесса для каждого варианта использования.
Регистрация локального пользователя
Этот вариант использования демонстрирует, как пользователь из своей родной страны или региона выполняет регистрацию с помощью Azure AD локальной учетной записи B2C.
Пользователь из Европы, Ближнего Востока и Африки (EMEA) пытается зарегистрироваться на myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь пытается зарегистрироваться. Процесс регистрации проверяет глобальную таблицу подстановки, чтобы определить, существует ли пользователь в одном из региональных клиентов Azure AD B2C.
Пользователь не найден в глобальной таблице подстановки. Учетная запись пользователя записывается в Azure AD B2C, а запись создается в глобальной таблице подстановки для отслеживания региона, в котором пользователь зарегистрировалась.
Региональный клиент возвращает маркер в приложение.
Существующие попытки регистрации локального пользователя
В этом варианте использования показано, как пользователь, повторно зарегистрировав одно и то же сообщение электронной почты из своей страны или региона, блокируется.
Пользователь из EMEA пытается зарегистрироваться в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь пытается зарегистрироваться. Процесс регистрации проверяет глобальную таблицу подстановки, чтобы определить, существует ли пользователь в одном из региональных клиентов Azure AD B2C.
Адрес электронной почты пользователя находится в глобальной таблице подстановки, указывая, что пользователь зарегистрировал этот адрес электронной почты в решении на определенный момент времени.
У пользователя появится сообщение об ошибке, указывающее, что его учетная запись существует.
Вход локального пользователя
Этот вариант использования демонстрирует, как пользователь из своей родной страны или региона выполняет вход с помощью локальной учетной записи Azure AD B2C.
Пользователь из EMEA пытается войти в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь вводит свои учетные данные в региональном клиенте.
Региональный клиент выдает маркер обратно в приложение.
Пользователь вошел в приложение.
Вход путешествующих пользователей
Этот вариант использования демонстрирует, как пользователь может перемещаться по регионам и поддерживать свой профиль пользователя и учетные данные, хранящиеся в региональном клиенте, в связи с его регистрации.
Пользователь из Северная Америка (NOAM) пытается войти в myapp.fr, так как они находятся в отпуске во Франции. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь вводит свои учетные данные в региональном клиенте.
Региональный клиент выполняет поиск в глобальной таблице подстановки, так как электронная почта пользователя не найдена в каталоге emea Azure AD B2C.
Адрес электронной почты пользователя указан для регистрации в клиенте NOAM Azure AD B2C.
Клиент EMEA Azure AD B2C выполняет Microsoft Entra поток ROPC для клиента NOAM Azure AD B2C для проверки учетных данных.
Примечание
Этот вызов также получает маркер для выполнения API Graph вызова. Клиент EMEA Azure AD B2C выполняет API Graph вызов клиента NOAM Azure AD B2C для получения профиля пользователя. Этот вызов проходит проверку подлинности с помощью маркера доступа для API Graph, полученных на последнем шаге.
Региональный клиент выдает обратное приложение маркера.
Локальный пользователь забыл пароль
Этот вариант использования демонстрирует, как пользователь может сбросить пароль, если он находится в своей стране или регионе.
Пользователь из EMEA пытается войти в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь прибывает в клиент B2C Azure AD EMEA и выбирает забытый пароль. Пользователь вводит и проверяет свой адрес электронной почты.
Email выполняется поиск, чтобы определить, в каком регионе находится пользователь.
Пользователь предоставляет новый пароль.
Новый пароль записывается в клиент B2C Azure AD EMEA.
Региональный клиент возвращает маркер в приложение.
Путешествующий пользователь забыл пароль
В этом варианте использования показано, как пользователь может сбросить свой пароль, когда он уезжает из региона, в котором он зарегистрировал свою учетную запись.
Пользователь из NOAM пытается войти в myapp.fr, так как они находятся в отпуске во Франции. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь прибывает в клиент B2C Azure AD EMEA и выбирает забытый пароль. Пользователь вводит и проверяет свой адрес электронной почты.
Email выполняется поиск, чтобы определить, в каком регионе находится пользователь.
Сообщение электронной почты найдено в клиенте NOAM Azure AD B2C. Пользователь предоставляет новый пароль.
Новый пароль записывается в клиент NOAM Azure AD B2C с помощью вызова API Graph.
Региональный клиент возвращает маркер в приложение.
Изменение пароля локального пользователя
Этот вариант использования демонстрирует, как пользователь может изменить свой пароль после входа в регион, в котором он зарегистрировал свою учетную запись.
Пользователь из EMEA пытается изменить пароль после входа в myapp.fr.
Пользователь прибывает в клиент emea Azure AD B2C, а набор файлов cookie Single-Sign On (SSO) позволяет пользователю немедленно изменить свой пароль.
Новый пароль записывается в учетную запись пользователей в клиенте Azure AD B2C в EMEA.
Региональный клиент возвращает маркер в приложение.
Смена пароля перемещаемого пользователя
Этот вариант использования демонстрирует, как пользователь может изменить свой пароль после входа в систему вне региона, в котором он зарегистрировал свою учетную запись.
Пользователи из NOAM пытаются изменить пароль после входа в myapp.fr.
Пользователь прибывает в клиент emea Azure AD B2C, а набор файлов cookie единого входа позволяет пользователю немедленно изменить свой пароль.
Сообщение электронной почты пользователя находится в клиенте NOAM после проверки глобальной таблицы подстановки.
Новый пароль записывается в учетную запись пользователей в клиенте NOAM Azure AD B2C с помощью вызова MS API Graph.
Региональный клиент возвращает маркер в приложение.
Проверка подлинности федеративного поставщика удостоверений
В следующих вариантах использования показаны примеры использования федеративных удостоверений для регистрации или входа в качестве клиента Azure AD B2C.
Регистрация локального федеративного идентификатора
Этот вариант использования демонстрирует, как пользователь из своего локального региона регистрируется в службе с помощью федеративного идентификатора.
Пользователь из EMEA пытается зарегистрироваться в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь выбирает вход с помощью федеративного поставщика удостоверений.
Выполните поиск в глобальной таблице подстановки.
Если связывание учетной записи находится в область. Продолжайте, если идентификатор федеративного поставщика удостоверений или сообщение электронной почты, полученное от федеративного поставщика удостоверений, не существует в таблице подстановки.
Если связь с учетной записью не находится в область. Продолжайте, если идентификатор федеративного поставщика удостоверений, возвращенный федеративной поставщиком удостоверений, не существует в таблице подстановки.
Запишите учетную запись пользователя в клиент Azure AD B2C emea.
Региональный клиент возвращает маркер в приложение.
Вход локального федеративного пользователя
Этот вариант использования демонстрирует, как пользователь из своего локального региона входит в службу с помощью федеративного идентификатора.
Пользователь из EMEA пытается войти в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь выбирает вход с помощью федеративного поставщика удостоверений.
Выполните поиск в глобальной таблице подстановки и убедитесь, что федеративный идентификатор пользователя зарегистрирован в EMEA.
Региональный клиент возвращает маркер в приложение.
Перемещение федеративного входа пользователей
В этом сценарии показано, как пользователь, расположенный вдали от региона, в котором он зарегистрировался, выполняет вход в службу с помощью федеративного поставщика удостоверений.
Пользователь из NOAM пытается войти на myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь выбирает вход с помощью федеративного поставщика удостоверений.
Примечание
Используйте один и тот же идентификатор приложения из раздела Регистрация приложения в удостоверений социальных удостоверений во всех Azure AD региональных клиентах B2C. Это гарантирует, что идентификатор, возвращающийся из поставщика удостоверений социальных удостоверений, всегда будет одинаковым.
Выполните поиск в глобальной таблице подстановки и определите, что федеративный идентификатор пользователя зарегистрирован в NOAM.
Чтение данных учетной записи из клиента NOAM Azure AD B2C с помощью MS API Graph.
Региональный клиент возвращает маркер в приложение.
Связывание учетной записи с соответствующими критериями
В этом сценарии показано, как пользователи смогут выполнять связывание учетных записей при выполнении критерия соответствия (обычно это адрес электронной почты).
Пользователь из EMEA пытается войти в myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь выбирает вход с помощью федеративного поставщика удостоверений или поставщика удостоверений социальных сетей.
Поиск выполняется в глобальной таблице подстановки для идентификатора, возвращенного федеративного поставщика удостоверений.
Если идентификатор не существует, но сообщение электронной почты от федеративного поставщика удостоверений существует в EMEA Azure AD B2C, это сценарий связывания учетных записей.
Считывает пользователя из каталога и определяет, какие методы проверки подлинности включены в учетной записи. Создайте экран для входа пользователя с помощью существующего метода проверки подлинности в этой учетной записи.
Когда пользователь подтвердит, что он владеет учетной записью в Azure AD B2C, добавьте новый идентификатор социальной сети в существующую учетную запись и добавьте идентификатор социальной сети в учетную запись в глобальной таблице подстановки.
Региональный клиент возвращает маркер в приложение.
Связывание перемещаемой учетной записи пользователя с соответствующими критериями
В этом сценарии показано, как пользователи смогут выполнять связывание учетных записей, когда они будут находиться вдали от региона.
Пользователь из NOAM пытается войти на myapp.fr. Если пользователь не отправляется на локальное имя узла, диспетчер трафика принудительно применяет перенаправление.
Пользователь приземляется в клиенте EMEA.
Пользователь выбирает вход с помощью федеративного поставщика удостоверений или поставщика удостоверений социальных сетей.
Поиск выполняется в глобальной таблице подстановки для идентификатора, возвращенного федеративного поставщика удостоверений.
Если идентификатор не существует, а сообщение электронной почты от федеративного поставщика удостоверений существует в другом регионе, это сценарий связывания с перемещаемой учетной записью пользователя.
Создайте id_token_hint ссылку, утверждающую, что пользователи уже собрали утверждения. Начальная загрузка клиента NOAM Azure AD B2C с помощью федерации. Пользователь докажет, что он владеет учетной записью через клиент NOAM Azure AD B2C.
Примечание
Этот метод используется для повторного использования существующей логики связывания учетных записей в домашнем клиенте и уменьшения числа вызовов внешних API для управления коллекцией удостоверений. Пример настраиваемой политики, использующим id_token_hint, можно найти здесь.
Когда пользователь подтвердит, что он владеет учетной записью в Azure AD B2C, добавьте новый идентификатор социальной сети в существующую учетную запись, выполнив API Graph вызов в клиент NOAM Azure AD B2C. Добавьте идентификатор социальной сети в учетную запись в глобальной таблице подстановки.
Региональный клиент возвращает маркер в приложение.