AWS Client VPN SAML a Google Workspace: mezera ve zpětném volání

Stránka app_not_configured_for_user pochází z Google Workspace a objeví se dřív, než je vyjednán jediný paket tunelu. Toto pořadí je celá diagnóza. Přeinstalace klienta, úprava profilu ani kontrola tras nemohou odstranit stránku, kterou koncový bod VPN ještě neviděl. Selhávající krok je předání v prohlížeči mezi poskytovatelem identity a posluchačem na vlastním počítači uživatele, a v tomto předání stojí za kontrolu přesně tři věci.

Čtěte stránku jako prohlášení poskytovatele identity

Google to vrací, když aplikace SAML není povolena pro účet, který se přihlásil. Aplikace může být vypnutá, uživatel může být mimo přiřazenou organizační jednotku nebo skupinu, nebo se nastavení poskytovatele služeb nemusí shodovat s tím, co požadavek žádal.

Nic z toho není problém certifikátu, trasy ani tunelu, i když si toho uživatel všiml v klientu VPN.

Dvě hodnoty, které klient přijme

AWS Client VPN provádí výměnu SAML iniciovanou poskytovatelem služeb, takže klient otevře prohlížeč, uživatel se ověří a poskytovatel odešle podepsané tvrzení zpět na adresu Assertion Consumer Service. Pro desktopového klienta od AWS je touto adresou posluchač na loopbacku, obvykle port 35001, a očekávané publikum je identifikátor entity aplikace SAML pro Client VPN, nikoli entita přihlášení do konzole AWS.

Obě hodnoty musí odpovídat tomu, co klient očekává: kam se tvrzení odesílá a komu je adresováno. Konfigurace zkopírovaná z aplikace SSO v konzoli může vypadat zcela věrohodně a přesto mířit na špatnou dvojici.

Vezměte obě hodnoty z požadavků Client VPN SAML, ne z obecného průvodce jednotným přihlášením v AWS. Entita SSO v konzoli vypadá dost podobně, aby byla lákavá. Je to jiná aplikace s jiným publikem a klient tvrzení odmítne, aniž by se vysvětlil. Zkopírujte dvojici jednou a uložte ji vedle profilu.

Google nepřijme obyčejné HTTP zpětné volání

Administrátorská konzole vyžaduje adresu ACS přes HTTPS, a zpětné volání klienta je obyčejné HTTP na loopbacku. Tuto hodnotu nelze do konfigurace aplikace Workspace vůbec zadat, a proto se některé týmy pokoušejí o reverzní proxy, která ukončí TLS a předá požadavek místnímu posluchači. To nesoulad neopraví: prohlížeč vidí jeden origin, klient ohlašuje jiný a vrácená odpověď může dorazit na špatné místo určení.

Fungujícím uspořádáním je zprostředkující poskytovatel identity. Aplikace SAML u zprostředkovatele dostane zpětné volání na loopback a publikum AWS a zprostředkovatel federuje účet Workspace výše. Pravidlo HTTPS u Google zůstává splněno a tvrzení, které dorazí ke klientu, stále uvádí adresu a publikum, které očekává.

Tento zprostředkovatel je administrativní závislost, kterou musí někdo vlastnit, sledovat a zahrnout do ukončení přístupu. Je to také druhé místo, kde se výpadek změní v selhání přihlášení. Vyceníte ho, než design slíbíte. Pokud ho nikdo nebude vlastnit, poctivá odpověď je, že klient AWS nemůže Workspace použít jako jediného poskytovatele identity.

Přiřazení a dvoufázové ověření

Než cokoli předěláte, ověřte, že je aplikace zapnutá pro správnou organizační jednotku nebo skupinu a že aplikace SAML třetích stran mají vlastní ovládání přiřazení oddělené od seznamu aplikací na straně Google.

Zkontrolujte také, zda má účet zapnuté dvoufázové ověření. Google ho může vyžadovat, než aplikace SAML začne být pro uživatele použitelná, a jedna odpověď v původním vlákně byla vyřešena právě takto. Je to nejlevnější věc k vyloučení a nejotravnější k objevení na konci.

Ověřte s čistou relací

Po každé změně testujte s novým profilem prohlížeče a čistou konfigurací klienta. Uložená tvrzení a znovu použité relace skrývají, zda oprava zabrala.

Potom porovnejte dva záznamy vedle sebe: auditní událost poskytovatele identity a log klienta. Úspěšné přihlášení bez tunelu ukazuje zpět na zpětné volání nebo publikum. Připojený tunel s nedostupným prostředkem je problém směrování nebo autorizace a patří zcela jinam.

Co neměnit

Neodstraňujte auth-federate z profilu a nevypínejte kontroly certifikátů, abyste stránku obešli. Obojí mění návrh ověřování, ne selhávající zpětné volání, a obojí se obvykle rozbije při příští aktualizaci klienta.

Opravte místo toho předání a zanechte poznámku, která uvádí zprostředkovatele, publikum a port loopback. Příští člověk, který stránku uvidí, bude potřebovat všechny tři.