IdP-aloitettu SSO vs. SP-aloitettu SSO#

Termistö#

• Identity Provider (IdP): Palvelu, joka tallentaa ja todentaa käyttäjien identiteetit.
• Service Provider (SP): Verkkopalvelu tai palvelu, joka tarjoaa palveluita käyttäjille.
• Single Sign-On (SSO): Istunto- ja käyttäjäntodentamispalvelu, joka antaa käyttäjän käyttää yhtä kirjautumistunnusta (esim. nimi ja salasana) useiden sovellusten käyttämiseen.
• SAML: Security Assertion Markup Language on avoin standardi todennus- ja valtuutustietojen vaihtoon osapuolten välillä, erityisesti identiteetin tarjoajan ja palveluntarjoajan välillä. Se on yleisesti käytetty protokolla SSO:lle. Kun käyttäjä on onnistuneesti todentu IdP:ssä, IdP lähettää SAML-asetuksen SP:lle, jonka SP validoi ja myöntää käyttäjälle pääsyn.
• OIDC: OpenID Connect on nykyaikaisempi ja turvallisempi protokolla SSO:lle. Se on rakennettu OAuth 2.0:n päälle ja tarjoaa tavan varmistaa käyttäjän identiteetin IdP:n suorittaman todentamisen perusteella. Kun käyttäjä on onnistuneesti todennettu IdP:ssä, IdP lähettää JWT-muotoisen tunnuksen SP:lle, jonka SP validoi ja myöntää käyttäjälle pääsyn.

SP-aloitettu SSO#

Kuten nimestäkin käy ilmi, SP-aloitettu SSO käynnistetään palveluntarjoajan toimesta. Käyttäjä aloittaa todennusprosessin käyttämällä resurssia SP:n verkkosivustolla. SP sitten ohjaa käyttäjän IdP:lle todennusta varten. Kun käyttäjä on todennettu, IdP luo tunnuksen (OIDC) tai SAML-asetuksen (SAML) ja lähettää sen takaisin SP:lle. SP validoi tunnuksen tai asetuksen ja myöntää käyttäjälle pääsyn.

1. Käyttäjä vierailee SP:n verkkosivustolla ja yrittää käyttää resurssia.
2. Käyttäjä klikkaa SSO-tarjoajan kirjautumispainiketta (esim. Google, Azure AD, Okta jne.).
3. SP ohjaa käyttäjän IdP:lle todennusta varten.
4. Käyttäjä kirjautuu IdP:lle.
5. IdP lähettää tunnuksen tai asetuksen takaisin SP:lle.
6. SP validoi tunnuksen tai asetuksen ja myöntää käyttäjälle pääsyn.

IdP-aloitettu SSO#

Toisin kuin SP-aloitettu SSO, IdP-aloitettu SSO käynnistetään identiteetin tarjoajan toimesta. Käyttäjä aloittaa todennusprosessin IdP:n verkkosivustolta. Normaalisti käyttäjä löytää luettelon tuetuista SP-sovelluksista IdP:n portaalista. Käyttäjä klikkaa SP-sovellusta ja ohjautuu SP:n verkkosivustolle esiautentikoidulla identiteetillä.

1. Käyttäjä kirjautuu IdP:lle.
2. Käyttäjä vierailee IdP:n portaalissa ja valitsee SP-sovelluksen.
3. IdP validoi käyttäjän nykyisen istunnon ja ohjaa käyttäjän SP:lle esiautentikoidulla SSO-identiteetillä.
4. SP validoi SSO-identiteetin ja myöntää käyttäjälle pääsyn.

Idp-aloitettu SSO vs. SP-aloitettu SSO#

IdP-aloitetun SSO:n edut verrattuna SP-aloitettuun SSO:hon#

IdP-aloitettu SSO on enemmän suuressa yrityksissä ja organisaatioissa käytetty, jotka luottavat moniin kolmannen osapuolen sovelluksiin tai palveluihin, kuten Workday, Salesforce jne. Se tarjoaa keskitetyn tavan hallita käyttäjien pääsyä useisiin sovelluksiin ja valvoa SSO-todennuksia. Ottaessaan käyttöön IdP-aloitetun SSO:n, työntekijät voivat suoraan käyttää yhdistettyjä sovelluksia IdP:n portailta ilman, että heidän tarvitsee vierailla kunkin sovelluksen verkkosivustolla. Tämä vähentää sisäänkäyntiaikaa ja parantaa käyttökokemusta.

IdP-aloitetun SSO:n riskit verrattuna SP-aloitettuun SSO:hon#

IdP-aloitettu SSO kantaa enemmän riskiä verrattuna SP-aloitettuun SSO:hon.

1. Todennuskontekstin puute: Kaikki IdP:ltä aloitetut todennuspyynnöt ovat pyyteettömiä. Näin SP aloittaa todennusprosessin, mikä saattaa avata oven luvattomalle pääsylle. On olemassa riski, että käyttäjän istunto voitaisiin kaapata. Haitallinen toimija voisi aloittaa kirjautumisprosessin lailliselle käyttäjälle ilman hänen tietämystään tai suostumustaan.

2. Istunnon kiinnittyminen: Koska SP ei aloita todennusprosessia, käyttäjän istunto voisi kiinnittyä IdP:n istuntoon. Tämä voisi johtaa istunnon kiinnittymishyökkäyksiin, joissa hyökkääjä voisi kiinnittää käyttäjän istunnon IdP:n istuntoon ja saada luvatonta pääsyä käyttäjän tilille.

3. Phishing-hyökkäykset: IdP-aloitettu SSO voisi olla altis phishing-hyökkäyksille. Haitallinen toimija voisi huijata käyttäjää vierailemaan väärennetyn IdP-portaalin sivustolla ja varastaa käyttäjän tunnukset. Kun käyttäjä kirjautuu sisään, hyökkääjä voisi ohjata käyttäjän SP:lle esiautentikoidulla identiteetillä.

4. Ei varmistusta pyynnön validoinnissa: SP-aloitetussa SSO:ssa, normaalisti SP sisältää tarvittavat turvallisuustiedot pyynnössä IdP:lle, jotta pyynnön koskemattomuus säilyisi. Kun SP vastaanottaa todennusvastauksen, se validoi nämä tiedot estääkseen CSRF-hyökkäykset. Esim. state-parametri OIDC:ssä ja RelayState SAML:ssä. Kuitenkin IdP-aloitetussa SSO:ssa, SP ei aloita todennusprosessia, joten SP:llä ei ole varmuutta pyynnön validoinnista.

IdP-aloitetun SSO:n rajoitukset verrattuna SP-aloitettuun SSO:hon#

OIDC ei tue IdP-aloitettua SSO:ta yllä mainittujen haavoittuvuuksien vuoksi. OIDC vaatii SP:n aloittamaan todennusprosessin varmistaakseen pyynnön koskemattomuuden. Vaikka käyttäjät aloittaisivat todennusprosessin kolmannelta osapuolelta, joka ei ole SP, käyttäjän tulisi ensin ohjautua SP:lle aloittamaan todennusprosessi.

Mutta SAML:ssa IdP-aloitettu SSO on mahdollista. IdP voi luoda SAML-asetuksen ilman, että SP aloittaa todennusprosessin. SAML IdP-aloitetussa SSO:ssa SAML-asetus voidaan lähettää suoraan SP:n ACS URL-osoitteeseen ilman oikeaa RequestID:tä ja RelayState:tä. SP:n tulisi pystyä käsittelemään tällainen asetus ja myöntämään käyttäjälle pääsyn. (Huomaa: Ilman RequestID:tä ja RelayState:tä SP:llä ei ole varmuutta pyynnön koskemattomuudesta).

Johtopäätös#

Vaikka IdP-aloitettu SSO tarjoaa keskitetyn tavan hallita käyttäjien pääsyä useisiin sovelluksiin, se kantaa enemmän riskejä verrattuna SP-aloitettuun SSO:hon. SP-aloitettu SSO on turvallisempi ja tarjoaa enemmän varmuutta todennuspyynnön koskemattomuudesta. On suositeltavaa käyttää SP-aloitettua SSO:ta sekä OIDC:ssä että SAML:ssä.