federacja kont

Federacja kont to mechanizm łączący tożsamości użytkownika w różnych, niezależnych systemach w jedną, wspólną sesję.

Federacja kont a wspólna tożsamość użytkownika

Federacja kont to sposób powiązania tożsamości użytkownika utrzymywanych w odrębnych systemach, domenach lub organizacjach. Użytkownik może uwierzytelnić się w jednym systemie tożsamości, a następnie uzyskać dostęp do innych aplikacji bez tworzenia w każdej z nich osobnego hasła i niezależnego procesu logowania. System, który potwierdza tożsamość, nazywa się dostawcą tożsamości, czyli IdP (Identity Provider). Aplikacja korzystająca z tego potwierdzenia jest dostawcą usługi, czyli SP (Service Provider), albo klientem zależnie od użytego protokołu.

Federacja nie oznacza automatycznego scalania baz użytkowników. Każdy system może nadal przechowywać własne dane, role i uprawnienia. Wspólna jest przede wszystkim informacja o tożsamości oraz sposób jej potwierdzania. Po udanym logowaniu IdP przekazuje aplikacji komunikat zawierający określone atrybuty, na przykład identyfikator użytkownika, adres poczty elektronicznej lub przynależność do grup. Aplikacja sama decyduje, jakie uprawnienia nadać na podstawie otrzymanych danych.

Role IdP, aplikacji i zaufania technicznego

Przepływ federacyjnego logowania rozpoczyna się zwykle od przekierowania użytkownika z aplikacji do IdP. IdP przeprowadza uwierzytelnienie, korzystając z własnego mechanizmu, takiego jak hasło, klucz bezpieczeństwa albo dodatkowy składnik uwierzytelniania. Następnie przekazuje aplikacji podpisane potwierdzenie. Aplikacja nie powinna przyjmować dowolnego komunikatu tylko dlatego, że zawiera poprawnie wyglądający identyfikator. Musi zweryfikować podpis, wystawcę komunikatu, odbiorcę, czas ważności oraz zgodność z wcześniej skonfigurowanymi parametrami.

W federacji kluczowe jest zaufanie konfiguracyjne pomiędzy stronami. Obejmuje ono między innymi identyfikatory IdP i aplikacji, adresy przekierowań, certyfikaty lub klucze używane do weryfikacji podpisów oraz zakres przekazywanych atrybutów. W protokole SAML aplikacja otrzymuje zazwyczaj asercję SAML, czyli podpisane stwierdzenie dotyczące uwierzytelnienia i atrybutów użytkownika. W rozwiązaniach opartych na OpenID Connect aplikacja otrzymuje token ID w formacie JWT, który opisuje uwierzytelnioną tożsamość. OAuth 2.0 może występować obok OpenID Connect, ale sam OAuth 2.0 służy przede wszystkim do delegowania dostępu do zasobów i nie jest protokołem potwierdzania tożsamości użytkownika.

SAML i OpenID Connect w przepływie logowania

SAML jest protokołem często stosowanym w integracjach między dostawcą tożsamości a aplikacją internetową. W typowym scenariuszu aplikacja wysyła żądanie uwierzytelnienia, a IdP zwraca odpowiedź z asercją. Odpowiedź może zostać dostarczona do określonego adresu ACS (Assertion Consumer Service). Weryfikacja obejmuje między innymi elementy Issuer, Audience, Subject oraz warunki czasowe. Pole Audience ogranicza zastosowanie asercji do wskazanej aplikacji, a warunki czasowe zapobiegają użyciu komunikatu po upływie jego ważności.

OpenID Connect jest warstwą tożsamości zbudowaną nad OAuth 2.0. Klient kieruje użytkownika do serwera autoryzacji, a po pomyślnym uwierzytelnieniu otrzymuje między innymi kod autoryzacyjny. Po stronie serwera kod jest wymieniany na tokeny. Token ID zawiera dane potrzebne do potwierdzenia tożsamości, natomiast token dostępu służy do wywoływania chronionego zasobu w zakresie przyznanych uprawnień. Parametr state pomaga chronić przepływ przed podmianą odpowiedzi, a nonce wiąże odpowiedź z konkretnym żądaniem logowania i ogranicza ryzyko ponownego wykorzystania tokenu ID.

Typowe przyczyny nieudanego logowania federacyjnego

Problemy z federacją kont często wynikają z rozbieżności konfiguracyjnych, a nie z samego hasła użytkownika. Częstym przypadkiem jest niezgodny adres przekierowania, identyfikator klienta, Entity ID albo adres ACS. Logowanie może także zakończyć się błędem, gdy certyfikat podpisujący wygasł, aplikacja korzysta ze starego klucza albo nie ufa aktualnemu certyfikatowi IdP. Warto sprawdzić również, czy komunikat pochodzi od oczekiwanego wystawcy i czy jego odbiorca odpowiada konkretnej aplikacji.

Znaczenie ma synchronizacja czasu pomiędzy urządzeniami uczestniczącymi w przepływie. Zbyt duża różnica zegarów może spowodować odrzucenie komunikatu jako jeszcze nieważnego albo już wygasłego. Diagnostyka powinna obejmować dzienniki IdP i aplikacji, pełny adres powrotu po przekierowaniu, identyfikator żądania oraz wynik walidacji podpisu i tokenu. Należy także sprawdzić mapowanie atrybutów: użytkownik może zostać poprawnie uwierzytelniony, ale nie otrzymać dostępu, jeśli aplikacja nie rozpoznaje przekazanego identyfikatora, grupy lub roli. Przy analizie laptopa lub komputera PC można dodatkowo zweryfikować przeglądarkę, zapisane sesje, rozszerzenia blokujące przekierowania oraz poprawność daty i godziny systemowej.