brak integracji z systemem SSO

Brak integracji z systemem SSO to alternatywne, powtórzone określenie tej samej usterki dotyczącej jednokrotnego logowania.

Na czym polega brak integracji z systemem SSO

Brak integracji z systemem SSO oznacza, że aplikacja lub usługa nie korzysta z mechanizmu jednokrotnego logowania (Single Sign-On). Użytkownik nie może wtedy uwierzytelnić się w jednym, centralnym systemie tożsamości i automatycznie uzyskać dostępu do kolejnego programu. Zamiast tego aplikacja może wymagać utworzenia własnego konta, podania osobnego loginu i hasła albo użycia lokalnego mechanizmu logowania. Samo istnienie kont użytkowników w katalogu firmowym nie oznacza jeszcze, że aplikacja jest z nim zintegrowana.

Integracja SSO wymaga uzgodnienia sposobu wymiany informacji między aplikacją a dostawcą tożsamości, nazywanym IdP (Identity Provider). W zależności od rozwiązania stosuje się między innymi protokół SAML 2.0 albo OpenID Connect działający na bazie OAuth 2.0. Dostawca tożsamości potwierdza, kim jest użytkownik, a aplikacja będąca usługodawcą, czyli SP (Service Provider) lub klientem OpenID Connect, otrzymuje potwierdzenie uwierzytelnienia i podstawowe dane potrzebne do utworzenia sesji.

Objawy widoczne podczas logowania

Typowym objawem jest pojawienie się osobnego formularza logowania mimo wcześniejszego zalogowania do firmowego portalu, systemu operacyjnego albo innej aplikacji korzystającej z centralnego katalogu. Użytkownik może być proszony o ponowne podanie hasła, a zmiana hasła w katalogu tożsamości nie musi wpływać na dane zapisane w tej aplikacji. Często występuje także konieczność ręcznego zakładania kont, nadawania uprawnień niezależnie od grup katalogowych oraz usuwania kont w kilku miejscach.

Brak SSO może być mylony z błędem konfiguracji pojedynczego konta. Jeżeli przekierowanie do dostawcy tożsamości nie następuje, przyczyną może być rzeczywisty brak integracji, ale również nieaktywny moduł logowania, nieprawidłowy adres logowania, wyłączony przycisk dostawcy tożsamości albo użycie niewłaściwego środowiska aplikacji. W przypadku SAML trzeba dodatkowo rozróżnić brak konfiguracji od błędów takich jak niezgodny adres ACS, czyli endpoint odbierający odpowiedź uwierzytelniającą, nieprawidłowy identyfikator encji lub odrzucony podpis komunikatu. W OpenID Connect podobną rolę diagnostyczną mają między innymi adres przekierowania, identyfikator klienta i poprawność wartości parametru issuer.

Skutki rozdzielenia kont i uwierzytelniania

Gdy aplikacja nie jest połączona z SSO, zarządzanie cyklem życia kont odbywa się oddzielnie. Utworzenie użytkownika w katalogu centralnym nie musi utworzyć konta w aplikacji, a odebranie dostępu w jednym systemie nie musi natychmiast odebrać dostępu w drugim. Administratorzy muszą pilnować zgodności nazw użytkowników, członkostwa w grupach oraz ról zapisanych lokalnie. Jeżeli aplikacja przechowuje własne hasła, pojawia się również drugi niezależny proces resetowania i blokowania poświadczeń.

Konsekwencje są widoczne także w diagnostyce. Należy ustalić, czy użytkownik korzysta z konta lokalnego, czy aplikacja powinna przekierować go do konkretnego IdP. Następnie sprawdza się konfigurację dostawcy tożsamości, mapowanie atrybutów, przypisanie aplikacji do użytkownika lub grupy oraz reguły nadawania ról. W SAML analizuje się metadane IdP i SP, certyfikat używany do podpisywania oraz czasy ważności odpowiedzi i asercji. W OpenID Connect weryfikuje się między innymi token ID, zakresy żądanych informacji, zgodność adresu redirect URI i możliwość pobrania kluczy publicznych służących do sprawdzenia podpisu tokenu. Sam komunikat „brak integracji” nie wskazuje jeszcze, który z tych elementów jest nieobecny lub niepoprawny.

Rozróżnienie braku funkcji od błędu konfiguracji

Przed zgłoszeniem usterki warto sprawdzić dokumentację konkretnej aplikacji i jej wersję, ponieważ obsługa SSO może być dostępna tylko w określonym wariancie licencyjnym, module albo planie administracyjnym. Istotne jest również ustalenie, czy badane środowisko jest produkcyjne, testowe czy lokalne. Aplikacja może mieć skonfigurowane SSO w jednym środowisku, podczas gdy drugi adres korzysta wyłącznie z kont lokalnych. Należy zebrać dokładny adres logowania, czas wystąpienia problemu, nazwę używanego dostawcy tożsamości oraz treść komunikatu, bez ujawniania haseł i tokenów sesyjnych.

Diagnostyka techniczna powinna objąć logi aplikacji, logi dostawcy tożsamości i historię przekierowań w przeglądarce. Jeżeli nie występuje żadne przekierowanie do IdP, prawdopodobny jest brak włączenia funkcji lub błędny wybór trybu logowania. Jeżeli przekierowanie występuje, ale powrót do aplikacji kończy się błędem, trzeba sprawdzić parametry protokołu, certyfikaty, adresy callback oraz synchronizację czasu. Po naprawie należy przetestować pełny cykl: rozpoczęcie logowania, uwierzytelnienie, powrót do aplikacji, przypisanie właściwego użytkownika i roli oraz zakończenie sesji. Osobno trzeba potwierdzić zachowanie dla nowego użytkownika, użytkownika bez przypisanej grupy i konta, któremu odebrano dostęp.