AWS Client VPN SAML e Google Workspace: la lacuna del callback

La pagina app_not_configured_for_user arriva da Google Workspace e compare prima che venga negoziato un solo pacchetto del tunnel. Quest’ordine è tutta la diagnosi. Reinstallare il client, modificare il profilo o controllare le route non può ripulire una pagina che l’endpoint VPN non ha ancora visto. Il passo che fallisce è un passaggio nel browser tra il provider di identità e un listener sulla macchina dell’utente, e in quel passaggio ci sono esattamente tre cose da verificare.

Leggete la pagina come una dichiarazione del provider di identità

Google restituisce questo quando l’applicazione SAML non è abilitata per l’account che ha effettuato l’accesso. L’app può essere disattivata, l’utente può trovarsi fuori dall’unità organizzativa o dal gruppo assegnato, oppure le impostazioni del provider di servizi possono non corrispondere a ciò che la richiesta chiedeva.

Niente di tutto ciò è un problema di certificato, di route o di tunnel, anche se l’utente se n’è accorto nel client VPN.

I due valori che il client accetterà

AWS Client VPN esegue uno scambio SAML avviato dal provider di servizi, quindi il client apre un browser, l’utente si autentica e il provider invia un’asserzione firmata a un URL Assertion Consumer Service. Per il client desktop fornito da AWS quell’URL è un listener su loopback, di solito la porta 35001, e il pubblico atteso è l’identificatore di entità dell’applicazione SAML Client VPN, non l’entità di accesso della console AWS.

Entrambi i valori devono corrispondere a ciò che il client si aspetta: dove viene pubblicata l’asserzione e a chi è indirizzata. Una configurazione copiata da un’applicazione SSO della console può sembrare del tutto plausibile e comunque puntare alla coppia sbagliata.

Prendete entrambi i valori dai requisiti Client VPN SAML, non da una guida generica all’accesso singolo di AWS. L’entità SSO della console è abbastanza simile da essere tentante. È un’altra applicazione con un altro pubblico, e il client rifiuta l’asserzione senza spiegarsi. Copiate la coppia una volta e conservatela accanto al profilo.

Google non accetterà il callback HTTP semplice

La console di amministrazione richiede un URL ACS HTTPS, e il callback del client è HTTP semplice su loopback. Quel valore non può essere digitato nella configurazione dell’app Workspace, ed è per questo che alcuni team provano un proxy inverso che termina TLS e inoltra al listener locale. Non ripara il disallineamento: il browser vede un’origine, il client ne annuncia un’altra, e la risposta restituita può arrivare con la destinazione sbagliata.

La soluzione che funziona è un provider di identità intermediario. L’applicazione SAML presso l’intermediario riceve il callback loopback e il pubblico AWS, e l’intermediario federa l’account Workspace a monte. La regola HTTPS di Google resta soddisfatta, e l’asserzione che raggiunge il client nomina ancora l’indirizzo e il pubblico che si aspetta.

Quell’intermediario è una dipendenza amministrativa che qualcuno deve possedere, monitorare e includere nella dismissione. È anche un secondo punto in cui un’interruzione diventa un errore di accesso. Valutatelo prima di promettere il progetto. Se nessuno se ne farà carico, la risposta onesta è che il client AWS non può usare Workspace come unico provider di identità.

Assegnazione e verifica in due passaggi

Prima di riprogettare qualcosa, confermate che l’app sia attiva per l’unità organizzativa o il gruppo corretti, e che le applicazioni SAML di terze parti abbiano i propri controlli di assegnazione, separati dall’elenco delle app lato Google.

Verificate anche se l’account ha attiva la verifica in due passaggi. Google può richiederla prima che un’applicazione SAML diventi utilizzabile per un utente, e una sola risposta nel thread originale è stata risolta esattamente così. È la cosa più economica da escludere e la più fastidiosa da scoprire per ultima.

Verificate con una sessione pulita

Dopo ogni modifica, provate con un profilo browser nuovo e una configurazione client pulita. Le asserzioni in cache e le sessioni riutilizzate nascondono se la correzione è arrivata.

Poi confrontate due registri fianco a fianco: l’evento di audit del provider di identità e il log del client. Un accesso riuscito senza tunnel rimanda al callback o al pubblico. Un tunnel connesso con una risorsa irraggiungibile è un problema di routing o di autorizzazione e appartiene a tutt’altro luogo.

Cosa non cambiare

Non rimuovete auth-federate dal profilo e non disattivate i controlli dei certificati per superare la pagina. Entrambi cambiano il progetto di autenticazione invece del callback che fallisce, ed entrambi tendono a rompersi al successivo aggiornamento del client.

Correggete invece il passaggio, e lasciate una nota che nomini l’intermediario, il pubblico e la porta loopback. La prossima persona che vedrà la pagina avrà bisogno di tutti e tre.