Formação
Percurso de aprendizagem
Arquiteto de Soluções: projetar soluções do Microsoft Power Platform - Training
Aprenda como um arquiteto de soluções projeta soluções.
Este browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
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.
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:
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:
AADB2C90091
de erro para seu aplicativo.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.
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:
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.
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.
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.
Você pode incluir a ID de correlação em seus tokens do Azure AD B2C. Para incluir o ID de correlação:
Abra o arquivo de extensões da sua política. Por exemplo, SocialAndLocalAccounts/
TrustFrameworkExtensions.xml
.
Procure o elemento BuildingBlocks . Se o elemento não existir, adicione-o.
Localize o elemento ClaimsSchema . Se o elemento não existir, adicione-o.
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>-->
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>
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
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.
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.
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.
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:
=>
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.A captura de tela a seguir mostra um exemplo da janela de detalhes do log de rastreamento do Application Insights.
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.
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.
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.
Usando essas ferramentas, você pode verificar a integração entre seu aplicativo e o Azure AD B2C. Por exemplo:
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.
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:
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.
Procure fileAssociações e, em seguida, em Extensão, selecione o XML.
Selecione Editar em settings.json.
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"
}
]
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.
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.
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.
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.
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.
Verifique o erro anterior.
As etapas de orquestração são do tipo , e CombinedSignInAndSignUp
contêm uma lista de ClaimsProviderSelection
opçõ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 ClaimsExchange
orquestraçã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> -->
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> -->
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> -->
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> -->
A causa para este erro é semelhante à do erro de declaração. Verifique o erro anterior.
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>
TenantId
valor nos elementos e <BasePolicy\>
corresponde ao <TrustFrameworkPolicy\>
seu locatário de destino do Azure AD B2C.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="" />
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"
.
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 .
Formação
Percurso de aprendizagem
Arquiteto de Soluções: projetar soluções do Microsoft Power Platform - Training
Aprenda como um arquiteto de soluções projeta soluções.