Tutorial: configurar a identidade de ping com o Azure Active Directory B2C para acesso híbrido seguro

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

Muitos sites de comércio eletrônico e aplicativos Web expostos à Internet são implantados por trás de sistemas de proxy ou de um sistema de proxy reverso. Esses sistemas de proxy pré-autenticam, impõem políticas e roteiam o tráfego. Cenários comuns incluem a proteção do aplicativo Web contra tráfego Web de entrada e o fornecimento de um gerenciamento de sessão uniforme entre implantações de servidor distribuído.

Geralmente, as configurações incluem uma camada de conversão de autenticação que externaliza a autenticação do aplicativo Web. Os proxies reversos fornecem o contexto do usuário autenticado para os aplicativos Web, por exemplo, um valor de cabeçalho em formato claro ou de resumo. Os aplicativos não estão usando tokens padrão do setor, como SAML (Security Assertion Markup Language), OAuth ou OIDC (Open ID Connect). Em vez disso, o proxy fornece o contexto de autenticação e mantém a sessão com o agente do usuário final, como um navegador ou aplicativo nativo. Como um serviço em execução como um intermediário, os proxies fornecem controle de sessão significativo. O serviço de proxy é eficiente e escalonável, e não um gargalo para os aplicativos por trás do serviço proxy. O diagrama é um fluxo de implementação de proxy reverso e comunicações.

Modernização

Se você quer modernizar uma plataforma de identidade com essas configurações, pode haver preocupações do cliente:

• Desacoplar o esforço para modernizar aplicativos da modernização de uma plataforma de identidade
• Ambientes com autenticação moderna e herdada, consumindo do provedor de serviço de identidade modernizado
  • Promover a consistência da experiência do usuário final
  • Fornecer uma experiência de entrada única entre aplicativos

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

Ambiente compartilhado

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

Azure AD B2C como provedor de identidade

No Azure AD B2C, você define políticas que geram experiências e comportamentos do usuário, também chamadas de percursos do usuário. Cada política desse tipo expõe um ponto de extremidade de protocolo que pode executar a autenticação como um IdP. No lado do aplicativo, não é necessário tratamento especial para determinadas políticas. Um aplicativo faz uma solicitação de autenticação padrão para o ponto de extremidade de autenticação específico do protocolo exposto por uma política.
Você pode configurar o Azure AD B2C para compartilhar o mesmo emissor em várias políticas ou um só emissor para cada política. Cada aplicativo pode apontar para políticas fazendo uma solicitação de autenticação nativa do protocolo, o que orienta os comportamentos do usuário, como logon, inscrição e edições de perfil. O diagrama mostra os fluxos de trabalho do aplicativo OIDC e SAML.

O cenário pode ser desafiador para 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, intercepta a solicitação de acesso.

Proxy reverso PingAccess

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

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

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

Proxy de federação de PingFederate

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

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

Pré-requisitos

Para começar, você precisará de:

• 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 VMs (máquinas virtuais) do Azure

Conectividade e comunicação

Confirme a conectividade e a comunicação a seguir.

• Servidor PingAccess – comunica-se com o servidor PingFederate, o navegador do cliente, o OIDC, o OAuth conhecido e a descoberta de chaves publicada pelo serviço Azure AD B2C e pelo servidor PingFederate
• Servidor PingFederate – comunica-se com o servidor PingFederate, o navegador do cliente, o OIDC, o OAuth conhecido e a descoberta de chaves publicada pelo serviço Azure AD B2C
• Aplicativo AuthN baseado em cabeçalho ou herdado – comunica-se com o servidor PingAccess
• Aplicativo de terceira parte confiável SAML – alcança o tráfego do navegador a partir do cliente. Acessa os metadados de federação SAML publicados pelo serviço Azure AD B2C.
• Aplicativo moderno – alcança o tráfego do navegador a partir do cliente. Acessa o OIDC, o OAuth conhecido e a descoberta de chaves publicada pelo serviço Azure AD B2C.
• API REST – alcança o tráfego de um cliente Web ou nativo. Acessa o OIDC, o OAuth conhecido e a descoberta de chaves publicada pelo serviço Azure AD B2C

Configurar o Azure AD B2C

Você pode usar fluxos de usuário básicos ou políticas de IEF (Identity Enterprise Framework) avançadas. PingAccess gera o ponto de extremidade de metadados, com base no valor do emissor, usando o protocolo WebFinger para convenção de descoberta. Para seguir essa convenção, atualize o emissor do Azure AD B2C usando propriedades da política de fluxo do 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 do token JWT.

Configurar PingAccess e PingFederate

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

Configurar o PingFederate como o provedor de token

Para configurar PingFederate como o provedor de token para PingAccess, verifique a conectividade de PingFederate para PingAccess. Confirme a conectividade de PingAccess para PingFederate.

Para obter mais informações, consulte Configurar o PingFederate como o provedor de tokens do PingAccess na documentação da Identidade do Ping.

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 obter mais informações, consulte O que posso configurar com o PingAccess? na documentação da Identidade do Ping.

Para criar um host virtual:

1. Vá até Configurações>Acesso>Hosts virtuais.
2. Selecione Adicionar host virtual.
3. Para Host, insira a parte do FQDN da URL do aplicativo.
4. Para Porta, insira 443.
5. Selecione Salvar.

Criar uma sessão Web

Para criar uma sessão Web:

1. Navegue até Configurações>Acesso>Sessões Web.
2. Selecione Adicionar Sessão Web.
3. Insira um Nome para a sessão Web.
4. Selecione o Tipo de cookie: JWT Assinado ou JWT Criptografado
5. Insira um valor exclusivo para Público.
6. Em ID do Cliente, insira a ID do Aplicativo do Microsoft Entra.
7. Em Segredo do Cliente, insira a Chave gerada para o aplicativo na ID do Microsoft Entra.
8. (Opcional) Crie e use declarações personalizadas com a API do Microsoft Graph: selecione Avançado. Desmarque Perfil de solicitação e Atualizar atributos do usuário. Saiba mais sobre as declarações personalizadas: Logon único baseado em cabeçalho para aplicativos locais com o proxy de aplicativo do Microsoft Entra.
9. Selecione Salvar

Criar mapeamento de identidade

Observação

Você poderá usar o mapeamento de identidade com mais de um aplicativo se eles estiverem esperando os 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 Mapeamento de identidade de tipo de cabeçalho.
5. Na tabela Mapeamento de atributo, especifique os mapeamentos necessários. Por exemplo,

Nome do atributo	Nome do cabeçalho
“upn”	x-userprincipalname
“email”	x-email
“oid”	x-oid
“scp”	x-scope
“amr”	x-amr

6. Selecione Salvar

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 Nome do site.
4. Insira o Destino do site. O destino é o par nomedohost:porta para o servidor que está hospedando 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 esperar conexões seguras, defina o Grupo de certificados confiáveis como Confiar em qualquer um.
7. Selecione Salvar.

Criar um aplicativo

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

1. Acesse Principais>Aplicativos

2. Selecione Adicionar aplicativo

3. Especifique um Nome para o aplicativo

4. Se preferir, insira uma Descrição para o aplicativo

5. Especifique a Raiz de contexto para o aplicativo. 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 em PingAccess.

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

8. Selecione o Site que você criou que contém o aplicativo

9. Selecione o Mapeamento de identidade que você criou

10. Selecione Habilitado para habilitar o site quando você salvar

11. Selecione Salvar

Configure a política de autenticação do PingFederate

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

1. Crie um contrato para ligar os atributos entre o 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 Hub de federação e contratos de política de autenticação na documentação da Identidade do Ping.

2. Para cada IdP, crie uma conexão IdP entre o IdP e o PingFederate, o hub da federação como o SP.

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

4. Na janela Seletores, configure um seletor de autenticação. Por exemplo, consulte uma instância do adaptador do primeiro identificador para mapear cada IdP para a conexão do IdP correspondente em uma política de autenticação.

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

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

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

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

Próximas etapas

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

• Políticas personalizadas no Azure AD B2C

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