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

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

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

Существует 2 решения этой проблемы:

• Отправьте новый запрос на аутентификацию с использованием сценария сброса пароля для пользователей в 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 и используйте его для идентификации потока входа.

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

Предпосылки

• Выполните действия, описанные в статье "Начало работы с настраиваемыми политиками в Active Directory B2C".

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

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

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

Отобразить идентификатор корреляции Azure AD B2C

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

1. Откройте файл расширений вашей политики. Например, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Найдите элемент BuildingBlocks . Если элемент не существует, добавьте его.

3. Найдите элемент ClaimsSchema . Если элемент не существует, добавьте его.

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

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

5. Откройте файл доверяющей стороны вашей политики. Например, 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.

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

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

Фильтруйте журнал трассировки

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

Подведите курсор к полю фильтра и выберите Включить фильтрацию по типу, чтобы отображались только соответствующие журналы трассировки. Нажмите кнопку "Очистить X", чтобы очистить фильтр.

Сведения о журнале трассировки 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.

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

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

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

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

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

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

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

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

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

Устранение неполадок с допустимостью политики

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

Наиболее распространенная ошибка при настройке пользовательских политик — это неправильное форматирование XML. Хороший редактор XML почти необходим. Он отображает XML в родном формате, раскрашивает содержимое, автоматически заполняет общие термины, сохраняет индексированные XML-элементы и может проверять на соответствие схеме XML.

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

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

1. В VS Code выберите Файл>Предпочтения>Настройки. Дополнительные сведения см. в разделе "Параметры пользователя и рабочей области".

2. Найдите ассоциации файлов, а затем в поле Расширение выберите XML.

3. Выберите Изменить в файле settings.json.

   

4. В 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"
     }
   ]
   

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

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

В следующем случае, элемент DisplayName правильный. Но, в неправильном порядке. Значение DisplayName должно быть перед элементом Protocol . Чтобы исправить проблему, наведите курсор на элемент DisplayName, чтобы расположить элементы в правильном порядке.

Загрузка политик и валидация политик

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

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

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

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

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

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

Ожидалось, что будет шаг с порядковым номером "{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 с идентификатором...

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

В настоящее время пользователь регистрируется как пользователь клиента yourtenant.onmicrosoft.com...

Вы входите с учетной записью из арендатора, который отличается от политики, которую вы пытаетесь загрузить. Например, ваш вход с [email protected], в то время как для вашей политики 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}". Не удается сохранить другую политику с тем же идентификатором.

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

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