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


Справочник по поставщику внешних методов многофакторной проверки подлинности Microsoft Entra (предварительная версия)

В этом разделе описывается, как внешний поставщик проверки подлинности подключается к многофакторной проверке подлинности (MFA) Microsoft Entra. Внешний поставщик проверки подлинности может интегрироваться с клиентами Идентификатора Microsoft Entra в качестве внешнего метода проверки подлинности (EAM). EAM может удовлетворить второй фактор требования MFA для доступа к ресурсу или приложению. Для использования систем управления корпоративными активами (EAM) требуется по крайней мере лицензия Microsoft Entra ID P1.

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

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

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

EAM добавляются в Microsoft Entra ID администратором тенанта. Если тенанту требуется EAM для многофакторной аутентификации (MFA), то вход считается соответствующим требованию MFA после того, как Microsoft Entra ID проверит оба условия:

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

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

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

EAMs реализованы на базе Open ID Connect (OIDC). Эта реализация требует по крайней мере трех общедоступных конечных точек:

Давайте подробнее рассмотрим, как работает авторизация в системе EAM.

  1. Пользователь пытается войти с помощью первого фактора, например пароля, в приложение, защищенное идентификатором Microsoft Entra.
  2. Идентификатор Microsoft Entra определяет, что необходимо выполнить другой фактор. Например, для политики условного доступа требуется многофакторная аутентификация.
  3. Пользователь выбирает EAM в качестве второго фактора.
  4. Идентификатор Microsoft Entra перенаправляет сеанс браузера пользователя на URL-адрес EAM:
    1. Этот URL-адрес обнаруживается по URL-адресу обнаружения, подготовленному администратором при создании EAM.
    2. Приложение предоставляет истекший или почти истекший токен, содержащий сведения для идентификации пользователя и арендатора.
  5. Внешний поставщик проверки подлинности проверяет, был ли маркер получен из идентификатора Microsoft Entra и проверяет содержимое маркера.
  6. Внешний поставщик проверки подлинности может при необходимости вызвать Microsoft Graph, чтобы получить дополнительные сведения о пользователе.
  7. Внешний поставщик проверки подлинности выполняет любые действия, которые он считает необходимым, например проверку подлинности пользователя с некоторыми учетными данными.
  8. Внешний поставщик проверки подлинности перенаправляет пользователя обратно к Microsoft Entra ID с действительным токеном, включая все необходимые утверждения.
  9. Идентификатор Microsoft Entra проверяет, что подпись токена пришла от настроенного внешнего поставщика аутентификации, а затем проверяет содержимое токена.
  10. Идентификатор Microsoft Entra проверяет маркер в соответствии с требованиями.
  11. Пользователь выполнил требование MFA, если проверка выполнена успешно. Кроме того, пользователю может потребоваться выполнить другие требования к политике.

Схема работы аутентификации с использованием внешнего метода.

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

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

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

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

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

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

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

  3. Задайте типы поддерживаемых учетных записей приложения: учетные записи в любом организационном каталоге (любой клиент Microsoft Entra ID — Multitenant).

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

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

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

    Примечание.

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

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

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

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

Примечание.

Согласие администратора для приложения требуется у арендатора, использующего EAM. Если согласие не предоставлено, при попытке администратора использовать EAM возникает следующая ошибка: AADSTS900491: служебный принципал <ваш идентификатор приложения> не найден.

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

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

Примечание.

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

Добавьте EAM в Microsoft Entra ID

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

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

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

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

Дополнительные сведения о добавлении внешнего метода проверки подлинности в Центре администрирования Microsoft Entra см. в разделе "Управление внешним методом проверки подлинности в идентификаторе Microsoft Entra ID (предварительная версия)".

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

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

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

Внешний поставщик удостоверений должен предоставить конечную точку OIDC Discovery. Эта конечная точка используется для получения дополнительных данных конфигурации. Полный URL-адрес, включая .well-known/oidc-configuration, должен быть включён в URL-адрес обнаружения, настроенный при создании EAM.

Конечная точка возвращает JSON-документ метаданных поставщика, размещенный там. Конечная точка также должна возвращать допустимый заголовок длины содержимого.

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

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

Значение метаданных Значение Комментарии
Издатель Этот URL-адрес должен соответствовать и URL-адресу узла, используемому для обнаружения, и значению iss в маркерах, выданных службой поставщика.
точка авторизации Конечная точка, с которым взаимодействует идентификатор Microsoft Entra для авторизации. Эта конечная точка должна присутствовать в качестве одного из URL-адресов ответа для разрешенных приложений.
jwks_uri Где идентификатор Microsoft Entra может найти открытые ключи, необходимые для проверки подписей, выданных поставщиком.
[!ПРИМЕЧАНИЕ]
Параметр x5c веб-ключа JSON (JWK) должен присутствовать для предоставления представлений ключей X.509.
поддерживаемые_области openid Другие значения также могут быть включены, но не требуются.
поддерживаемые_типы_ответов ид_токен Другие значения также могут быть включены, но не требуются.
поддерживаемые_типы_предметов
id_token_signing_alg_values_supported Корпорация Майкрософт поддерживает RS256
поддерживаемые типы требований Обычная Это свойство является необязательным, но при наличии оно должно содержать нормальное значение; другие значения также могут быть включены.
http://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",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

http://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.

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

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

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

  1. Опубликуйте существующий сертификат и новый сертификат в jwks_uri.
  2. Продолжайте подписывать с помощью существующего сертификата, пока кэш Microsoft Entra ID не будет обновлен, не истечет или не обновится (каждые 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

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

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

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

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

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

Примечание.

Важно проверить id_token_hint, чтобы убедиться, что этот 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.

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

Примечание.

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

Параметр запроса проверки подлинности Значение Описание
область openid
response_type идентификационный токен Значение, используемое для неявного потока.
режим_ответа form_post Мы используем форму POST, чтобы избежать проблем с большими URL-адресами. Мы ожидаем, что все параметры будут отправлены в тексте запроса.
идентификатор_клиента Идентификатор клиента, предоставленный идентификатору Microsoft Entra внешним поставщиком удостоверений, например ABCD. Дополнительные сведения см. в описании метода внешней проверки подлинности.
redirect_url Универсальный идентификатор ресурса перенаправления (URI), в который внешний поставщик удостоверений отправляет ответ (id_token_hint).
См. пример после этой таблицы.
nonce Случайная строка, созданная идентификатором Microsoft Entra. Это может быть идентификатор сеанса. Если это указано, его необходимо вернуть в ответе на идентификатор Microsoft Entra.
state При передаче поставщик должен вернуть состояние в ответе. Идентификатор Microsoft Entra использует состояние для сохранения контекста вызова.
Подсказка_токена_идентификатора Токен, выданный службой идентификации Microsoft Entra для конечного пользователя и предназначенный для использования поставщиком.
требования Большой двоичный объект JSON, содержащий запрошенные утверждения. Дополнительные сведения о формате этого параметра см. в параметре запроса утверждений из документации OIDC и примере после этой таблицы.
идентификатор-запроса-клиента Значение глобального уникального идентификатора (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

Пример EAM, удовлетворяющий MFA

Вот пример аутентификации, где EAM удовлетворяет MFA. Этот пример помогает поставщику узнать, какие запросы ожидает Microsoft Entra ID.

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

  • Метод проверки подлинности, используемый для второго фактора, соответствует требованию 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 по умолчанию

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

Утверждение Значение Описание
МКС Определяет службу маркеров безопасности (STS), которая создает и возвращает маркер, а также клиент Идентификатора Microsoft Entra, в котором пользователь прошел проверку подлинности. Приложению также следует использовать часть утверждения, содержащую GUID, для ограничения списка клиентов, которым разрешено входить в приложение, если это применимо. Издатель должен соответствовать URL-адресу издателя из метаданных JSON обнаружения OIDC для клиента, в котором пользователь вошел в систему.
aud Аудитория должна быть настроена на идентификатор клиента внешнего поставщика удостоверений для Microsoft Entra ID.
эксп Срок действия истекает через короткое время после выдачи, достаточно, чтобы избежать проблем с отклонением времени. Поскольку этот токен не предназначен для проверки подлинности, нет причин для его действия, чтобы намного пережить запрос.
иат Задайте время выдачи как обычно.
tid Идентификатор клиента предназначен для рекламы клиента поставщику. Он представляет клиент Идентификатора Microsoft Entra, из которому находится пользователь.
oid Неизменяемый идентификатор объекта в платформе идентификации Microsoft. В этом случае это учетная запись пользователя. Его также можно использовать для безопасного выполнения проверок авторизации и в качестве ключа в таблицах базы данных. Этот идентификатор однозначно идентифицирует пользователя в приложениях. Два разных приложения, которые входят в один и тот же аккаунт, получают одно и то же значение в утверждении oid. Следовательно, oid можно использовать в запросах к онлайн-службам Microsoft, например, Microsoft Graph.
предпочтительное_имя_пользователя Предоставляет удобное для восприятия значение, которое идентифицирует субъект маркера. Это значение не гарантируется уникальным в рамках клиента и предназначено только для отображения.
дочерний объект Идентификатор субъекта для конечного пользователя у эмитента. Субъект, в отношении которого маркер утверждает сведения, например данные о пользователе приложения. Это значение является неизменяемым и не может быть переназначено или повторно использовано. Это значение можно использовать для безопасных проверок авторизации, например, когда маркер используется для доступа к ресурсу, а также в качестве ключа в таблицах базы данных. Поскольку субъект всегда присутствует в токенах, выпускаемых Microsoft Entra ID, рекомендуется использовать это значение в системе авторизации общего назначения. Тем не менее, объект является парным идентификатором; он уникален для конкретного идентификатора приложения. Таким образом, если один пользователь входит в два разных приложения с использованием двух разных идентификаторов клиента, эти приложения получают два разных значения для утверждения субъекта. Этот результат может быть или не требуется, в зависимости от ваших требований к архитектуре и конфиденциальности. См. также утверждение oid (которое остается неизменным во всех приложениях в рамках одного арендатора).

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

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

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

Корпорация Майкрософт рекомендует связывать учетные записи на стороне поставщика с учетной записью в Azure AD с помощью утверждений 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 для гостевого пользователя в клиенте:

{
  "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"
  }.


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

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

  1. Из запроса:
  2. Из утверждений в id_token_hint:
    • При необходимости он может вызвать Microsoft Graph , чтобы получить другие сведения об этом пользователе. oid и tid утверждения в id_token_hint полезны в этом отношении. Дополнительные сведения об утверждениях, предоставленных в id_token_hint, см. в разделе утверждения id_token_hint по умолчанию.
  3. Затем выполните любое другое действие проверки подлинности, созданное продуктом поставщика.
  4. В зависимости от результатов действий пользователя и других факторов поставщик будет создавать и отправлять ответ обратно в идентификатор Microsoft Entra, как описано в следующем разделе.

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

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

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

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

Утверждение Значение Описание
МКС Эмитент — должен соответствовать эмитенту из метаданных обнаружения провайдера.
aud Аудитория — идентификатор клиента Microsoft Entra ID. См. client_id в вызове Microsoft Entra ID к внешнему поставщику идентичностей.
exp Время окончания срока действия — задано как обычное.
iat Время выдачи — задано как обычно.
дочерний объект Тема — должна соответствовать значению 'sub' из id_token_hint, отправленного для инициации этого запроса.
nonce Тот же самый "nonce", который был передан в запросе.
acr Утверждения ACR для запроса проверки подлинности. Это значение должно соответствовать одному из значений из запроса, отправленного для запуска этого запроса. Возвращено только одно утверждение по acr. Список утверждений см. в разделе "Поддерживаемые acr утверждения".
amr Утверждения amr о методе аутентификации, используемом для проверки подлинности. Это значение должно быть возвращено в виде массива, и возвращается только одно утверждение метода. Список утверждений см. в разделе "Поддерживаемые amr утверждения".
Поддерживаемые утверждения acr
Утверждение Примечания.
владение или принадлежность Проверка подлинности должна проходить с учетом владения или наследования.
знаниеиливладение Проверка подлинности должна выполняться с фактором, основанным на знаниях, или на факторе владения.
знаниеиливрожденность Аутентификация должна выполняться с использованием знания или фактора, связанного с принадлежностью.
знание или обладание или принадлежность Проверка подлинности должна выполняться на основе фактора знаний, владения или наследуемых характеристик.
знание Проверка подлинности должна выполняться с использованием фактора, основанного на знании.
владение Проверка подлинности должна выполняться с учетом фактора владения.
Присущность Проверка подлинности должна выполняться с использованием фактора, основанного на присущих характеристиках.
Поддерживаемые утверждения AMR
Утверждение Примечания.
лицо Биометрические данные с распознаванием лиц
Фидо Использовался FIDO2
fpt Биометрия с отпечатком пальца
hwk Подтверждение владения аппаратным ключом
ирис Биометрия со сканированием радужной оболочки
otp Один раз пароль
pop Подтверждение принадлежности
сетчатка Биометрия сканирования сетчатки
sc Смарт-карта
СМС Подтверждение по SMS на зарегистрированный номер
swk Подтверждение наличия программно защищенного ключа
тел. Подтверждение по телефону
vbm Биометрия с голосовой печатью

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

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

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

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

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

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

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

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

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

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

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

Например:

СБОЙ IDSTS70002: ошибка проверки учетных данных. ENTRA IDSTS50012: внешний токен идентификатора издателя "https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa" не прошел проверку подписи. KeyID токена: 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333 Идентификатор корреляции: aaaa0000-bb11-2222-33cc-444444dddddd Метка времени: 2023-07-24 16:51:34Z

Пользовательские элементы управления и Системы управления активами (EAM)

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

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

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

    Примечание.

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

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

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

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

Ссылки

Глоссарий

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

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

Дополнительные сведения о настройке EAM в Центре администрирования Microsoft Entra см. в статье "Управление внешним методом проверки подлинности в Microsoft (предварительная версия)".