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

  • Статья

Для начала с помощью селектора Choose a policy type (Выбрать тип политики) выберите тип пользовательской политики. 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 как этап оркестрации.

Необходимые компоненты

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

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

  1. Войдите на портал Azure.

  2. В разделе Службы Azure выберите Azure AD B2C.

  3. Выберите Соединители API, затем — Создать соединитель API.

    Screenshot of basic configuration for an API connector

  4. Укажите отображаемое имя для вызова. Например, Проверить данные пользователя.

  5. Укажите URL-адрес конечной точки для вызова API.

  6. Выберите Тип проверки подлинности и настройте сведения проверки подлинности для вызова API. Узнайте, как защитить свой соединитель API.

    Screenshot of authentication configuration for an API connector

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

Запрос, отправляемый в 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": "11111111-0000-0000-0000-000000000000",
 "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":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

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

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

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

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

Важно!

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

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

Чтобы добавить соединитель API в пользовательский сценарий, выполните действия, описанные ниже.

  1. Войдите на портал Azure.

  2. В разделе Службы Azure выберите Azure AD B2C.

  3. Выберите Пользовательские сценарии, затем выберите сценарий пользователя, к которому надо добавить соединитель API.

  4. Выберите Соединители API, затем выберите конечные точки API, которые надо вызывать в пользовательском потоке при выполнении действий, описанных ниже.

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

    Selecting an API connector for a step in the user flow

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

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

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

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

Пример запроса, отправленного в 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, зависят от информации, предоставленной поставщиком удостоверений. Утверждение 'email' (адрес электронной почты) отправляется всегда.

Ожидаемые типы ответов из веб-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":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

{
 "clientId": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "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 получает HTTP-запрос от идентификатора Microsoft Entra во время пользовательского потока, он может возвращать следующие ответы:

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

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

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

В ответе продолжения 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
}
Параметр Type Обязательное поле Описание
версия Строка Да Версия интерфейса API.
действие Строка Да Необходимое значение: Continue.
<builtInUserAttribute> <attribute-type> No Возвращаемые значения могут перезаписывать значения, полученные от пользователя.
<extension_{идентификатор_приложения_расширений}_CustomAttribute> <attribute-type> No Утверждение необязательно должно содержать _<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",
}
Параметр Type Обязательное поле Описание
версия Строка Да Версия интерфейса API.
действие Строка Да Значением должно быть ShowBlockPage
userMessage Строка Да Сообщение, отображаемое для пользователя.

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

Example of a blocking response

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

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."
}
Параметр Type Обязательное поле Описание
версия Строка Да Версия интерфейса API.
действие Строка Да Необходимое значение: ValidationError.
status Целое число/строка Да Должен иметь значение 400 или "400" для ответа ValidationError (Ошибка при проверке).
userMessage Строка Да Сообщение, отображаемое для пользователя.

Примечание.

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

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

Example of a validation-error response

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

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

В следующем коде 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 (Конфликт) с элементом JSON userMessage. IEF ожидает, что REST API вернет утверждение userMessage. Это утверждение будет представлено пользователю в виде строки в случае сбоя проверки.

{
    "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. Утверждения можно объявить в разделе схемы утверждений.

  1. Откройте файл расширения политики. Например, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
  2. Найдите элемент BuildingBlocks. Если такой элемент не существует, добавьте его.
  3. Найдите элемент ClaimsSchema. Если такой элемент не существует, добавьте его.
  4. Добавьте следующие утверждения в элемент 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>

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

Технический профиль 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 содержит текущий идентификатор языка пользователя. Дополнительные сведения см. в статье об арбитрах утверждений.

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

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

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

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

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

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

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

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

  1. Найдите элемент 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>

Проверка пользовательской политики

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Идентификатора Microsoft Entra из меню каталогов и подписок.
  3. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Регистрация приложений.
  4. Выберите Инфраструктура процедур идентификации.
  5. Выберите Отправка пользовательской политики, а затем отправьте файлы политики TrustFrameworkExtensions.xml и SignUpOrSignin.xml, которые вы изменили.
  6. Выберите отправленную вами политику регистрации или входа и нажмите кнопку Выполнить.
  7. Вы сможете зарегистрироваться, используя адрес электронной почты.
  8. Щелкните ссылку Подписаться.
  9. В поле Your loyalty ID (Идентификатор программы лояльности) введите 1234 и нажмите кнопку Продолжить. На этом этапе вы получите сообщение об ошибке проверки.
  10. Измените значение на другое и нажмите кнопку Продолжить.
  11. Токен, отправленный обратно в ваше приложение, включает утверждение promoCode.
{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
  "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"
  ...
}

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

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

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

Рекомендации

Убедитесь в следующем:

  • API-интерфейс соответствует контрактам на запросы и ответы API, как описано выше.
  • URL-адрес конечной точки соединителя API указывает на правильную конечную точку API.
  • API явным образом проверяет полученные утверждения, которые ему необходимы, на наличие в них значений NULL.
  • API реализует способ проверки подлинности, описанный в статье о защите соединителя API.
  • API реагирует на операции как можно быстрее, чтобы обеспечить работу пользовательского интерфейса без задержек.
    • Azure AD B2C будет ожидать ответа в течение 20 секунд. Если ответ не получен, выполняется еще одна попытка (повтор) вызвать API.
    • Если используется бессерверная функция или масштабируемая веб-служба, реализуйте план размещения, по которому API в рабочей среде постоянно будет в "пробужденном" или "теплом" состоянии. Для Функций Azure в рабочей среде рекомендуется использовать план категории не ниже "Премиум".
  • Обеспечьте высокую доступность вашего API.
  • Отслеживайте и оптимизируйте производительность нижестоящих API, баз данных и других зависимостей вашего API.

Важно!

Ваши конечные точки должны соответствовать требованиям безопасности Azure AD B2C. Ранние версии и шифры TLS считаются нерекомендуемыми. Дополнительные сведения см. в статье Требования к комплекту шифров и TLS в Azure AD B2C.

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

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

  • Отслеживайте коды состояния HTTP, отличные от HTTP 200 и 400.
  • Код состояния HTTP 401 или 403 обычно указывает на проблему, связанную с проверкой подлинности. Дважды проверьте настроенный уровень проверки подлинности API и соответствующую конфигурацию в соединителе API.
  • При необходимости используйте более агрессивные уровни ведения журнала (например, "трассировка" или "отладка").
  • Отслеживайте работу API на предмет больших значений для времени отклика.

Кроме того, Azure AD B2C записывает метаданные о транзакциях API, происходящих во время проверки подлинности пользователя, с помощью потока пользователя. Вот как найти эти значения:

  1. Откройте Azure AD B2C.
  2. В разделе Действия выберите Журналы аудита.
  3. Отфильтруйте представление списка: в качестве даты выберите нужный интервал времени, а в качестве действия — вызов API в потоке пользователя.
  4. Проверьте отдельные записи в журнале. Каждая строка представляет собой попытку вызова соединителя API в потоке пользователя. Если вызов API завершается неудачей и происходит повторная попытка, она также отражается одной строкой. Атрибут numberOfAttempts указывает, сколько раз вызывался API. Возможные значения — 1 и 2. Другие сведения о вызове API подробно представлены в журналах.

Example of an API connector transaction during user authentication

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

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

Рекомендации

Убедитесь в следующем:

  • API явным образом проверяет полученные утверждения, которые ему необходимы, на наличие в них значений NULL.
  • API реализует способ проверки подлинности, описанный в статье о защите соединителя API.
  • API реагирует на операции как можно быстрее, чтобы обеспечить работу пользовательского интерфейса без задержек.
    • Если используется бессерверная функция или масштабируемая веб-служба, реализуйте план размещения, по которому API в рабочей среде постоянно будет в "пробужденном" или "теплом" состоянии. Для Функций Azure рекомендуется использовать план категории не ниже "Премиум".
  • Обеспечьте высокую доступность вашего API.
  • Отслеживайте и оптимизируйте производительность нижестоящих API, баз данных и других зависимостей вашего API.

Важно!

Ваши конечные точки должны соответствовать требованиям безопасности Azure AD B2C. Ранние версии и шифры TLS считаются нерекомендуемыми. Дополнительные сведения см. в статье Требования к комплекту шифров и TLS в Azure AD B2C.

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

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

  • Отслеживайте коды состояния HTTP, отличные от HTTP 200 и 400.
  • Код состояния HTTP 401 или 403 обычно указывает на проблему, связанную с проверкой подлинности. Дважды проверьте настроенный уровень проверки подлинности API и соответствующую конфигурацию в соединителе API.
  • При необходимости используйте более агрессивные уровни ведения журнала (например, "трассировка" или "отладка").
  • Отслеживайте работу API на предмет больших значений для времени отклика.

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