IdP-initiowane SSO vs SP-initiowane SSO#

Terminologia#

• Dostawca Tożsamości (IdP): Usługa, która przechowuje i uwierzytelnia tożsamości użytkowników.
• Dostawca Usług (SP): Strona internetowa lub usługa, która świadczy usługi użytkownikom.
• Jednokrotne Logowanie (SSO): Usługa sesji i uwierzytelniania użytkownika, która pozwala użytkownikowi używać jednego zestawu danych logowania (np. nazwy i hasła) do uzyskiwania dostępu do wielu aplikacji.
• SAML: Security Assertion Markup Language to otwarty standard do wymiany danych uwierzytelniających i autoryzacyjnych między stronami, w szczególności między dostawcą tożsamości a dostawcą usług. Jest to powszechnie używany protokół dla SSO. Gdy użytkownik zostanie pomyślnie uwierzytelniony przez IdP, IdP wysyła asercję SAML do SP, którą SP weryfikuje i przyznaje dostęp użytkownikowi.
• OIDC: OpenID Connect to nowoczesny i bezpieczny protokół dla SSO. Jest zbudowany na bazie OAuth 2.0 i zapewnia sposób na weryfikację tożsamości użytkownika w oparciu o uwierzytelnienie przeprowadzone przez IdP. Gdy użytkownik zostanie pomyślnie uwierzytelniony przez IdP, IdP wysyła token w formacie JWT do SP, który SP weryfikuje i przyznaje dostęp użytkownikowi.

SP-initiowane SSO#

Jak sama nazwa wskazuje, SP-initiowane SSO jest inicjowane przez dostawcę usług. Użytkownik rozpoczyna proces uwierzytelniania, uzyskując dostęp do zasobu na stronie SP. SP następnie przekierowuje użytkownika do IdP w celu uwierzytelnienia. Po uwierzytelnieniu użytkownika, IdP generuje token (OIDC) lub asercję SAML (SAML) i wysyła go z powrotem do SP. SP weryfikuje token lub asercję i przyznaje użytkownikowi dostęp.

1. Użytkownik odwiedza stronę internetową SP i próbuje uzyskać dostęp do zasobu.
2. Użytkownik klika przycisk logowania dostawcy SSO (np. Google, Azure AD, Okta itp.).
3. SP przekierowuje użytkownika do IdP w celu uwierzytelnienia.
4. Użytkownik loguje się do IdP.
5. IdP przesyła token lub asercję z powrotem do SP.
6. SP weryfikuje token lub asercję i przyznaje użytkownikowi dostęp.

IdP-initiowane SSO#

W przeciwieństwie do SP-initiowanego SSO, IdP-initiowane SSO jest inicjowane przez dostawcę tożsamości. Użytkownik rozpoczyna proces uwierzytelniania z witryny IdP. Zwykle użytkownik znajdzie listę obsługiwanych aplikacji SP na portalu IdP. Użytkownik klika aplikację SP i jest przekierowywany na stronę internetową SP z wstępnie uwierzytelnioną tożsamością.

1. Użytkownik loguje się do IdP.
2. Użytkownik odwiedza portal IdP i wybiera aplikację SP.
3. IdP weryfikuje bieżącą sesję użytkownika i przekierowuje użytkownika do SP z wstępnie uwierzytelnioną tożsamością SSO.
4. SP weryfikuje tożsamość SSO i przyznaje dostęp użytkownikowi.

Idp-initiowane SSO vs SP-initiowane SSO#

Zalety IdP-initiowanego SSO w porównaniu do SP-initiowanego SSO#

IdP-initiowane SSO jest bardziej przyjęte przez duże przedsiębiorstwa i organizacje, które polegają na różnych aplikacjach lub usługach firm trzecich, takich jak Workday, Salesforce itp. Zapewnia to centralny sposób zarządzania dostępem użytkowników do wielu aplikacji i egzekwowania uwierzytelnienia SSO. Dzięki włączeniu IdP-initiowanego SSO, pracownicy mogą bezpośrednio uzyskiwać dostęp do połączonych aplikacji z portalu IdP, bez konieczności odwiedzania strony internetowej każdej aplikacji, co skraca czas wdrożenia i poprawia wrażenia użytkownika.

Ryzyka IdP-initiowanego SSO w porównaniu do SP-initiowanego SSO#

IdP-initiowane SSO niesie większe ryzyko w porównaniu z SP-initiowanym SSO.

1. Brak kontekstu uwierzytelniania: Wszystkie żądania uwierzytelnienia zainicjowane przez IdP są niezamawiane. W ten sposób SP inicjuje proces uwierzytelniania, potencjalnie otwierając drzwi do nieautoryzowanego dostępu. Istnieje ryzyko, że sesja użytkownika może zostać przechwycona. Złośliwy aktor mógłby zainicjować proces logowania dla legalnego użytkownika bez jego wiedzy lub zgody.

2. Utrwalanie sesji: Ponieważ SP nie inicjuje procesu uwierzytelniania, sesja użytkownika może być związana z sesją IdP. Może to prowadzić do ataków utrwalających sesję, gdzie atakujący mógłby utrwalić sesję użytkownika z sesją IdP i uzyskać nieautoryzowany dostęp do konta użytkownika.

3. Ataki phishingowe: IdP-initiowane SSO może być podatne na ataki phishingowe. Złośliwy aktor mógłby oszukać użytkownika, zmuszając go do odwiedzenia fałszywego portalu IdP i kradzieży danych uwierzytelniających użytkownika. Gdy użytkownik się zaloguje, atakujący mógłby przekierować użytkownika na SP z wstępnie uwierzytelnioną tożsamością.

4. Brak pewności co do walidacji żądania: W SP-initiowanym SSO zwykle SP uwzględnia niezbędne informacje zabezpieczające w żądaniu do IdP, aby utrzymać integralność żądania. Gdy SP otrzyma odpowiedź na uwierzytelnienie, zweryfikuje te informacje, aby zapobiec atakom CSRF. Na przykład parametr state w OIDC i RelayState w SAML. Jednak w IdP-initiowanym SSO, SP nie inicjuje procesu uwierzytelniania, w związku z czym SP nie ma pewności co do walidacji żądania.

Ograniczenia IdP-initiowanego SSO w porównaniu do SP-initiowanego SSO#

IdP-initiowane SSO nie jest obsługiwane przez OIDC z powodu powyższych podatności. OIDC wymaga, aby SP inicjował proces uwierzytelniania, aby zapewnić integralność żądania. Nawet w przypadkach, gdy użytkownicy rozpoczynają proces uwierzytelniania od strony trzeciej, która nie jest SP, użytkownik powinien być najpierw skierowany do SP, aby zainicjować proces uwierzytelniania.

Ale w SAML, IdP-initiowane SSO jest możliwe. IdP może generować asercję SAML bez inicjowania procesu uwierzytelniania przez SP. W SAML IdP-initiowanym SSO, asercja SAML bez odpowiedniego RequestID i RelayState może być wysłana bezpośrednio na adres URL ACS SP. SP powinien być w stanie obsłużyć tego rodzaju asercję i przyznać dostęp użytkownikowi. (Uwaga: Bez RequestID i RelayState, SP nie ma pewności co do integralności żądania).

Wniosek#

Choć IdP-initiowane SSO zapewnia centralizowany sposób zarządzania dostępem użytkowników do wielu aplikacji, niesie ze sobą większe ryzyko w porównaniu do SP-initiowanego SSO. SP-initiowane SSO jest bardziej bezpieczne i zapewnia większą pewność co do integralności żądania uwierzytelniającego. Zaleca się używanie SP-initiowanego SSO zarówno dla OIDC, jak i SAML opartego SSO.