SSO avviato da IdP vs SSO avviato da SP#

Terminologia#

• Identity Provider (IdP): Il servizio che memorizza e autentica le identità degli utenti.
• Service Provider (SP): Un sito web o servizio che fornisce servizi agli utenti.
• Single Sign-On (SSO): Un servizio di sessione e autenticazione degli utenti che permette a un utente di utilizzare un insieme di credenziali di accesso (ad esempio, nome e password) per accedere a più applicazioni.
• SAML: Security Assertion Markup Language è uno standard aperto per lo scambio di dati di autenticazione e autorizzazione tra le parti, in particolare, tra un provider di identità e un provider di servizi. È un protocollo comunemente usato per l'SSO. Una volta che un utente è autenticato con successo dall'IdP, l'IdP invia un'asserzione SAML allo SP, che lo SP convalida e concede l'accesso all'utente.
• OIDC: OpenID Connect è un protocollo più moderno e sicuro per l'SSO. È costruito su OAuth 2.0 e fornisce un modo per verificare l'identità dell'utente basato sull'autenticazione eseguita dall'IdP. Una volta che un utente è autenticato con successo dall'IdP, l'IdP invia un token in formato JWT allo SP, che lo SP convalida e concede l'accesso all'utente.

SSO avviato da SP#

Come suggerisce il nome, il SSO avviato da SP è avviato dal provider di servizi. L'utente inizia il processo di autenticazione accedendo a una risorsa sul sito web dello SP. Lo SP quindi reindirizza l'utente all'IdP per l'autenticazione. Una volta che l'utente è autenticato, l'IdP genera un token (OIDC) o un'asserzione SAML (SAML) e lo invia allo SP. Lo SP convalida il token o l'asserzione e concede l'accesso all'utente.

1. L'utente visita il sito web dello SP e cerca di accedere a una risorsa.
2. L'utente fa clic sul pulsante di accesso del provider SSO (ad esempio, Google, Azure AD, Okta, ecc.).
3. Lo SP reindirizza l'utente all'IdP per l'autenticazione.
4. L'utente accede all'IdP.
5. L'IdP invia un token o un'asserzione allo SP.
6. Lo SP convalida il token o l'asserzione e concede l'accesso all'utente.

SSO avviato da IdP#

A differenza dell'SSO avviato da SP, l'SSO avviato da IdP è avviato dal provider di identità. L'utente inizia il processo di autenticazione dal sito web dell'IdP. Normalmente, l'utente troverà un elenco di applicazioni SP supportate nel portale dell'IdP. L'utente clicca sull'applicazione SP e viene reindirizzato al sito web dello SP con un'identità pre-autenticata.

1. L'utente accede all'IdP.
2. L'utente visita il portale dell'IdP e seleziona un'applicazione SP.
3. L'IdP convalida la sessione corrente dell'utente e lo reindirizza allo SP con un'identità SSO pre-autenticata.
4. Lo SP convalida l'identità SSO e concede l'accesso all'utente.

Idp-initiated SSO vs SP-initiated SSO#

Vantaggi del SSO avviato da IdP rispetto a quello avviato da SP#

Il SSO avviato da IdP è più adottato dalle grandi imprese e organizzazioni che si affidano a varie app o servizi di terze parti come Workday, Salesforce, ecc. Fornisce un modo centralizzato per gestire l'accesso degli utenti a più applicazioni e applicare le autenticazioni SSO. Attivando il SSO avviato da IdP, i dipendenti possono accedere direttamente alle applicazioni connesse dal portale dell'IdP senza dover visitare il sito web di ciascuna applicazione. Riducendo i tempi di onboarding e migliorando l'esperienza utente.

Rischi del SSO avviato da IdP rispetto a quello avviato da SP#

Il SSO avviato da IdP comporta più rischi rispetto al SSO avviato da SP.

1. Mancanza del contesto di autenticazione: Tutte le richieste di autenticazione avviate dall'IdP sono non sollecitate. Pertanto, l'SP ha avviato il processo di autenticazione, potenzialmente aprendo la porta ad accessi non autorizzati. Esiste il rischio che la sessione dell'utente possa essere dirottata. Un attore malintenzionato potrebbe avviare il processo di accesso per un utente legittimo senza la loro conoscenza o il loro consenso.

2. Fissazione della sessione: Poiché l'SP non avvia il processo di autenticazione, la sessione dell'utente potrebbe essere fissata alla sessione dell'IdP. Questo potrebbe portare ad attacchi di fissazione della sessione in cui un attaccante potrebbe fissare la sessione dell'utente alla sessione dell'IdP e ottenere accesso non autorizzato all'account dell'utente.

3. Attacchi di phishing: Il SSO avviato da IdP potrebbe essere vulnerabile agli attacchi di phishing. Un attore malintenzionato potrebbe indurre l'utente a visitare un falso portale dell'IdP e rubare le credenziali dell'utente. Una volta che l'utente accede, l'attaccante potrebbe reindirizzare l'utente allo SP con un'identità pre-autenticata.

4. Nessuna garanzia sulla convalida della richiesta: In un SSO avviato da SP, normalmente lo SP includerà le informazioni di sicurezza necessarie nella richiesta all'IdP per mantenere l'integrità della richiesta. Una volta che lo SP riceve la risposta di autenticazione, convaliderà queste informazioni per prevenire eventuali attacchi CSRF. Ad esempio, il parametro state in OIDC e RelayState in SAML. Tuttavia, nell'SSO avviato da IdP, lo SP non avvia il processo di autenticazione, quindi lo SP non ha alcuna garanzia sulla convalida della richiesta.

Limitazioni del SSO avviato da IdP rispetto a quello avviato da SP#

Il SSO avviato da IdP non è supportato da OIDC a causa delle vulnerabilità sopra menzionate. OIDC richiede che l'SP avvii il processo di autenticazione per garantire l'integrità della richiesta. Anche nei casi in cui gli utenti iniziano il processo di autenticazione da una terza parte che non è lo SP, l'utente dovrebbe essere prima diretto allo SP per avviare il processo di autenticazione.

Ma in SAML, l'SSO avviato da IdP è possibile. L'IdP può generare un'asserzione SAML senza che lo SP avvii il processo di autenticazione. In un SAML SSO avviato da IdP, un'asserzione SAML senza un corretto RequestID e RelayState potrebbe essere inviata direttamente all'URL ACS dello SP. Lo SP dovrebbe essere in grado di gestire questo tipo di asserzione e concedere l'accesso all'utente. (Nota: Senza il RequestID e il RelayState, lo SP non ha alcuna garanzia sull'integrità della richiesta).

Conclusione#

Anche se il SSO avviato da IdP fornisce un modo centralizzato per gestire l'accesso degli utenti a più applicazioni, comporta più rischi rispetto al SSO avviato da SP. Il SSO avviato da SP è più sicuro e offre maggiore garanzia sull'integrità della richiesta di autenticazione. Si consiglia di utilizzare il SSO avviato da SP sia per il SSO basato su OIDC che su SAML.