Используйте Microsoft Entra MFA с внешним MFA поставщиком

В этой статье описывается, как внешний поставщик многофакторной проверки подлинности (MFA) подключается к Microsoft Entra MFA.

При авторизации пользователя оцениваются политики арендатора. Требования к проверке подлинности определяются на основе ресурса, к которому пользователь пытается получить доступ.

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

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

Администратор клиента добавляет внешние методы MFA в идентификатор Microsoft Entra. Если клиенту требуется внешний метод MFA, вход будет соответствовать требованиям Microsoft Entra MFA после того, как Microsoft Entra ID подтвердит оба условия.

  • Первый фактор был завершен с помощью идентификатора Microsoft Entra ID.
  • Второй фактор был завершен с использованием внешнего метода MFA.

Эта проверка соответствует требованию MFA для двух или нескольких типов методов:

  • То, что вы знаете (знания)
  • То, что у вас есть (владение)
  • То, что вы (врождённое)

Внешние методы MFA реализуются поверх OpenID Connect (OIDC). Эта реализация требует по крайней мере трех общедоступных конечных точек для реализации внешнего метода MFA:

Далее описан процесс входа с использованием внешнего метода MFA:

  1. Пользователь пытается войти с помощью первого фактора, например пароля, в приложение, защищенное идентификатором Microsoft Entra.

  2. Идентификатор Microsoft Entra определяет, что другой фактор должен быть удовлетворен (например, если для политики условного доступа требуется MFA).

  3. Пользователь выбирает внешний метод MFA в качестве второго фактора.

  4. Идентификатор Microsoft Entra перенаправляет сеанс браузера пользователя на URL-адрес внешнего метода MFA.

    Этот URL-адрес извлекается из обнаруженного URL-адреса, подготовленного администратором при настройке внешнего метода MFA.

    Приложение предоставляет истекший или почти истекший токен, содержащий сведения для идентификации пользователя и арендатора.

  5. Внешний поставщик MFA проверяет, получен ли маркер из идентификатора Microsoft Entra и проверяет содержимое маркера.

  6. Внешний поставщик MFA может вызвать Microsoft Graph, чтобы получить дополнительные сведения о пользователе.

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

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

  9. Microsoft Entra ID проверяет, что подпись токена предоставлена настроенным внешним поставщиком MFA, а затем проверяет содержимое токена.

  10. Идентификатор Microsoft Entra проверяет маркер в соответствии с требованиями.

  11. Если проверка выполнена успешно, это означает, что пользователь выполнил требование MFA. Кроме того, пользователю может потребоваться выполнить другие требования к политике.

Настройка нового внешнего поставщика MFA с помощью идентификатора Microsoft Entra

Чтобы выдать id_token_hint, для внешних методов MFA нужно приложение, представляющее интеграцию. Приложение можно создать двумя способами:

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

Использование мультитенантного приложения может снизить вероятность неправильной настройки в каждом клиенте. Поставщики также могут вносить изменения в метаданные (например, URL-адреса ответа в одном месте), а не требовать от каждого клиента вносить изменения.

Чтобы настроить мультитенантное приложение, администратор поставщика должен сначала:

  1. Создайте клиент идентификатора Microsoft Entra (если у них еще нет идентификатора).

  2. Зарегистрируйте приложение в клиенте.

  3. В приложении в разделе "Поддерживаемые типы учетных записей" выберите "Учетные записи" в любом каталоге организации (любой клиент Идентификатора Microsoft Entra — Multitenant).

  4. Добавьте значения делегированного разрешения openid и profile для Microsoft Graph.

  5. Не публикуйте ни одну область в этом приложении.

  6. Добавьте допустимые authorization_endpoint URL-адреса внешнего поставщика удостоверений в это приложение в качестве URL-адресов ответа.

    Примечание.

    При регистрации приложения добавьте указанное в документе обнаружения поставщика значение authorization_endpoint в качестве URL-адреса перенаправления. В противном случае вы получите следующую ошибку: "ENTRA IDSTS50161: не удалось проверить URL-адрес авторизации внешнего поставщика утверждений!"

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

Свойство Описание
Код объекта Поставщик может использовать идентификатор объекта с Microsoft Graph для запроса сведений о приложении.

Поставщик может использовать идентификатор объекта для программного извлечения и изменения сведений о приложении.
Идентификатор приложения Поставщик может использовать идентификатор приложения в качестве идентификатора клиента приложения.
URL-адрес домашней страницы URL-адрес домашней страницы поставщика ни для чего не используется, но его необходимо для регистрации приложения.
URL-адреса ответов Допустимые URL-адреса перенаправления для поставщика. Сопоставьте URL-адрес хоста поставщика, который был задан для арендатора поставщика. Один из зарегистрированных URL-адресов ответа должен соответствовать префиксу authorization_endpoint значения, извлекаемого идентификатором Microsoft Entra для URL-адреса узла с помощью обнаружения OIDC.

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

Примечание.

Необходимо согласие администратора для приложения в клиенте, использующего внешний метод MFA. Если вы не предоставляете согласие, при попытке администратора использовать внешний метод MFA возникает следующая ошибка: "AADSTS900491: субъект-служба <идентификатор приложения> не найден".

Настройка необязательных утверждений

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

Примечание.

Независимо от того, как создается приложение, поставщику необходимо настроить необязательные утверждения для каждой облачной среды. Если мультитенантное приложение используется для глобальной среды Azure и Azure для государственных организаций США, для каждой облачной среды требуется другой идентификатор приложения и приложения.

Добавление внешнего метода MFA в идентификатор Microsoft Entra

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

У каждого поставщика есть одна запись в объекте списка политики. Каждая запись должна указывать:

  • Если метод включен.
  • Включённые группы, которые имеют возможность использовать метод.
  • Исключенные группы, которые не могут использовать метод.

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

Узнайте больше о добавлении внешнего метода MFA в Центре администрирования Microsoft Entra.

Взаимодействие идентификатора Microsoft Entra с поставщиком

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

Обнаружение метаданных поставщика

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

URL-адрес обнаружения должен использовать схему https и должен заканчиваться /.well-known/openid-configuration. Вы не можете включать дополнительные сегменты пути, строки запроса или фрагменты после этого сегмента. Полный URL-адрес обнаружения должен быть включен в URL-адрес, который вы настраиваете при создании внешнего метода аутентификации MFA.

Конечная точка возвращает документ JSON метаданных поставщика, размещенный там. Конечная точка также должна возвращать допустимый заголовок длины содержимого. Документ метаданных должен соответствовать openID Connect Discovery 1.0 (включая набор 2 errata) и включать все необходимые поля метаданных OIDC.

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

Сведения о документе OIDC с значениями метаданных поставщика см. в разделе метаданных поставщика.

Значение метаданных Значение Комментарии
Issuer Должен быть HTTPS-URL.

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

Издатель может включать порт или сегмент пути, но не должен содержать параметры запроса или идентификаторы фрагментов.
authorization_endpoint Конечная точка, с которой связывается Microsoft Entra ID для авторизации. Эта конечная точка должна присутствовать в качестве одного из URL-адресов ответа для разрешенных приложений.
jwks_uri Расположение, в котором идентификатор Microsoft Entra может найти открытые ключи, необходимые для проверки подписей, выданных поставщиком. jwks_uri быть конечной точкой HTTPS и не должен включать параметры запроса или идентификаторы фрагментов.

Параметр веб-ключа JSON (JWK) x5c должен присутствовать для предоставления представлений предоставленных ключей X.509.
scopes_supported openid Другие значения также могут быть включены, но не являются обязательными.
response_types_supported id_token Другие значения также могут быть включены, но не являются обязательными.
subject_types_supported
id_token_signing_alg_values_supported Корпорация Майкрософт поддерживает RS256.
claim_types_supported normal Это свойство является необязательным, но если оно присутствует, оно должно содержать normal значение. Другие значения также могут быть включены. 
https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Примечание.

Параметр JWK x5c должен присутствовать для предоставления представлений указанных ключей X.509.

Примеры URL-адреса обнаружения и издателя

В следующих примерах показаны допустимые и недопустимые сочетания URL-адреса обнаружения и издателя для этой интеграции.

Допустимые пары URL-адреса обнаружения и издателя
  • URL-адрес обнаружения: https://example.com/.well-known/openid-configuration
    Эмитент: https://example.com
  • URL-адрес обнаружения: https://example.com:8443/.well-known/openid-configuration
    Эмитент: https://example.com:8443
  • URL-адрес обнаружения: https://example.com/tenant1/.well-known/openid-configuration
    Эмитент: https://example.com/tenant1
Недопустимые примеры URL-адреса обнаружения и издателя
  • URL-адрес обнаружения: https://example.com/.well-known/openid-configuration
    Издатель: https://example.com:443/ (порт HTTPS по умолчанию явно добавлен в издателе.)
  • URL-адрес обнаружения: https://example.com:443/.well-known/openid-configuration
    Издатель: https://example.com/ (несоответствие портов.)
  • URL-адрес обнаружения: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
    Издатель: https://example.com (Невозможно включить строку запроса в URL-адрес обнаружения.)

Кэширование метаданных поставщика

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

Этот кэш обновляется каждые 24 часа. Мы рекомендуем поставщикам выполнить следующие действия, чтобы обновить ключи.

  1. Опубликуйте существующий сертификат и новый сертификатjwks_uri.
  2. Продолжайте входить с существующим сертификатом, пока кэш идентификатора Microsoft Entra не обновится, не истечет срок его действия или он не будет обновлен (каждые 2 дня).
  3. Переключитесь на вход с помощью New Cert.

Мы не публикуем расписания смены ключей шифрования. Зависимая служба должна быть готова обрабатывать как немедленные, так и периодические переключения. Мы рекомендуем использовать выделенную библиотеку, созданную для этой цели, например azure-activedirectory-identitymodel-extensions-for-dotnet. Дополнительные сведения см. в разделе Смена ключа подписи в Microsoft Entra ID.

Обнаружение метаданных идентификатора Microsoft Entra

Поставщики также должны получить открытые ключи идентификатора Microsoft Entra, чтобы проверить маркеры, выданные идентификатором Microsoft Entra.

Конечные точки обнаружения метаданных идентификатора Microsoft Entra ID:

  • Глобальная служба Azure: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
  • Azure для государственных организаций США: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
  • Microsoft Azure, управляемый 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Идентификатор открытого ключа из маркера ("kid" из JSON Web Signature (JWS)) можно использовать для определения того, какой из ключей, полученных из свойства jwks_uri должен использоваться для проверки подписи токена Microsoft Entra ID.

Проверка токенов, выданных Microsoft Entra ID

Сведения о том, как проверить маркеры, выданные идентификатором Microsoft Entra, см. в разделе "Проверка маркера идентификатора". Для потребителей наших метаданных обнаружения нет специальных шагов.

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

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

Примечание.

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

Вызов Microsoft Entra ID к внешнему провайдеру удостоверений

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

Чтобы сообщить поставщику о пользователе, для которого Microsoft Entra ID выполняет запрос, Microsoft Entra ID передает токен через параметр id_token_hint.

Этот вызов выполняется через POST запрос, так как большой список параметров передается поставщику. Большой список предотвращает использование браузеров, ограничивающих длину GET запроса.

Параметры запроса проверки подлинности перечислены в следующей таблице.

Примечание.

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

Параметр запроса проверки подлинности Значение Описание
scope openid
response_type Id_token Значение, используемое для неявного потока.
response_mode form_post Мы используем форму POST , чтобы избежать проблем с большими URL-адресами. Мы ожидаем, что все параметры будут отправлены в тексте запроса.
client_id Идентификатор клиента, предоставленный Microsoft Entra ID поставщиком внешних удостоверений, например ABCD. Более подробную информацию см. в описании MFA внешнего метода.
redirect_uri Универсальный код ресурса перенаправления (URI), в который внешний поставщик удостоверений отправляет ответ (id_token_hint). См. пример после этой таблицы.
nonce Случайная строка, созданная идентификатором Microsoft Entra. Это может быть идентификатор сеанса. Если это указано, его необходимо вернуть в ответе на идентификатор Microsoft Entra.
state При передаче данных поставщик должен вернуть state в своем ответе. Microsoft Entra ID использует state для поддержания контекста вызова.
id_token_hint Токен, который идентификатор Microsoft Entra выдает для пользователя и передаётся для выгоды поставщика.
claims Большой двоичный объект JSON, содержащий запрошенные утверждения. Дополнительные сведения о формате этого параметра см. в параметре запроса утверждений из документации OIDC и примере после этой таблицы.
client-request-id Значение глобального уникального идентификатора (GUID) Поставщик может регистрировать это значение, чтобы помочь устранить неполадки.

Пример URI перенаправления

URI перенаправления должны быть зарегистрированы у поставщика вне основного канала. Адреса перенаправления URI, которые вы можете отправить, следующие:

  • Глобальная служба Azure: https://login.microsoftonline.com/common/federation/externalauthprovider
  • Azure для государственных организаций США: https://login.microsoftonline.us/common/federation/externalauthprovider
  • Microsoft Azure, управляемый 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Пример внешнего метода MFA, удовлетворяющего MFA

Ниже приведен пример того, где внешний метод MFA удовлетворяет требованиям MFA. Этот пример помогает поставщику узнать, какие запросы ожидает Microsoft Entra ID.

Идентификатор Microsoft Entra использует сочетание значений acr и amr для проверки того, что:

  • Метод проверки подлинности, используемый для второго фактора, соответствует требованию MFA.
  • Метод проверки подлинности отличается типом от того, который используется для завершения первого фактора при входе в Microsoft Entra ID.
{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Утверждения id_token_hint по умолчанию

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

Утверждение Значение Описание
iss Определяет службу маркеров безопасности (STS), которая создает и возвращает маркер, а также клиент Идентификатора Microsoft Entra, в котором пользователь прошел проверку подлинности.

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

Издатель должен соответствовать URL-адресу издателя из метаданных JSON обнаружения OIDC для клиента, в котором пользователь выполнил вход.
aud Аудитория должна быть настроена на идентификатор клиента внешнего поставщика удостоверений для Microsoft Entra ID.
exp Срок действия истекает через короткое время после выдачи, достаточно, чтобы избежать проблем с отклонением времени. Поскольку этот токен не предназначен для проверки подлинности, нет причин для его действия, чтобы намного пережить запрос.
iat Задайте время выдачи как обычно.
tid Идентификатор клиента предназначен для рекламы клиента поставщику. Он представляет клиент Идентификатора Microsoft Entra, из которому находится пользователь.
oid Неизменяемый идентификатор объекта в платформе идентификации Microsoft. В этом случае это учетная запись пользователя. Его также можно использовать для безопасного выполнения проверок авторизации и в качестве ключа в таблицах базы данных.

Этот идентификатор однозначно идентифицирует пользователя в приложениях. Два разных приложения, которые авторизуют одного и того же пользователя, получают одно и то же значение в требовании oid. Таким образом, oid утверждение можно использовать в запросах к веб-службам Майкрософт, таким как Microsoft Graph.
preferred_username Предоставляет удобочитаемое значение, определяющее объект токена. Это значение не гарантируется уникальным в рамках клиента и предназначено только для отображения.
sub Идентификатор субъекта для пользователя у эмитента. Субъект, в отношении которого маркер утверждает сведения, например данные о пользователе приложения.

Это значение является неизменяемым и не может быть переназначено или повторно использовано. Его можно использовать для безопасного выполнения проверок авторизации, например, когда маркер используется для доступа к ресурсу. Его можно использовать в качестве ключа в таблицах баз данных.

Поскольку субъект всегда присутствует в токенах, выпускаемых Microsoft Entra ID, рекомендуется использовать это значение в системе авторизации общего назначения. Субъект, однако, является парным идентификатором и уникален для конкретного ID приложения.

Таким образом, если один пользователь входит в два разных приложения с помощью двух разных идентификаторов клиента, эти приложения получают два разных значения для утверждения субъекта.

Этот результат может потребоваться или не требуется в зависимости от ваших требований к архитектуре и конфиденциальности.

См. также oid утверждение (которое остается неизменным в приложениях в клиенте).

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

Необязательные утверждения из идентификатора Microsoft Entra

Если поставщику требуются необязательные утверждения из идентификатора Microsoft Entra, можно настроить следующие необязательные утверждения для id_token: given_name, family_name, preferred_username. upn Дополнительные сведения см. в разделе "Необязательные утверждения".

Рекомендуется связать учетные записи на стороне поставщика с учетной записью в Azure с помощью утверждений oid и tid. Эти два утверждения гарантированно будут уникальными для учетной записи в арендаторе.

Пример id_token_hint

Ниже приведен пример id_token_hint элемента каталога:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Вот пример id_token_hint для гостевого пользователя в тенанте.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Предлагаемые действия для внешних поставщиков удостоверений

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

  • Из запроса:

    • Убедитесь, что redirect_uri опубликован, как описано в запросе Microsoft Entra ID к внешнему поставщику удостоверений.
    • Убедитесь, что настроенный URL-адрес обнаружения использует HTTPS и заканчивается /.well-known/openid-configuration. Кроме того, убедитесь, что он не включает параметры запроса или идентификаторы фрагментов. Убедитесь, что значение издателя точно соответствует документу идентификации.
    • Убедитесь, что элемент client_id имеет значение, назначенное для Microsoft Entra ID, например ABCD.
    • Поставщик должен сначала проверитьid_token_hint, представлен ли ему идентификатор Microsoft Entra.

  • Из утверждений в id_token_hint:

    • (Необязательно) Вызов Microsoft Graph для получения других сведений об этом пользователе. Утверждения oid и tid в id_token_hint полезны в этом отношении. Дополнительные сведения о утверждениях, предоставленных в id_token_hint, см. в разделе "Утверждения по умолчаниюid_token_hint".

  • Выполните любое другое действие проверки подлинности для продукта поставщика.

  • В зависимости от результатов действий пользователя и других факторов поставщик будет создавать и отправлять ответ обратно в идентификатор Microsoft Entra, как описано в следующем разделе.

Обработка ответа поставщика идентификатором Microsoft Entra

Поставщику необходимо использовать POST для отправки ответа обратно в redirect_uri. Следующие параметры должны быть предоставлены в успешном ответе:

Параметр Значение Описание
id_token Токен, который выдает внешний поставщик удостоверений.
state То же состояние, которое было передано в запросе, если имеется. В противном случае это значение не должно присутствовать.

При успешном выполнении поставщик будет выдавать id_token значение для пользователя. Идентификатор Microsoft Entra использует опубликованные метаданные OIDC, чтобы убедиться, что маркер содержит ожидаемые утверждения и выполняет любую другую проверку маркера, требуемую OIDC.

Утверждение Значение Описание
iss Издатель: должен соответствовать издателю в метаданных обнаружения поставщика.
aud Аудитория: идентификатор клиента Microsoft Entra ID. Просмотрите client_id в вызове Microsoft Entra ID к внешнему поставщику идентификации.
exp Время окончания срока действия: задано как обычное.
iat Время выдачи: задано как обычно.
sub Предмет: должен соответствовать sub, указанному в id_token_hint, отправленном для инициирования этого запроса.
nonce То же nonce значение, которое было передано в запросе.
acr acr Требования для запроса аутентификации. Это значение должно соответствовать одному из значений из запроса, отправленного для запуска этого запроса. Возвращается только одно acr утверждение. Список утверждений см. в разделе "Поддерживаемые acr утверждения".
amr Утверждения о методе аутентификации, который используется. Это значение должно быть возвращено в виде массива, и возвращается только одно утверждение метода. Список утверждений см. в разделе "Поддерживаемые amr утверждения".
Поддерживаемые претензии ACR
Утверждение Примечания.
possessionorinherence Проверка подлинности должна использовать фактор, основанный на владении или человеческих качествах.
knowledgeorpossession Проверка подлинности должна использовать фактор на основе знаний или владения.
knowledgeorinherence Проверка подлинности должна использовать фактор на основе знаний или факторов, связанных с принадлежностью.
knowledgeorpossessionorinherence Проверка подлинности должна использовать фактор на основе знаний, владения или наследования.
knowledge Проверка подлинности должна использовать фактор на основе знаний.
possession Проверка подлинности должна использовать фактор на основе владения.
inherence Проверка подлинности должна использовать фактор, основанный на угерентности.
Поддерживаемые утверждения AMR
Утверждение Примечания.
face Биометрические данные с распознаванием лиц
fido Используется FIDO2
fpt Биометрия с отпечатком пальца
hwk Подтверждение владения аппаратным ключом
iris Биометрия со сканированием радужной оболочки
otp Одноразовый пароль
pop Подтверждение принадлежности
retina Биометрия сканирования сетчатки
sc Смарт-карта
sms Подтверждение по SMS на зарегистрированный номер
swk Подтверждение наличия программно защищенного ключа
tel Подтверждение по телефону
vbm Биометрия с голосовой печатью

Microsoft Entra ID требует, чтобы требования MFA были выполнены для выдачи токена с подтверждением MFA. В результате только методы с другим типом могут удовлетворять второму требованию фактора. Как упоминалось ранее, различные типы методов, которые можно использовать для удовлетворения второго фактора, являются знаниями, владением и наследностью.

Идентификатор Microsoft Entra проверяет сопоставление типов на основе следующей таблицы.

Метод утверждения Тип Примечания.
face Наследность Биометрические данные с распознаванием лиц.
fido Владение Используется FIDO2. Для некоторых реализаций также может потребоваться биометрические данные, но тип метода владения сопоставляется, так как это основной атрибут безопасности.
fpt Наследность Биометрия с использованием отпечатков пальцев.
hwk Владение Подтверждение владения аппаратным ключом.
iris Наследность Биометрические данные со сканированием радужной оболочки.
otp Владение Одноразовый пароль.
pop Владение Подтверждение владения.
retina Наследность Биометрическое сканирование сетчатки.
sc Владение Смарт-карта.
sms Владение Подтверждение по СМС на зарегистрированный номер.
swk Владение Подтверждение наличия программно защищенного ключа.
tel Владение Подтверждение по телефону.
vbm Наследность Биометрические данные с голосовым отпечатком.

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

Сбой указывается путем выдачи параметров ответа на ошибку.

Параметр Значение Описание
Ошибка Код ошибки ASCII, например access_denied или temporarily_unavailable

Microsoft Entra ID считает запрос успешным, если в ответе присутствует id_token parameter, и токен действителен. В противном случае запрос считается неудачным. Microsoft Entra ID завершает первоначальную попытку аутентификации с ошибкой из-за выполнения требования политики условного доступа.

Идентификатор Microsoft Entra сбрасывает состояние попытки аутентификации со своей стороны примерно через 5 минут после перенаправления к провайдеру.

Обработка ошибок ответов Microsoft Entra ID

Службы Microsoft Azure используют correlationId значение для сопоставления вызовов между различными внутренними и внешними системами. Он служит общим идентификатором всей операции или потока, который потенциально включает несколько HTTP-вызовов. При возникновении ошибки во время любой операции ответ содержит поле с именем Идентификатор корреляции.

Если вы обратитесь в службу поддержки Майкрософт или аналогичную службу, укажите значение идентификатора корреляции . Она помогает быстрее получать доступ к данным телеметрии и журналам.

Например:

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Пользовательские элементы управления и внешние методы многофакторной аутентификации (MFA)

В Microsoft Entra ID внешние методы MFA и пользовательские элементы управления условным доступом могут работать параллельно, пока клиенты готовятся к переходу и миграции на внешние методы MFA.

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

  • Политики должны использовать элемент управления "Требовать многофакторную проверку подлинности " вместо пользовательского элемента управления.

    Примечание.

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

  • Новая политика может быть проверена сначала с подмножеством пользователей. Тестовая группа исключена из политики, требующей пользовательских элементов управления, и включена в политику, требующую многофакторной проверки подлинности. Если администратору удобно, чтобы политика, требующая MFA, удовлетворяется внешним методом MFA, администратор может включить всех необходимых пользователей в политику с предоставлением MFA. Политика, настроенная для пользовательских элементов управления, может быть перемещена в параметр Off .

Поддержка интеграции

Если при создании внешней интеграции метода MFA с идентификатором Microsoft Entra ID возникают проблемы, независимый поставщик решений (ISV) Microsoft Customer Experience Engineering (CxE) может помочь. Чтобы связаться с командой поставщика программного обеспечения CxE, отправьте запрос на помощь.

Ссылки

Глоссарий

Срок Описание
МИД Многофакторная проверка подлинности.
Внешний метод MFA Метод проверки подлинности от поставщика, отличного от идентификатора Microsoft Entra, который используется в рамках проверки подлинности пользователя.
OIDC OpenID Connect — это протокол проверки подлинности на основе OAuth 2.0.
00001111-aaaa-2222-bbbb-3333cccc4444 Пример значения appid, интегрированного с внешним методом MFA.

Связанный контент

  • Last updated on