AWS Client VPN SAML y Google Workspace: el hueco de la devolución de llamada

La página app_not_configured_for_user viene de Google Workspace y aparece antes de que se negocie un solo paquete del túnel. Ese orden es todo el diagnóstico. Reinstalar el cliente, editar el perfil o revisar las rutas no puede limpiar una página que el extremo del VPN todavía no ha visto. El paso que falla es un traspaso en el navegador entre el proveedor de identidad y un escucha en la propia máquina del usuario, y en ese traspaso hay exactamente tres cosas que vale la pena revisar.

Lea la página como una declaración del proveedor de identidad

Google devuelve esto cuando la aplicación SAML no está habilitada para la cuenta que inició sesión. Puede que la aplicación esté desactivada, que el usuario esté fuera de la unidad organizativa o del grupo asignado, o que la configuración del proveedor de servicio no coincida con lo que pidió la solicitud.

Nada de eso es un problema de certificado, de ruta ni de túnel, aunque el usuario lo haya notado en el cliente del VPN.

Los dos valores que el cliente aceptará

AWS Client VPN ejecuta un intercambio SAML iniciado por el proveedor de servicio, así que el cliente abre un navegador, el usuario se autentica y el proveedor envía una aserción firmada a una URL de Assertion Consumer Service. Para el cliente de escritorio que proporciona AWS esa URL es un escucha en loopback, normalmente el puerto 35001, y la audiencia esperada es el identificador de entidad de la aplicación SAML de Client VPN, no la entidad de inicio de sesión de la consola de AWS.

Ambos valores tienen que coincidir con lo que espera el cliente: dónde se publica la aserción y a quién va dirigida. Una configuración copiada de una aplicación SSO de la consola puede parecer del todo plausible y aun así apuntar al par equivocado.

Tome ambos valores de los requisitos de Client VPN SAML, no de una guía genérica de inicio de sesión único de AWS. La entidad SSO de la consola se parece lo suficiente como para ser tentadora. Es otra aplicación con otra audiencia, y el cliente rechaza la aserción sin explicarse. Copie el par una vez y guárdelo junto al perfil.

Google no aceptará la devolución de llamada HTTP simple

La consola de administración exige una URL ACS HTTPS, y la devolución de llamada del cliente es HTTP simple en loopback. Ese valor no se puede escribir en la configuración de la aplicación de Workspace, y por eso algunos equipos prueban un proxy inverso que termina TLS y reenvía al escucha local. Eso no repara el desajuste: el navegador ve un origen, el cliente anuncia otro, y la respuesta devuelta puede llegar con el destino equivocado.

La disposición que funciona es un proveedor de identidad intermediario. La aplicación SAML del intermediario recibe la devolución de llamada en loopback y la audiencia de AWS, y el intermediario federa la cuenta de Workspace hacia arriba. La regla HTTPS de Google sigue cumpliéndose, y la aserción que llega al cliente sigue nombrando la dirección y la audiencia que espera.

Ese intermediario es una dependencia administrativa que alguien tiene que poseer, monitorear e incluir en la baja. También es un segundo lugar donde una caída se convierte en un fallo de inicio de sesión. Valórelo antes de prometer el diseño. Si nadie va a encargarse de él, la respuesta honesta es que el cliente de AWS no puede usar Workspace como su único proveedor de identidad.

Asignación y verificación en dos pasos

Antes de rediseñar nada, confirme que la aplicación está activada para la unidad organizativa o el grupo correctos, y que las aplicaciones SAML de terceros tienen sus propios controles de asignación, separados de la lista de aplicaciones del lado de Google.

Compruebe también si la cuenta tiene activada la verificación en dos pasos. Google puede exigirla antes de que una aplicación SAML sea utilizable por un usuario, y una sola respuesta del hilo original se resolvió exactamente así. Es lo más barato de descartar y lo más molesto de descubrir al final.

Verifique con una sesión limpia

Después de cualquier cambio, pruebe con un perfil de navegador nuevo y una configuración de cliente limpia. Las aserciones en caché y las sesiones reutilizadas ocultan si la corrección ha llegado.

Después compare dos registros uno al lado del otro: el evento de auditoría del proveedor de identidad y el registro del cliente. Un inicio de sesión correcto sin túnel apunta a la devolución de llamada o a la audiencia. Un túnel conectado con un recurso inalcanzable es un problema de enrutamiento o de autorización y pertenece a otro sitio por completo.

Qué no cambiar

No quite auth-federate del perfil ni desactive las comprobaciones de certificados para pasar la página. Ambos cambios alteran el diseño de autenticación en lugar de la devolución de llamada que falla, y ambos suelen romperse en la siguiente actualización del cliente.

Arregle más bien el traspaso y deje una nota que nombre al intermediario, la audiencia y el puerto de loopback. La próxima persona que vea la página necesitará las tres cosas.