Co dzieje się na etapie przeglądarki przy sfederowanym logowaniu do VPN

Klikasz Połącz, a zamiast pola hasła klient VPN otwiera Twoją przeglądarkę. To przekazanie myli osoby, które oczekują, że tunel uwierzytelni się sam. Przeglądarka nie jest objazdem: to tam dostawca tożsamości faktycznie uwierzytelnia osobę, a klient tylko czeka na wynik.

Przejście przez jedno logowanie od początku do końca pokazuje, gdzie należy przypisać każdy błąd, i właśnie ten fragment większość runbooków pomija.

Zacznij od klienta, nie od konfiguracji bramy

Klient buduje żądanie i wysyła przeglądarkę do dostawcy tożsamości z identyfikatorem dostawcy usług i adresem powrotu. IdP Twojej organizacji wykonuje następnie to, co ma skonfigurowane: hasło, MFA, kontrolę urządzenia, dostęp warunkowy. Jeśli przeglądarka ma już ważną sesję, widoczna część może zająć sekundę lub dwie. Ta krótkość to ponowne użycie sesji, a nie pominięta kontrola.

Zanim cokolwiek innego, sprawdź w konfiguracji federacji klienta dwie wartości: metadane lub URL IdP, któremu ufa, oraz adres wywołania zwrotnego, którego oczekuje. Niezgodność w tym miejscu kończy się błędem, zanim zostanie wpisane jakiekolwiek hasło.

Co musi zwrócić dostawca tożsamości

IdP odpowiada podpisaną odpowiedzią SAML zawierającą asercję: kim jest podmiot, kto ją wydał, dla kogo jest przeznaczona i jak długo pozostaje ważna. Te pola są kontraktem. Wystawca, odbiorcy, adresat i okno ważności muszą się zgadzać z tym, czego oczekuje usługa.

Odpowiedź podpisana przez właściwy IdP, ale zaadresowana do innego odbiorcy, jest nadal nieprawidłowa. To kontrola, którą ludzie pomijają, kopiując metadane z laboratorium do produkcji.

Co usługa VPN weryfikuje, zanim Ci zaufa

Usługa weryfikuje podpis względem zaufanego certyfikatu, sprawdza wystawcę, odbiorców i adresata, a następnie ocenia warunki czasowe. Dopiero potem mapuje asercję na użytkownika lub grupę i stosuje politykę autoryzacji VPN. Uwierzytelnianie i autoryzacja to tutaj osobne kroki, a ważna asercja bez pasującej grupy daje sesję, która się łączy i do niczego nie dociera.

Asercja to materiał uwierzytelniający, nie hasło. Wklejenie jej do innego klienta albo zachowanie na późniejsze ponowne połączenie nie jest obsługiwanym logowaniem.

Dwa czasy życia, które kończą się osobno

Sesja przeglądarki u IdP i sesja VPN na bramie wygasają według różnych zegarów. Wylogowanie z IdP niekoniecznie zrywa ustanowiony tunel, a rozłączenie tunelu nie wylogowuje Cię z przeglądarki.

AWS Client VPN dokumentuje, że jego przepływ sfederowany nie obsługuje SAML single logout, co jest jednym konkretnym przykładem tej luki. Sprawdź własną usługę, zamiast zakładać symetrię.

Dlatego ponowne połączenie zachowuje się inaczej o 09:00 i o 15:00. Może po cichu użyć ponownie sesji IdP, ponownie poprosić o MFA albo zawieść, bo czas trwania sesji endpointu wygasł, a sesja przeglądarki nie. Przepływ federacji AWS opisuje własne wymagania dotyczące klienta i odpowiedzi, a inne usługi stosują inne przekazania.

Gdy etap przeglądarki zawodzi, sprawdź to w podanej kolejności

Pracuj od przeglądarki na zewnątrz, ponieważ komunikat o błędzie zwykle wskazuje ostatni przeskok, a nie pierwszy.

Jeśli strona nigdy się nie ładuje, URL IdP klienta lub ścieżka do niego jest błędna. Jeśli IdP odrzuca żądanie, identyfikator dostawcy usług lub adres wywołania zwrotnego nie zgadza się z jego konfiguracją. Jeśli przeglądarka pokazuje sukces, a klient nadal zawodzi, odpowiedź trafiła w złe miejsce albo nie przeszła walidacji odbiorców i czasu. A jeśli tunel wstaje bez dostępu, asercja została zaakceptowana, ale mapowania grup już nie.

Trzymaj oczekiwaną stronę, adres wywołania zwrotnego i mapowanie grup w jednym dokumencie. Wtedy użytkownik zgłaszający zepsute logowanie do VPN może powiedzieć, którą z tych czterech rzeczy zobaczył, a odpowiedź jest już w połowie napisana.