Qué ocurre en el paso del navegador de un inicio de sesión federado de VPN

Haces clic en Conectar y, en lugar de un campo de contraseña, el cliente VPN abre tu navegador. Ese traspaso confunde a quien espera que el túnel se autentique solo. El navegador no es un desvío: es donde el proveedor de identidad autentica realmente a la persona, y el cliente solo espera el resultado.

Recorrer un inicio de sesión de principio a fin muestra a qué paso pertenece cada fallo, y esa es la parte que la mayoría de los runbooks se salta.

Empieza por el cliente, no por la configuración de la pasarela

El cliente construye una solicitud y envía el navegador al proveedor de identidad con un identificador de proveedor de servicios y una ubicación de retorno. Después el IdP de tu organización ejecuta lo que tenga configurado: contraseña, MFA, comprobación del dispositivo, acceso condicional. Si el navegador ya tiene una sesión válida, la parte visible puede durar uno o dos segundos. Esa brevedad es reutilización de sesión, no una comprobación omitida.

Lee en la configuración de federación del cliente dos valores antes que nada: los metadatos o la URL del IdP en el que confía, y la dirección de retorno que espera. Una discrepancia ahí falla antes de que se escriba ninguna contraseña.

Qué debe devolver el proveedor de identidad

El IdP responde con una respuesta SAML firmada que contiene una aserción: quién es el sujeto, quién la emitió, para quién es y cuánto tiempo es válida. Esos campos son el contrato. Emisor, audiencia, destinatario y ventana de validez deben coincidir con lo que espera el servicio.

Una respuesta firmada por el IdP correcto pero dirigida a otra audiencia sigue siendo inválida. Esa es la comprobación que la gente omite cuando copia metadatos de un laboratorio a producción.

Qué valida el servicio de VPN antes de confiar en ti

El servicio verifica la firma con el certificado de confianza, comprueba el emisor, la audiencia y el destinatario, y luego evalúa las condiciones temporales. Solo después asigna la aserción a un usuario o grupo y aplica la política de autorización de la VPN. Autenticación y autorización son pasos separados aquí, y una aserción válida sin un grupo coincidente produce una sesión que conecta y no llega a nada.

La aserción es material de autenticación, no una contraseña. Pegarla en otro cliente, o guardarla para una reconexión posterior, no es un inicio de sesión admitido.

Dos vidas que terminan por separado

La sesión del navegador en el IdP y la sesión de VPN en la pasarela caducan con relojes distintos. Cerrar sesión en el IdP no derriba necesariamente un túnel establecido, y desconectar el túnel no te cierra la sesión del navegador.

AWS Client VPN documenta que su flujo federado no admite el cierre de sesión único SAML, que es un ejemplo concreto de esa brecha. Comprueba tu propio servicio en lugar de suponer simetría.

Por eso una reconexión se comporta distinto a las 09:00 y a las 15:00. Puede reutilizar la sesión del IdP en silencio, pedir MFA otra vez o fallar porque la duración de la sesión del extremo expiró y la del navegador no. El flujo de federación de AWS describe sus propios requisitos de cliente y de respuesta, y otros servicios usan traspasos distintos.

Cuando falla el paso del navegador, comprueba esto en orden

Trabaja desde el navegador hacia fuera, porque el mensaje de error suele nombrar el último salto y no el primero.

Si la página nunca carga, la URL del IdP en el cliente o la ruta hasta ella es incorrecta. Si el IdP rechaza la solicitud, el identificador de proveedor de servicios o el retorno no coinciden con su configuración. Si el navegador muestra éxito y el cliente sigue fallando, la respuesta llegó al lugar equivocado o no pasó la validación de audiencia y tiempo. Y si el túnel sube sin acceso, se aceptó la aserción pero no el mapeo de grupo.

Ten la página esperada, el retorno y el mapeo de grupo en un solo documento. Así, un usuario que informa de un inicio de sesión de VPN roto puede decir cuál de esas cuatro cosas vio, y la respuesta ya está medio escrita.