AWS Client VPN SAML i Google Workspace: luka w wywołaniu zwrotnym
Google pokazuje app_not_configured_for_user, zanim powstanie jakikolwiek tunel. Klient chce zwykłego wywołania zwrotnego HTTP na loopbacku, którego Workspace nie akceptuje.
Strona app_not_configured_for_user pochodzi z Google Workspace i pojawia się, zanim wynegocjowany zostanie choćby jeden pakiet tunelu. Ta kolejność to cała diagnoza. Ponowna instalacja klienta, edycja profilu czy sprawdzanie tras nie usuną strony, której punkt końcowy VPN jeszcze nie widział. Krokiem, który zawodzi, jest przekazanie w przeglądarce między dostawcą tożsamości a nasłuchującym na maszynie użytkownika, i w tym przekazaniu warto sprawdzić dokładnie trzy rzeczy.
Czytaj stronę jako oświadczenie dostawcy tożsamości
Google zwraca to, gdy aplikacja SAML nie jest włączona dla konta, które się zalogowało. Aplikacja może być wyłączona, użytkownik może znajdować się poza przypisaną jednostką organizacyjną lub grupą, albo ustawienia dostawcy usług nie odpowiadają temu, czego wymagało żądanie.
Nic z tego nie jest problemem certyfikatu, trasy ani tunelu, choć użytkownik zauważył to w kliencie VPN.
Dwie wartości, które klient zaakceptuje
AWS Client VPN prowadzi wymianę SAML inicjowaną przez dostawcę usług, więc klient otwiera przeglądarkę, użytkownik się uwierzytelnia, a dostawca wysyła podpisane twierdzenie z powrotem na adres URL Assertion Consumer Service. Dla klienta pulpitu dostarczanego przez AWS ten adres to nasłuchujący na loopbacku, zwykle port 35001, a oczekiwaną publicznością jest identyfikator encji aplikacji SAML Client VPN, a nie encja logowania konsoli AWS.
Obie wartości muszą odpowiadać temu, czego oczekuje klient: gdzie publikowane jest twierdzenie i do kogo jest adresowane. Konfiguracja skopiowana z aplikacji SSO w konsoli może wyglądać całkowicie wiarygodnie i nadal celować w niewłaściwą parę.
Weź obie wartości z wymagań Client VPN SAML, a nie z ogólnego przewodnika po jednokrotnym logowaniu AWS. Encja SSO w konsoli wygląda wystarczająco podobnie, by kusić. To inna aplikacja z inną publicznością, a klient odrzuca twierdzenie bez wyjaśnienia. Skopiuj parę raz i zachowaj ją obok profilu.
Google nie zaakceptuje zwykłego wywołania zwrotnego HTTP
Konsola administracyjna wymaga adresu ACS przez HTTPS, a wywołanie zwrotne klienta to zwykły HTTP na loopbacku. Tej wartości w ogóle nie można wpisać w konfiguracji aplikacji Workspace, dlatego niektóre zespoły próbują odwrotnego proxy, które kończy TLS i przekazuje do lokalnego nasłuchującego. To nie naprawia niezgodności: przeglądarka widzi jedno pochodzenie, klient ogłasza inne, a zwrócona odpowiedź może dotrzeć do złego miejsca przeznaczenia.
Działa pośredniczący dostawca tożsamości. Aplikacja SAML u pośrednika otrzymuje wywołanie zwrotne loopback i publiczność AWS, a pośrednik federuje konto Workspace w górę. Reguła HTTPS Google pozostaje spełniona, a twierdzenie, które dociera do klienta, nadal wskazuje oczekiwany adres i publiczność.
Ten pośrednik to zależność administracyjna, którą ktoś musi mieć, monitorować i uwzględnić przy odejściu pracownika. To także drugie miejsce, w którym awaria zamienia się w błąd logowania. Wyceń to, zanim obiecasz projekt. Jeśli nikt się tego nie podejmie, uczciwa odpowiedź brzmi: klient AWS nie może używać Workspace jako jedynego dostawcy tożsamości.
Przypisanie i weryfikacja dwuetapowa
Zanim cokolwiek przeprojektujesz, potwierdź, że aplikacja jest włączona dla właściwej jednostki organizacyjnej lub grupy, a aplikacje SAML firm trzecich mają własne mechanizmy przypisania, oddzielne od listy aplikacji po stronie Google.
Sprawdź też, czy na koncie włączona jest weryfikacja dwuetapowa. Google może jej wymagać, zanim aplikacja SAML stanie się użyteczna dla użytkownika, i jedna odpowiedź w pierwotnym wątku została rozwiązana dokładnie w ten sposób. To najtańsza rzecz do wykluczenia i najbardziej irytująca do odkrycia na końcu.
Zweryfikuj na czystej sesji
Po każdej zmianie testuj na nowym profilu przeglądarki i czystej konfiguracji klienta. Twierdzenia z pamięci podręcznej i ponownie użyte sesje ukrywają, czy poprawka zadziałała.
Następnie porównaj dwa zapisy obok siebie: zdarzenie audytu dostawcy tożsamości i log klienta. Udane logowanie bez tunelu wskazuje z powrotem na wywołanie zwrotne lub publiczność. Połączony tunel z nieosiągalnym zasobem to problem routingu lub autoryzacji i należy zupełnie gdzie indziej.
Czego nie zmieniać
Nie usuwaj auth-federate z profilu i nie wyłączaj sprawdzania certyfikatów, by przejść stronę. Oba zmieniają projekt uwierzytelniania, a nie zawodzące wywołanie zwrotne, i oba zwykle psują się przy następnej aktualizacji klienta.
Zamiast tego napraw przekazanie i zostaw notatkę, która wymienia pośrednika, publiczność i port loopback. Następna osoba, która zobaczy tę stronę, będzie potrzebować wszystkich trzech.