AWS Client VPN SAML und Google Workspace: die Lücke beim Callback

Die Seite app_not_configured_for_user kommt von Google Workspace und erscheint, bevor ein einziges Tunnelpaket ausgehandelt wurde. Diese Reihenfolge ist die ganze Diagnose. Eine Neuinstallation des Clients, das Bearbeiten des Profils oder das Prüfen der Routen kann eine Seite nicht beseitigen, die der VPN-Endpunkt noch nie gesehen hat. Der Schritt, der scheitert, ist eine Übergabe im Browser zwischen dem Identitätsanbieter und einem Listener auf dem Rechner des Benutzers, und in dieser Übergabe lohnt es sich, genau drei Dinge zu prüfen.

Lesen Sie die Seite als Aussage des Identitätsanbieters

Google gibt dies zurück, wenn die SAML-Anwendung für das angemeldete Konto nicht aktiviert ist. Die App kann abgeschaltet sein, der Benutzer kann außerhalb der zugewiesenen Organisationseinheit oder Gruppe liegen, oder die Einstellungen des Dienstanbieters passen nicht zu dem, was die Anforderung verlangte.

Nichts davon ist ein Zertifikats-, Routen- oder Tunnelproblem, auch wenn der Benutzer es im VPN-Client bemerkt hat.

Die zwei Werte, die der Client akzeptiert

AWS Client VPN führt einen vom Dienstanbieter initiierten SAML-Austausch durch, der Client öffnet also einen Browser, der Benutzer authentifiziert sich, und der Anbieter schickt eine signierte Assertion an eine Assertion Consumer Service-URL zurück. Für den von AWS bereitgestellten Desktop-Client ist diese URL ein Listener auf Loopback, üblicherweise Port 35001, und die erwartete Audience ist die Entitätskennung der Client VPN SAML-Anwendung, nicht die Entität der AWS-Console-Anmeldung.

Beide Werte müssen zu dem passen, was der Client erwartet: wohin die Assertion gesendet wird und an wen sie adressiert ist. Eine Konfiguration, die aus einer SSO-Anwendung in der Console kopiert wurde, kann völlig plausibel aussehen und trotzdem das falsche Paar treffen.

Nehmen Sie beide Werte aus den Client VPN SAML-Anforderungen, nicht aus einer allgemeinen AWS-Anleitung für einmalige Anmeldung. Die SSO-Entität in der Console sieht ähnlich genug aus, um verlockend zu sein. Es ist eine andere Anwendung mit einer anderen Audience, und der Client weist die Assertion zurück, ohne sich zu erklären. Kopieren Sie das Paar einmal und bewahren Sie es neben dem Profil auf.

Google akzeptiert den einfachen HTTP-Callback nicht

Die Admin-Console verlangt eine HTTPS-ACS-URL, und der Callback des Clients ist einfaches HTTP auf Loopback. Dieser Wert lässt sich überhaupt nicht in die Konfiguration der Workspace-App eintragen, deshalb versuchen manche Teams einen Reverse-Proxy, der TLS beendet und an den lokalen Listener weiterleitet. Das behebt die Diskrepanz nicht: Der Browser sieht einen Origin, der Client gibt einen anderen an, und die zurückgegebene Antwort kann am falschen Ziel ankommen.

Was funktioniert, ist ein Broker als Identitätsanbieter. Die SAML-Anwendung beim Broker bekommt den Loopback-Callback und die AWS-Audience, und der Broker föderiert das Workspace-Konto nach oben. Googles HTTPS-Regel bleibt erfüllt, und die Assertion, die den Client erreicht, nennt weiterhin die Adresse und Audience, die er erwartet.

Dieser Broker ist eine administrative Abhängigkeit, die jemand besitzen, überwachen und beim Offboarding berücksichtigen muss. Er ist auch eine zweite Stelle, an der ein Ausfall zu einem Anmeldefehler wird. Kalkulieren Sie ihn, bevor Sie das Design versprechen. Wenn niemand ihn übernimmt, lautet die ehrliche Antwort, dass der AWS-Client Workspace nicht als einzigen Identitätsanbieter nutzen kann.

Zuordnung und Zwei-Faktor-Bestätigung

Bevor Sie irgendetwas umbauen, bestätigen Sie, dass die App für die richtige Organisationseinheit oder Gruppe aktiv ist und dass SAML-Apps von Drittanbietern eigene Zuordnungssteuerungen haben, getrennt von der App-Liste auf Google-Seite.

Prüfen Sie auch, ob für das Konto die Zwei-Faktor-Bestätigung aktiv ist. Google kann sie verlangen, bevor eine SAML-App für einen Benutzer nutzbar wird, und eine einzelne Antwort im ursprünglichen Thread wurde genau so gelöst. Es ist das Billigste, was man ausschließen kann, und das Ärgerlichste, was man zuletzt entdeckt.

Prüfen Sie mit einer sauberen Sitzung

Testen Sie nach jeder Änderung mit einem frischen Browserprofil und einer sauberen Client-Konfiguration. Zwischengespeicherte Assertions und wiederverwendete Sitzungen verbergen, ob die Korrektur angekommen ist.

Vergleichen Sie dann zwei Aufzeichnungen nebeneinander: das Audit-Ereignis des Identitätsanbieters und das Client-Log. Eine erfolgreiche Anmeldung ohne Tunnel deutet zurück auf den Callback oder die Audience. Ein verbundener Tunnel mit einer nicht erreichbaren Ressource ist ein Routing- oder Autorisierungsproblem und gehört ganz woanders hin.

Was Sie nicht ändern sollten

Entfernen Sie auth-federate nicht aus dem Profil und deaktivieren Sie keine Zertifikatsprüfungen, um an der Seite vorbeizukommen. Beides ändert das Authentifizierungsdesign statt des fehlschlagenden Callbacks, und beides bricht meist beim nächsten Client-Update.

Reparieren Sie stattdessen die Übergabe und hinterlassen Sie eine Notiz, die Broker, Audience und Loopback-Port nennt. Die nächste Person, die die Seite sieht, wird alle drei brauchen.