AWS Client VPN SAML i Google Workspace: l’escletxa del retorn de crida

La pàgina app_not_configured_for_user ve de Google Workspace i apareix abans que es negociï un sol paquet de túnel. Aquest ordre és tot el diagnòstic. Reinstal·lar el client, editar el perfil o revisar les rutes no pot netejar una pàgina que l’extrem del VPN encara no ha vist. El pas que falla és un traspàs al navegador entre el proveïdor d’identitat i un oient a la màquina de l’usuari, i en aquest traspàs hi ha exactament tres coses que val la pena revisar.

Llegeix la pàgina com una declaració del proveïdor d’identitat

Google retorna això quan l’aplicació SAML no està habilitada per al compte que ha iniciat la sessió. L’aplicació pot estar desactivada, l’usuari pot quedar fora de la unitat organitzativa o del grup assignat, o la configuració del proveïdor de servei pot no coincidir amb la petició.

Res d’això no és un problema de certificat, de ruta o de túnel, encara que l’usuari ho hagi notat al client del VPN.

Els dos valors que el client acceptarà

AWS Client VPN fa un intercanvi SAML iniciat pel proveïdor de servei, així que el client obre un navegador, l’usuari s’autentica i el proveïdor envia una asserció signada a una URL d’Assertion Consumer Service. Per a el client d’escriptori que proporciona AWS, aquesta URL és un oient a loopback, normalment el port 35001, i l’audiència esperada és l’identificador d’entitat de l’aplicació SAML de Client VPN, no l’entitat d’inici de sessió de la consola d’AWS.

Tots dos valors han de coincidir amb el que el client espera: on es publica l’asserció i a qui s’adreça. Una configuració copiada d’una aplicació SSO de la consola pot semblar del tot versemblant i, tot i així, apuntar a la parella equivocada.

Pren els dos valors dels requisits de Client VPN SAML, no d’una guia genèrica d’inici de sessió únic d’AWS. L’entitat SSO de la consola s’hi assembla prou per ser temptadora. És una aplicació diferent amb una audiència diferent, i el client rebutja l’asserció sense explicar-se. Copia la parella una vegada i desa-la al costat del perfil.

Google no acceptarà el retorn de crida HTTP simple

La consola d’administració exigeix una URL ACS HTTPS, i el retorn de crida del client és HTTP simple a loopback. Aquest valor no es pot escriure de cap manera a la configuració de l’aplicació de Workspace, i per això alguns equips proven un proxy invers que acaba el TLS i reenvia a l’oient local. Això no arregla el desajust: el navegador veu un origen, el client n’anuncia un altre, i la resposta retornada pot arribar amb una destinació equivocada.

La disposició que funciona és un proveïdor d’identitat intermediari. L’aplicació SAML de l’intermediari rep el retorn de crida a loopback i l’audiència d’AWS, i l’intermediari federa el compte de Workspace cap amunt. La regla HTTPS de Google continua satisfeta, i l’asserció que arriba al client encara anomena l’adreça i l’audiència que espera.

Aquest intermediari és una dependència administrativa que algú ha de posseir, monitorar i incloure en la baixa. També és un segon lloc on una caiguda es converteix en un error d’inici de sessió. Calcula’n el cost abans de prometre el disseny. Si ningú no se’n farà càrrec, la resposta honesta és que el client d’AWS no pot fer servir Workspace com a únic proveïdor d’identitat.

Assignació i verificació en dos passos

Abans de redissenyar res, confirma que l’aplicació està activada per a la unitat organitzativa o el grup correctes, i que les aplicacions SAML de tercers tenen els seus propis controls d’assignació separats de la llista d’aplicacions del costat de Google.

Comprova també si el compte té la verificació en dos passos activada. Google la pot exigir abans que una aplicació SAML sigui utilitzable per a un usuari, i una sola resposta al fil original es va resoldre exactament així. És el més barat de descartar i el més molest de descobrir al final.

Verifica amb una sessió neta

Després de qualsevol canvi, prova amb un perfil de navegador nou i una configuració de client neta. Les assercions en memòria cau i les sessions reutilitzades amaguen si la correcció ha arribat a bon port.

Després compara dos registres costat a costat: l’esdeveniment d’auditoria del proveïdor d’identitat i el registre del client. Un inici de sessió correcte sense túnel assenyala el retorn de crida o l’audiència. Un túnel connectat amb un recurs inabastable és un problema d’encaminament o d’autorització i pertany a un altre lloc.

Què no cal canviar

No treguis auth-federate del perfil ni desactivis les comprovacions de certificats per passar la pàgina. Tots dos canvien el disseny d’autenticació en lloc del retorn de crida que falla, i tots dos solen trencar-se a la següent actualització del client.

Arregla més aviat el traspàs i deixa una nota que anomeni l’intermediari, l’audiència i el port de loopback. La propera persona que vegi la pàgina necessitarà les tres coses.