Tutorial: Configurar a identidade do ping com Azure Ative Directory B2C para acesso híbrido seguro

Neste tutorial de amostra, aprenda a estender Azure Ative Directory (AD) B2C com PingAccess e PingFederate para permitir um acesso híbrido seguro.

Muitas propriedades web existentes, tais como sites de eCommerce e aplicações web que são expostas à internet são implementadas por trás de um sistema de procuração, às vezes referido como um sistema de procuração inversa. Estes sistemas de procuração fornecem várias funções, incluindo pré-autenticação, aplicação de políticas e encaminhamento de tráfego. Os casos de uso de exemplo incluem proteger a aplicação web do tráfego web de entrada e fornecer uma gestão uniforme da sessão através de implementações distribuídas do servidor.

Na maioria dos casos, esta configuração inclui uma camada de tradução de autenticação que externaliza a autenticação a partir da aplicação web. Os proxies invertidos, por sua vez, fornecem o contexto autenticado dos utilizadores às aplicações web, de uma forma mais simples, como um valor de cabeçalho na forma clara ou digestiva. Nesta configuração, as aplicações não estão a utilizar quaisquer fichas padrão da indústria, tais como Linguagem de Marcação de Afirmação de Segurança (SAML), OAuth ou Open ID Ligação (OIDC), em vez disso dependem do representante para fornecer o contexto de autenticação e manter a sessão com o agente utilizador final, como o navegador ou a aplicação nativa. Como um serviço que funciona num "homem-no-meio", os proxies podem fornecer o controlo final da sessão. Isto também significa que o serviço de procuração deve ser altamente eficiente e escalável, não para se tornar um estrangulamento ou um único ponto de falha para as aplicações por trás do serviço de procuração. O diagrama é uma representação de uma implementação típica de procuração inversa e fluxo das comunicações.

image shows the reverse proxy implementation

Se estiver numa situação em que pretende modernizar a plataforma de identidade nestas configurações, são levantadas as preocupações.

  • Como pode o esforço de modernização da aplicação ser dissociado da modernização da plataforma de identidade?

  • Como se pode estabelecer um ambiente de coexistência com a autenticação moderna e legado, consumindo do prestador de serviços de identidade modernizado?

    a. Como impulsionar a consistência da experiência do utilizador final?

    b. Como proporcionar uma única experiência de inscrição em todas as aplicações coexistindo?

Discutimos uma abordagem para resolver tais preocupações integrando o Azure AD B2C com tecnologias PingAccess e PingFederate .

Ambiente de coexistência

Uma solução simples tecnicamente viável que também é rentável é configurar o sistema de procuração inversa para usar o sistema de identidade modernizado, delegando a autenticação.
Neste caso, os proxies irão suportar os protocolos de autenticação modernos e utilizar a autenticação baseada em redirecionamento (passivo) que enviará o utilizador para o novo fornecedor de Identidade (IdP).

Azure AD B2C como fornecedor de identidade

O Azure AD B2C tem a capacidade de definir políticas que impulsionam diferentes experiências e comportamentos do utilizador que também são chamados de viagens de utilizador orquestradas a partir do final do servidor. Cada uma dessas políticas expõe um ponto final de protocolo que pode realizar a autenticação como se fosse um IdP. Não é necessário um tratamento especial do lado da aplicação para políticas específicas. A aplicação simplesmente faz um pedido de autenticação padrão do setor para o ponto final de autenticação específico do protocolo exposto pela política de interesse.
O Azure AD B2C pode ser configurado para partilhar o mesmo emitente através de múltiplas políticas ou emitente único para cada política. Cada aplicação pode apontar para uma ou muitas destas políticas, fazendo um pedido de autenticação nativa protocolar e impulsionando os comportamentos desejados do utilizador, tais como edições de inscrição, inscrição e perfis. O diagrama mostra fluxos de trabalho de aplicações OIDC e SAML.

image shows the OIDC and SAML implementation

Embora o cenário mencionado funcione bem para aplicações modernizadas, pode ser um desafio para as aplicações antigas redirecionar adequadamente o utilizador, uma vez que o pedido de acesso às aplicações pode não incluir o contexto para a experiência do utilizador. Na maioria dos casos, a camada de procuração ou um agente integrado na aplicação web interceta o pedido de acesso.

PingAccess como um proxy invertido

Muitos clientes têm implementado o PingAccess como o representante inverso para desempenhar um ou muitos papéis, como notado anteriormente neste artigo. O PingAccess pode intercetar um pedido direto através de ser o homem-no-meio ou como um redirecionamento que vem de um agente que está a funcionar no servidor de aplicações web.

O PingAccess pode ser configurado com OIDC, OAuth2 ou SAML para realizar a autenticação contra um fornecedor de autenticação a montante. Um único IdP a montante pode ser configurado para este fim no servidor PingAccess. O diagrama seguinte mostra esta configuração.

image shows the PingAccess with OIDC implementation

Numa implantação típica do Azure AD B2C, onde várias políticas estão expondo vários IDPs, representa um desafio. Uma vez que o PingAccess só pode ser configurado com um único IdP a montante.

PingFederate como proxy da federação

PingFederate é uma ponte de identidade da empresa que pode ser totalmente configurada como um provedor de autenticação ou um representante para outros IdPs a montante múltiplos, se necessário. O diagrama seguinte mostra esta capacidade.

image shows the PingFederate implementation

Esta capacidade pode ser usada para alternar contextualmente/dinamicamente ou declarativamente um pedido de entrada para uma política específica do Azure AD B2C. Segue-se uma representação do fluxo de sequência de protocolo para esta configuração.

image shows the PingAccess and PingFederate workflow

Pré-requisitos

Para começar, vai precisar de:

  • Uma subscrição do Azure. Se não tiver uma, obtenha uma conta grátis.

  • Um inquilino Azure AD B2C que está ligado à sua assinatura Azure.

  • PingAccess e PingFederate implantados em contentores Docker ou diretamente em VMs Azure.

Conectividade

Verifique se o seguinte está ligado.

  • Servidor PingAccess – Capaz de comunicar com o servidor PingFederate, browser cliente, OIDC, OAuth bem conhecido e teclas descoberta publicada pelo serviço Azure AD B2C e servidor PingFederate.

  • PingFederate servidor – Capaz de comunicar com o servidor PingAccess, browser de clientes, OIDC, OAuth bem conhecido e descoberta de chaves publicada pelo serviço Azure AD B2C.

  • Aplicação AuthN baseada em cabeçalho ou legado – Capaz de comunicar de e para o servidor PingAccess.

  • Saml contando com a aplicação do partido – Capaz de alcançar o tráfego do navegador a partir do cliente. Capaz de aceder aos metadados da federação SAML publicados pelo serviço Azure AD B2C.

  • Aplicação moderna – Capaz de alcançar o tráfego do navegador a partir do cliente. Capaz de aceder ao OIDC, OAuth bem conhecido, e descoberta de chaves publicada pelo serviço Azure AD B2C.

  • REST API – Capaz de chegar ao tráfego de um cliente nativo ou web. Capaz de aceder ao OIDC, OAuth bem conhecido, e descoberta de chaves publicada pelo serviço Azure AD B2C.

Configurar Azure Ad B2C

Pode utilizar para este fim os fluxos básicos de utilizador ou políticas avançadas de enquadramento empresarial de identidade (IEF). O PingAccess gera o ponto final dos metadados com base no valor do Emitente utilizando a convenção de descoberta baseada na WebFinger . Para acompanhar esta convenção, atualize a atualização do emitente Azure AD B2C utilizando as propriedades da política nos fluxos de utilizador.

image shows the token settings

Nas políticas avançadas, isto pode ser configurado usando o elemento de metadados IssuanceClaimPattern para o valor doemitente JWTFp no perfil técnico do emissor JWT.

Configure PingAccess/PingFederate

A secção seguinte cobre a configuração necessária. O diagrama ilustra o fluxo geral do utilizador para a integração.

image shows the PingAccess and PingFederate integration

Configure PingFederate como provedor de fichas

Para configurar o PingFederate como fornecedor de token para o PingAccess, garantir a conectividade do PingFederate ao PingAccess é estabelecida seguida pela conectividade do PingAccess ao PingFederate.
Consulte este artigo para ver os passos de configuração.

Configurar um pedido de PingAccess para autenticação baseada em cabeçalhos

Deve ser criada uma aplicação PingAccess para a aplicação web alvo para autenticação baseada em cabeçalho. Siga estes passos.

Passo 1 - Criar um anfitrião virtual

Importante

Para configurar esta solução, é necessário criar um hospedeiro virtual para cada aplicação. Para obter mais informações sobre considerações de configuração e seus impactos, consulte considerações principais.

Siga estes passos para criar um hospedeiro virtual:

  1. Vá a Definições>Acolssvirtuais>

  2. Selecione Adicionar Anfitrião Virtual

  3. No campo Anfitrião, insira a parte FQDN do URL de aplicação

  4. No campo do Porto, insira o 443

  5. Selecione Guardar

Passo 2 – Criar uma sessão web

Siga estes passos para criar uma sessão web:

  1. Navegue para Definições>AccessWeb>Sessions

  2. Selecione Adicionar Sessão Web

  3. Forneça um Nome para a sessão web.

  4. Selecione o Tipo de Cookie, ou JWT assinado ou JWT encriptado

  5. Proporcionar um valor único para o Público

  6. No campo ID do Cliente , insira o ID da Aplicação AZure

  7. No campo Cliente Secreto , insira a Chave que gerou para a aplicação em Azure AD.

  8. Opcional - Pode criar e utilizar reclamações personalizadas com o Microsoft Graph API. Se optar por fazê-lo, selecione Advanced e desmarca as opções de Perfil de Pedido e Descoserção de Atributos do Utilizador . Para obter mais informações sobre a utilização de reclamações personalizadas, consulte uma reclamação personalizada.

  9. Selecione Guardar

Passo 3 - Criar mapeamento de identidade

Nota

O mapeamento de identidade pode ser usado com mais de uma aplicação se mais de uma aplicação estiver à espera dos mesmos dados no cabeçalho.

Siga estes passos para criar mapeamento de identidade:

  1. Ir para mapeamentos Definições>AccessIdentity>

  2. Selecione adicionar mapeamento de identidade

  3. Especificar um Nome

  4. Selecione o tipo de mapeamento de identidade de cabeçalho

  5. Na tabela 'Atribuir', especifique os mapeamentos necessários. Por exemplo,

    Nome do atributo Nome do cabeçalho
    'upn' nome x-userprincipal
    'e-mail' x-e-mail
    'oid' x-oid
    'scp' x-âmbito
    'amr' x-amr
  6. Selecione Guardar

Passo 4 - Criar um site

Nota

Em algumas configurações, é possível que um site possa conter mais do que uma aplicação. Um site pode ser usado com mais de uma aplicação, se for caso disso.

Siga estes passos para criar um site:

  1. Ir ao MainSites>

  2. Selecione Adicionar Site

  3. Especificar um Nome para o site

  4. Insira o site Target. O alvo é o nome anfitrião:par de porta para o servidor que hospeda a aplicação. Não entre no caminho para a aplicação neste campo. Por exemplo, uma aplicação terá https://mysite:9999/AppName um valor-alvo do mysite: 9999

  5. Indique se o alvo espera ou não ligações seguras.

  6. Se o alvo estiver à espera de ligações seguras, desconfiem do Grupo de Certificados Fidedignos para Fidedignidade Qualquer.

  7. Selecione Guardar

Passo 5 - Criar uma aplicação

Siga estes passos para criar uma aplicação no PingAccess para cada aplicação em Azure que pretende proteger.

  1. Ir ao MainApplications>

  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 para a aplicação. Por exemplo, uma aplicação em https://mysite:9999/AppName terá uma raiz de contexto de /AppName. A raiz de contexto deve começar com um corte (/), não deve terminar com um corte (/), 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 hospedeiro virtual e raiz de contexto deve ser única 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

Configure a política de autenticação PingFederate

Configure a política de autenticação PingFederate para federar aos múltiplos IDPs fornecidos pelos inquilinos Azure AD B2C

  1. Crie um contrato para fazer a ponte entre os IdPs e o SP. Para mais informações, consulte o centro da Federação e os contratos de política de autenticação. É provável que só precise de um contrato, a menos que o SP exija um conjunto diferente de atributos de cada IdP.

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

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

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

  5. Criar uma ligação SP entre o PingFederate, o centro da federação como idp, e o SP.

  6. Adicione o contrato de autenticação correspondente à ligação SP na janela De Mapeamento de Fonte de Autenticação .

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

  8. Trabalhe com o SP para ligar ao PingFederate, o centro da federação como idp.

Passos seguintes

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