Tutorial: Configurar a Identidade de Ping com o Azure Ative Directory B2C para acesso híbrido seguro

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais nas nossas Perguntas Frequentes.

Neste tutorial, saiba como estender os recursos do Azure Ative Directory B2C (Azure AD B2C) com PingAccess e PingFederate. O PingAccess fornece acesso a aplicativos e APIs, além de um mecanismo de política para acesso de usuário autorizado. O PingFederate é um servidor de federação empresarial para autenticação de usuários e logon único, uma autoridade que permite que clientes, funcionários e parceiros acessem aplicativos a partir de dispositivos. Use-os juntos para habilitar o acesso híbrido seguro (SHA).

Muitos sites de comércio eletrónico e aplicações web expostas à Internet são implantadas atrás de sistemas de proxy ou de sistemas de proxy reverso. Esses sistemas de proxy pré-autenticam, aplicam políticas e roteiam o tráfego. Os cenários típicos incluem a proteção de aplicativos Web contra o tráfego da Web de entrada e o fornecimento de um gerenciamento de sessão uniforme em implantações de servidor distribuído.

Geralmente, as configurações incluem uma camada de tradução de autenticação que externaliza a autenticação do aplicativo Web. Os proxies reversos fornecem o contexto de usuário autenticado para os aplicativos Web, como um valor de cabeçalho em forma clara ou resumida. Os aplicativos não estão usando tokens padrão do setor, como SAML (Security Assertion Markup Language), OAuth ou OpenID Connect (OIDC). Em vez disso, o proxy fornece contexto de autenticação e mantém a sessão com o agente do usuário final, como navegador ou aplicativo nativo. Como um serviço executado como um man-in-the-middle, os proxies fornecem um controle de sessão significativo. O serviço de proxy é eficiente e escalável, não é um gargalo para aplicativos por trás do serviço de proxy. O diagrama é uma implementação de proxy reverso e fluxo de comunicação.

Modernização

Se você quiser modernizar uma plataforma de identidade em tais configurações, pode haver preocupações do cliente:

• Desacople o esforço para modernizar aplicativos da modernização de uma plataforma de identidade
• Ambientes com autenticação moderna e legada, utilizando o provedor de serviços de identidade modernizado
  • Aumente a consistência da experiência do usuário final
  • Forneça uma experiência de login único entre aplicativos

Em resposta a essas preocupações, a abordagem neste tutorial é uma integração de Azure AD B2C, PingAccesse PingFederate.

Ambiente partilhado

Uma solução tecnicamente viável e econômica é configurar o sistema de proxy reverso para usar o sistema de identidade modernizado, delegando autenticação.
Os proxies suportam os protocolos de autenticação modernos e usam a autenticação baseada em redirecionamento (passiva) que envia os usuários para o novo provedor de identidade (IdP).

Azure AD B2C como um provedor de identidade

No Azure AD B2C, você define políticas que impulsionam experiências e comportamentos do usuário, também chamadas de jornadas do usuário. Cada política expõe um ponto de extremidade de protocolo que pode executar a autenticação como um IdP. No lado do aplicativo, não há tratamento especial necessário para determinadas políticas. Uma aplicação faz uma solicitação de autenticação padrão para o endpoint de autenticação específico do protocolo disponibilizado por uma política.
Você pode configurar o Azure AD B2C para compartilhar o mesmo emissor entre políticas ou emissor exclusivo para cada política. Cada aplicativo pode apontar para políticas fazendo uma solicitação de autenticação nativa do protocolo, que orienta comportamentos do usuário, como entrada, inscrição e edições de perfil. O diagrama mostra fluxos de trabalho de aplicativos OIDC e SAML.

O cenário pode ser desafiador para os aplicativos herdados redirecionarem o usuário com precisão. A solicitação de acesso aos aplicativos pode não incluir o contexto da experiência do usuário. Na maioria dos casos, a camada de proxy, ou um agente integrado no aplicativo Web, interceta a solicitação de acesso.

Proxy de reversão do PingAccess

Você pode implantar o PingAccess como proxy reverso. O PingAccess interceta uma solicitação direta sendo o intermediário ou como um redirecionamento de um agente em execução no servidor de aplicativos Web.

Configure o PingAccess com OIDC, OAuth2 ou SAML para autenticação com um provedor de autenticação upstream. Você pode configurar um IdP upstream para essa finalidade no servidor PingAccess. Veja o diagrama a seguir.

Em uma implantação típica do Azure AD B2C com políticas expondo IdPs, há um desafio. O PingAccess é configurado com um IdP upstream.

Proxy de federação PingFederate

Você pode configurar o PingFederate como um provedor de autenticação ou um proxy para IdPs upstream. Veja o diagrama a seguir.

Use essa função para alternar contextualmente, dinamicamente ou declarativamente uma solicitação de entrada para uma política B2C do Azure AD. Veja o seguinte diagrama do fluxo de sequência do protocolo.

Pré-requisitos

Para começar, você precisará:

• Uma assinatura do Azure
  • Se não tiver uma, obtenha uma conta gratuita do Azure
• Um locatário do Azure AD B2C vinculado à sua assinatura do Azure
• PingAccess e PingFederate implantados em contêineres do Docker ou em máquinas virtuais (VMs) do Azure

Conectividade e comunicação

Confirme a seguinte conectividade e comunicação.

• do servidor PingAccess – Comunica-se com o servidor PingFederate, navegador cliente, OIDC, OAuth bem conhecido e descoberta de chaves publicada pelo serviço Azure AD B2C e servidor PingFederate
• do servidor PingFederate – Comunica-se com o servidor PingAccess, navegador cliente, OIDC, OAuth bem conhecido e descoberta de chaves publicada pelo serviço Azure AD B2C
• Aplicativo AuthN herdado ou baseado em cabeçalho – Comunica de e para o servidor PingAccess
• aplicativo de terceira parte confiável SAML – Alcança o tráfego do navegador do cliente. Acessa os metadados de federação SAML publicados pelo serviço Azure AD B2C.
• Aplicação moderna – Acede ao tráfego do navegador desde o cliente. Acede aos pontos bem conhecidos do OIDC, OAuth, e à descoberta de chaves publicadas pelo serviço Azure AD B2C.
• API REST – Alcança o tráfego de um cliente nativo ou web. Acede ao OIDC, OAuth bem conhecido, e à descoberta de chaves publicadas pelo serviço Azure AD B2C.

Configurar o Azure AD B2C

Você pode usar fluxos de usuário básicos ou políticas avançadas do Identity Enterprise Framework (IEF). O PingAccess gera o endpoint de metadados com base no valor da entidade emissora, usando o protocolo WebFinger para a convenção de descoberta. Para seguir essa convenção, atualize o emissor do Azure AD B2C usando as propriedades da política de fluxo de usuário.

Nas políticas avançadas, a configuração inclui o elemento de metadados IssuanceClaimPattern para o valor AuthorityWithTfp no perfil técnico do emissor JWT.

Configurar o PingAccess e o PingFederate

Use as instruções nas seções a seguir para configurar o PingAccess e o PingFederate. Veja o diagrama a seguir do fluxo geral de usuários de integração.

Configurar o PingFederate como o provedor de token

Para configurar o PingFederate como o provedor de token para PingAccess, garanta a conectividade de PingFederate para PingAccess. Confirme a conectividade do PingAccess com o PingFederate.

Configurar um aplicativo PingAccess para autenticação baseada em cabeçalho

Use as instruções a seguir para criar um aplicativo PingAccess para o aplicativo Web de destino, para autenticação baseada em cabeçalho.

Criar um host virtual

Importante

Crie um host virtual para cada aplicativo.

Para criar um host virtual:

1. Ir para Definições>Acesso>Anfitriões Virtuais.
2. Selecione Adicionar Host Virtual.
3. Para Host, insira a parte FQDN da URL do Aplicativo.
4. Para Port, digite 443.
5. Selecione Guardar.

Criar uma sessão Web

Para criar uma sessão Web:

1. Navegue até Configurações de >Access>Web Sessions.
2. Selecione Adicionar sessão da Web.
3. Insira um Nome para a sessão na Web.
4. Selecione o Tipo de cookie: JWT Assinado ou JWT Encriptado.
5. Insira um valor exclusivo para Público.
6. Para ID do Cliente, insira o ID da Aplicação Microsoft Entra.
7. Para Segredo do Cliente , insira a chave de que você gerou para o aplicativo no Microsoft Entra ID.
8. (Opcional) Crie e use declarações personalizadas com a API do Microsoft Graph: Selecione Avançado . Desmarque Perfil de Solicitação e Atualize Atributos de Utilizador. Saiba mais sobre declarações personalizadas: Logon único baseado em cabeçalho para aplicativos locais com o proxy de aplicativo Microsoft Entra.
9. Selecione Guardar

Criar mapeamento de identidade

Observação

Você pode usar o mapeamento de identidade com mais de uma aplicação, se estiverem à espera dos mesmos dados no cabeçalho.

Para criar o mapeamento de identidade:

1. Vá para Configurações>Acesso>Mapeamentos de Identidade.
2. Selecione Adicionar mapeamento de identidade.
3. Especifique um *Nome.
4. Selecione o mapeamento de identidade Tipo de mapeamento de identidade de cabeçalho.
5. Na tabela Mapeamento de Atributos, especifique os mapeamentos necessários. Por exemplo

Nome do atributo	Nome do cabeçalho
'UPN'	x-userprincipalname
correio eletrónico	X-E-mail
'Óide'	X-OIDE
«SCP»	x-âmbito
amr	X-AMR

6. Selecione Guardar

Criar um site

Observação

Em algumas configurações, um site pode conter vários aplicativos. Você pode usar um site com mais de um aplicativo, quando apropriado.

Para criar um site:

1. Vá para Principal>Sites.
2. Selecione Adicionar Site.
3. Insira o site Nome.
4. Aceda ao site Target. O destino é o par hostname:port para o servidor que hospeda o aplicativo. Não insira o caminho do aplicativo neste campo. Por exemplo, um aplicativo em https://mysite:9999/AppName tem um valor de destino de mysite:9999.
5. Indique se o destino espera conexões seguras.
6. Se o destino espera conexões seguras, defina o Grupo de Certificados Confiáveis como Confiar em qualquer.
7. Selecione Guardar.

Criar uma aplicação

Para criar um aplicativo no PingAccess para cada aplicativo no Azure que você deseja proteger.

1. Ir para Principal>Aplicações

2. Selecione Adicionar aplicativo

3. Especifique um Nome para a aplicação

4. Opcionalmente, insira uma Descrição para a aplicação

5. Especifique o raiz de contexto para a aplicação. Por exemplo, um aplicativo em https://mysite:9999/AppName terá uma raiz de contexto de /AppName. A raiz de contexto deve começar com uma barra (/), não deve terminar com uma barra (/) e pode ter mais de uma camada de profundidade, por exemplo, /Apps/MyApp.

6. Selecione o host virtual que você criou

   Observação

   A combinação de host virtual e raiz de contexto deve ser exclusiva no PingAccess.

7. Selecione a sessão Web que você criou

8. Selecione o Site que criou e que contém a aplicação

9. Selecione o Mapeamento de Identidade que você criou

10. Selecione Ativado para ativar o site quando guardar

11. Selecione Guardar

Configurar a política de autenticação PingFederate

Configurar a política de autenticação PingFederate para federar com os vários IdPs fornecidos pelos locatários do Azure AD B2C

1. Crie um contrato para interligar os atributos entre os IdPs e o SP. Você deve precisar de apenas um contrato, a menos que o SP exija um conjunto diferente de atributos de cada IdP. Para obter mais informações, consulte o Hub de Federação e os contratos de política de autenticação na documentação da Ping Identity.

2. Para cada IdP, crie uma conexão de IdP entre o IdP e o PingFederate, que funciona como o hub de federação e como prestador de serviços.

3. Na janela Mapeamento de Sessão de Destino, adicione os contratos de política de autenticação aplicáveis à conexão IdP.

4. Na janela Seletores, configure um seletor de autenticação. Por exemplo, veja um exemplo do Identifier First Adapter para mapear cada IdP à conexão IdP correspondente numa política de autenticação.

5. Crie uma conexão SP entre o PingFederate, o hub de federação como IdP, e o Provedor de Serviço.

6. Adicione o contrato de política de autenticação correspondente à conexão do SP na janela Mapeamento de Fonte de Autenticação.

7. Trabalhe com cada IdP para se conectar ao PingFederate, o hub de federação como SP.

8. Trabalhe com o SP para se conectar ao PingFederate, o hub de federação como IdP.

Próximos passos

Para obter informações adicionais, consulte os seguintes artigos

• Políticas personalizadas no Azure AD B2C

• Introdução às políticas personalizadas no Azure AD B2C