Устранение неполадок с потоками пользователей и настраиваемыми политиками Azure AD B2C

Статья
11/20/2023

Для начала с помощью селектора Choose a policy type (Выбрать тип политики) выберите тип пользовательской политики. Azure Active Directory B2C предлагает два метода определения способа взаимодействия пользователей с вашими приложениями: с помощью предопределенных потоков пользователей или полностью настраиваемых пользовательских политик. Действия, которые необходимо выполнить, отличаются для каждого метода.

Приложению необходимо обработать определенные ошибки, сообщения о которых поступают от службы Azure B2C. В этой статье описываются некоторые распространенные ошибки и способы их устранения.

Ошибка сброса пароля

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

Эту проблему можно устранить двумя способами.

Ответ на новый запрос проверки подлинности с помощью потока пользователя Azure AD B2C для сброса пароля.
Используйте рекомендуемый интерфейс самостоятельного сброса пароля (SSPR).

Пользователь отменил операцию

Служба Azure AD B2C также может возвращать ошибку в приложение, когда пользователь отменяет операцию. Ниже приведены примеры сценариев, в которых пользователь выполняет операцию отмены.

Политика пользователя использует рекомендуемый интерфейс самостоятельного сброса пароля (SSPR) с локальной учетной записью потребителя. Пользователь выбирает ссылку Forgot your password?, а затем нажимает кнопку "Отмена", прежде чем процесс потока пользователя завершится. В этом случае служба Azure AD B2C возвращает в приложение код ошибки AADB2C90091.
Пользователь выбирает проверку подлинности с помощью внешнего поставщика удостоверений, например LinkedIn. Пользователь нажмет кнопку Отмена перед проверкой подлинности в самом поставщике удостоверений. В этом случае служба Azure AD B2C возвращает в приложение код ошибки AADB2C90273. Дополнительные сведения о кодах ошибок, возвращаемых службой Azure Active Directory B2C, приведены здесь.

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

При использовании настраиваемых политик Azure Active Directory B2C (Azure AD B2C) могут возникать проблемы с форматом языка XML или средой выполнения политик. В этой статье вы ознакомитесь с инструментами и подсказками, которые помогут вам обнаружить и решить эти проблемы.

Мы рассмотрим устранение неполадок, связанных с настройками пользовательских политик Azure AD B2C. В этой статье не рассматривается приложение проверяющей стороны или его библиотека удостоверений.

Общие сведения об идентификаторе корреляции Azure AD B2C

Идентификатор корреляции Azure AD B2C — это уникальное значение идентификатора, которое связывается с запросами авторизации. Он проходит через все этапы оркестрации, которые проходит пользователь. С помощью идентификатора корреляции можно:

выявлять действия входа в приложении и наблюдать за эффективностью политики;
находить журналы Azure Application Insights для запроса на вход;
передавать идентификатор корреляции REST API и использовать его для идентификации потока входа.

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

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

Выполните шаги, описанные в статье Начало работы с настраиваемыми политиками в Azure Active Directory B2C.

Получение идентификатора корреляции Azure AD B2C

Идентификатор корреляции можно найти на странице регистрации или входа Azure AD B2C. В браузере выберите Просмотр источника. Корреляция отображается в виде комментария в верхней части страницы.

Screenshot of Azure AD B2C sign-in page view source.

Скопируйте идентификатор корреляции, а затем продолжайте процесс входа. Используйте идентификатор корреляции для отслеживания поведения при входе. Дополнительные сведения см. в статье, посвященной устранению неполадок для Application Insights.

Проверка связи с идентификатором корреляции Azure AD B2C

Идентификатор корреляции можно включать в маркеры Azure AD B2C. Чтобы включить идентификатор корреляции, выполните указанные ниже действия.

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

Добавьте утверждение идентификатора корреляции в элемент ClaimsSchema.

<!-- 
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="correlationId">
      <DisplayName>correlation ID</DisplayName>
      <DataType>string</DataType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks>-->

Откройте файл проверяющей стороны политики. Пример: SocialAndLocalAccounts/SignUpOrSignIn.xml. Исходящее утверждение будет добавлено в маркер после успешного пути взаимодействия пользователя и отправлено в приложение. Измените элемент технического профиля в разделе проверяющей стороны, чтобы добавить correlationId в качестве исходящего утверждения.
```
<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      ...
      <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>
```

Устранение неполадок с Application Insights

Для диагностики проблем с настраиваемыми политиками используйте Application Insights. Application Insights отслеживает действия в рамках пути взаимодействия пользователя настраиваемой политики. Он предоставляет способ диагностики исключений и наблюдения за обменом утверждениями между Azure AD B2C и различными поставщиками утверждений. Поставщики утверждений определяются техническими профилями, такими как поставщики удостоверений, службы на основе API, каталог пользователя Azure AD B2C и другие службы.

Рекомендуется установить расширение Azure AD B2C для VS Code. При использовании расширения Azure AD B2C журналы упорядочиваются по имени политики, идентификатору корреляции (Application Insights представляет первую цифру идентификатора корреляции) и метке времени журнала. Эта функция позволяет найти соответствующий журнал на основе локальной метки времени и отследить путь взаимодействия пользователя в рамках Azure AD B2C.

Примечание.

Существует небольшая задержка, как правило, менее чем за пять минут, прежде чем вы увидите новые журналы в Приложении Аналитика.
Сообщество разработало расширение Visual Studio Code для Azure AD B2C, чтобы помочь разработчикам служб идентификации. Расширение не поддерживается корпорацией Майкрософт и предоставляется строго как есть.

Один поток входа может выдавать несколько трассировок Azure Application Insights. На снимке экрана ниже у политики B2C_1A_signup_signin три журнала. Каждый журнал представляет определенную часть потока входа.

На следующем снимке экрана показано расширение Azure AD B2C для VS Code в обозревателе трассировки Azure Application Insights.

Screenshot of Azure AD B2C extension for VS Code with Azure Application Insights trace.

Фильтрация журнала трассировки

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

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter highlighting.

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

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter.

Детали журнала трассировки Application Insights

При выборе трассировки Azure Application Insights расширение открывает окно сведений Application Insights со следующими данными:

Application Insights — общие сведения о журнале трассировки, включая имя политики, идентификатор корреляции, идентификатор трассировки Azure Application Insights и метку времени трассировки.
Технические профили — список технических профилей, которые отображаются в журнале трассировки.
Утверждения — алфавитный список утверждений, которые есть в журнале трассировки, и их значения. Если утверждение встречается в журнале трассировки несколько раз с разными значениями, то знак => обозначает самое новое из них. Вы можете проверить эти утверждения, чтобы определить, правильно ли заданы ожидаемые значения. Например, если у вас есть предусловие, проверяющее значение утверждения, раздел утверждений поможет определить, почему поток выполняется не так, как ожидается.
Преобразование утверждений — список преобразований утверждений, которые отображаются в журнале трассировки. Каждое преобразование утверждения содержит входящие утверждения, входные параметры и исходящие утверждения. В разделе преобразования утверждений содержатся сведения об отправленных данных и результатах преобразования утверждений.
Маркеры — список маркеров, которые отображаются в журнале трассировки. Сюда относятся базовые маркеры федеративного поставщика OAuth и маркеры поставщика удостоверений OpenID Connect. Маркер федеративного поставщика удостоверений содержит подробные сведения о том, как поставщик возвращает утверждения в Azure AD B2C, на основании чего можно сопоставить исходящие утверждения технического профиля поставщика удостоверений.
Исключения — список исключений или неустранимых ошибок, которые отображаются в журнале трассировки.
JSON-код Application Insights — необработанные данные, возвращаемые из Application Insights.

На следующем снимке экрана показан пример окна сведений журнала трассировки Application Insights.

Screenshot of Azure AD B2C extension Azure AD B2C trace report.

Устранение неполадок с маркерами JWT

Для проверки и отладки маркеров JWT разработчики могут декодировать JWT через https://jwt.ms или другой аналогичный сайт. Создайте тестовое приложение, которое может выполнять перенаправление на https://jwt.ms для проверки маркера. Если вы еще этого не сделали, зарегистрируйте веб-приложение и включите неявное предоставление маркера идентификации.

Screenshot of JWT token preview.

Используйте параметры Запустить сейчас и https://jwt.ms, чтобы проверить свои политики независимо от мобильного приложения или веб-приложения. Этот веб-сайт работает как приложение проверяющей стороны. В нем отображается содержимое веб-маркера JSON (JWT), которое создает политика Azure AD B2C.

Устранение неполадок с протоколом SAML

Чтобы настроить и отладить интеграцию с поставщиком услуг, можно использовать расширение браузера для протокола SAML, например SAML DevTools для Chrome, SAML-трассировщик для FireFox или средства разработчика для Edge или IE.

На следующем снимке экрана показано, как в расширении SAML DevTools отображается запрос SAML, который Azure AD B2C отправляет поставщику удостоверений, а также ответ SAML.

Screenshot of SAML protocol trace log.

С помощью этих средств можно проверить интеграцию приложения с Azure AD B2C. Например:

Проверьте, содержит ли запрос SAML подпись, и определите, какой алгоритм используется для входа в запрос авторизации.
Проверьте, возвращает ли Azure AD B2C сообщение об ошибке.
Проверьте, зашифрован ли раздел утверждения.
Просмотрите имя утверждения, возвращаемое поставщиком удостоверений.

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

Устранение неполадок, связанных с допустимостью политики

Завершив разработку политики, вы отправляете ее в Azure AD B2C. В политике могут возникнуть некоторые проблемы, но перед отправкой политики вы можете действительность политики.

Самой распространенной ошибкой при настройке пользовательских политик является неправильный формат XML. Вам нужен хороший редактор XML. Он отображает XML-коды в собственном коде, содержимое цветных кодов, предварительно заполняет общие термины, сохраняет индексированные XML-элементы и может проверяться на основе схемы XML.

Рекомендуется использовать Visual Studio Code. Затем установите расширение XML, например для поддержки языка XML от Red Hat. Расширение XML позволяет проверить схему XML перед отправкой XML-файла на основе определения схемы XSD настраиваемой политики.

С помощью стратегии связывания XML-файлов такой файл можно привязать к XSD, добавив в файл settings.json VS Code указанные ниже параметры. Для этого:

В VS Code выберите параметры> файла>Параметры. Дополнительные сведения см. в статье о параметрах пользователя и рабочей области.
Выполните поиск по запросу fileAssociations, а затем в разделе Расширение выберите XML.
Выберите Изменить в settings.json.

В файле settings.json добавьте следующий код JSON:

"xml.fileAssociations": [
  {
    "pattern": "**.xml",
    "systemId": "https://raw.githubusercontent.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/master/TrustFrameworkPolicy_0.3.0.0.xsd"
  }
]

Сохраните изменения.

В следующем примере показана ошибка проверки XML. При наведении указателя мыши на имя элемента в расширении перечисляются ожидаемые элементы.

Screenshot of VS Code XML schema validation error indicator.

В следующем случае элемент DisplayName является правильным. При этом ошибка заключается в порядке. Элемент DisplayName должен находиться перед элементом Protocol. Чтобы устранить эту проблему, перетащите элемент DisplayName мышью в правильное место в последовательности.

Screenshot of VS Code XML schema validation order error.

Передача политик и их проверка

Проверка файла политики XML выполняется автоматически при передаче. Большинство ошибок приводят к сбою отправки. Проверка включает файл политики, который требуется отправить. Она также включает цепочку файлов, с которыми связан файл для отправки (файл политики проверяющей стороны, файл расширения и базовый файл).

Совет

Azure AD B2C выполняет дополнительную проверку для политики проверяющей стороны. Если с политикой возникла проблема, даже в случае изменения только политики расширения рекомендуется также передавать политику проверяющей стороны.

В этом разделе описаны распространенные ошибки, возникающие при проверке, и их возможные решения.

Обнаружена ошибка проверки схемы. ... имеет недопустимый дочерний элемент "{name}"

Политика содержит недопустимый XML-элемент, или XML-элемент является допустимым, но находится в неправильном месте последовательности. Чтобы исправить такую ошибку, ознакомьтесь с разделом Устранение неполадок, связанных с допустимостью политики.

Присутствует повторяющаяся последовательность ключей "{number}"

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

Совет

Чтобы перенумеровать все шаги оркестрации в пути взаимодействия пользователя и его элементах в политике, можно воспользоваться командой расширения Azure AD B2C для VS Code(Shift+Ctrl+r).

... ожидается, что шаг с порядком "{number}", но он не найден...

См. предыдущую ошибку.

За шагом оркестрации "{number}" в пути взаимодействия пользователя "{name}"... следует шаг выбора поставщика утверждений, который должен быть операцией обмена утверждениями, но имеет тип...

Шаги оркестрации типов ClaimsProviderSelection и CombinedSignInAndSignUp содержат список вариантов, из которых пользователь может выбрать нужный. За этим шагом должен следовать шаг типа ClaimsExchange с одной или несколькими операциями обмена утверждениями.

Это ошибка возникает с указанными ниже шагами оркестрации. Второй шаг оркестрации должен иметь тип ClaimsExchange, а не ClaimsProviderSelection.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/>
          <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange"/>
        </ClaimsProviderSelections>
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email"/>
        </ClaimsExchanges>
      </OrchestrationStep> 

      <OrchestrationStep Order="2" Type="ClaimsProviderSelection">
        ...
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... шаг {number} с 2 операциями обмена утверждениями. Ему должен предшествовать выбор поставщика утверждений для определения способа обмена утверждениями.

У шага оркестрации типа ClaimsExchange должен быть один элемент ClaimsExchange, если только предыдущий шаг не относится к типу ClaimsProviderSelection или CombinedSignInAndSignUp. Это ошибка возникает с указанными ниже шагами оркестрации. Шестой шаг содержит две операции обмена утверждениями.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

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

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Присутствует повторяющаяся последовательность ключей "{name}"

В пути взаимодействия несколько элементов ClaimsExchange с одним значением Id. Эта ошибка возникает на указанных ниже шагах. Идентификатор AADUserWrite дважды встречается в пути взаимодействия пользователя.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Чтобы исправить такую ошибку, измените название операции обмена утверждениями на восьмом шаге оркестрации на уникальное значение, например Call-REST-API.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-API" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

...ссылается на ClaimType с идентификатором "{имя утверждения}", но ни политика, ни ее базовые политики не содержат такого элемента

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

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

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="schoolId" />
  ...
</OutputClaims>

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

Устранить такую ошибку можно путем добавления утверждения в схему утверждений.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="schoolId">
      <DisplayName>School name</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your school name</UserHelpText>
      <UserInputType>TextBox</UserInputType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks> -->

...ссылается на ClaimsTransformation с идентификатором...

Причина этой ошибки аналогична причине ошибки утверждения. См. предыдущую ошибку.

Пользователь в данный момент вошел в качестве пользователя арендатора "ваш-арендатор.onmicrosoft.com"...

Вы входите с учетной записью из клиента, который отличается от политики, которую вы пытаетесь отправить. Например, вход с admin@contoso.onmicrosoft.comпомощью учетной записью , а для политики TenantId задано значение fabrikam.onmicrosoft.com.

<TrustFrameworkPolicy ...
  TenantId="fabrikam.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>fabrikam.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  ...
</TrustFrameworkPolicy>

Убедитесь, что значение параметра TenantId в элементах <TrustFrameworkPolicy\> и <BasePolicy\> соответствует целевому арендатору Azure AD B2C.

Утверждение "{name}" — это исходящее утверждение технического профиля проверяющей стороны, но оно не является исходящим утверждением ни в одном из шагов пути взаимодействия пользователя...

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

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

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="schoolId" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

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

<OutputClaim ClaimTypeReferenceId="schoolId" DefaultValue="" />

Входная строка была указана в неправильном формате

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

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="age">
      <DisplayName>Age</DisplayName>
      <DataType>int</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

Затем вы попытались задать для него строковое значение:

<OutputClaim ClaimTypeReferenceId="age" DefaultValue="ABCD" />

Чтобы исправить такую ошибку, задайте допустимое значение, например DefaultValue="0".

У арендатора "{name}" уже есть политика с идентификатором "{name}". Невозможно сохранить другую политику с тем же идентификатором

Вы пытаетесь отправить политику в арендатор, но политика с таким именем уже была отправлена туда ранее.

Чтобы исправить эту ошибку, при отправке политики установите флажок Перезаписать настраиваемую политику, если она уже существует.

Screenshot that demonstrates how to overwrite the custom policy if it already exists.

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

Узнайте, как получить журналы Azure Active Directory B2C с помощью Application Insights.