Oggi, la maggior parte dei siti consente l’accesso tramite provider come Google, Facebook, Twitter ed altri social network.
Questo ci ha sicuramente semplificato la vita: sono lontani i tempi in cui ci dovevamo preoccupare di avere login/password per ogni portale.
Ovviamente questo tipo di approccio è stato implementato sia per le applicazioni customer ma soprattutto all’interno di applicazioni aziendali.
Questo meccanismo prende il nome di Single Sign-On.
Il Single Sign-On (SSO) è un metodo di autenticazione che consente agli utenti di accedere a più applicazioni e sistemi con un set di credenziali di accesso (nome utente e password).
L’utente deve inserire le proprie informazioni di accesso solo una volta e verrà automaticamente effettuato l’accesso a tutti i sistemi e le applicazioni a cui è stato concesso l’accesso.
Un paragone può essere fatto considerando il sistema di registrazione presso un hotel: l’utente effettua il check-in (tramite ad esempio una carta di identità) ed ottiene la chiave per accedere a tutti i servizi dell’hotel. Per esempio può accedere alla piscina, ai servizi interni del bar ed al ristorante.
Solo al termine della sua permanenza dovrà restituire la chiave. Questo tipo di accesso ha richiesto l’identificazione dell’utente soltanto una sola volta: durante la fase di check-in.
SSO funziona in maniera del tutto simile.
SSO – Funzionamento
Di seguito i passi che vengono utilizzati nell’utilizzo del Single Sign-On:
- L’utente accede all’applicazione web del server SSO fornendo le proprie credenziali (login/password). Questo passaggio viene definito autenticazione.
- L’applicazione web del server SSO verifica e convalida le credenziali, emettendo un cookie locale. Questo cookie consente all’utente di rimanere connesso all’applicazione Web. In pratica è quello che avviene quando la reception dell’hotel rilascia la chiave di accesso ai vari servizi.
- L’utente cerca di accedere ad uno servizi (es. l’app che consente di prenotare la piscina). Quello che succede è che l’utente viene reindirizzato verso l’app del server SSO che però sa che l’utente è già stato autenticato. L’app per l’accesso alla piscina emetterà un proprio cookie che è diverso rispetto al cookie precedentemente emesso. In pratica il primo cookie verrà utilizzatto per le richieste al server SSO, mentre l’altro cookie verrà utilizzato per l’accesso al servizio di accesso alla piscina.
- Supponiamo ora che l’utente necessiti di accedere al servizio sauna è che aperto a tutti gli utenti dell’hotel. Non è necessario che venga emesso un nuovo cookie, perchè in background verrà utilizzato il cookie di accesso emesso per il server SSO. Non è necessario alcun altro passaggio per l’autenticazione ed i dati di accesso potranno eventualmente essere salvati all’interno di una sessione web.
In genere, per implementare SSO in un’applicazione Web .NET Core, è possibile usare le librerie seguenti oltre al framework .NET Core:
- .NET Core Identity per la gestione degli utenti. Questo gestisce tutto ciò che riguarda l’utente, come profilo utente, password, ruoli, reimpostazione password, token di conferma e-mail, ecc.
- Identity Server , come framework raccomandato dalla documentazione Microsoft, implementa i protocolli OpenID Connect e OAuth 2.0 e aiuta a gestire i dati di configurazione e i dati operativi.
- Database SQL come SQL Server, Azure SQL. I dati utente, i dati di configurazione e i dati operativi sono altamente relazionali e gli aggiornamenti su questi dati devono essere affidabili e transazionali. Inoltre, la dimensione dei dati è ridotta per adattarsi a un singolo database ed è improbabile che sia necessario il partizionamento orizzontale. Un database SQL relazionale sarebbe una buona soluzione.