Добавление соединителей API для регистрации потоков пользователей

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

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

Будучи разработчиком или ИТ-администратором, вы можете использовать соединители API для интеграции потоков пользователей для регистрации с интерфейсами REST API, чтобы настроить процесс регистрации и интегрировать его с внешними системами. В конце этого пошагового руководства вы сможете создать поток пользователя Azure AD B2C, взаимодействующий со службами REST API для изменения возможностей регистрации.

Вы можете создать конечную точку API с помощью одного из наших примеров.

В этом сценарии мы добавим возможность для пользователей вводить номер лояльности на страницу регистрации в Azure AD B2C. REST API проверяет, сопоставляется ли сочетание номера электронной почты и лояльности с рекламным кодом. Если REST API находит рекламный код для этого пользователя, он будет возвращен в Azure AD B2C. Наконец, промо-код будет вставлен в требования токена, чтобы приложение могло его использовать.

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

Предпосылки

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

Выполните действия, описанные в статье "Начало работы с настраиваемыми политиками в Active Directory B2C". В этом руководстве описано, как обновить пользовательские файлы политики для использования конфигурации клиента Azure AD B2C.
Зарегистрируйте веб-приложение.

Создание соединителя API

Чтобы использовать соединитель API, сначала создайте соединитель API, затем включите его в пользовательском сценарии.

Войдите на портал Azure.
В разделе "Службы Azure" выберите Azure AD B2C.
Выберите соединители API и выберите новый соединитель API.
Укажите отображаемое имя для вызова. Например, проверьте сведения о пользователе.
Укажите URL-адрес конечной точки для вызова API.
Выберите Тип проверки подлинности и настройте сведения проверки подлинности для вызова API. Узнайте, как защитить свой соединитель API.
Выберите Сохранить.

Запрос, отправляемый в API

Соединитель API материализуется в форме запроса HTTP POST, который отправляет атрибуты пользователя ("claims") в виде пар "ключ-значение" в теле JSON. Атрибуты сериализуются аналогично свойствам пользователя Microsoft Graph.

Пример запроса

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

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

Пользовательские атрибуты существуют в формате extension_<extensions-app-id>_CustomAttribute в каталоге. Ваш API должен быть рассчитан на прием утверждений в таком же сериализованном формате. Дополнительные сведения о настраиваемых атрибутах см. в разделе "Определение настраиваемых атрибутов" в Azure AD B2C.

Кроме того, эти утверждения обычно отправляются во всех запросах:

Языковые стандарты пользовательского интерфейса (ui_locales) — языковые стандарты пользователя, настроенные на его устройстве. Их можно использовать в API для возврата ответов для пользователей из разных стран.
Шаг ('step') — шаг или этап в пользовательском потоке, для которого был вызван соединитель API. Значения:
- PostFederationSignup — соответствует выражению "После федерации с поставщиком удостоверений во время регистрации"
- PostAttributeCollection — соответствует параметру "Перед созданием пользователя"
- PreTokenIssuance — соответствует параметру "Перед отправкой токена (предварительный просмотр)". Дополнительные сведения об этом шаге
Идентификатор клиента ('client_id') — appId значение приложения, в котором пользователь проходит аутентификацию в пользовательском потоке. Это не приложение ресурса в токенах доступа.
Адрес электронной почты (email) или идентификаторы (identities) — данные, которые ваш API может использовать для определения конечного пользователя, проходящего аутентификацию в приложении.

Это важно

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

Включение API-коннектора в процессе пользовательского сценария

Выполните следующие действия, чтобы добавить соединитель API в процесс регистрации пользователя.

Войдите на портал Azure.
В разделе "Службы Azure" выберите Azure AD B2C.
Выберите Пользовательские сценарии, затем выберите сценарий пользователя, к которому надо добавить соединитель API.
Выберите Соединители API, затем выберите конечные точки API, которые надо вызывать в пользовательском потоке при выполнении действий, описанных ниже.
- После установления федерации с поставщиком удостоверений во время регистрации
- Перед созданием пользователя
- Перед отправкой маркера (предварительная версия)
Выберите Сохранить.

Эти действия существуют только для регистрации и входа (рекомендуется) ирегистрации (рекомендуется), но применяются только к части регистрации.

Соединитель API на этом этапе процесса регистрации вызывается сразу после аутентификации пользователя с помощью поставщика удостоверений (например, Google, Facebook и Microsoft Entra ID). Этот шаг предшествует странице сбора атрибутов — форме, отображаемой пользователю с целью сбора атрибутов пользователя. Этот шаг не вызывается, если пользователь регистрируется в локальной учетной записи.

Пример запроса, отправленного в API на этом шаге

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

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

Ожидаемые типы ответов из веб-API на этом шаге

Когда веб-API получает HTTP-запрос от идентификатора Microsoft Entra во время пользовательского потока, он может возвращать следующие ответы:

Ответ продолжения
Блокирующий ответ

Ответ продолжения

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

В ответе на продолжение API может возвратить утверждения. Если API возвращает утверждение, то это утверждение выполняет следующее действие:

Предварительно заполняет поле ввода на странице коллекции атрибутов.

См. пример продолжительного ответа.

Блокирующий ответ

Блокирующий ответ прерывает пользовательский поток. Он может быть выдан API-интерфейсом целенаправленно, чтобы остановить продолжение пользовательского сценария, отобразив для пользователя страницу блокировки. На странице блокировки отображается сообщение userMessage, предоставленное API-интерфейсом.

См. пример блокирующего ответа.

Перед созданием пользователя

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

Пример запроса, отправленного в API на этом шаге

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

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

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения
Блокирующий ответ
Ответ валидации

Ответ продолжения

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

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

Чтобы записать утверждения в каталог при регистрации, которые не должны собираться от пользователя, необходимо по-прежнему выбрать утверждения в разделе "Атрибуты пользователя " потока пользователя, который по умолчанию запрашивает у пользователя значения, но можно использовать настраиваемые поля JavaScript или CSS для скрытия полей ввода от конечного пользователя.

См. пример продолжительного ответа.

Блокирующий ответ

См. пример блокирующего ответа.

Ответ об ошибке при проверке

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

См. пример ответа об ошибке при проверке.

Перед отправкой токена (предварительный просмотр)

Это важно

Соединители API, используемые на этом шаге, находятся в предварительной версии. Дополнительные сведения о предварительных версиях см. в разделе "Условия продукта для веб-служб".

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

Пример запроса, отправленного в API на этом шаге

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "11112222-bbbb-3333-cccc-4444dddd5555",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

Утверждения, отправляемые API, зависят от сведений, определенных для пользователя.

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Ответ продолжения

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

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

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

См. пример продолжительного ответа.

Замечание

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

Примеры ответов

Пример ответа с продолжением

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

Параметр	Тип	Обязательно	Описание
версия	Струна	Да	Версия вашего API.
действие	Струна	Да	Необходимое значение: `Continue`.
<встроенныйПользовательскийАтрибут>	<атрибут-тип>	нет	Возвращаемые значения могут перезаписывать значения, полученные от пользователя.
<extension_{идентификатор_приложения_расширений}_CustomAttribute>	<атрибут-тип>	нет	В утверждении не обязательно должно содержаться `_<extensions-app-id>_`, это необязательно. Возвращаемые значения могут перезаписывать значения, полученные от пользователя.

Пример блокирующего ответа

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}

Параметр	Тип	Обязательно	Описание
версия	Струна	Да	Версия вашего API.
действие	Струна	Да	Значением должно быть `ShowBlockPage`
сообщение пользователя	Струна	Да	Сообщение, отображаемое для пользователя.

Отображение блокирующего ответа в интерфейсе пользователя

Пример блокировки ответа

Пример ответа об ошибке при проверке

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}

Параметр	Тип	Обязательно	Описание
версия	Струна	Да	Версия вашего API.
действие	Струна	Да	Необходимое значение: `ValidationError`.
статус	Целое число/строка	Да	Должен иметь значение `400` или `"400"` для ответа ValidationError (Ошибка при проверке).
сообщение пользователя	Струна	Да	Сообщение, отображаемое для пользователя.

Замечание

Код состояния HTTP должен иметь значение 400 в дополнение к значению "status" в тексте ответа.

Отображение ответа об ошибке при проверке в интерфейсе пользователя

Пример ответа на ошибку проверки

Подготовка конечной точки REST API

Для этого пошагового руководства у вас должен быть REST API, проверяющий, зарегистрирован ли адрес электронной почты в вашей серверной системе с идентификатором лояльности. Если была произведена регистрация, REST API должен вернуть рекламный код для регистрации, который клиент может использовать для приобретения товаров в вашем приложении. В противном случае REST API должен вернуть сообщение об ошибке HTTP 409: "Идентификатор лояльности "{идентификатор лояльности}" не связан с адресом электронной почты "{email}".

Следующий код JSON иллюстрирует данные Azure AD B2C, которые будут отправляться в конечную точку REST API.

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

После проверки данных REST API он должен вернуть HTTP 200 (ОК) со следующими данными JSON:

{
    "promoCode": "24534"
}

Если проверка завершилась ошибкой, REST API должен вернуть HTTP 409 (Конфликт) с элементом userMessage JSON. IEF ожидает userMessage утверждения о том, что REST API возвращается. Это утверждение будет представлено пользователю в виде строки, если проверка не пройдена.

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

Настройка конечной точки REST API выходит за рамки этой статьи. Мы создали пример Функций Azure. Полный код функции Azure можно получить на сайте GitHub.

Определение утверждений

Утверждение предоставляет временное хранилище данных во время выполнения политики Azure AD B2C. Утверждения можно декларировать в разделе схемы утверждений.

Откройте файл расширений вашей политики. Например: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
Найдите элемент BuildingBlocks . Если элемент не существует, добавьте его.
Найдите элемент ClaimsSchema . Если элемент не существует, добавьте его.
Добавьте следующие утверждения в элемент ClaimsSchema .

<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</ClaimType>
  <ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Добавление технического профиля API RESTful

Технический профиль RESTful обеспечивает поддержку взаимодействия с собственной службой RESTful. Azure AD B2C отправляет данные в службу RESTful в виде InputClaims коллекции и получает данные обратно в виде коллекции OutputClaims. Найдите элемент ClaimsProviders и добавьте новый поставщик утверждений следующим образом:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

В этом примере userLanguage служба REST отправляется как lang в полезные данные JSON. Значение утверждения содержит текущий идентификатор пользовательского userLanguage языка. Дополнительные сведения см. в разделе "Сопоставитель утверждений".

Настройка технического профиля API RESTful

После развертывания REST API задайте метаданные технического REST-ValidateProfile профиля, чтобы они отражали вашу собственную REST API, включая:

ServiceUrl. Задайте URL-адрес конечной точки REST API.
SendClaimsIn. Укажите способ отправки входных утверждений поставщику утверждений RESTful.
Тип аутентификации. Задайте тип проверки подлинности, выполняемой поставщиком утверждений RESTful.
AllowInsecureAuthInProduction. В рабочей среде обязательно задайте для этих метаданных значение true

Дополнительные конфигурации см. в метаданных технического профиля RESTful .

Комментарии выше AuthenticationType и AllowInsecureAuthInProduction указывают изменения, которые необходимо внести при переходе в рабочую среду. Сведения о защите API RESTful для рабочей среды см. в статье Secure RESTful API.

Проверка входных данных пользователя

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

Добавьте ссылку на технический профиль проверки в технический профиль регистрации, который вызывает REST-ValidateProfile. Новый технический профиль проверки будет добавлен в верхнюю часть <ValidationTechnicalProfiles> коллекции, определенной в базовой политике. Это означает, что только после успешной проверки Azure AD B2C переходит к созданию учетной записи в каталоге.

Найдите элемент ClaimsProviders . Добавьте нового поставщика утверждений следующим образом:

<ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surName"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Self Asserted</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-Social">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
        <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surname"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Включите утверждение в токен

Чтобы вернуть утверждение промокода обратно в приложение проверяющей стороны, добавьте выходное утверждение в SocialAndLocalAccounts/SignUpOrSignIn.xml файл. Исходное утверждение позволит добавить утверждение в токен после успешного процесса взаимодействия пользователя и будет отправлено приложению. Измените элемент технического профиля в разделе доверяющей стороны, чтобы добавить promoCode в качестве выходного утверждения.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <OutputClaim ClaimTypeReferenceId="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Проверка настраиваемой политики

Войдите на портал Azure.
Если у вас есть доступ к нескольким арендаторам, щелкните значок Настройки в верхнем меню, чтобы переключиться на арендатора Microsoft Entra ID из меню Каталоги и подписки.
Выберите все службы в левом верхнем углу портала Azure, а затем найдите и выберите регистрацию приложений.
Выберите Identity Experience Framework.
Выберите " Отправить настраиваемую политику", а затем отправьте измененные файлы политики: TrustFrameworkExtensions.xmlи SignUpOrSignin.xml.
Выберите политику регистрации или входа, которую вы добавили, и нажмите кнопку "Запустить сейчас ".
Вы можете зарегистрироваться с помощью адреса электронной почты.
Щелкните ссылку "Регистрация сейчас ".
В поле Идентификатор лояльности введите 1234 и нажмите кнопку "Продолжить". На этом этапе необходимо получить сообщение об ошибке проверки.
Перейдите к другому значению и нажмите кнопку "Продолжить".
Маркер, отправляемый в приложение, включает promoCode утверждение.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "22223333-cccc-4444-dddd-5555eeee6666",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

Дальнейшие шаги

Начните с наших примеров.
Защита соединителя API

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2024-01-24

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

Создание соединителя API

Запрос, отправляемый в API

Включение API-коннектора в процессе пользовательского сценария

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Блокирующий ответ

Перед созданием пользователя

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Блокирующий ответ

Ответ об ошибке при проверке

Перед отправкой токена (предварительный просмотр)

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Примеры ответов

Пример ответа с продолжением

Пример блокирующего ответа

Пример ответа об ошибке при проверке

Подготовка конечной точки REST API

Определение утверждений

Добавление технического профиля API RESTful

Настройка технического профиля API RESTful

Проверка входных данных пользователя

Включите утверждение в токен

Проверка настраиваемой политики

Использование бессерверных облачных функций

Лучшие практики

Использование ведения журналов

Использование бессерверных облачных функций

Лучшие практики

Использование ведения журналов

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

Добавьте API-коннектор в поток регистрации пользователей

Предпосылки

Создание соединителя API

Запрос, отправляемый в API

Включение API-коннектора в процессе пользовательского сценария

После установления федеративной связи с поставщиком удостоверений во время регистрации

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Блокирующий ответ

Перед созданием пользователя

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Блокирующий ответ

Ответ об ошибке при проверке

Перед отправкой токена (предварительный просмотр)

Пример запроса, отправленного в API на этом шаге

Ожидаемые типы ответов из веб-API на этом шаге

Ответ продолжения

Примеры ответов

Пример ответа с продолжением

Пример блокирующего ответа

Пример ответа об ошибке при проверке

Подготовка конечной точки REST API

Определение утверждений

Добавление технического профиля API RESTful

Настройка технического профиля API RESTful

Проверка входных данных пользователя

Включите утверждение в токен

Проверка настраиваемой политики

Рекомендации и устранение неполадок

Использование бессерверных облачных функций

Лучшие практики

Использование ведения журналов

Использование бессерверных облачных функций

Лучшие практики

Использование ведения журналов

Дальнейшие шаги

Обратная связь

Дополнительные ресурсы