AWS Client VPN SAML en Google Workspace: het gat in de callback

De pagina app_not_configured_for_user komt van Google Workspace en verschijnt voordat er één tunnelpakket is onderhandeld. Die volgorde is de hele diagnose. De client herinstalleren, het profiel bewerken of routes controleren kan een pagina niet wissen die het VPN-eindpunt nog niet heeft gezien. De stap die faalt, is een overdracht in de browser tussen de identiteitsprovider en een listener op de machine van de gebruiker zelf, en in die overdracht zijn precies drie dingen het controleren waard.

Lees de pagina als een verklaring van de identiteitsprovider

Google geeft dit terug wanneer de SAML-applicatie niet is ingeschakeld voor het account dat zich aanmeldde. De app kan uit staan, de gebruiker kan buiten de toegewezen organisatie-eenheid of groep vallen, of de instellingen van de serviceprovider komen mogelijk niet overeen met wat de aanvraag vroeg.

Niets daarvan is een certificaat-, route- of tunnelprobleem, ook al merkte de gebruiker het op in de VPN-client.

De twee waarden die de client accepteert

AWS Client VPN voert een door de serviceprovider geïnitieerde SAML-uitwisseling uit, dus de client opent een browser, de gebruiker authenticeert, en de provider stuurt een ondertekende assertion terug naar een Assertion Consumer Service-URL. Voor de desktopclient die AWS levert is die URL een listener op loopback, meestal poort 35001, en het verwachte publiek is de entiteitsidentificatie van de Client VPN SAML-applicatie, niet de entiteit van de AWS-console-aanmelding.

Beide waarden moeten overeenkomen met wat de client verwacht: waar de assertion wordt geplaatst en aan wie die is gericht. Een configuratie die uit een SSO-applicatie in de console is gekopieerd, kan volstrekt plausibel lijken en toch het verkeerde paar targeten.

Neem beide waarden uit de Client VPN SAML-vereisten, niet uit een algemene AWS-handleiding voor eenmalige aanmelding. De SSO-entiteit in de console lijkt er genoeg op om verleidelijk te zijn. Het is een andere applicatie met een ander publiek, en de client weigert de assertion zonder zich te verklaren. Kopieer het paar één keer en bewaar het naast het profiel.

Google accepteert de gewone HTTP-callback niet

De beheerdersconsole vereist een HTTPS ACS-URL, en de callback van de client is gewone HTTP op loopback. Die waarde kan helemaal niet in de configuratie van de Workspace-app worden getypt, daarom proberen sommige teams een reverse proxy die TLS beëindigt en naar de lokale listener doorstuurt. Dat herstelt de mismatch niet: de browser ziet één origin, de client adverteert een andere, en het teruggekeerde antwoord kan op de verkeerde bestemming aankomen.

De opzet die werkt is een broker-identiteitsprovider. De SAML-applicatie bij de broker krijgt de loopback-callback en het AWS-publiek, en de broker federeert het Workspace-account omhoog. De HTTPS-regel van Google blijft voldaan, en de assertion die de client bereikt, noemt nog steeds het adres en het publiek dat hij verwacht.

Die broker is een administratieve afhankelijkheid die iemand moet bezitten, monitoren en in offboarding moet opnemen. Het is ook een tweede plek waar een storing een aanmeldingsfout wordt. Beprijs het voordat je het ontwerp belooft. Als niemand het wil bezitten, is het eerlijke antwoord dat de AWS-client Workspace niet als enige identiteitsprovider kan gebruiken.

Toewijzing en tweestapsverificatie

Voordat je iets herontwerpt, bevestig dat de app aan staat voor de juiste organisatie-eenheid of groep, en dat SAML-apps van derden hun eigen toewijzingsbesturing hebben, los van de app-lijst aan de Google-kant.

Controleer ook of op het account tweestapsverificatie is ingeschakeld. Google kan het eisen voordat een SAML-app bruikbaar wordt voor een gebruiker, en één antwoord in de oorspronkelijke thread is precies zo opgelost. Het is het goedkoopste om uit te sluiten en het vervelendste om als laatste te ontdekken.

Verifieer met een schone sessie

Test na elke wijziging met een vers browserprofiel en een schone clientconfiguratie. Gecachte assertions en hergebruikte sessies verbergen of de oplossing is aangekomen.

Vergelijk daarna twee registraties naast elkaar: de auditevent van de identiteitsprovider en het clientlog. Een geslaagde aanmelding zonder tunnel wijst terug naar de callback of het publiek. Een verbonden tunnel met een onbereikbare resource is een routerings- of autorisatieprobleem en hoort ergens anders thuis.

Wat je niet moet veranderen

Verwijder auth-federate niet uit het profiel en schakel certificaatcontroles niet uit om de pagina voorbij te komen. Beide veranderen het ontwerp van de authenticatie in plaats van de falende callback, en beide breken meestal bij de volgende clientupdate.

Repareer in plaats daarvan de overdracht, en laat een notitie achter met de naam van de broker, het publiek en de loopback-poort. De volgende persoon die de pagina ziet, heeft alle drie nodig.