Tutorial: Configurar o Ping Identity com o Azure Active Directory B2C para acesso híbrido seguro

Neste tutorial, saiba como expandir as capacidades do Azure Active Directory B2C (Azure AD B2C) com PingAccess e PingFederate. O PingAccess fornece acesso a aplicações e APIs e um motor de política para acesso autorizado ao utilizador. PingFederate é um servidor de federação empresarial para autenticação de utilizador e início de sessão único, uma autoridade que permite aos clientes, colaboradores e parceiros aceder a aplicações a partir de dispositivos. Utilize-as em conjunto para ativar o acesso híbrido seguro (SHA).

Muitos sites de comércio eletrónico e aplicações Web expostos à Internet são implementados atrás de sistemas proxy ou de um sistema de proxy inverso. Estes sistemas proxy pré-autenticam, impõem a política e encaminham o tráfego. Os cenários típicos incluem a proteção de aplicações Web contra o tráfego web de entrada e o fornecimento de uma gestão de sessões uniforme entre implementações de servidores distribuídos.

Geralmente, as configurações incluem uma camada de tradução de autenticação que externaliza a autenticação a partir da aplicação Web. Os proxies inversos fornecem o contexto de utilizador autenticado às aplicações Web, como um valor de cabeçalho de forma clara ou resumida. As aplicações não estão a utilizar tokens padrão da indústria, como Security Assertion Markup Language (SAML), 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 utilizador final, como o browser ou a aplicação nativa. Como um serviço em execução como um homem no meio, os proxies fornecem um controlo de sessão significativo. O serviço proxy é eficiente e dimensionável, não é um estrangulamento para as aplicações por trás do serviço proxy. O diagrama é um fluxo de implementação e comunicações de proxy inverso.

Modernização

Se quiser modernizar uma plataforma de identidade nessas configurações, poderão existir preocupações do cliente:

• Desassociar o esforço para modernizar as aplicações da modernização de uma plataforma de identidade
• Ambientes com autenticação moderna e legada, que consomem a partir do fornecedor de serviços de identidade modernizado
  • Impulsionar a consistência da experiência do utilizador final
  • Proporcionar uma experiência de início de sessão único em todas as aplicações

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

Ambiente partilhado

Uma solução tecnicamente viável e económica consiste em configurar o sistema de proxy inverso para utilizar o sistema de identidade modernizado, delegando a autenticação.
Os proxies suportam os protocolos de autenticação modernos e utilizam a autenticação baseada em redirecionamento (passiva) que envia os utilizadores para o novo fornecedor de identidade (IdP).

Azure AD B2C como fornecedor de identidade

No Azure AD B2C, define políticas que impulsionam as experiências e comportamentos dos utilizadores, também denominadas percursos de utilizador. Cada uma dessas políticas expõe um ponto final de protocolo que pode efetuar a autenticação como um IdP. Do lado da aplicação, não é necessário um processamento especial para determinadas políticas. Uma aplicação faz um pedido de autenticação padrão para o ponto final de autenticação específico do protocolo exposto por uma política.
Pode configurar Azure AD B2C para partilhar o mesmo emissor entre políticas ou emissor exclusivo para cada política. Cada aplicação pode apontar para políticas ao efetuar um pedido de autenticação nativo de protocolo, o que impulsiona os comportamentos dos utilizadores, como o início de sessão, a inscrição e as edições de perfil. O diagrama mostra os fluxos de trabalho da aplicação OIDC e SAML.

O cenário pode ser um desafio para as aplicações legadas redirecionarem o utilizador com precisão. O pedido de acesso às aplicações pode não incluir o contexto de experiência do utilizador. Na maioria dos casos, a camada de proxy ou um agente integrado na aplicação Web interceta o pedido de acesso.

PingAccess proxy inverso

Pode implementar o PingAccess como o proxy inverso. O PingAccess interceta um pedido direto por ser o man-in-the-middle ou como um redirecionamento de um agente em execução no servidor de aplicações Web.

Configure o PingAccess com OIDC, OAuth2 ou SAML para autenticação com um fornecedor de autenticação a montante. Pode configurar um IdP a montante para esta finalidade no servidor PingAccess. Veja o seguinte diagrama.

Numa implementação típica Azure AD B2C com políticas que expõem IdPs, existe um desafio. O PingAccess está configurado com um IdP a montante.

PingFederate proxy de federação

Pode configurar o PingFederate como um fornecedor de autenticação ou um proxy para IdPs a montante. Veja o seguinte diagrama.

Utilize esta função para mudar contextualmente, dinamicamente ou declarativamente um pedido de entrada para um Azure AD política B2C. Veja o seguinte diagrama do fluxo de sequência de protocolos.

Pré-requisitos

Para começar, precisará de:

• Uma subscrição do Azure
  • Se não tiver uma, obtenha uma conta gratuita do Azure
• Um inquilino Azure AD B2C associado à sua subscrição do Azure
• PingAccess e PingFederate implementados em contentores do Docker ou em máquinas virtuais (VMs) do Azure

Conectividade e comunicação

Confirme a seguinte conectividade e comunicação.

• Servidor PingAccess – Comunica com o servidor PingFederate, o browser cliente, o OIDC, o OAuth bem conhecido e a deteção de chaves publicada pelo serviço Azure AD B2C e pelo servidor PingFederate
• Servidor PingFederate – comunica com o servidor PingAccess, o browser cliente, o OIDC, o OAuth bem conhecido e a deteção de chaves publicada pelo serviço Azure AD B2C
• Aplicação AuthN legada ou baseada em cabeçalhos – comunica de e para o servidor PingAccess
• Aplicação de entidade confiadora SAML – atinge o tráfego do browser a partir do cliente. Acede aos metadados de federação SAML publicados pelo serviço Azure AD B2C.
• Aplicação moderna – atinge o tráfego do browser a partir do cliente. Acede à deteção de chaves OIDC, OAuth bem conhecida e publicada pelo serviço Azure AD B2C.
• API REST – atinge o tráfego de um cliente nativo ou Web. Acede à deteção de chaves OIDC, OAuth bem conhecida e publicada pelo serviço Azure AD B2C

Configurar Azure AD B2C

Pode utilizar fluxos de utilizador básicos ou políticas avançadas do Identity Enterprise Framework (IEF). O PingAccess gera o ponto final de metadados, com base no valor do emissor, através do protocolo WebFinger para a convenção de deteção. Para seguir esta convenção, atualize o emissor do Azure AD B2C com as propriedades da política de fluxo de utilizador.

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

Configurar PingAccess e PingFederate

Utilize as instruções nas secções seguintes para configurar PingAccess e PingFederate. Veja o diagrama seguinte do fluxo de utilizador de integração geral.

Configurar PingFederate como o fornecedor de tokens

Para configurar o PingFederate como o fornecedor de tokens para PingAccess, garanta a conectividade do PingFederate ao PingAccess. Confirme a conectividade do PingAccess ao PingFederate.

Para obter mais informações, veja Configure PingFederate as the token provider for PingAccess (Configurar PingFederate como fornecedor de tokens para PingAccess ) na documentação da Identidade do Ping.

Configurar uma aplicação PingAccess para autenticação baseada em cabeçalhos

Utilize as seguintes instruções para criar uma aplicação PingAccess para a aplicação Web de destino, para autenticação baseada em cabeçalhos.

Criar um anfitrião virtual

Importante

Crie um anfitrião virtual para cada aplicação. Para obter mais informações, consulte O que posso configurar com o PingAccess? na documentação Identidade do Ping.

Para criar um anfitrião virtual:

1. Aceda a Definições>Aceder> aAnfitriões Virtuais.
2. Selecione Adicionar Anfitrião Virtual.
3. Em Anfitrião, introduza a parte FQDN do URL da Aplicação.
4. Em Porta, introduza 443.
5. Selecione Guardar.

Criar uma sessão Web

Para criar uma sessão Web:

1. Navegue para Definições>Sessões Web doAccess>.
2. Selecione Adicionar Sessão Web.
3. Introduza um Nome para a sessão Web.
4. Selecione o Tipo de Cookie: JWT Assinado ou JWT Encriptado.
5. Introduza um valor exclusivo para Audiência.
6. Para ID de Cliente, introduza o ID da Aplicação Microsoft Entra.
7. Em Segredo do Cliente, introduza a Chave que gerou para a aplicação no Microsoft Entra ID.
8. (Opcional) Crie e utilize afirmações personalizadas com o Microsoft Graph API: Selecione Avançadas. Desselecione o Perfil de Pedido e Atualize Os Atributos de Utilizador. Saiba mais sobre afirmações personalizadas: Início de sessão único baseado em cabeçalhos para aplicações no local com Microsoft Entra proxy de aplicações.
9. Selecione Guardar

Criar mapeamento de identidade

Nota

Pode utilizar o mapeamento de identidades com mais do que uma aplicação, caso estejam à espera dos mesmos dados no cabeçalho.

Para criar o mapeamento de identidades:

1. Aceda a Definições Mapeamentos>de Identidade deAcesso>.
2. Selecione Adicionar Mapeamento de Identidade.
3. Especifique um *Nome.
4. Selecione o Tipo de mapeamento de identidades do 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
'e-mail'	x-email
'oid'	x-oid
'scp'	âmbito x
"amr"	x-amr

6. Selecione Guardar

Criar um site

Nota

Em algumas configurações, um site pode conter várias aplicações. Quando adequado, pode utilizar um site com mais do que uma aplicação.

Para criar um site:

1. Aceda aSitesPrincipais>.
2. Selecione Adicionar Site.
3. Introduza o Nome do site.
4. Introduza o destino do site. O destino é o par hostname:port para o servidor que aloja a aplicação. Não introduza o caminho da aplicação neste campo. Por exemplo, uma aplicação em https://mysite:9999/AppName tem um valor de destino de mysite:9999.
5. Indique se o destino espera ligações seguras.
6. Se o destino esperar ligações seguras, defina o Grupo de Certificados Fidedignos para Confiar em Qualquer.
7. Selecione Guardar.

Criar uma aplicação

Para criar uma aplicação no PingAccess para cada aplicação no Azure que pretende proteger.

1. Aceda aAplicaçõesPrincipais>

2. Selecione Adicionar Aplicação

3. Especificar um Nome para a aplicação

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

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

6. Selecione o anfitrião virtual que criou

   Nota

   A combinação de anfitrião virtual e raiz de contexto tem de ser exclusiva no PingAccess.

7. Selecione a sessão Web que criou

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

9. Selecione o Mapeamento de Identidade que 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 para os múltiplos IdPs fornecidos pelos inquilinos do Azure AD B2C

1. Crie um contrato para fazer a ponte entre os atributos entre os IdPs e o SP. Só deverá precisar de um contrato, a menos que o SP necessite de um conjunto diferente de atributos de cada IdP. Para obter mais informações, veja Contratos de política de autenticação e hub de federação na documentação Identidade do Ping.

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

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

4. Na janela Seletores , configure um seletor de autenticação. Por exemplo, veja uma instância do Identificador Primeiro Adaptador para mapear cada IdP para a ligação de IdP correspondente numa política de autenticação.

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

6. Adicione o contrato de política de autenticação correspondente à ligação SP na janela Mapeamento de Origem de Autenticação .

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

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

Passos seguintes

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

• Políticas personalizadas no Azure AD B2C

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