AWS Client VPN SAML e Google Workspace: o oco da devolución de chamada

A páxina app_not_configured_for_user vén de Google Workspace e aparece antes de que se negocie un só paquete do túnel. Esa orde é todo o diagnóstico. Reinstalar o cliente, editar o perfil ou revisar as rutas non pode limpar unha páxina que o extremo do VPN aínda non viu. O paso que falla é un traspaso no navegador entre o provedor de identidade e un escoitante na propia máquina do usuario, e nese traspaso hai exactamente tres cousas que paga a pena revisar.

Lea a páxina como unha declaración do provedor de identidade

Google devolve isto cando a aplicación SAML non está habilitada para a conta que iniciou sesión. Pode que a aplicación estea desactivada, que o usuario estea fóra da unidade organizativa ou do grupo asignado, ou que a configuración do provedor de servizo non coincida co que pediu a solicitude.

Nada diso é un problema de certificado, de ruta nin de túnel, aínda que o usuario o notase no cliente do VPN.

Os dous valores que o cliente aceptará

AWS Client VPN executa un intercambio SAML iniciado polo provedor de servizo, así que o cliente abre un navegador, o usuario autentícase e o provedor envía unha aserción asinada a un URL de Assertion Consumer Service. Para o cliente de escritorio que fornece AWS ese URL é un escoitante en loopback, normalmente o porto 35001, e a audiencia esperada é o identificador de entidade da aplicación SAML de Client VPN, non a entidade de inicio de sesión da consola de AWS.

Ambos os valores teñen que coincidir co que espera o cliente: onde se publica a aserción e a quen vai dirixida. Unha configuración copiada dunha aplicación SSO da consola pode parecer totalmente plausible e aínda así apuntar ao par equivocado.

Tome ambos os valores dos requisitos de Client VPN SAML, non dunha guía xenérica de inicio de sesión único de AWS. A entidade SSO da consola parécese o suficiente como para ser tentadora. É outra aplicación con outra audiencia, e o cliente rexeita a aserción sen explicarse. Copie o par unha vez e gárdeo xunto ao perfil.

Google non aceptará a devolución de chamada HTTP simple

A consola de administración esixe un URL ACS HTTPS, e a devolución de chamada do cliente é HTTP simple en loopback. Ese valor non se pode escribir na configuración da aplicación de Workspace, e por iso algúns equipos proban un proxy inverso que remata TLS e reenvía ao escoitante local. Iso non repara o desaxuste: o navegador ve unha orixe, o cliente anuncia outra, e a resposta devolta pode chegar co destino equivocado.

A disposición que funciona é un provedor de identidade intermediario. A aplicación SAML do intermediario recibe a devolución de chamada en loopback e a audiencia de AWS, e o intermediario federa a conta de Workspace cara arriba. A regra HTTPS de Google segue cumpríndose, e a aserción que chega ao cliente segue nomeando o enderezo e a audiencia que espera.

Ese intermediario é unha dependencia administrativa que alguén ten que posuír, monitorizar e incluír na baixa. Tamén é un segundo lugar onde unha caída se converte nun fallo de inicio de sesión. Valóreo antes de prometer o deseño. Se ninguén vai encargarse del, a resposta honesta é que o cliente de AWS non pode usar Workspace como o seu único provedor de identidade.

Asignación e verificación en dous pasos

Antes de redeseñar nada, confirme que a aplicación está activada para a unidade organizativa ou o grupo correctos, e que as aplicacións SAML de terceiros teñen os seus propios controis de asignación, separados da lista de aplicacións do lado de Google.

Comprobe tamén se a conta ten activada a verificación en dous pasos. Google pode esixila antes de que unha aplicación SAML sexa utilizábel por un usuario, e unha soa resposta do fío orixinal resolveuse exactamente así. É o máis barato de descartar e o máis molesto de descubrir ao final.

Verifique cunha sesión limpa

Despois de calquera cambio, proba cun perfil de navegador novo e unha configuración de cliente limpa. As asercións na caché e as sesións reutilizadas agochan se a corrección chegou.

Despois compare dous rexistros un ao lado do outro: o evento de auditoría do provedor de identidade e o rexistro do cliente. Un inicio de sesión correcto sen túnel apunta á devolución de chamada ou á audiencia. Un túnel conectado cun recurso inalcanzable é un problema de encamiñamento ou de autorización e pertence a outro sitio por completo.

Que non cambiar

Non quite auth-federate do perfil nin desactive as comprobacións de certificados para pasar a páxina. Ambos os cambios alteran o deseño de autenticación en lugar da devolución de chamada que falla, e ambos adoitan romper na seguinte actualización do cliente.

Arranxe mellor o traspaso e deixe unha nota que nomee o intermediario, a audiencia e o porto de loopback. A próxima persoa que vexa a páxina necesitará as tres cousas.