Общие сведения о расширениях пользовательской проверки подлинности

Конвейер проверки подлинности Идентификатора Microsoft Entra состоит из нескольких встроенных событий проверки подлинности, таких как проверка учетных данных пользователя, политики условного доступа, многофакторная проверка подлинности, самостоятельный сброс пароля и многое другое.

Пользовательские расширения проверки подлинности Microsoft Entra позволяют расширить потоки проверки подлинности с помощью собственной бизнес-логики в определенных точках в потоке проверки подлинности. Расширение пользовательской проверки подлинности по сути является прослушивателем событий, который при активации выполняет http-вызов к конечной точке REST API, в которой определяется действие рабочего процесса.

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

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

Обзор компонентов

Необходимо настроить два компонента: пользовательское расширение проверки подлинности в Microsoft Entra и REST API. Пользовательское расширение проверки подлинности указывает конечную точку REST API, время вызова REST API и учетные данные, необходимые для его вызова.

Это видео содержит подробные инструкции по настройке расширений пользовательской проверки подлинности Microsoft Entra и предлагает рекомендации и полезные советы по оптимальной реализации.

Процесс входа

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

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

  1. Пользователь пытается войти в приложение и перенаправляется на страницу входа в Microsoft Entra.
  2. После завершения определенного шага проверки подлинности активируется прослушиватель событий.
  3. Ваше пользовательское расширение проверки подлинности отправляет HTTP-запрос в вашу конечную точку REST API. Запрос содержит сведения о событии, профиле пользователя, данных сеанса и других контекстных данных.
  4. REST API выполняет настраиваемый рабочий процесс.
  5. REST API возвращает HTTP-ответ на идентификатор Microsoft Entra.
  6. Расширение пользовательской проверки подлинности Microsoft Entra обрабатывает ответ и настраивает проверку подлинности на основе типа события и данных полезной нагрузки HTTP-ответа.
  7. Маркер возвращается в приложение.

Конечные точки REST API

При активации события идентификатор Microsoft Entra вызывает конечную точку REST API, которую вы владеете. REST API должен быть общедоступным. Его можно разместить с помощью Функций Azure, Службы приложений Azure, Azure Logic Apps или другой общедоступной конечной точки API.

Вы можете использовать любой язык программирования, платформу или решение с низким кодом без кода, например Azure Logic Apps для разработки и развертывания REST API. Чтобы быстро приступить к работе, рассмотрите возможность использования функции Azure. Он позволяет запускать код в бессерверной среде, не создавая виртуальную машину или публикуя веб-приложение.

REST API должен обрабатывать следующее:

Просмотрите это видео, чтобы узнать, как создать конечную точку REST API расширений проверки подлинности с помощью Azure Logic Apps без написания кода. Приложение логики Azure позволяет пользователям создавать рабочие процессы с помощью визуального конструктора. Видео охватывает настройку сообщений электронной почты проверки и применяется ко всем типам пользовательских расширений проверки подлинности, включая пользовательских поставщиков утверждений.

Тело запроса

Запрос к REST API включает полезные данные JSON, содержащие сведения о событии, профиле пользователя, данных запроса проверки подлинности и других контекстных данных. Атрибуты полезных данных JSON можно использовать для выполнения логики через ваш API.

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

Возврат данных и типа действия

После того как веб-API выполняет рабочий процесс с вашей бизнес-логикой, он обязан вернуть тип действия, который указывает Microsoft Entra, как продолжить процесс аутентификации.

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

Ответ REST API может включать данные. Например, событие начала выдачи токена может предоставить набор атрибутов, которые можно сопоставить с токеном безопасности.

Защита REST API

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

  1. Когда расширение пользовательской проверки подлинности вызывает REST API, оно отправляет заголовок HTTP Authorization с токеном доступа, выданным Microsoft Entra ID.
  2. Маркер носителя содержит претензию appid или azp. Проверьте, что соответствующее утверждение содержит значение 99045fe1-7639-4a75-9d4a-577b6ca3810f. Это значение гарантирует, что идентификатор Microsoft Entra — это тот, кто вызывает REST API.
    1. Для приложений версии 1 проверьте appid утверждение.
    2. Для приложений версии 2 проверьте azp утверждение.
  3. Утверждение "audience" токена aud содержит идентификатор связанной регистрации приложения. Конечная точка REST API должна проверить, выдан ли токен носителя для этой конкретной аудитории.
  4. Утверждение издателя токена-носителя iss содержит URL-адрес издателя Microsoft Entra. В зависимости от конфигурации клиента URL-адрес издателя является одним из следующих.
    • Рабочая сила: https://login.microsoftonline.com/{tenantId}/v2.0.
    • Клиент: https://{domainName}.ciamlogin.com/{tenantId}/v2.0.

Настраиваемые типы событий проверки подлинности

В этом разделе перечислены события настраиваемых расширений проверки подлинности, доступные в рабочей силе и внешних арендаторах Microsoft Entra ID. Подробные сведения о событиях см. в соответствующей документации.

Событие Арендатор рабочей силы Внешний арендатор
Начало выдачи токена
Начало коллекции атрибутов
Отправка коллекции атрибутов
Однократная отправка секретного кода
Восстановление учетной записи (дополнительная проверка утверждений)

Начало выдачи токена

Событие начала выпуска токена OnTokenIssuanceStart активируется, когда токен готовится к выдаче приложению. Это тип события, который настраивается в пользовательском поставщике утверждений. Поставщик пользовательских утверждений — это пользовательское расширение проверки подлинности, которое вызывает REST API для получения утверждений из внешних систем. Настраиваемый поставщик утверждений сопоставляет утверждения из внешних систем с маркерами и может быть назначен одному или нескольким приложениям в каталоге.

Начало коллекции атрибутов

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

Отправка коллекции атрибутов

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

Однократная отправка секретного кода

Событие OnOtpSend вызывается при отправке одноразового кода доступа по электронной почте. Он позволяет вызывать REST API для использования собственного поставщика электронной почты. Это событие можно использовать для отправки настраиваемых сообщений электронной почты пользователям, которые регистрируются с помощью адреса электронной почты, войдите с помощью единовременного секретного кода (EMAIL OTP), сбросите пароль с помощью OTP электронной почты или используйте email OTP для многофакторной проверки подлинности (MFA).

При активации события OnOtpSend Microsoft Entra отправляет одноразовый пароль в указанный вами REST API. Затем REST API использует выбранного поставщика электронной почты, такого как Служба коммуникации Azure или SendGrid, чтобы отправить одноразовый секретный код с вашим пользовательским шаблоном электронной почты, а также указать адрес отправителя и тему письма, поддерживая при этом локализацию.

Восстановление учетной записи (дополнительная проверка утверждений)

Событие OnVerifiedIdClaimValidation активируется во время восстановления учетной записи, когда пользователь представляет утверждения проверенного идентификатора для подтверждения их личности. Основная причина использования настраиваемого расширения проверки подлинности для восстановления учетной записи заключается в том, чтобы убедиться, что пользователь, запрашивающий восстановление, является фактическим сотрудником, а не только допустимым человеком. Когда пользователь представляет свой проверенный идентификатор, Microsoft Entra передает утверждения из учетных данных в пользовательское расширение проверки подлинности. Затем ваш REST API может сравнить эти утверждения с авторитетным источником данных, например системой управления персоналом или базой данных записей сотрудников, и вернуть решение о прохождении или отказе.

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

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

Связанное содержимое

  • Last updated on