Solucionar problemas de políticas personalizadas do Azure AD B2C e fluxos de usuário

Erro de redefinição de senha

Esse erro ocorre quando a experiência de redefinição de senha de autoatendimento não está habilitada em um fluxo de usuário. Portanto, selecionar o link Esqueceu sua senha? Não dispara um fluxo de usuário de redefinição de senha. Em vez disso, o código AADB2C90118 de erro é retornado ao seu aplicativo.

Há 2 soluções para esse problema:

• Responda novamente com uma nova solicitação de autenticação usando o fluxo de usuário de redefinição de senha do Azure AD B2C.
  • Use a experiência recomendada de redefinição de senha de autoatendimento (SSPR).

O usuário cancelou a operação

O serviço Azure AD B2C também pode retornar um erro ao seu aplicativo quando um usuário cancela uma operação. Veja a seguir exemplos de cenários em que um usuário executa uma operação de cancelamento:

• Uma política de usuário usa a experiência recomendada de redefinição de senha de autoatendimento (SSPR) com uma conta local do consumidor. O usuário seleciona o link Esqueceu sua senha e , em seguida, seleciona o botão Cancelar antes que a experiência de fluxo do usuário seja concluída. Nesse caso, o serviço Azure AD B2C retorna o código AADB2C90091 de erro para seu aplicativo.
• Um usuário opta por autenticar com um provedor de identidade externo, como o LinkedIn. O usuário seleciona o botão Cancelar antes de autenticar no próprio provedor de identidade. Nesse caso, o serviço Azure AD B2C retorna o código AADB2C90273 de erro para seu aplicativo. Saiba mais sobre códigos de erro retornados pelo serviço Azure Active Directory B2C.

Para lidar com esse erro, busque a descrição do erro para o usuário e responda novamente com uma nova solicitação de autenticação usando o mesmo fluxo de usuário.

Se você usar políticas personalizadas do Azure AD B2C (Azure Active Directory B2C), poderá enfrentar desafios com o formato XML da linguagem de política ou problemas de runtime. Este artigo descreve algumas ferramentas e dicas que podem ajudá-lo a descobrir e resolver problemas.

Este artigo se concentra na solução de problemas da configuração de política personalizada do Azure AD B2C. Ele não aborda o aplicativo de terceira parte confiável nem sua biblioteca de identidade.

Visão geral da ID de correlação do Azure AD B2C

A ID de correlação do Azure AD B2C é um valor de identificador exclusivo anexado às solicitações de autorização. Ele passa por todas as etapas de orquestração pelas quais um usuário passa. Com a ID de correlação, você pode:

• Identifique a atividade de entrada em seu aplicativo e acompanhe o desempenho de sua política.
• Localize os logs do Azure Application Insights da solicitação de login.
• Passe a ID de correlação para sua API REST e use-a para identificar o fluxo de entrada.

A ID de correlação é alterada sempre que uma nova sessão é estabelecida. Ao depurar suas políticas, certifique-se de fechar as abas existentes do navegador ou abrir um novo navegador no modo privado.

Pré-requisitos

• Conclua as etapas em Comece a usar políticas personalizadas no Active Directory B2C.

Obter a ID de correlação do Azure AD B2C

Você pode encontrar a ID de correlação na página de inscrição ou entrada do Azure AD B2C. No navegador, selecione a origem da exibição. A correlação aparece como um comentário na parte superior da página.

Copie a ID de correlação e continue o fluxo de autenticação. Use o ID de correlação para observar o comportamento de login. Para obter mais informações, consulte Solução de problemas com o Application Insights.

Ecoar o ID de correlação do Azure AD B2C

Você pode incluir a ID de correlação em seus tokens do Azure AD B2C. Para incluir a ID de correlação:

1. Abra o arquivo de extensões da política. Por exemplo, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Pesquise o elemento BuildingBlocks . Se o elemento não existir, adicione-o.

3. Localize o elemento ClaimsSchema . Se o elemento não existir, adicione-o.

4. Adicione a declaração de ID de correlação ao elemento ClaimsSchema .

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

5. Abra o arquivo de terceira parte confiável de sua política. Por exemplo, arquivo SocialAndLocalAccounts/SignUpOrSignIn.xml. A declaração de saída será adicionada ao token após o percurso bem-sucedido do usuário e enviada ao aplicativo. Modifique o elemento de perfil técnico na seção da terceira parte confiável para adicionar correlationId como uma declaração de saída.

   <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>
   

Solução de problemas com o Application Insights

Para diagnosticar problemas com suas políticas personalizadas, use o Application Insights. O Application Insights rastreia a atividade do percurso do usuário relacionado à política personalizada. Ele fornece uma maneira de diagnosticar exceções e observar a troca de declarações entre o Azure AD B2C e os vários provedores de declarações. Os provedores de declarações são definidos por perfis técnicos, como provedores de identidade, serviços baseados em API, diretório de usuário do Azure AD B2C e outros serviços.

É recomendável instalar a extensão do Azure AD B2C para o VS Code. Com a extensão do Azure AD B2C, os logs são organizados para você por nome de política, ID de correlação (o Application Insights apresenta o primeiro dígito da ID de correlação) e o carimbo de data/hora do log. Esse recurso ajuda você a encontrar o log relevante com base no carimbo de data/hora local e ver o percurso do usuário conforme executado pelo Azure AD B2C.

Um único processo de login pode emitir mais de um rastreamento do Azure Application Insights. Na captura de tela a seguir, a política B2C_1A_signup_signin tem três logs. Cada log representa parte do fluxo de login.

A captura de tela a seguir apresenta a extensão do Azure AD B2C para o VS Code com o explorador de rastreamento do Azure Application Insights.

Filtrar o log de rastreamento

Com o foco no explorador de rastreamento do Azure AD B2C, comece a digitar o primeiro dígito do ID de correlação ou um horário que você deseja encontrar. Você vê, no canto superior direito do explorador de rastreamento do Azure AD B2C, uma caixa de filtro mostrando o que você digitou até agora, e os logs de rastreamento correspondentes são realçados.

Passar o mouse sobre a caixa de filtro e selecionar Habilitar Filtro no Tipo mostra somente os logs de rastreamento correspondentes. Use o botão Limpar 'X' para limpar o filtro.

Detalhes do log de rastreamento do Application Insights

Quando você seleciona um rastreamento do Azure Application Insights, a extensão abre a janela de detalhes do Application Insights com as seguintes informações:

• Application Insights – Informações genéricas sobre o log de rastreamento, incluindo o nome da política, a ID de correlação, a ID de rastreamento do Azure Application Insights e o carimbo de data/hora de rastreamento.
• Perfis técnicos – lista de perfis técnicos que aparecem no log de rastreamento.
• Declarações – lista alfabética de declarações que aparecem no log de rastreamento e seus valores. Se uma declaração aparecer no log de rastreamento várias vezes com valores diferentes, um => sinal designa o valor mais recente. Você pode examinar essas declarações para determinar se os valores de declaração esperados estão definidos corretamente. Por exemplo, se você tiver uma pré-condição que verifique um valor de declaração, a seção de declarações poderá ajudá-lo a determinar por que um fluxo esperado se comporta de forma diferente.
• Transformação de declarações - Lista de transformações de declarações que aparecem no log de rastreamento. Cada transformação de declarações contém as declarações de entrada, os parâmetros de entrada e as declarações de saída. A seção de transformação de declarações fornece informações sobre os dados enviados e o resultado da transformação de declarações.
• Tokens – lista de tokens que aparecem no log de rastreamento. Os tokens incluem os tokens do OAuth federado subjacente e do provedor de identidade OpenId Connect. O token do provedor de identidade federado fornece detalhes sobre como o provedor de identidade retorna as declarações para o Azure AD B2C para que você possa mapear as declarações de saída do perfil técnico do provedor de identidade.
• Exceções – lista de exceções ou erros fatais que aparecem no log de rastreamento.
• JSON do Application Insights – Os dados brutos retornados do Application Insights.

A captura de tela a seguir mostra um exemplo da janela de detalhes do log de rastreamento do Application Insights.

Solucionar problemas de JWTs

Para fins de validação e depuração do JWT, você pode decodificar JWTs usando um site como https://jwt.ms. Crie um aplicativo de teste que possa redirecionar para https://jwt.ms para inspeção de token. Se você ainda não fez isso, registre um aplicativo Web e habilite a concessão implícita do token de ID.

Use Executar agora e https://jwt.ms para testar suas políticas independentemente de seu aplicativo web ou móvel. Este site age como um aplicativo de terceira parte confiável. Ele exibe o conteúdo do JWT (token Web JSON) gerado pela política do Azure AD B2C.

Solucionar problemas de protocolo SAML

Para ajudar a configurar e depurar a integração com seu provedor de serviços, você pode usar uma extensão de navegador para o protocolo SAML, por exemplo, a extensão SAML DevTools para Chrome, o rastreamento saml para o Firefox ou as ferramentas de desenvolvedor do Edge ou Internet Explorer.

A captura de tela a seguir demonstra como a extensão SAML DevTools apresenta a solicitação SAML que o Azure AD B2C envia ao provedor de identidade e a resposta SAML.

Usando essas ferramentas, você pode verificar a integração entre seu aplicativo e o Azure AD B2C. Por exemplo:

• Verifique se a solicitação SAML contém uma assinatura e determine qual algoritmo é usado para entrar na solicitação de autorização.
• Verifique se o Azure AD B2C retorna uma mensagem de erro.
• Verifique se a seção asserção está criptografada.
• Obtenha o nome das reivindicações que retornam o provedor de identidade.

Você também pode rastrear a troca de mensagens entre o navegador cliente e o Azure AD B2C, com o Fiddler. Isso pode ajudar você a ter uma ideia de onde a jornada do usuário está falhando nas etapas de orquestração.

Solucionar problemas de validade da política

Depois de terminar de desenvolver sua política, carregue a política no Azure AD B2C. Pode haver alguns problemas com sua política, mas você pode validar sua política antes de carregá-la.

O erro mais comum na configuração de políticas personalizadas é XML formatado incorretamente. Um bom editor XML é quase essencial. Ele exibe conteúdo de XML nativamente, codifica cores, pré-filtra termos comuns, mantém os elementos XML indexados e pode validar em um esquema XML.

O uso do Visual Studio Code é recomendado. Em seguida, instale uma extensão XML, como o Suporte à Linguagem XML pelo Red Hat. A extensão XML permite validar o esquema XML antes de carregar seu arquivo XML usando a definição de esquema XSD de política personalizada.

Você pode usar a estratégia de associação de arquivo XML para associar o arquivo XML ao XSD adicionando as seguintes configurações ao arquivo VS Code settings.json . Para fazer isso:

1. No VS Code, selecione Configurações de Preferências>de Arquivo>. Para obter mais informações, consulte Configurações de Usuário e Workspace.

2. Pesquise fileAssociations e, em seguida, na Extensão, selecione o XML.

3. Selecione Editar em settings.json.

   

4. No settings.json, adicione o seguinte código 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. Salve as alterações.

O exemplo a seguir mostra um erro de validação XML. Quando você move o mouse sobre o nome do elemento, a extensão lista os elementos esperados.

No caso a seguir, o elemento DisplayName está correto. Mas, na ordem errada. O DisplayName deve ser antes do Protocol elemento. Para corrigir o problema, mova o mouse sobre o DisplayName elemento para a ordem correta dos elementos.

Políticas de upload e validação de política

A validação do arquivo de política XML é executada automaticamente no upload. A maioria dos erros faz com que o upload falhe. A validação inclui o arquivo de política que você deseja carregar. Ele também inclui a cadeia de arquivos à qual o arquivo de upload se refere (o arquivo de política da parte confiável, o arquivo de extensões e o arquivo base).

Esta seção contém os erros de validação comuns e as soluções prováveis.

Erro de validação de esquema encontrado ...tem elemento filho inválido “{name}”

Sua política contém um elemento XML inválido ou o elemento XML é válido, mas parece estar na ordem errada. Para corrigir esse tipo de erro, confira a seção Solucionar problemas de validade da política .

Há uma sequência de chaves duplicada '{number}'

Um percurso do usuário ou sub percurso consiste em uma lista ordenada de etapas de orquestração executadas em sequência. Depois de alterar seu percurso, renumere as etapas sequencialmente sem ignorar os inteiros de 1 a N.

... uma etapa com a ordem "{number}" era esperada, mas ela não foi encontrada...

Verifique o erro anterior.

A ordem da etapa de orquestração "{number}" no percurso do usuário "{name}"... é seguida por uma etapa de seleção de provedor de declarações e deve ser uma troca de declarações, mas é do tipo...

O tipo de etapas de orquestração ClaimsProviderSelection e CombinedSignInAndSignUp contém uma lista de opções que um usuário pode escolher. Ela deve seguir com o tipo de ClaimsExchange e uma ou mais trocas de declarações.

As etapas de orquestração a seguir causam esse tipo ou erro. A segunda etapa de orquestração deve ser tipo ClaimsExchange, não 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> -->

... etapa {number} com duas trocas de declarações. Ele deve ser precedido por uma seleção de provedor de declarações para determinar quais trocas de declarações podem ser usadas

Um tipo de etapa de orquestração ClaimsExchange deve ter um único ClaimsExchange, a menos que a etapa anterior seja do tipo ClaimsProviderSelection ou CombinedSignInAndSignUp. As etapas de orquestração a seguir causam esse tipo de erro. A sexta etapa contém duas trocas de declarações.

<!-- 
<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> -->

Para corrigir esse tipo de erro, use duas etapas de orquestração. Cada uma delas com uma troca de declarações.

<!-- 
<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> -->

Há uma sequência de chaves duplicada '{name}'

Um percurso tem vários ClaimsExchange com o mesmo Id. As etapas a seguir causam esse tipo de erro. O ID AADUserWrite aparece duas vezes no percurso do usuário.

<!-- 
<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> -->

Para corrigir esse tipo de erro, altere a troca de declarações das oitavas etapas de orquestração para um nome exclusivo, como 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> -->

... faz uma referência a ClaimType com a id "{claim name}", mas nem a política nem nenhuma de suas políticas base contêm esse elemento

Esse tipo de erro ocorre quando sua política faz uma referência a uma declaração que não é declarada no esquema de declarações. As reivindicações devem ser definidas em pelo menos um dos arquivos da política.

Por exemplo, um perfil técnico com a declaração de saída schoolId. No entanto, a declaração de saída schoolId nunca é declarada na política ou em uma política ancestral.

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

Para corrigir esse tipo de erro, verifique se o ClaimTypeReferenceId valor está escrito incorretamente ou se não existe no esquema. Caso a declaração esteja definida na política de extensões, mas também seja usada na política de base. Verifique se a declaração está definida na política na qual ela é usada ou em uma política de nível superior.

Adicionar a declaração ao esquema de declarações resolve esse tipo de erro.

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

...faz referência a uma ClaimsTransformation com ID...

A causa desse erro é semelhante àquela do erro de declaração. Verifique o erro anterior.

No momento, o usuário está conectado como usuário do tenant 'yourtenant.onmicrosoft.com'...

Você faz login com uma conta de um locatário diferente da política que você tenta carregar. Por exemplo, você entra com admin@contoso.onmicrosoft.com, mas sua política TenantId está definida como 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>

• Verifique se o valor TenantId nos elementos <TrustFrameworkPolicy\> e <BasePolicy\> corresponde ao locatário de destino do Azure AD B2C.

O tipo de declaração "{name}" é a declaração de saída do perfil técnico da terceira parte confiável, mas ela não é uma declaração de saída em nenhuma das etapas do percurso do usuário...

Em uma política de terceira parte confiável, você adicionou uma declaração de saída, mas ela não é uma declaração de saída em nenhuma das etapas do percurso do usuário. O Azure AD B2C não pode ler o valor da declaração no pacote de declarações.

No exemplo a seguir, a declaração schoolId é uma declaração de saída do perfil técnico da terceira parte confiável, mas não é uma declaração de saída em nenhuma das etapas do percurso do usuário SignUpOrSignIn.

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

Para corrigir esse tipo de erro, certifique-se de que as declarações de saída apareçam em pelo menos uma coleção de declarações de saída de perfil técnico das etapas de orquestração. Se a jornada do usuário não puder gerar a declaração, no perfil técnico da parte confiável, defina um valor padrão, como uma sequência de caracteres vazia.

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

A cadeia de caracteres de entrada não estava em um formato correto

Você definiu um tipo de valor incorreto para uma reivindicação de outro tipo. Por exemplo, você define uma reivindicação inteira.

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

Em seguida, você tenta definir um valor de cadeia de caracteres:

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

Para corrigir esse tipo de erro, defina o valor correto, como DefaultValue="0".

O locatário "{name}" já tem uma política com a ID "{name}". Outra política com a mesma ID não pode ser armazenada

Você tenta carregar uma política em seu locatário, mas outra com o mesmo nome já foi carregada nele.

Para corrigir esse tipo de erro, selecione a caixa de seleção Substituir a política personalizada se ela já existir ao carregar a política.