Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 em nossas perguntas frequentes.
Neste tutorial, saiba como estender os recursos do Azure Active Directory B2C (Azure AD B2C) com PingAccess e PingFederate. O PingAccess fornece acesso a aplicativos e APIs e um mecanismo de política para acesso de usuário autorizado. O PingFederate é um servidor de federação corporativo para autenticação de usuário e logon único, uma autoridade que permite que clientes, funcionários e parceiros acessem aplicativos de dispositivos. Use-os juntos para habilitar o acesso híbrido seguro (SHA).
Muitos sites de comércio eletrônico e aplicativos da Web expostos à Internet são implantados por trás de sistemas proxy ou um sistema de proxy reverso. Esses sistemas proxy pré-autenticam, impõem políticas e roteiam o tráfego. Os cenários típicos incluem a proteção de aplicativos Web contra tráfego de entrada da Web 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 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, como um valor de cabeçalho em formato claro ou resumido. Os aplicativos não estão usando tokens padrão do setor, como SAML (Security Assertion Markup Language), OAuth ou OIDC (OpenID Connect). 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 intermediário, os proxies fornecem controle de sessão significativo. O serviço de proxy é eficiente e escalonável, não é um gargalo para aplicativos por trás do serviço de proxy. O diagrama é uma implementação de proxy reverso e um fluxo de comunicação.
Modernização
Se você quiser modernizar uma plataforma de identidade nessas configurações, pode haver preocupações do cliente:
- Dissocie o esforço para modernizar aplicativos da modernização de uma plataforma de identidade
- Ambientes com autenticação moderna e legada, consumindo do provedor de serviços de identidade modernizado
- Impulsione a consistência da experiência do usuário final
- Fornecer uma experiência de logon único em todos os aplicativos
Em resposta a essas preocupações, a abordagem neste tutorial é uma integração do Azure AD B2C, PingAccess e PingFederate .
Ambiente compartilhado
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 dão suporte aos 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 orientam experiências e comportamentos do usuário, também chamados de percursos do usuário. Cada uma dessas políticas expõe um endpoint de protocolo que pode executar a autenticação como um IdP. No lado do aplicativo, não há nenhum tratamento especial necessário 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 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 de protocolo, que orienta comportamentos do usuário, como entrada, 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 os aplicativos legados redirecionarem o usuário com precisão. A solicitação de acesso aos aplicativos pode não incluir o contexto de 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 do PingAccess
Você pode implantar o PingAccess como o proxy reverso. O PingAccess intercepta 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. 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. O PingAccess é configurado com um IdP upstream.
Proxy de federação do PingFederate
Você pode configurar o 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 de protocolo.
Pré-requisitos
Para começar, você precisará de:
- Uma assinatura do Azure
- Se você não tiver uma, obtenha uma conta gratuita do Azure
- Um tenant 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 publicadas pelo serviço Azure AD B2C e pelo servidor PingFederate
- Servidor PingFederate – Comunica-se com o servidor PingAccess, navegador do cliente, OIDC, OAuth conhecido e descoberta de chaves publicadas pelo serviço Azure AD B2C
- Aplicativo AuthN herdado ou baseado em cabeçalho – Comunica-se 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.
- 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 nativo ou web. Acessa o OIDC, o OAuth conhecido e a descoberta de chaves publicados 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 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 as 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 JWT.
Configurar PingAccess e PingFederate
Use as instruções nas seções a seguir para configurar o PingAccess e o PingFederate. Consulte o diagrama a seguir do fluxo geral do usuário de integração.
Configurar o PingFederate como o provedor de token
Para configurar o PingFederate como o provedor de token para o PingAccess, verifique a conectividade do PingFederate com o 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:
- Vá para Configurações>Acessar>hosts virtuais.
- Selecione Adicionar Host Virtual.
- Em Host, insira a parte FQDN da URL do aplicativo.
- Para Porta, insira 443.
- Clique em Salvar.
Criar uma sessão da Web
Para criar uma sessão da Web:
- Navegue até Configurações>Acessar>Sessões da Web.
- Selecione Adicionar Sessão Web.
- Insira um Nome para a sessão da Web.
- Selecione o tipo de cookie: JWT assinado ou JWT criptografado.
- Insira um valor exclusivo para Público-alvo.
- Em ID do cliente, insira a ID do aplicativo do Microsoft Entra.
- Em Segredo do Cliente, insira a Chave gerada para o aplicativo na ID do Microsoft Entra.
- (Opcional) Criar e usar declarações personalizadas com a API do Microsoft Graph: selecione Avançado. Desmarque Solicitar perfil e atualizar atributos do usuário. Saiba mais sobre declarações personalizadas: logon único baseado em cabeçalho para aplicativos locais com o proxy de aplicativo do Microsoft Entra.
- Selecione Salvar
Criar mapeamento de identidade
Observação
Você pode 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:
- Vá para Configurações>Acessar>mapeamentos de identidade.
- Selecione Adicionar Mapeamento de Identidade.
- Especifique um *Nome.
- Selecione o tipo de mapeamento de identidade do cabeçalho Mapeamento de identidade.
- Na tabela Mapeamento de Atributos , especifique os mapeamentos necessários. Por exemplo
Nome do atributo | Nome do cabeçalho |
---|---|
'UPN' | x-userprincipalname |
'E-mail' | X-E-mail |
'oid' | X-Oid |
'SCP' | X-Scope |
'amr' | X-Amr |
- 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:
- Vá paraSites Principais>.
- Selecione Adicionar site.
- Digite o nome do site.
- Insira o destino do site. 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.
- Indique se o destino espera conexões seguras.
- Se o destino espera conexões seguras, defina o Grupo de Certificados Confiáveis como Confiar em Qualquer.
- Clique em Salvar.
Criar um aplicativo
Para criar um aplicativo no PingAccess para cada aplicativo no Azure que você deseja proteger.
Ir para as principais>aplicações
Selecione Adicionar aplicativo
Especifique um Nome para o aplicativo
Opcionalmente, insira uma Descrição para o aplicativo
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.
Selecione o host virtual que você criou
Observação
A combinação de host virtual e raiz de contexto deve ser exclusiva no PingAccess.
Selecione a sessão da Web que você criou
Selecione o site que você criou que contém o aplicativo
Selecione o Mapeamento de identidade que você criou
Selecione Ativado para habilitar o site ao salvar
Selecione Salvar
Configurar a política de autenticação do PingFederate
Configurar a política de autenticação PingFederate para federar com os vários IdPs fornecidos pelos locatários do Azure AD B2C
Crie um contrato para fazer a ponte 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 Contratos de política de autenticação e hub de federação na documentação Identidade de Ping.
Para cada IdP, crie uma conexão IdP entre o IdP e o PingFederate, o hub de federação como o SP.
Na janela Mapeamento de Sessão de Destino , adicione os contratos de política de autenticação aplicáveis à conexão IdP.
Na janela Seletores , configure um seletor de autenticação. Por exemplo, consulte uma instância do Adaptador Identifier First para mapear cada IdP para a conexão IdP correspondente em uma política de autenticação.
Crie uma conexão SP entre o PingFederate, o hub de federação como o IdP e o SP.
Adicione o contrato de diretiva de autenticação correspondente à conexão do SP na janela Mapeamento da Fonte de Autenticação .
Trabalhe com cada IdP para se conectar ao PingFederate, o hub de federação como o SP.
Trabalhe com o SP para se conectar ao PingFederate, o hub de federação como o IdP.
Próximas etapas
Para obter informações adicionais, consulte os seguintes artigos