Que ocorre no paso do navegador dun inicio de sesión federado de VPN

Preme Conectar e, en lugar dun campo de contrasinal, o cliente VPN abre o teu navegador. Ese traspaso confunde a quen espera que o túnel se autentique só. O navegador non é un desvío: é onde o provedor de identidade autentica realmente a persoa, e o cliente só espera o resultado.

Percorrer un inicio de sesión de principio a fin mostra a que paso pertence cada fallo, e esa é a parte que a maioría dos runbooks se salta.

Comeza polo cliente, non pola configuración da pasarela

O cliente constrúe unha solicitude e envía o navegador ao provedor de identidade cun identificador de provedor de servizos e unha localización de retorno. Despois o IdP da túa organización executa o que teña configurado: contrasinal, MFA, comprobación do dispositivo, acceso condicional. Se o navegador xa ten unha sesión válida, a parte visible pode durar un ou dous segundos. Esa brevidade é reutilización de sesión, non unha comprobación omitida.

Le na configuración de federación do cliente dous valores antes que nada: os metadatos ou o URL do IdP no que confía, e o enderezo de retorno que espera. Unha discrepancia alí falla antes de que se escriba ningún contrasinal.

Que debe devolver o provedor de identidade

O IdP responde cunha resposta SAML asinada que contén unha aserción: quen é o suxeito, quen a emitiu, para quen é e canto tempo é válida. Eses campos son o contrato. Emisor, audiencia, destinatario e xanela de validez deben coincidir co que espera o servizo.

Unha resposta asinada polo IdP correcto pero dirixida a outra audiencia segue sendo inválida. Esa é a comprobación que a xente omite cando copia metadatos dun laboratorio a produción.

Que valida o servizo VPN antes de confiar en ti

O servizo verifica a sinatura co certificado de confianza, comproba o emisor, a audiencia e o destinatario, e despois avalía as condicións temporais. Só despois asigna a aserción a un usuario ou grupo e aplica a política de autorización da VPN. Autenticación e autorización son pasos separados aquí, e unha aserción válida sen un grupo coincidente produce unha sesión que conecta e non chega a nada.

A aserción é material de autenticación, non un contrasinal. Pegala noutro cliente, ou gardala para unha reconexión posterior, non é un inicio de sesión admitido.

Dúas vidas que rematan por separado

A sesión do navegador no IdP e a sesión de VPN na pasarela caducan con reloxos distintos. Pechar a sesión no IdP non derruba necesariamente un túnel establecido, e desconectar o túnel non che pecha a sesión do navegador.

AWS Client VPN documenta que o seu fluxo federado non admite o peche de sesión único SAML, que é un exemplo concreto desa fenda. Comproba o teu propio servizo en lugar de supoñer simetría.

Por iso unha reconexión compórtase distinto ás 09:00 e ás 15:00. Pode reutilizar a sesión do IdP en silencio, pedir MFA outra vez ou fallar porque a duración da sesión do extremo expirou e a do navegador non. O fluxo de federación de AWS describe os seus propios requisitos de cliente e de resposta, e outros servizos usan traspasos distintos.

Cando falla o paso do navegador, comproba isto en orde

Traballa desde o navegador cara a fóra, porque a mensaxe de erro adoita nomear o último salto e non o primeiro.

Se a páxina nunca carga, o URL do IdP no cliente ou o camiño ata ela é incorrecto. Se o IdP rexeita a solicitude, o identificador de provedor de servizos ou o retorno non coinciden coa súa configuración. Se o navegador mostra éxito e o cliente segue fallando, a resposta chegou ao lugar equivocado ou non pasou a validación de audiencia e tempo. E se o túnel sobe sen acceso, aceptouse a aserción pero non o mapeo de grupo.

Ten a páxina esperada, o retorno e o mapeo de grupo nun só documento. Así, un usuario que informa dun inicio de sesión de VPN roto pode dicir cal desas catro cousas viu, e a resposta xa está medio escrita.