Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применяется:
Внешние клиенты (дополнительные сведения)
Настроив федерацию с настраиваемым поставщиком удостоверений 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.
Войдите в Центр администрирования Microsoft Entra как минимум в качестве администратора внешнего поставщика удостоверений.
Перейдите к Entra ID>Внешние удостоверения личности>Все поставщики удостоверений личности.
Перейдите на вкладку "Custom", а затем выберите "Добавить новую>Open ID Connect".
Введите следующие сведения для поставщика удостоверяющей информации:
Отображаемое имя: имя поставщика удостоверений, отображаемое пользователям во время входа и регистрации. Например, войти с помощью имени поставщика удостоверяющей информации или зарегистрироваться с помощью имени поставщика удостоверяющей информации.
хорошо известная конечная точка (также известная как 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не поддерживаются.
Нажмите «Далее: сопоставление утверждений» для настройки сопоставления утверждений или «Просмотр и создание» для добавления поставщика идентификации.
Заметка
Корпорация Майкрософт рекомендует не использовать неявный поток авторизации или поток ROPC. Поэтому конфигурация внешнего поставщика удостоверений OpenID Connect не поддерживает эти потоки. Рекомендуемый способ поддержки SPA — поток кода авторизации OAuth 2.0 (с PKCE), который поддерживается конфигурацией федерации OIDC.
Добавьте поставщика удостоверений OIDC в пользовательский поток
На этом этапе вы настроили поставщика удостоверений OIDC в Microsoft Entra ID, но он еще недоступен ни на одной из страниц входа. Чтобы добавить поставщика удостоверений OIDC в сценарий действий пользователя:
В вашем внешнем клиенте перейдите к Entra ID>Внешние идентичности>Потоки пользователей.
Выберите поток пользователя, куда вы хотите добавить поставщика удостоверений OIDC.
В разделе "Настройки" выберите поставщики удостоверений.
В разделе Другие поставщики удостоверенийвыберите поставщика удостоверений OIDC.
Выберите Сохранить.
Сделать адрес электронной почты необязательным при регистрации через внешнего поставщика удостоверений
По умолчанию пользователи должны указать адрес электронной почты при регистрации через внешнего поставщика удостоверений (IdP). Если внешний поставщик удостоверений не отправляет утверждение с адресом электронной почты, пользователи получают сообщение об ошибке AADSTS901011: No email address was obtained from the external oidc identity provider при регистрации. Чтобы избежать этой ошибки, настройте поток пользователя, чтобы сделать атрибут электронной почты необязательным. После этого пользователи могут завершить регистрацию, используя только учётную запись внешнего поставщика удостоверений, без указания адреса электронной почты.
Important
Указание адреса электронной почты как необязательного — это настройка на уровне потока пользователя. Это изменение относится к регистрациям для всех приложений, связанных с пользовательским потоком.
Заметка
Если адрес электронной почты не собирается, одноразовый код, отправляемый по электронной почте, нельзя использовать для многофакторной аутентификации. Убедитесь, что альтернативный метод MFA (например, SMS) включен, если для политик требуется MFA.
Tip
Окно выбора аккаунта обычно отображает адрес электронной почты пользователя. Если адрес электронной почты не указан, вместо него отображается отображаемое имя. Чтобы пользователям было проще распознавать свою учетную запись, сопоставьте утверждение name в разделе Сопоставление утверждений или запрашивайте отображаемое имя при регистрации.
Обновите пользовательский сценарий, чтобы адрес электронной почты был необязательным
Чтобы сделать атрибут электронной почты необязательным в потоке пользователя, используйте Microsoft API Graph для обновления свойства onAttributeCollection потока пользователя.
Найдите идентификатор потока пользователя, который требуется обновить. Один из способов сделать это — использовать Graph Explorer для перечисления всех потоков пользователей:
GET https://graph.microsoft.com/v1.0/identity/authenticationEventsFlowsНайдите
idпотока пользователя иonAttributeCollectionсвойство в ответе.Скопируйте свойство
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.