Поделиться через


Маршруты пользователей и пользовательские политики

В Azure AD B2C вы можете определить бизнес-логику, которой следуют пользователи, чтобы получить доступ к вашему приложению. Например, вы можете определить последовательность действий, выполняемых пользователями при входе в систему, регистрации, редактировании профиля или сбросе пароля. После завершения последовательности пользователь получает токен и получает доступ к вашему приложению.

В Azure AD B2C есть два способа предоставить пользователям идентификационные данные:

  • Потоки пользователей — это встроенные предопределенные политики с возможностью настройки, которые позволят вам за несколько минут организовать процессы для регистрации, входа и редактирования политик.

  • Настраиваемые политики позволяют создавать собственные пути взаимодействия пользователей для сложных сценариев взаимодействия с удостоверениями, которые не поддерживаются потоками пользователей. Azure AD B2C использует настраиваемые политики для обеспечения расширяемости.

На следующем снимке экрана показан пользовательский интерфейс параметров маршрута пользователей в сравнении с файлами конфигурации настраиваемой политики.

Снимок экрана: пользовательский интерфейс параметров потока пользователя и файлы конфигурации настраиваемой политики.

Из этой статьи вы получите представление о маршрутах пользователей и настраиваемых политиках, а также сможете решить, какой метод лучше всего подойдет для вашего бизнеса.

Маршруты пользователей

Чтобы вы могли быстро разрешить наиболее распространенные задачи идентификации, на портале Azure предоставляются несколько предопределенных настраиваемых политик, которые называются маршрутами пользователей.

Для них вы можете настроить некоторые параметры, чтобы управлять поведением приложений при работе с удостоверениями:

  • типы учетных записей, используемые для входа в систему, такие как учетные записи социальных сетей, например Facebook, или локальные учетные записи с адресами электронной почты и паролями для входа;
  • атрибуты, которые нужно получить от пользователя, например имя, почтовый индекс и страна или регион проживания;
  • Microsoft Entra многофакторной проверки подлинности
  • настройка пользовательского интерфейса;
  • набор утверждений в маркере, который получает приложение после того, как пользователь завершит поток пользователя;
  • Управление сеансом
  • и прочее

Большинство распространенных сценариев идентификации для приложений можно определить и эффективно реализовать с помощью маршрутов пользователей. Мы рекомендуем использовать встроенные маршруты пользователей, если не предполагается сложных сценариев взаимодействия с пользователями, требующих полной гибкости настраиваемых политик.

Пользовательские политики

Пользовательские политики — это файлы конфигурации, которые определяют поведение вашего клиента Azure AD B2C. Для самых распространенных задач идентификации на портале Azure AD B2C заданы маршруты пользователей. Пользовательские политики, в свою очередь, могут быть полностью изменены разработчиком удостоверений для выполнения множества разнообразных задач.

Пользовательская политика является полностью настраиваемой и управляется на основе политик. Она управляет отношениями доверия между сущностями в стандартных протоколах, таких как OpenID Connect, OAuth, SAML, и нескольких нестандартных, например обмен утверждениями между системами на основе REST API. Эта платформа обеспечивает удобные и доступные возможности для пользователей.

Пользовательская политика дает возможность создавать пути взаимодействия пользователя с любым сочетанием шагов. Пример:

  • Федерация с другими поставщиками удостоверений.
  • Вызовы первой и третьей сторонней многофакторной проверки подлинности
  • Получение данных, вводимых пользователем.
  • Интеграция с внешними системами через интерфейсы REST API.

Каждый путь взаимодействия пользователя определяется политикой. Вы можете создать любое количество политик (максимальное или минимальное), чтобы обеспечить лучшее взаимодействие с пользователем для вашей организации.

Схема со сложным примером пути взаимодействия пользователя на основе Identity Experience Framework

Пользовательская политика определяется несколькими XML-файлами, которые ссылаются друг на друга в иерархической цепочке. XML-элементы определяют схему утверждений, преобразования утверждений, определения содержимого, поставщиков утверждений, технические профили, шаги оркестрации в пути взаимодействия пользователя и другие элементы для работы с удостоверениями.

Высокая гибкость настраиваемых политик лучше всего подходит для случаев, когда вам нужно создать сложные сценарии идентификации. Разработчики, которые настраивают пользовательские политики, должны точно и подробно определить отношения доверия, чтобы добавить конечные точки метаданных, точные определения обмена утверждениями и настроить секретные данные, ключи и сертификаты, отличающиеся в зависимости от поставщика удостоверений.

Дополнительные сведения см. в статье Пользовательские политики в Azure Active Directory B2C.

Сравнение потоков пользователей и пользовательских политик

В следующей таблице приводится подробное сравнение разных сценариев, которые можно реализовать с помощью маршрутов пользователей Azure AD B2C и пользовательских политик.

Контекст Маршруты пользователей Пользовательские политики
Целевые пользователи Все разработчики приложений имеют или не имеют опыт работы с удостоверениями. Специалисты по удостоверениям, системные интеграторы, консультанты и внутренние команды по работе с удостоверениями. Они знакомы с потоками OpenID Connect, поставщиками удостоверений и аутентификацией на основе утверждений.
Метод настройки Портал Azure с удобным пользовательским интерфейсом. Непосредственное изменение XML-файлов и их отправка на портал Azure.
Настройка пользовательского интерфейса Полная настройка пользовательского интерфейса, включая HTML, CSS и JavaScript.

Поддержка нескольких языков для пользовательских строк.
Аналогично маршрутам пользователей
Настройка атрибутов Стандартные и пользовательские атрибуты. Аналогично маршрутам пользователей
Управление токенами и сеансами Настройка токенов и поведения сеансов. Аналогично маршрутам пользователей
Поставщики удостоверений Предопределенный локальный поставщик или поставщик социальных сетей, например федерация с клиентами Microsoft Entra. OIDC, SAML, OAuth в соответствии со стандартами. Аутентификация также возможна благодаря интеграции с REST API.
Задачи, связанные с удостоверениями Регистрация или вход в систему с помощью локальных учетных записей или учетных записей разных социальных сетей.

Самостоятельный сброс пароля.

Изменение профиля.

Многофакторная проверка подлинности.

Потоки маркера доступа.
Выполняют те же задачи, что и потоки пользователей, с помощью пользовательских поставщиков удостоверений или настраиваемых областей.

Подготовка учетной записи пользователя в другой системе во время регистрации.

Отправка приветственного сообщения почты с помощью поставщика услуг электронной почты.

Использование пользовательского хранилища за пределами Azure AD B2C.

Проверка предоставленной пользователями информации с помощью доверенной системы с использованием API.

Интеграция приложений

В своем клиенте вы можете создать множество маршрутов пользователей различных типов и при необходимости использовать их в приложениях. Как маршруты пользователей, так и пользовательские политики можно повторно использовать в разных приложениях. Такая гибкость позволяет определять и изменять процесс идентификации, внося лишь незначительные изменения в код или совсем не изменяя его.

Когда пользователь пытается войти в приложение, оно направляет запрос авторизации в пользовательскую конечную точку, которая представляет собой поток пользователя или пользовательскую политику. Соответствующий поток пользователей или пользовательская политика определяют и контролируют взаимодействие с пользователем. Когда завершится пользовательский маршрут регистрации, Azure AD B2C создаст токен и перенаправит пользователя обратно в приложение.

Мобильное приложение, для которого стрелками обозначен поток через страницу входа Azure AD B2C

Один поток пользователя или одна пользовательская политика могут применяться в нескольких приложениях. Одно приложение может использовать несколько потоков пользователей и (или) настраиваемых политик.

Например, приложение использует поток для регистрации или входа пользователей в систему. После входа пользователям, возможно, потребуется изменить информацию профиля. В этом случае приложение инициирует другой запрос авторизации через маршрут пользователя для изменения профиля.

Приложение запускает маршрут пользователя с помощью стандартного HTTP-запроса на проверку подлинности, содержащего параметры маршрута пользователя или имя пользовательской политики. Настраиваемый токен возвращается в качестве ответа.

Следующие шаги