SSO (Single Sign-On)

Single Sign-On pozwala użytkownikowi zalogować się raz i uzyskać dostęp do poczty oraz innych usług organizacji.

Jedno uwierzytelnienie dla wielu usług

SSO, czyli Single Sign-On, jest mechanizmem jednokrotnego uwierzytelniania. Użytkownik potwierdza swoją tożsamość w jednym, centralnym systemie, a następnie może otwierać kolejne usługi bez ponownego wpisywania hasła przy każdym przejściu. Przykładem może być dostęp do poczty, firmowego komunikatora, aplikacji webowej, panelu dokumentów albo systemu obsługi zgłoszeń. Poszczególne usługi nie muszą samodzielnie przechowywać i sprawdzać hasła użytkownika, ponieważ korzystają z informacji przekazanej przez dostawcę tożsamości.

W typowym przepływie uczestniczą trzy elementy: użytkownik korzystający z przeglądarki, aplikacja wymagająca logowania oraz dostawca tożsamości, określany jako Identity Provider, IdP. Aplikacja pełniąca funkcję dostawcy usługi nosi nazwę Service Provider, SP, albo relying party w rozwiązaniach opartych na OpenID Connect. Gdy użytkownik otwiera chronioną usługę, aplikacja przekierowuje go do IdP. Po pomyślnym uwierzytelnieniu IdP przekazuje aplikacji potwierdzenie tożsamości oraz wybrane informacje o koncie. Dzięki temu użytkownik wraca do usługi już jako rozpoznana osoba.

SAML, OpenID Connect i Kerberos w mechanizmie SSO

SSO nie jest jednym protokołem, lecz sposobem organizacji logowania realizowanym przez różne standardy. W aplikacjach internetowych często stosuje się SAML 2.0. W tym modelu dostawca tożsamości wystawia asercję SAML, czyli podpisany komunikat opisujący wynik uwierzytelnienia i atrybuty użytkownika. Aplikacja usługowa weryfikuje podpis, sprawdza odbiorcę komunikatu, jego okres ważności oraz adres usługi, a następnie tworzy własną sesję użytkownika. SAML wykorzystuje komunikaty XML i jest powszechny w integracjach między organizacjami oraz w aplikacjach biznesowych.

W nowoczesnych aplikacjach internetowych i mobilnych często używa się OpenID Connect, który działa jako warstwa uwierzytelniania nad OAuth 2.0. Po zalogowaniu dostawca tożsamości wydaje między innymi token ID zapisany w formacie JWT. Token ID opisuje uwierzytelnionego użytkownika i jest przeznaczony dla aplikacji klienckiej. OAuth 2.0 dotyczy przede wszystkim delegowania dostępu do zasobów, dlatego sam token dostępu OAuth nie powinien być automatycznie traktowany jako dowód tożsamości. W środowiskach opartych na domenie Windows spotyka się także Kerberos, w którym po uwierzytelnieniu użytkownik otrzymuje bilety umożliwiające dostęp do usług bez ponownego podawania hasła.

Sesja, token i kontrola dostępu po zalogowaniu

Jednokrotne logowanie nie oznacza, że każda usługa otrzymuje pełną kontrolę nad kontem użytkownika. IdP przekazuje tylko określony zestaw danych i potwierdza konkretną sesję. Aplikacja powinna sprawdzać między innymi identyfikator odbiorcy, wystawcę komunikatu, czas wystawienia, termin wygaśnięcia, nonce lub stan żądania oraz podpis kryptograficzny, zależnie od użytego protokołu. W OpenID Connect ważną rolę odgrywa także parametr state, który pomaga powiązać odpowiedź z rozpoczętym procesem logowania, oraz nonce chroniący przed ponownym użyciem niepasującej odpowiedzi.

SSO upraszcza obsługę kont, ale nie zastępuje kontroli uprawnień. Po rozpoznaniu użytkownika aplikacja nadal musi zdecydować, do jakich funkcji i zasobów konto ma dostęp. Informacje o grupach, rolach lub zakresach uprawnień mogą być przekazywane w atrybutach SAML albo w odpowiednich oświadczeniach tokenu, lecz ich interpretacja zależy od konfiguracji konkretnej usługi. Osobną kwestią jest zakończenie sesji. Wylogowanie z jednej aplikacji może zakończyć tylko jej lokalną sesję, natomiast pełne wylogowanie z SSO wymaga obsługi mechanizmu Single Logout lub analogicznej funkcji po stronie wszystkich uczestniczących usług.

Podczas diagnozowania problemu z SSO należy rozdzielić kilka możliwych przyczyn: odrzucenie danych logowania przez IdP, błędny adres przekierowania, niezgodność identyfikatora aplikacji, nieważny lub nieprawidłowo podpisany token, rozbieżność czasu systemowego oraz brak wymaganych atrybutów konta. Istotne są również certyfikaty używane do podpisywania komunikatów, konfiguracja zaufania między usługą i IdP oraz poprawne ustawienie domen i ciasteczek sesyjnych w przeglądarce. Sam fakt, że użytkownik może zalogować się do jednej usługi, nie potwierdza poprawności konfiguracji pozostałych integracji.

Sprawdzanie problemów z logowaniem SSO na komputerze

Analizę warto rozpocząć od ustalenia, czy problem dotyczy wszystkich usług, czy tylko jednej aplikacji. Jeżeli logowanie do dostawcy tożsamości kończy się błędem przed przekierowaniem do usługi, przyczyny należy szukać w koncie, metodzie uwierzytelnienia albo polityce IdP. Jeżeli użytkownik zostaje poprawnie uwierzytelniony, lecz aplikacja odrzuca odpowiedź, trzeba porównać konfigurację SP lub relying party z ustawieniami IdP. Pomocne są komunikaty zapisane w dziennikach aplikacji, identyfikator żądania, dokładny czas zdarzenia oraz adres usługi, do którego nastąpiło przekierowanie.

Na laptopie lub komputerze PC można sprawdzić działanie SSO w aktualnej przeglądarce, w trybie bez rozszerzeń oraz po usunięciu danych witryny dotyczących wyłącznie problematycznej usługi. Należy zweryfikować, czy przeglądarka nie blokuje ciasteczek wymaganych do utrzymania sesji między domenami, czy zegar systemowy pokazuje prawidłowy czas i czy połączenie z IdP nie jest przerywane przez filtr sieciowy. W przypadku certyfikatu lub tokenu nie należy omijać ostrzeżeń bezpieczeństwa bez ustalenia ich przyczyny. Prawidłowa diagnostyka polega na odtworzeniu sekwencji przekierowań, porównaniu komunikatu błędu z logami oraz sprawdzeniu, który element przepływu odrzucił żądanie.

Naprawa problemu może wymagać korekty konfiguracji aplikacji, odświeżenia certyfikatu, poprawienia adresu callback, przywrócenia właściwego czasu systemowego albo naprawy lokalnej sesji przeglądarki. Jeżeli usterka dotyczy samego laptopa lub komputera PC, a nie centralnej konfiguracji tożsamości, można dodatkowo sprawdzić system, przeglądarkę, połączenie sieciowe i działanie wymaganych składników oprogramowania. W Warszawie diagnostyka i naprawa sprzętu komputerowego powinny być prowadzone na podstawie objawów oraz wyników testów, z rozdzieleniem problemu urządzenia od błędu usługi SSO.