AWS Client VPN SAML et Google Workspace : la faille du retour de rappel

La page app_not_configured_for_user vient de Google Workspace et apparaît avant qu’un seul paquet de tunnel soit négocié. Cet ordre est tout le diagnostic. Réinstaller le client, modifier le profil ou vérifier les routes ne peut pas effacer une page que le point de terminaison VPN n’a pas encore vue. L’étape qui échoue est un passage dans le navigateur entre le fournisseur d’identité et un écouteur sur la machine de l’utilisateur, et dans ce passage il y a exactement trois choses à vérifier.

Lisez la page comme une déclaration du fournisseur d’identité

Google renvoie cela lorsque l’application SAML n’est pas activée pour le compte qui s’est connecté. L’application peut être désactivée, l’utilisateur peut se trouver hors de l’unité organisationnelle ou du groupe attribué, ou les paramètres du fournisseur de service peuvent ne pas correspondre à ce que la demande exigeait.

Rien de tout cela n’est un problème de certificat, de route ou de tunnel, même si c’est dans le client VPN que l’utilisateur l’a remarqué.

Les deux valeurs que le client acceptera

AWS Client VPN effectue un échange SAML initié par le fournisseur de service : le client ouvre un navigateur, l’utilisateur s’authentifie, et le fournisseur renvoie une assertion signée vers une URL Assertion Consumer Service. Pour le client de bureau fourni par AWS, cette URL est un écouteur sur loopback, généralement le port 35001, et l’audience attendue est l’identifiant d’entité de l’application SAML Client VPN, non l’entité de connexion à la console AWS.

Les deux valeurs doivent correspondre à ce que le client attend : où l’assertion est publiée et à qui elle est adressée. Une configuration copiée depuis une application SSO de la console peut sembler parfaitement plausible et viser malgré tout la mauvaise paire.

Prenez les deux valeurs dans les exigences Client VPN SAML, pas dans un guide générique d’authentification unique AWS. L’entité SSO de la console ressemble assez pour être tentante. C’est une autre application avec une autre audience, et le client rejette l’assertion sans s’expliquer. Copiez la paire une fois et conservez-la à côté du profil.

Google n’acceptera pas le rappel HTTP simple

La console d’administration exige une URL ACS en HTTPS, et le rappel du client est du HTTP simple sur loopback. Cette valeur ne peut pas du tout être saisie dans la configuration de l’application Workspace, et c’est pourquoi certaines équipes essaient un proxy inverse qui termine TLS et transmet à l’écouteur local. Cela ne répare pas l’incohérence : le navigateur voit une origine, le client en annonce une autre, et la réponse renvoyée peut arriver avec la mauvaise destination.

La disposition qui fonctionne est un fournisseur d’identité intermédiaire. L’application SAML de l’intermédiaire reçoit le rappel loopback et l’audience AWS, et l’intermédiaire fédère le compte Workspace en amont. La règle HTTPS de Google reste satisfaite, et l’assertion qui atteint le client nomme toujours l’adresse et l’audience qu’il attend.

Cet intermédiaire est une dépendance administrative que quelqu’un doit posséder, surveiller et inclure dans le départ. C’est aussi un second endroit où une panne devient un échec de connexion. Chiffrez-le avant de promettre la conception. Si personne ne veut l’assumer, la réponse honnête est que le client AWS ne peut pas utiliser Workspace comme unique fournisseur d’identité.

Attribution et vérification en deux étapes

Avant de revoir quoi que ce soit, confirmez que l’application est activée pour la bonne unité organisationnelle ou le bon groupe, et que les applications SAML tierces ont leurs propres contrôles d’attribution, distincts de la liste d’applications côté Google.

Vérifiez aussi si le compte a la vérification en deux étapes activée. Google peut l’exiger avant qu’une application SAML devienne utilisable pour un utilisateur, et une seule réponse du fil d’origine a été résolue exactement ainsi. C’est la chose la moins coûteuse à écarter et la plus pénible à découvrir en dernier.

Vérifiez avec une session propre

Après chaque changement, testez avec un profil de navigateur neuf et une configuration client propre. Les assertions en cache et les sessions réutilisées masquent si le correctif a pris.

Comparez ensuite deux enregistrements côte à côte : l’événement d’audit du fournisseur d’identité et le journal du client. Une connexion réussie sans tunnel renvoie au rappel ou à l’audience. Un tunnel connecté avec une ressource injoignable est un problème de routage ou d’autorisation et appartient à un tout autre endroit.

Ce qu’il ne faut pas changer

Ne retirez pas auth-federate du profil et ne désactivez pas les contrôles de certificat pour passer la page. Les deux changent la conception de l’authentification plutôt que le rappel défaillant, et les deux cassent généralement à la mise à jour suivante du client.

Corrigez plutôt le passage, et laissez une note qui nomme l’intermédiaire, l’audience et le port loopback. La prochaine personne à voir la page aura besoin des trois.