Il Single Sign-On (SSO) è una sessione centralizzata e un servizio di autenticazione utente in cui è possibile utilizzare un set di credenziali per accedere a più applicazioni. La sua bellezza sta nella sua semplicità; il servizio vi autentica su una piattaforma designata, consentendovi di utilizzare una pletora di servizi senza dover accedere e disconnettersi ogni volta.

Se implementato correttamente, SSO può essere ottimo per la produttività, il monitoraggio e la gestione IT e il controllo della sicurezza. Con un token di sicurezza (una coppia di nome utente e password), un amministratore può abilitare e disabilitare l’accesso degli utenti a più sistemi, piattaforme, app e altre risorse. SSO riduce anche il rischio di password perse, dimenticate o deboli.

Come funziona il Single Sign-On?

Esistono alcuni standard diversi che possono essere utilizzati per implementare SSO, ma tutti seguono lo stesso modello di base, consentendo alle applicazioni di trasferire le responsabilità per l’autenticazione degli utenti a qualche altra applicazione o servizio.

Nel gergo SSO, un’applicazione o un sito Web a cui un utente potrebbe voler accedere (da un client di posta elettronica a un sito Web di una banca a una condivisione di rete) è un fornitore di servizi. La maggior parte delle piattaforme come queste includono le proprie funzionalità per l’autenticazione degli utenti. Con SSO, tuttavia, tale responsabilità viene assegnata a un provider di identità, in genere, la piattaforma SSO stessa.

Quando l’utente tenta di accedere al fornitore di servizi, questo si consulta con il fornitore di identità per assicurarsi che l’utente abbia dimostrato di essere chi dichiara di essere. Il fornitore di servizi può impostare parametri su come funziona l’autenticazione, richiedendo ad esempio che il fornitore di identità utilizzi l’autenticazione a due fattori (2FA) o la biometria. Il provider di identità chiederà all’utente di accedere o, se ha effettuato l’accesso di recente, potrebbe semplicemente comunicarlo al provider di servizi senza disturbare ulteriormente l’utente.

I fornitori di servizi e identità comunicano tramite token, ovvero piccole raccolte di informazioni strutturate firmate digitalmente per garantire la fiducia reciproca tra le parti. È attraverso questi token che il provider di identità comunicherà al provider di servizi che l’utente si è autenticato, ma, soprattutto, i token non includono dati di autenticazione come la password dell’utente oi dati biometrici. Di conseguenza, anche se i token vengono intercettati da un utente malintenzionato o i sistemi del fornitore di servizi vengono violati, la password e l’identità dell’utente rimangono al sicuro. L’utente può anche utilizzare le stesse credenziali di accesso per qualsiasi provider di servizi che utilizza tale provider di identità.

Dal punto di vista dell’amministratore di sistema, la piattaforma SSO rappresenta uno “sportello unico” in cui è possibile gestire gli ID utente. Quando un dipendente lascia un’azienda, ad esempio, la sua capacità di accedere a una serie di applicazioni interne può essere revocata senza problemi.

Architettura Single Sign-On

Nello scenario più comune, il provider di identità e il provider di servizi stabiliscono una relazione di fiducia scambiando certificati digitali e metadati e comunicano tra loro tramite standard aperti come SAML (Security Assertion Markup Language), OAuth o OpenID.

In un articolo sulla Oracle Security Newsletter, Paul Toal approfondisce i modelli architettonici SSO, comprese le architetture tutt’altro che ideali che potreste dover implementare se i vostri provider di servizi non possono comunicare direttamente con un provider di identità.

cso_single_sign-on_table-2-100802088-large

Dovrete anche tenere presente che la vostra piattaforma SSO dovrà integrarsi nella vostra più ampia architettura IT organizzativa e dovrete pensare attentamente a come farlo mantenendo la vostra posizione di sicurezza generale. Ad esempio, un sistema SSO potrebbe impedire agli strumenti di sicurezza a valle di rilevare l’indirizzo IP di origine dell’utente che tenta di accedere al sistema.

Esempio di Single Sign-On

Prendiamo come esempio un’implementazione specifica per vedere come funziona SSO nella pratica. Immaginate di essere l’utente in un ambiente con Single Sign-On e state cercando di accedere a una risorsa su un server. La sequenza degli eventi è questa:

  • Si tenta di accedere al fornitore di servizi: di nuovo, si tratta generalmente di un’applicazione o di un sito Web.
  • Come parte di una richiesta di autenticazione dell’utente, il fornitore di servizi invia un token che contiene alcune informazioni su di voi (come il vostro indirizzo e-mail) al fornitore di identità, un ruolo svolto dal vostro sistema SSO.
  • Il provider di identità controlla prima per vedere se siete già stato autenticati, nel qual caso vi concederà l’accesso all’applicazione del provider di servizi e salterà al passaggio 5.
  • Se invece non avete mai effettuato l’accesso, vi verrà chiesto di farlo fornendo tutte le credenziali richieste dal provider di identità.
  • Una volta convalidate queste credenziali, il provider di identità invierà un token al provider di servizi, confermando che siete stati autenticati.
  • Questo token viene passato tramite il browser al fornitore di servizi.
  • Una volta ricevuto, il token viene convalidato in base alla relazione di fiducia che è stata impostata tra il provider di servizi e il provider di identità durante la configurazione iniziale.
  • All’utente viene infine concesso l’accesso al fornitore di servizi.

Se volete approfondire il tipo di messaggi tipici di queste transazioni, controllate gli esempi di OneLogin basati su SAML; è possibile esaminare il codice XML completo per i tipi di asserzioni trasmesse dal provider di identità al provider di servizi nello scenario descritto sopra.

Vantaggi della sicurezza Single Sign-On

Il più grande vantaggio per la sicurezza di SSO nell’azienda è che consente a un’organizzazione di aumentare il numero di utenti e il numero di accessi associati senza sacrificare la sicurezza o impantanarsi in un provisioning infinito degli account. Grazie alla gestione automatizzata delle credenziali, gli amministratori di sistema non sono più tenuti a occuparsi manualmente dell’accesso di tutti i dipendenti ai servizi che desiderano. Ciò a sua volta riduce il fattore di errore umano e libera il tempo dell’IT per concentrarsi su attività più importanti.

Altri vantaggi includono il provisioning rapido per le applicazioni cloud-first; se l’implementazione SSO supporta l’ascesa di standard aperti come SAML 2.0, l’applicazione può essere rapidamente fornita da un amministratore SSO e distribuita ai dipendenti. SSO può anche essere combinato con 2FA per una maggiore sicurezza e può fornire guadagni di produttività e meno reimpostazioni delle password da parte dell’help desk IT.

Tuttavia, sarebbe sbagliato far credere che SSO sia una panacea per tutte le sfide legate alla sicurezza. Bisogna infatti tenere conto di fattori come costi, controllo, standardizzazione (SAML vs OAuth) e sicurezza. I difetti di autenticazione, come la vulnerabilità Accedi con Apple o quella OAuth di Microsoft, potrebbero consentire a un utente malintenzionato di accedere a un sito o servizio come se fosse la vittima che stava prendendo di mira.

Soluzioni Single Sign-On

Esistono diversi tipi di soluzioni SSO da considerare, dalle offerte commerciali alle piattaforme open source personalizzate.

Gli strumenti SSO dei principali fornitori includono:

  • Duo / Cisco SSO
  • Single Sign-On idaptive
  • ManageEngine / Zoho Identity Manager Plus
  • MicroFocus / NetIQ Access Manager
  • Okta Single Sign-On
  • OneLogin Single Sign-On
  • PerfectCloud SmartSignIn
  • Ping Identity PingOne
  • RSA SecurID Access Suite