Partilhar via

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

  • Artigo

Antes de começar, use o seletor Escolha um tipo de política para escolher o tipo de política que você está configurando. O Azure Ative Directory B2C oferece dois métodos para definir como os usuários interagem com seus aplicativos: por meio de fluxos de usuário predefinidos ou por meio de políticas personalizadas totalmente configuráveis. As etapas exigidas neste artigo são diferentes para cada método.

Seu aplicativo precisa lidar com determinados erros provenientes do serviço B2C do Azure. Este artigo destaca alguns dos erros comuns e como lidar com eles.

Erro de redefinição de senha

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

Existem 2 soluções para este problema:

  • Responda 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. A seguir estão 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 de 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 se 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 os códigos de erro de retorno do serviço Azure Ative Directory B2C.

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

Se você usar políticas personalizadas do Azure Ative Directory B2C (Azure AD B2C), poderá enfrentar desafios com problemas de linguagem de política, formato XML ou tempo de execução. 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 ou sua biblioteca de identidades.

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 que um usuário passa. Com o ID de correlação, você pode:

  • Identifique a atividade de início de sessão na sua aplicação e acompanhe o desempenho da sua política.
  • Encontre os logs do Azure Application Insights da solicitação de entrada.
  • 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 guias existentes do navegador ou abrir um novo navegador no modo privado.

Pré-requisitos

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 fonte de visualização. A correlação aparece como um comentário na parte superior da página.

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

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

Ecoar a 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 o ID de correlação:

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

  2. Procure 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 da sua política. Por exemplo, SocialAndLocalAccounts/SignUpOrSignIn.xml arquivo. A declaração de saída será adicionada ao token após uma jornada de usuário bem-sucedida e enviada para o aplicativo. Modifique o elemento de perfil técnico na seção terceira parte confiável para adicionar a correlationId declaração como 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 da jornada do usuário da 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, o diretório de usuário do Azure AD B2C e outros serviços.

Recomendamos instalar a extensão do Azure AD B2C para 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 localizar o log relevante com base no carimbo de data/hora local e ver a jornada do usuário conforme executada pelo Azure AD B2C.

Nota

  • Há um pequeno atraso, geralmente menos de cinco minutos, antes que você possa ver novos logs no Application Insights.
  • A comunidade desenvolveu a extensão Visual Studio Code para o Azure AD B2C para ajudar os desenvolvedores de identidade. A extensão não é suportada pela Microsoft e é disponibilizada estritamente no estado em que se encontra.

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

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

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

Filtrar o registo de rastreio

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

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

Passar o cursor sobre a caixa de filtro e selecionar Ativar filtro no tipo mostra apenas os logs de rastreamento correspondentes. Use o botão 'X' Limpar para limpar o filtro.

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

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 do 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 designará o valor mais recente. Você pode revisar 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 verifica o valor de uma declaração, a seção de declarações pode 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, parâmetros de entrada e 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 o OAuth federado subjacente e os tokens do provedor de identidade OpenId Connect. O token do provedor de identidade federada fornece detalhes sobre como o provedor de identidade retorna as declarações ao 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 que os retornos do Application Insights.

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

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

Solucionar problemas de tokens JWT

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

Screenshot of JWT token preview.

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

Solucionar problemas do 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, extensão SAML DevTools para Chrome, SAML-tracer para FireFox ou ferramentas de desenvolvedor Edge ou IE.

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.

Screenshot of SAML protocol trace log.

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 de asserção está criptografada.
  • Obtenha o nome das declarações que retornam o provedor de identidade.

Você também pode rastrear a troca de mensagens entre seu navegador cliente e o Azure AD B2C, com o Fiddler. Ele pode ajudá-lo a obter uma indicação de onde sua jornada do usuário está falhando em suas etapas de orquestração.

Solucionar problemas de validade da política

Depois de concluir o desenvolvimento da política, carregue-a para o Azure AD B2C. Pode haver alguns problemas com sua política, mas você pode validá-la 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 XML nativamente, conteúdo de códigos de cores, pré-preenche termos comuns, mantém elementos XML indexados e pode validar em relação a um esquema XML.

Recomendamos o uso do Visual Studio Code. Em seguida, instale uma extensão XML, como XML Language Support da Red Hat. A extensão XML permite validar o esquema XML antes de carregar o 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 vincular o arquivo XML XSD adicionando as seguintes configurações ao seu arquivo VS Code settings.json . Para tal:

  1. No VS Code, selecione Configurações de preferências>de arquivo>. Para obter mais informações, consulte Configurações de usuário e espaço de trabalho.

  2. Procure fileAssociações e, em seguida, em Extensão, selecione o XML.

  3. Selecione Editar em settings.json.

    Screenshot of VS Code XML schema validation.

  4. Em 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. Guarde 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.

Screenshot of VS Code XML schema validation error indicator.

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

Screenshot of VS Code XML schema validation order error.

Políticas de carregamento e validação de políticas

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

Gorjeta

O Azure AD B2C executa validação adicional para a política de terceira parte confiável. Ao ter um problema com sua política, mesmo que você edite apenas a política de extensão, é uma boa prática carregar a política de terceira parte confiável também.

Esta secçã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, consulte a seção Solucionar problemas de validade da política.

Existe uma sequência de chaves duplicada '{número}'

Uma jornada ou subjornada do usuário consiste em uma lista ordenada de etapas de orquestração que são executadas em sequência. Depois de alterar sua jornada, renumere as etapas sequencialmente sem pular nenhum número inteiro de 1 para N.

Gorjeta

Você pode usar a extensão do Azure AD B2C para o comando VS Code(Shift+Ctrl+r) para renumerar todas as etapas de orquestração de jornadas e subjornadas do usuário em sua política.

... esperava-se que tivesse passo com a ordem "{número}", mas não foi encontrado...

Verifique o erro anterior.

Ordem de passos de orquestração "{número}" na jornada do usuário "{nome}" ... é seguido por uma etapa de seleção do provedor de sinistros e deve ser uma troca de sinistros, mas é do tipo...

As etapas de orquestração são do tipo , e CombinedSignInAndSignUp contêm uma lista de ClaimsProviderSelectionopções que um usuário pode escolher. Deve seguir-se por tipo de com uma ou mais trocas de ClaimsExchange sinistros.

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

... passo {número} com 2 trocas de sinistros. Deve ser precedida de uma seleção do fornecedor de sinistros para determinar qual troca de sinistros pode ser usada

Um tipo de etapa de orquestração deve ClaimsExchange 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 sinistros.

<!-- 
<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 etapa de orquestração com uma troca de reivindicaçõ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> -->

Existe uma sequência de chaves duplicada '{name}'

Uma viagem tem várias ClaimsExchange com o mesmo Id. As etapas a seguir causam esse tipo de erro. O ID AADUserWrite aparece duas vezes na jornada 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 id "{claim name}", mas nem a política nem nenhuma de suas políticas básicas contém tal elemento

Esse tipo de erro acontece quando sua política faz referência a uma declaração que não é declarada no esquema de declarações. As declaraçõ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 . Mas 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. Se a declaração estiver definida na política de extensões, mas também estiver sendo usada na política base. Verifique se a declaração está definida na política em que é 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 um ClaimsTransformation com ID...

A causa para este erro é semelhante à do erro de declaração. Verifique o erro anterior.

O usuário está atualmente registrado como um usuário do locatário 'yourtenant.onmicrosoft.com'...

Inicia sessão com uma conta de um inquilino diferente da política que tenta carregar. Por exemplo, inicie sessão com admin@contoso.onmicrosoft.com, enquanto a 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 TenantId valor nos elementos e <BasePolicy\> corresponde ao <TrustFrameworkPolicy\> seu 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 não é uma declaração de saída em nenhuma das etapas da jornada do usuário...

Em uma política de terceira parte confiável, você adicionou uma declaração de saída, mas a declaração de saída não é uma declaração de saída em nenhuma das etapas da jornada do usuário. O Azure AD B2C não pode ler o valor da declaração do 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 da jornada 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, verifique se as declarações de saída aparecem em pelo menos uma coleção de declarações de saída de perfil técnico de uma etapa de orquestração. Se a jornada do usuário não puder gerar a declaração, no perfil técnico da terceira parte confiável, defina um valor padrão, como cadeia de caracteres vazia.

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

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

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

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

Em seguida, tente definir um valor de cadeia de caracteres:

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

Para corrigir esse tipo de erro, certifique-se de definir o valor correto, como DefaultValue="0".

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

Tenta carregar uma política para o seu inquilino, mas uma política com o mesmo nome já foi carregada para o seu inquilino.

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

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

Próximos passos