O que acontece na etapa do navegador em um login VPN federado

Você clica em Conectar e, em vez de uma caixa de senha, o cliente VPN abre o seu navegador. Essa passagem confunde quem espera que o túnel se autentique sozinho. O navegador não é um desvio: é onde o provedor de identidade realmente autentica a pessoa, e o cliente apenas aguarda o resultado.

Percorrer um login do início ao fim mostra a que etapa cada falha pertence, e é justamente essa parte que a maioria dos runbooks pula.

Comece pelo cliente, não pela configuração do gateway

O cliente monta uma solicitação e envia o navegador ao provedor de identidade com um identificador de provedor de serviço e um local de retorno. O IdP da sua organização executa então o que estiver configurado: senha, MFA, verificação de dispositivo, acesso condicional. Se o navegador já tiver uma sessão válida, a parte visível pode levar um ou dois segundos. Essa brevidade é reúso de sessão, não uma verificação pulada.

Leia na configuração de federação do cliente dois valores antes de qualquer coisa: os metadados ou a URL do IdP em que ele confia, e o endereço de callback que ele espera. Uma divergência ali falha antes de qualquer senha ser digitada.

O que o provedor de identidade precisa devolver

O IdP responde com uma resposta SAML assinada contendo uma assertion: quem é o sujeito, quem a emitiu, para quem ela vale e por quanto tempo permanece válida. Esses campos são o contrato. Emissor, audience, destinatário e janela de validade precisam corresponder ao que o serviço espera.

Uma resposta assinada pelo IdP correto, mas endereçada a outra audience, ainda é inválida. É a verificação que as pessoas pulam quando copiam metadados de um laboratório para a produção.

O que o serviço de VPN valida antes de confiar em você

O serviço verifica a assinatura contra o certificado confiável, checa o emissor, a audience e o destinatário, e então avalia as condições de tempo. Só depois disso ele mapeia a assertion para um usuário ou grupo e aplica a política de autorização da VPN. Autenticação e autorização são etapas separadas aqui, e uma assertion válida sem grupo correspondente gera uma sessão que conecta e não alcança nada.

A assertion é material de autenticação, não uma senha. Colá-la em outro cliente, ou guardá-la para uma reconexão posterior, não é um login suportado.

Dois tempos de vida que terminam separadamente

A sessão do navegador no IdP e a sessão VPN no gateway expiram em relógios diferentes. Sair do IdP não necessariamente derruba um túnel estabelecido, e desconectar o túnel não encerra sua sessão no navegador.

O AWS Client VPN documenta que seu fluxo federado não suporta SAML single logout, o que é um exemplo concreto da lacuna. Verifique o seu próprio serviço em vez de assumir simetria.

É por isso que uma reconexão se comporta de forma diferente às 09:00 e às 15:00. Ela pode reutilizar a sessão do IdP silenciosamente, pedir MFA novamente, ou falhar porque a duração da sessão do endpoint expirou enquanto a do navegador não. O fluxo de federação da AWS descreve os próprios requisitos de cliente e de resposta, e outros serviços usam passagens diferentes.

Quando a etapa do navegador falha, verifique nesta ordem

Trabalhe do navegador para fora, porque a mensagem de erro costuma nomear o último salto em vez do primeiro.

Se a página nunca carrega, a URL do IdP no cliente ou o caminho até ela está errado. Se o IdP rejeita a solicitação, o identificador de provedor de serviço ou o callback não corresponde à configuração dele. Se o navegador mostra sucesso e o cliente ainda falha, a resposta chegou ao lugar errado ou falhou na validação de audience e de tempo. E se o túnel sobe sem acesso, a assertion foi aceita, mas o mapeamento de grupo não.

Mantenha a página esperada, o callback e o mapeamento de grupo em um único documento. Assim, um usuário que relata um login VPN quebrado pode dizer qual dessas quatro coisas ele viu, e a resposta já está metade escrita.