Single Sign On - Single Log Out

Che cos'è il Single Sign On ?

Uno dei maggiori benefici introdotti da una infrastruttura di autenticazione è la possibilità di introdurre il "Single Sign On", o SSO. Un utente identifica se stesso presso un servizio centralizzato di autenticazione (presso il nostro Ateneo è stato scelto di usare Shibboleth come uno dei componenti del servizio), inserendo le proprie credenziali, ossia il proprio nome utente e la propria password, una volta sola per l'intera sessione di lavoro. Dopodiché l'utente può accedere a molti differenti servizi senza la necessità di dovere reimmettere le proprie credenziali in ciascuno di essi.

Quando un servizio riceve una richiesta da un utente che non ha sessioni attive con il servizio stesso, quest'ultimo manderà una richiesta di autenticazione al servizio centralizzato di autenticazione (Shibboleth). Se l'utente si era già collegato al al servizio centralizzato di autenticazione perché aveva già usato altri servizi, il servizio centralizzato di autenticazione attesterà l'identità dell'utente, senza richiedere nuovamente all'utente di reimmettere nome utente e password. Se invece questo è il primo servizio che l'utente attiva nella sessione di lavoro, il servizio centralizzato di autenticazione si prenderà cura dell'intero processo di autenticazione e ritornerà al servizio richiedente un attestato di identità dell'utente stesso, dopo averne verificato la corretta immissione delle credenziali.

L'attestato di identità che il servizio centralizzato di autenticazione restituisce al servizio finale può essere corredato con attributi che possono essere utili al servizio stesso per descrivere l'utente. La selezione degli attributi forniti è regolata da un accordo stipulato tra il servizio finale e il servizio centralizzato di autenticazione.

Benefici per l'utente resi possibili dal SSO

• L'utente dovrà ricordare una sola coppia di credenziali per un numero molto elevato di servizi;
• Il nome utente e la password devono essere introdotti solo una volta per l'intera sessione di lavoro;
• Gli attributi essenziali riguardanti l'utente possono essere forniti automaticamente senza bisogno che il servizio li debba chiedere all'utente;
• La password dell'utente è memorizzata e custodita in un solo posto - il servizio centralizzato di autenticazione dell'Ateneo - pertanto il rischio di compromissione o di uso scorretto viene significativamente ridotto.

Benefici per il fornitore di servizi resi possibili dal SSO

• Viene eliminata la necessità di gestire l'elenco dei nomi utenti e delle password per tutti gli utenti;
• Gli attributi forniti dal servizio centralizzato di autenticazione sono sempre aggiornati, perciò non ci saranno più problemi dovuti a dati non aggiornati o non più validi;
• Il servizio non deve implementare la procedura di dialogo con l'utente per richiedere l'autenticazione;
• L'introduzione di migliorie nel versante della sicurezza, ad esempio la possibilità di autenticarsi con chiavi fisiche (smartcard) o biometriche non richiederà alcuna modifica al servizio.

Non usare il SSO quando ....

Dopo la prima autenticazione non viene più richiesto all'utente di ri-autenticarsi per il resto della sessione di lavoro

When not to use SSO

Once a user is signed on, no further authentication is required for the rest of the session. If the user leaves the workplace without logging out, an intruder could then take the user's place at the workstation, masquerading as the signed on user - not only for those services already activated but for all services to which the user has access.

To reduce the risk of workstations being "hijacked", an SSO session will time out after a few hours, requiring a new sign on. So, a workstation being left signed on at the end of the workday will not be available to nightly intruders. However, in an open environment such as a university campus with many public Internet terminals continuously available to hundreds or thousands of others, the risk is significantly higher of an intruder hijacking the workstation before the timeout is activated.

For certain services such as those involving personal information or economical transfers, this may be considered unsatisfactory. To counter the risks, a service may indicate, when inquiring about the user, that even if the user already has a running Feide session, a user dialog should be opened to obtain a "fresh" authentication. The benefits of a single user name and password, common login procedures, user attribute management and localized password management are obtained; only the single sign on functionality is given up.

A service choosing not to use SSO will always request a fresh sign-on, making hijacking far less likely. Services managing personal data or economic transaction should weigh the user benefits of SSO against the need for improved protection against masquerading attempts.

It should be noted disabling SSO will not protect against hijacking of an opened service session. A service disabling SSO should also consider enforcing a short timeout for the local service session for even higher security. The timeout value for the service session is a local matter that does not affect the communication with Moria.