Добавление OpenID Connect в качестве внешнего поставщика удостоверений

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

Настроив федерацию с настраиваемым поставщиком удостоверений OpenID Connect (OIDC), пользователи могут зарегистрироваться и войти в приложения, используя существующие учетные записи из федеративного внешнего поставщика. Эта федерация OIDC позволяет выполнять проверку подлинности с различными поставщиками, которые соответствуют протоколу OpenID Connect.

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

Необходимые условия

Настройте вашего поставщика удостоверений OpenID Connect

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

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

https://<tenant-subdomain>.ciamlogin.com/<tenant-ID>/federation/oauth2

https://<tenant-subdomain>.ciamlogin.com/<tenant-subdomain>.onmicrosoft.com/federation/oauth2

Включите возможность регистрации и входа с вашим провайдером идентификации

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

Параметры федерации

Чтобы сконфигурировать федерацию OpenID Connect с вашим провайдером удостоверений в Внешняя идентификация Microsoft Entra, вам потребуется следующее:

  • Известная конечная точка
  • URI издателя
  • идентификатор клиента
  • метода проверки подлинности клиента
  • секретный ключ клиента
  • Объем
  • тип ответа
  • Сопоставление утверждений
    • Подкатегория
    • Имя
    • Личное имя
    • Фамилия
    • Электронная почта (требуется по умолчанию; может быть необязательным)
    • Электронная почта подтверждена
    • Номер телефона
    • Номер_телефона_подтвержден
    • Адрес улицы
    • Местность
    • Область
    • Почтовый индекс
    • Страна

Настройка нового поставщика удостоверений OpenID Connect в Центре администрирования

После настройки поставщика удостоверений выполните следующий шаг, чтобы настроить новую федерацию OpenID Connect в Центре администрирования Microsoft Entra.

  1. Войдите в Центр администрирования Microsoft Entra как минимум в качестве администратора внешнего поставщика удостоверений.

  2. Перейдите к Entra ID>Внешние удостоверения личности>Все поставщики удостоверений личности.

  3. Перейдите на вкладку "Custom", а затем выберите "Добавить новую>Open ID Connect".

    Снимок экрана добавления нового пользовательского поставщика удостоверений.

  4. Введите следующие сведения для поставщика удостоверяющей информации:

    • Отображаемое имя: имя поставщика удостоверений, отображаемое пользователям во время входа и регистрации. Например, войти с помощью имени поставщика удостоверяющей информации или зарегистрироваться с помощью имени поставщика удостоверяющей информации.

    • хорошо известная конечная точка (также известная как URI метаданных) — это URI для обнаружения OIDC, используемый для того, чтобы получить конфигурацию вашего поставщика удостоверений. Ответ — это документ JSON, включающий расположения конечных точек OAuth 2.0. Как минимум, документ метаданных должен содержать следующие свойства: issuer, authorization_endpoint, token_endpoint, token_endpoint_auth_methods_supported, response_types_supportedsubject_types_supportedи jwks_uri. Дополнительные сведения см. в спецификациях по OpenID Connect Discovery.

    • URI издателя OpenID: сущность поставщика удостоверений, которая выдает токены доступа для вашего приложения. Например, если вы используете OpenID Connect для объединения с Azure AD B2C, URI издателя выглядит следующим образом: https://login.b2clogin.com/{tenant}/v2.0/ URI-идентификатор издателя — это URL-адрес, который чувствителен к регистру и использует схему https. Он содержит схему, узел и при необходимости номер порта и компоненты пути, но не содержит компонентов параметров запроса или фрагмента.

    Заметка

    Чтобы объединиться с клиентом Идентификатора Microsoft Entra, см. статью "Добавление клиента идентификатора Microsoft Entra в качестве поставщика удостоверений OpenID Connect". Федерация OIDC также не совместима с функцией приглашения внешнего пользователя (предварительная версия).

    • идентификатор клиента и секрет клиента — это идентификаторы, которые поставщик удостоверений использует для идентификации зарегистрированной службы приложений. Укажите секрет клиента при выборе метода проверки подлинности на основе client_secret.
    • Аутентификация клиента — это тип метода, который будет использоваться для выполнения аутентификации с вашим поставщиком удостоверений с помощью токен-эндпоинта. Поддерживаются методы аутентификации client_secret_post и client_secret_jwt. Хотя пользовательский интерфейс центра администрирования может отображаться private_key_jwt в качестве параметра, этот метод в настоящее время не поддерживается и не должен быть выбран.

    Заметка

    Из-за возможных проблем client_secret_basic безопасности метод проверки подлинности клиента не поддерживается.

    • Область охвата определяет сведения и разрешения, которые вы хотите получить от вашего поставщика удостоверений, например openid profile. Запросы OpenID Connect должны содержать значение параметра openid для получения токена идентификатора от поставщика удостоверений. Другие области можно добавить, разделяя пробелами. См. документацию по OpenID Connect для других доступных областей, таких как profile, emailи многое другое.
    • тип ответа описывает, какая информация возвращается при первоначальном вызове authorization_endpoint вашего поставщика удостоверений. В настоящее время поддерживается только тип ответа code. id_token и token не поддерживаются.
  5. Нажмите «Далее: сопоставление утверждений» для настройки сопоставления утверждений или «Просмотр и создание» для добавления поставщика идентификации.

Заметка

Корпорация Майкрософт рекомендует не использовать неявный поток авторизации или поток ROPC. Поэтому конфигурация внешнего поставщика удостоверений OpenID Connect не поддерживает эти потоки. Рекомендуемый способ поддержки SPA — поток кода авторизации OAuth 2.0 (с PKCE), который поддерживается конфигурацией федерации OIDC.

Добавьте поставщика удостоверений OIDC в пользовательский поток

На этом этапе вы настроили поставщика удостоверений OIDC в Microsoft Entra ID, но он еще недоступен ни на одной из страниц входа. Чтобы добавить поставщика удостоверений OIDC в сценарий действий пользователя:

  1. В вашем внешнем клиенте перейдите к Entra ID>Внешние идентичности>Потоки пользователей.

  2. Выберите поток пользователя, куда вы хотите добавить поставщика удостоверений OIDC.

  3. В разделе "Настройки" выберите поставщики удостоверений.

  4. В разделе Другие поставщики удостоверенийвыберите поставщика удостоверений OIDC.

    Скриншот пользовательского поставщика OIDC в списке IdP.

  5. Выберите Сохранить.

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

По умолчанию пользователи должны указать адрес электронной почты при регистрации через внешнего поставщика удостоверений (IdP). Если внешний поставщик удостоверений не отправляет утверждение с адресом электронной почты, пользователи получают сообщение об ошибке AADSTS901011: No email address was obtained from the external oidc identity provider при регистрации. Чтобы избежать этой ошибки, настройте поток пользователя, чтобы сделать атрибут электронной почты необязательным. После этого пользователи могут завершить регистрацию, используя только учётную запись внешнего поставщика удостоверений, без указания адреса электронной почты.

Important

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

Заметка

Если адрес электронной почты не собирается, одноразовый код, отправляемый по электронной почте, нельзя использовать для многофакторной аутентификации. Убедитесь, что альтернативный метод MFA (например, SMS) включен, если для политик требуется MFA.

Tip

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

Обновите пользовательский сценарий, чтобы адрес электронной почты был необязательным

Чтобы сделать атрибут электронной почты необязательным в потоке пользователя, используйте Microsoft API Graph для обновления свойства onAttributeCollection потока пользователя.

  1. Найдите идентификатор потока пользователя, который требуется обновить. Один из способов сделать это — использовать Graph Explorer для перечисления всех потоков пользователей:

    GET https://graph.microsoft.com/v1.0/identity/authenticationEventsFlows
    

    Найдите id потока пользователя и onAttributeCollection свойство в ответе.

  2. Скопируйте свойство onAttributeCollection из ответа и используйте его для обновления пользовательского потока с помощью запроса PATCH. Единственное изменение, которое нужно внести, — установить для атрибута email свойство required в значение false:

    PATCH https://graph.microsoft.com/v1.0/identity/authenticationEventsFlows/{user-flow-id}
    Content-Type: application/json
    
    {
        "@odata.type": "#microsoft.graph.externalUsersSelfServiceSignUpEventsFlow",
        "onAttributeCollection": {
            "@odata.type": "#microsoft.graph.onAttributeCollectionExternalUsersSelfServiceSignUp",
            "attributeCollectionPage": {
                "views": [
                    {
                        "title": null,
                        "description": null,
                        "inputs": [
                            {
                                "attribute": "email",
                                "label": "Email Address",
                                "inputType": "text",
                                "defaultValue": null,
                                "hidden": false,
                                "editable": true,
                                "writeToDirectory": true,
                                "required": false,
                                "validationRegEx": "^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\\.[a-zA-Z0-9-]+)*$",
                                "options": []
                            }
                        ]
                    }
                ]
            }
        }
    }
    

    Заметка

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

Известные ограничения

Политики условного доступа, требующие регистрации MFA, не работают должным образом, если внешний клиент федеративн с внешним поставщиком удостоверений (IdP). Это ограничение может привести к одному из следующих действий:

  • Пользователи не могут зарегистрировать метод MFA и не могут завершить вход и часто возникают ошибки.
  • Пользователи не перенаправляются в поток регистрации MFA при входе, как ожидалось.
  • Пользователь, созданный без адреса электронной почты, не может зарегистрировать адрес электронной почты для использования с одноразовым секретным кодом (OTP) в качестве метода MFA.