Visão geral da política personalizada do Azure AD B2C

As políticas personalizadas são arquivos de configuração que definem o comportamento do locatário do Azure AD B2C (Azure Active Directory B2C). Embora os fluxos dos usuários sejam predefinidos no portal do Azure AD B2C para as tarefas mais comuns de identidade, um desenvolvedor de identidade pode editar políticas personalizadas para concluir diversas tarefas diferentes.

Uma política personalizada é totalmente configurável e controlada por política. Uma política personalizada orquestra a confiança entre as entidades nos protocolos padrão. Por exemplo, OpenID Connect, OAuth, SAML e alguns não padrão, como trocas de declarações de sistema para sistema baseadas na API REST. A estrutura cria experiências fáceis de usar e rotuladas em branco.

Uma política personalizada é representada como um ou vários arquivos formatados em XML que se referenciam entre si em uma cadeia hierárquica. Os elementos XML definem os blocos de construção, a interação com o usuário e outras partes e a lógica de negócios.

Pacote de início de política personalizada

O pacote de início de política personalizada do Azure AD B2C já tem várias políticas predefinidas para ajudá-lo a começar rapidamente. Cada um desses pacotes de início contém o menor número de perfis de técnicos e percurso do usuário necessários para alcançar os cenários descritos:

  • LocalAccounts – permite o uso apenas de contas locais.
  • SocialAccounts – permite o uso apenas de contas sociais (ou federadas).
  • SocialAndLocalAccounts – permite o uso de contas locais e de contas sociais. A maioria das amostras se referem a essa política.
  • SocialAndLocalAccountsWithMFA – habilita opções de autenticação locais, sociais e multifator.

No repositório GitHub de exemplos do Azure AD B2C,são encontrados exemplos para vários percursos e cenários do usuário CIAM personalizados do Azure AD B2C aprimorados. Por exemplo, aprimoramentos de política de conta local, aprimoramentos de política de conta de rede social, aprimoramentos de MFA, aprimoramentos de interface do usuário, aprimoramentos genéricos, migração de aplicativos, migração de usuários, acesso condicional, teste na Web e CI/CD.

Para entender as noções básicas

Declarações

Uma declaração fornece armazenamento temporário de dados durante uma execução de política do Azure AD B2C. As declarações são mais como variáveis em uma linguagem de programação. Ela pode armazenar informações sobre o usuário, como nome, sobrenome ou outra declaração obtida do usuário ou de outros sistemas (trocas de declarações). O esquema de declarações é o lugar em que você declara suas declarações.

Quando a política é executada, o Azure AD B2C envia e recebe declarações de e para partes internas e externas e envia um subconjunto dessas declarações para o aplicativo de terceira parte confiável como parte do token. As declarações são usadas das seguintes maneiras:

  • Uma declaração é salva, lida ou atualizada no objeto de usuário do diretório.
  • Uma declaração é recebida de um provedor de identidade externo.
  • As declarações são enviadas ou recebidas usando um serviço de API REST personalizado.
  • Os dados são coletados como declarações do usuário durante os fluxos de inscrição ou edição de perfil.

Manipular as declarações

As transformações de declarações são funções predefinidas que podem ser usadas para converter uma determinada declaração em outra, avaliar uma declaração ou definir um valor de declaração. Por exemplo, adicionar um item a uma coleção de cadeias de caracteres, alterar maiúsculas e minúsculas de uma cadeia de caracteres ou avaliar uma declaração de data e hora. Uma transformação de declarações especifica um método de transformação, que também é predefinido.

Personalizar e localizar a interface do usuário

Para coletar informações dos usuários introduzindo uma página no navegador da Web, use o perfil técnico autodeclarado. Você pode editar o perfil técnico autodeclarado para adicionar declarações e personalizar a entrada do usuário.

Para personalizar a interface do usuário para o perfil técnico autodeclarado, especifique uma URL no elemento de definição de conteúdo com conteúdo HTML personalizado. No perfil técnico autodeclarado, você aponta para essa ID de definição de conteúdo.

Para personalizar cadeias de caracteres específicas do idioma, use o elemento localização. A definição de conteúdo pode conter um elemento localização que especifica uma lista de recursos localizados a serem carregados. O Azure AD B2C mescla os elementos da interface do usuário com o conteúdo HTML carregado da URL e exibe a página ao usuário.

Visão geral da política de terceira parte confiável

Um aplicativo de terceira parte confiável, que no protocolo SAML é conhecido como um provedor de serviços, chama a política de terceira parte confiável para executar um percurso de usuário específico. A política de terceira parte confiável especifica o percurso do usuário a ser executado e a lista de declarações que o token inclui.

Diagram showing the policy execution flow

Todos os aplicativos de terceira parte confiável que usam a mesma política recebem as mesmas declarações de token e o usuário passa pelo mesmo percurso do usuário.

Percursos do usuário

Os percursos do usuário permitem que você defina a lógica de negócios com o caminho pelo qual o usuário segue para obter acesso ao aplicativo. O usuário é levado pelo percurso do usuário para recuperar as declarações que devem ser apresentadas ao aplicativo. O percurso do usuário é composto de uma sequência de etapas de orquestração. Um usuário deve chegar até a última etapa para adquirir um token.

As instruções a seguir descrevem como você pode adicionar etapas de orquestração à política de pacote de inicialização de conta social e local. Este é um exemplo de uma chamada à API REST que foi adicionada.

customized user journey

Etapas de orquestração

A etapa de orquestração faz referência a um método que implementa a finalidade ou funcionalidade pretendida. Esse método é chamado de perfil técnico. Quando o percurso do usuário precisa de ramificação para representar melhor a lógica de negócios, a etapa de orquestração faz referência ao subpercurso. Um subpercurso contém seu próprio conjunto de etapas de orquestração.

O usuário deve acessar a última etapa de orquestração no percurso do usuário para adquirir um token. Mas talvez os usuários não precisem percorrer todas as etapas de orquestração. As etapas de orquestração podem ser executadas condicionalmente com base nas condições prévias definidas na etapa de orquestração.

Após a conclusão de uma etapa de orquestração, o Azure AD B2C armazena as declarações de saída no recipiente de declarações. As declarações no recipiente de declarações podem ser utilizadas por outras etapas de orquestração no percurso do usuário.

O diagrama a seguir mostra como as etapas de orquestração do percurso do usuário podem acessar o recipiente de declarações.

Azure AD B2C user journey

Perfil técnico

Um perfil técnico fornece uma interface para se comunicar com diferentes tipos de partes. Um percurso do usuário combina a chamada de perfis técnicos por meio de etapas de orquestração para definir a lógica de negócios.

Todos os tipos de perfis técnicos compartilham o mesmo conceito. Você envia declarações de entrada, executa transformação de declaração e se comunica com a parte configurada. Depois que o processo for concluído, o perfil técnico retornará as declarações de saída para o recipiente de declarações. Para obter mais informações, confira visão geral de perfis técnicos.

Perfil técnico de validação

Quando um usuário interage com a interface do usuário, você pode optar por validar os dados coletados. Para interagir com o usuário, um perfil técnico autodeclarado deve ser usado.

Para validar a entrada do usuário, um perfil técnico de validação é chamado do perfil técnico autodeclarado. Um perfil técnico de validação é um método para chamar um perfil técnico não interativo. Nesse caso, o perfil técnico pode retornar declarações de saída ou uma mensagem de erro. A mensagem de erro é renderizada para o usuário na tela, permitindo que o usuário tente novamente.

O diagrama a seguir ilustra como o Azure AD B2C usa um perfil técnico de validação para validar as credenciais do usuário.

Validation technical profile diagram

Modelo de herança

Cada pacote de início inclui os seguintes arquivos:

  • Um arquivo de Base que contém a maioria das definições. Para ajudar na solução de problemas e na manutenção de longo prazo das políticas, tente minimizar o número de alterações feitas nesse arquivo.
  • Um arquivo de localização que armazena as cadeias de caracteres de localização. Esse arquivo de política é derivado do arquivo de Base. Use esse arquivo para acomodar idiomas diferentes para atender às suas necessidades de clientes.
  • Um arquivo de Extensões que contém as alterações de configuração exclusivas para seu locatário. Este arquivo de política é derivado do arquivo de Localização. Use esse arquivo para adicionar novas funcionalidades ou substituir a funcionalidade existente. Por exemplo, use esse arquivo para federar com novos provedores de identidade.
  • Um arquivo RP (Terceira Parte Confiável) que é o único arquivo centrado em tarefa invocado diretamente pelo aplicativo de terceira parte confiável, como seus aplicativos Web, móveis ou da área de trabalho. Cada tarefa exclusiva, como inscrição, entrada ou edição de perfil, requer o próprio arquivo de política de terceira parte confiável. Este arquivo de política é derivado do arquivo de Extensões.

O modelo de herança é assim:

  • A política filho em qualquer nível pode herdar de política pai e estendê-la adicionando novos elementos.
  • Para cenários mais complexos, você pode adicionar mais níveis de herança (até 10 no total).
  • Você pode adicionar mais políticas de terceira parte confiável. Por exemplo, excluir conta, alterar um número de telefone, política de terceira parte confiável SAML e muito mais.

O diagrama a seguir mostra a relação entre os arquivos de política e os aplicativos de terceira parte confiável.

Diagram showing the trust framework policy inheritance model

Diretrizes e melhores práticas

Práticas recomendadas

Em uma política personalizada do Azure AD B2C, você pode integrar a própria lógica de negócios para criar as experiências do usuário necessárias e estender a funcionalidade do serviço. Temos um conjunto de melhores práticas e recomendações para começar.

  • Crie sua lógica dentro da política de extensãoou da política de terceira parte confiável. Você pode adicionar novos elementos, que substituem a política base ao fazer referência à mesma ID. Essa abordagem permite escalar horizontalmente o projeto, facilitando ao mesmo tempo a atualização da política base mais tarde, caso a Microsoft lance novos pacotes de início.
  • Na política de base, é altamente recomendável evitar fazer qualquer alteração. Quando necessário, faça comentários onde as alterações forem feitas.
  • Quando estiver substituindo um elemento, como metadados de perfil técnico, evite copiar o perfil técnico inteiro da política de base. Em vez disso, copie apenas a seção necessária do elemento. Confira Desabilitar a verificação de email para um exemplo de como fazer a alteração.
  • Para reduzir a duplicação de perfis técnicos, onde a funcionalidade principal é compartilhada, use a inclusão de perfil técnico.
  • Evite gravar no diretório do Microsoft Entra durante a entrada, o que pode resultar em problemas de limitação.
  • Se a política tiver dependências externas, como APIs REST, verifique se elas estão altamente disponíveis.
  • Para uma melhor experiência do usuário, verifique se os modelos HTML personalizados estão implantados globalmente usando a entrega de conteúdo online. A CDN (rede de distribuição de conteúdo) do Azure permite reduzir os tempos de carregamento, economizar largura de banda e melhorar a velocidade de resposta.
  • Se quiser fazer uma alteração no percurso do usuário, copie todo o percurso do usuário da política de base para a política de extensão. Informe uma ID do percurso do usuário exclusiva para o percurso do usuário que você copiou. Depois, na política de terceira parte confiável, altere o elemento do percurso do usuário padrão para apontar para o novo percurso do usuário.

Solução de problemas

Ao desenvolver com políticas do Azure AD B2C, você pode encontrar erros ou exceções ao executar o percurso do usuário. Isso pode ser investigado usando o Application Insights.

Integração contínua

Ao usar um pipeline de CI/CD (integração e entrega contínuas) configurado no Azure Pipelines, você pode incluir as políticas personalizadas do Azure AD B2C na entrega de software e automação de controle de código. Conforme você implanta em diferentes ambientes do Azure AD B2C, por exemplo, desenvolvimento, teste e produção, recomendamos que você remova os processos manuais e execute testes automatizados usando o Azure Pipelines.

Prepare o seu ambiente

Começar a usar a política personalizada do Azure AD B2C:

  1. Criar um locatário do Azure AD B2C
  2. Registre um aplicativo Web usando o portal do Azure para poder testar a política.
  3. Adicione as chaves de política necessárias e registre os aplicativos do Identity Experience Framework.
  4. Obtenha o pacote de início da política do Azure AD B2C faça o upload no locatário.
  5. Depois de fazer o upload do pacote de início, teste a política de inscrição ou de entrada.
  6. Recomendamos que você faça o download e instale o Visual Studio Code (VS Code). O Visual Studio Code é um editor de código-fonte leve e poderoso, que é executado na área de trabalho e está disponível para Windows, macOS e Linux. Com o VS Code, você pode navegar rapidamente e editar seus arquivos XML da política personalizada do Azure AD B2C instalando a extensão do Azure AD B2C para o VS Code

Próximas etapas

Depois de configurar e testar a política do Azure AD B2C, você pode começar a personalizar a política. Consulte os seguintes artigos para saber como: