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

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

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

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

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

EAMs добавляются в идентификатор Microsoft Entra администратором клиента. Если клиенту требуется EAM для MFA, вход считается обязательным после проверки идентификатора Microsoft Entra id:

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

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

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

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

• Конечная точка обнаружения OIDC, как описано в разделе "Обнаружение метаданных поставщика"
• Допустимая конечная точка проверки подлинности OIDC
• URL-адрес публикации общедоступных сертификатов поставщика

Давайте рассмотрим, как работает вход с EAM:

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

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

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

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

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

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

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

Добавление EAM в идентификатор Microsoft Entra

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

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

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

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

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

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

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

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

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

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

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

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

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="
      ]
    }
  ]
}

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

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

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

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

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

Обнаружение метаданных идентификатора 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 (JWS)), можно определить, какие из ключей, полученных из свойства jwks_uri, следует использовать для проверки подписи маркера идентификатора Microsoft Entra ID.

Проверка маркеров, выданных идентификатором Microsoft Entra

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

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

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

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

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

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

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

Пример 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.

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

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

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

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

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

Рекомендуемое использование утверждений

Корпорация Майкрософт рекомендует связывать учетные записи на стороне поставщика с учетной записью в 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": "[email protected]"
  "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": "[email protected]",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

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

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

1. Из запроса:
   • Убедитесь, что redirect_uri опубликовано в вызове идентификатора Microsoft Entra к внешнему поставщику удостоверений.
   • Убедитесь, что client_id имеет значение, назначенное идентификатору Microsoft Entra, например ABCD.
   • Поставщик должен сначала проверить id_token_hint, представленный ему идентификатором Microsoft Entra.
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.

Поддерживаемые утверждения acr

Поддерживаемые утверждения amr

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

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

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

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

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

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

Обработка ответа на ошибки идентификатора записи Майкрософт

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

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

Например:

ЗАПИСЬ IDSTS70002: ошибка проверки учетных данных. ENTRA IDSTS50012: внешний маркер идентификатора издателя "https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa" не удалось проверить подпись. KeyID токена : "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u" Trace ID: 0000aaaa-11bb-cccc-dd22-eeee333333 Идентификатор корреляции: aaaa00000-bb11-2222-33cc-44444d: 2023-07-24 16:51:34Z

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

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

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

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

  Примечание.

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

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

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

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

Ссылки

• Спецификация OAuth2.0 и OIDC

Глоссарий

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

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