Czy VPN SSO automatycznie loguje użytkowników do aplikacji wewnętrznych?

Jedno logowanie może objąć tunel i aplikacje za nim, ale tylko wtedy, gdy każda aplikacja ma własne zaufanie. Oto kolejność podłączania i testowania.

Brama VPN, która uwierzytelnia się przez dostawcę tożsamości, dowodzi jednej rzeczy: dostawca poręczył za użytkownika przed bramą. Nie przekazuje temu użytkownikowi poświadczeń do firmowej wiki, panelu monitoringu ani serwera kompilacji. Te usługi logują ludzi przez własną federację i stosują własną autoryzację, a tunel decyduje tylko, które pakiety mogą do nich dotrzeć.

Trzy sesje, trzy osobne decyzje

Trzymaj stany osobno, bo każdy wygasa według własnego harmonogramu. Sesja VPN to akceptacja tożsamości przez bramę plus przyznany dostęp sieciowy. Sesja przeglądarki u dostawcy tożsamości to to, co przeglądarka nadal przechowuje dla tego dostawcy i może ponownie wykorzystać zgodnie z jego polityką. Sesja aplikacji należy do jednej usługi, która zweryfikowała skierowaną do niej odpowiedź.

Mieszanie tych stanów daje błędne pytanie, zwykle sformułowane jako dlaczego tunel nie loguje użytkownika wszędzie. Przeformułuj je: która aplikacja nie ma wpisu federacji, która odrzuca użytkownika i której brakuje trasy. Jedno zachęcenie do logowania, które otwiera aplikację intranetową, nadal może wrócić do dostawcy, bo drugie przekierowanie to nowe żądanie autoryzacji dla innej grupy odbiorców.

Podłącz bramę jako własną aplikację

Zarejestruj VPN jako zatwierdzoną aplikację u dostawcy, z własnym identyfikatorem, URI przekierowania i przypisaniem użytkowników. Następnie zdecyduj, jakie autoryzacje sieciowe daje to logowanie, bo to polityka VPN, a nie funkcja dostawcy. Użytkownicy, którzy mają docierać tylko do podsieci monitoringu, dostają inną politykę bramy, a nie inne hasło.

Odpowiedź uwierzytelnienia tunelu nie jest poświadczeniem wielokrotnego użytku. Tokeny ID OIDC zawierają roszczenie odbiorcy wskazujące klienta, dla którego je wydano, a asercje bearer SAML ograniczają odbiorcę do odbierającego dostawcę usług. Druga usługa, która akceptuje odpowiedź pierwszej, jest błędnie skonfigurowana, a kopiowanie tokenu do innej aplikacji nie jest integracją.

Zarejestruj każdą aplikację wewnętrzną, potem ustaw kontekst przeglądarki

Każda usługa potrzebuje obsługiwanych wartości SAML lub OIDC: wystawcy, identyfikatora klienta, URL wywołania zwrotnego lub konsumenta asercji, wymaganych roszczeń i przypisania. Dostępność dochodzi na wierzchu, bo kontrole tożsamości nigdy nie dostarczają trasy ani odpowiedzi DNS.

  1. Utwórz wpis aplikacji i potwierdź, że identyfikator encji lub klienta zgadza się z tym, co wysyła aplikacja.
  2. Zarejestruj dokładny URL wywołania zwrotnego, łącznie ze schematem i portem; drobna pomyłka zawodzi po uwierzytelnieniu użytkownika.
  3. Przypisz użytkowników lub grupy, a następnie potwierdź, że wymagane roszczenia są wydawane.
  4. Zezwól na punkty końcowe dostawcy tożsamości oraz aplikację prywatną, inaczej przekierowanie nie może się zakończyć.

Kontekst przeglądarki decyduje, czy istniejąca sesja dostawcy zostanie ponownie użyta. Klient natywny otwierający przeglądarkę systemową może dzielić ten stan, a widok osadzony z własnym słoikiem cookies zwykle nie może. Nowa przeglądarka, okna prywatne i drugi profil zaczynają od zera, co jest oczekiwane, a nie zepsutą konfiguracją SSO.

Uruchom przepływ i odczytaj, gdzie się zatrzymuje

Odtwórz to przy użyciu panelu sieci przeglądarki i śledź łańcuch przekierowań. Użyteczne przejście podąża po jednym skoku naraz: od bramy do dostawcy, od dostawcy z powrotem do aplikacji z kodem lub asercją, od aplikacji do punktu końcowego tokenów dostawcy, sesja aplikacji wydana. Skok, na którym łańcuch się zatrzymuje, wskazuje komponent do naprawy.

Dwie kontrole z wiersza poleceń rozstrzygają zwykłe wątpliwości, a obie można bezpiecznie uruchomić z hosta administracyjnego:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Gdy metadane wymieniają punkty końcowe, których nigdy nie zarejestrowałeś, aplikacja wskazuje innego dzierżawcę lub wystawcę. Gdy pierwsze żądanie do aplikacji odpowiada 302 na nieoczekiwany host, konfiguracja federacji aplikacji jest miejscem do sprawdzenia, a nie profil VPN.

Napraw zachęty, ustalając, kto o nie poprosił

Drugie zachęcenie do hasła nie jest automatycznie usterką. Aplikacja może wymagać wyższego poziomu zapewnienia, albo dostawca może wymuszać maksymalny wiek sesji i nowe wyzwanie. Usuwanie tych wymagań, aby przepływ był cichszy, osłabia celową kontrolę, więc ustal, który komponent o nie poprosił, zanim zmienisz politykę.

Potem zdecyduj, co poprawić. Jeśli zachęta pochodzi od aplikacji, popraw jej wpis federacji. Jeśli pochodzi od dostawcy zgodnie z polityką, udokumentuj wymóg. Jeśli aplikacja jest nieosiągalna po udanym logowaniu, podejrzany jest routing tunelu, bo tożsamość i dostarczanie pakietów zawodzą w różnych miejscach i wyglądają podobnie z miejsca użytkownika.

Powiązane artykuły