IdP

Definicja IdP

IdP (Identity Provider, dostawca tożsamości) to usługa, która uwierzytelnia użytkownika i przekazuje aplikacji potwierdzenie jego tożsamości w postaci tokenu SAML lub OpenID Connect. Aplikacja, zwana service providerem (SP), nie musi wtedy przechowywać haseł i ufa wystawcy tokenu zamiast sprawdzać poświadczenia samodzielnie. Na tym opiera się logowanie jednokrotne (SSO).

IdP opisuje rolę w protokole, a nie produkt, więc może ją pełnić usługa w chmurze, serwer utrzymywany we własnej infrastrukturze albo moduł większej platformy. W SAML 2.0 nazywa się ją identity provider, a w OpenID Connect ten sam podmiot to OpenID Provider (OP), aplikacja zaś to Relying Party (RP). Nazwy są różne, ale układ ten sam: jedna strona uwierzytelnia, druga polega na jej wyniku.

Jedna organizacja bywa jednocześnie IdP dla własnych aplikacji i SP wobec zewnętrznego IdP partnera, bo rolę wyznacza kierunek zaufania. Podobnie brzmiący skrót IDPS oznacza zwykle systemy wykrywania i zapobiegania włamaniom, czyli inną klasę narzędzi, opisaną w hasłach IDS i IPS.

Jak to działa

Typowy przebieg to logowanie inicjowane przez aplikację (SP-initiated), w którym użytkownik zaczyna od aplikacji, a dopiero ona kieruje go do dostawcy.

1. Użytkownik otwiera aplikację, która nie ma jego sesji i nie wie, kim jest.
2. Aplikacja przekierowuje przeglądarkę do IdP z żądaniem uwierzytelnienia.
3. IdP sprawdza hasło i drugi składnik, o ile polityka go wymaga, a jeżeli użytkownik ma już ważną sesję u dostawcy, pomija ponowne logowanie. Na tym polega SSO.
4. IdP zwraca token: asercję SAML albo ID Token OpenID Connect.
5. Aplikacja weryfikuje podpis, sprawdza, czy token jest przeznaczony dla niej, i zakłada własną sesję.

W SAML 2.0 token to asercja, czyli dokument XML z oświadczeniem o użytkowniku, o sposobie jego uwierzytelnienia i o jego atrybutach. W OpenID Connect to ID Token, czyli JSON Web Token (JWT) z danymi o uwierzytelnieniu użytkownika.

Zaufanie powstaje przed pierwszym logowaniem. W SAML IdP i SP wymieniają metadane, czyli adresy punktów końcowych i klucze do weryfikacji podpisów, a w OpenID Connect aplikację rejestruje się u dostawcy i podpis tokenu weryfikuje jego kluczem. Bez tej wymiany aplikacja nie ma podstaw, by uznać cudzy token.

Wariant inicjowany przez dostawcę (IdP-initiated) działa odwrotnie: użytkownik jest już zalogowany u IdP, na przykład w portalu z listą aplikacji, klika jedną z nich, a IdP wysyła asercję do aplikacji bez wcześniejszego żądania z jej strony. Ten wariant opisuje standard SAML, ale nie każde wdrożenie go dopuszcza.

Po zalogowaniu aplikacja prowadzi własną sesję, niezależną od sesji u dostawcy, a czas trwania obu ustawia konfiguracja po każdej stronie. Zakończenie sesji u IdP nie musi więc kończyć sesji w aplikacjach, bo zależy to od obsługi wylogowania po obu stronach.

Struktura i klasyfikacja

IdP można klasyfikować na dwóch niezależnych osiach: według protokołu, którym przekazuje tożsamość, i według tego, kto go utrzymuje.

Protokoły: SAML, OpenID Connect i OAuth 2.0

SAML 2.0 to oparty na XML standard organizacji OASIS z 2005 roku, a OpenID Connect (Core 1.0 z 2014 roku) to warstwa tożsamości zbudowana na OAuth 2.0. OAuth 2.0 (RFC 6749, 2012) to rama autoryzacji, która sama nie opisuje, jak uwierzytelnia się użytkownika.

Model wdrożenia

Drugi podział dotyczy tego, kto utrzymuje IdP, a produkty w tabeli są tylko przykładami.

Wdrożenia hybrydowe łączą oba modele, na przykład katalog lokalny z IdP w chmurze.

Federacja tożsamości to układ zaufania między IdP i aplikacjami z różnych organizacji: użytkownik loguje się u IdP swojej firmy, a aplikacja partnera honoruje wynik i nie musi przechowywać jego hasła.

W szerszym kontekście

Najszerszy poziom to zarządzanie kontami, rolami i uprawnieniami wraz z cyklem życia pracownika, w skrócie IAM. IdP jest komponentem tej warstwy: korzysta z jej kont i atrybutów, a w zamian uwierzytelnia i wystawia tokeny. W produktach funkcje obu poziomów często się zlewają, ale pojęcia pozostają osobne. SSO to efekt widoczny dla użytkownika: jedno logowanie, wiele aplikacji.

• IdP to miejsce, w którym drugi składnik (MFA) da się wymusić dla wszystkich podpiętych aplikacji naraz. Metody bez hasła, takie jak passkey, działają, o ile dostawca je obsługuje.
• Zero Trust traktuje tożsamość jako jeden z sygnałów decyzji o dostępie. IdP dostarcza ten sygnał, ale model wymaga też oceny kontekstu i uprawnień przy każdym dostępie.
• CIAM to odmiana dla klientów i partnerów zewnętrznych. IdP pełni tam tę samą rolę.
• PAM chroni konta uprzywilejowane. IdP go nie zastępuje: uwierzytelnienie administratora to co innego niż kontrola tego, co robi po zalogowaniu.
• IdP widzi każde logowanie do podpiętych aplikacji, więc jest naturalnym źródłem zapisów: kto, kiedy, do której aplikacji i z jakim wynikiem. Zwykle trafiają do SIEM, gdzie służą do wykrywania anomalii i do audytu.

Zastosowanie w praktyce

• Logowanie do aplikacji SaaS. Dostęp do usług zewnętrznych opiera się na jednym koncie firmowym, więc pracownik nie zakłada osobnego hasła do każdej aplikacji.
• Drugi składnik w jednym miejscu. Polityka MFA ustawiona raz u IdP obejmuje wszystkie aplikacje, które przez niego się logują, a konta lokalne w aplikacji, jeśli nadal istnieją, tej polityki nie widzą.
• Odebranie dostępu przy odejściu pracownika. Dezaktywacja konta u IdP odcina nowe logowania do wszystkich podpiętych aplikacji naraz, ale nie kończy automatycznie aktywnych sesji, wydanych tokenów ani kont i kluczy API poza IdP, bo ich wygaśnięcie zależy od konfiguracji każdej aplikacji.
• Federacja z partnerami. Pracownicy partnera korzystają z aplikacji organizacji, logując się u własnego dostawcy.
• Własne aplikacje. Zespół buduje logowanie na standardowym protokole zamiast własnej bazy haseł, a skoro mniej kodu przechowuje poświadczenia, mniej kodu trzeba chronić.

Najczęstsze nieporozumienia

"IdP to to samo co IAM" - fałsz. IdP uwierzytelnia i wystawia tokeny, a konta, role, uprawnienia i ich cykl życia to szerszy obszar IAM. Produkty często łączą oba w jednym panelu, ale rozróżnienie zostaje.

"OAuth 2.0 służy do logowania" - fałsz. OAuth 2.0 opisuje delegowanie dostępu, a sposób uwierzytelnienia użytkownika zostawia poza zakresem. Logowanie standaryzuje OpenID Connect, który dodaje do OAuth 2.0 ID Token. Access token służy do wywołań API, a nie do ustalania, kim jest użytkownik.

"SSO bez MFA jest bezpieczne" - fałsz. SSO zmniejsza liczbę haseł, ale jedno z nich otwiera wtedy wszystkie podpięte aplikacje, więc siła logowania do IdP wyznacza siłę ochrony całego zestawu. Drugi składnik, najlepiej odporny na phishing, powinien być tam regułą.

"IdP to pojedynczy punkt awarii, więc lepiej go nie wdrażać" - ryzyko jest realne, ale wniosek z niego nie wynika. Alternatywą są osobne hasła w każdej aplikacji, z własnymi słabościami: powtórzeniami, brakiem jednej polityki i ręcznym odbieraniem dostępu. Centralny IdP trzeba za to zaprojektować na dwa różne scenariusze.

Przy niedostępności typowe środki to redundancja IdP, udokumentowana procedura awaryjna i konta typu break-glass dla administratorów, przechowywane poza IdP. Przejęcie jest groźniejsze, bo napastnik, który zdobędzie klucz podpisujący tokeny albo konto administratora dostawcy, może wystawiać tokeny dla dowolnego użytkownika. Dlatego administratorów IdP chroni najsilniejsze uwierzytelnienie, zmiany konfiguracji są ograniczone i rejestrowane, logowania monitorowane, a na wypadek przejęcia przygotowuje się plan wymiany kluczy i unieważniania sesji.

FAQ

Powiązane pojęcia