Reading Time: 5 minutes

Single Sign-on

Il numero di servizi, fruiti dagli utenti tramite l’internet pubblica o su una rete aziendale privata, è in progressivo aumento.

Ciascuno di essi richiede il superamento di una procedura di autenticazione per la quale occorre implementare meccanismi spesso diversi e mantenere credenziali differenti.

Il processo di autenticazione parte quasi sempre dalla digitazione di una componente segreta (chiave, password), che opportunamente trasformata, consente di identificare univocamente l’utente presso il servente.

Ogni utente sensibile alle problematiche di sicurezza conosce la necessità di utilizzare credenziali diverse per accedere a servizi gestiti da entità diverse.

Nonostante l’approccio teorico sia generalmente noto e condiviso spesso sorgono numerose complicazioni pratiche.

Mantenere un segreto diverso per ogni diverso servizio utilizzato può infatti tradursi in un compito estremamente complesso per un utente comune.

La situazione si fa ancora più complicata se l’utente correttamente decide di rispettare la regola di non memorizzare su alcun supporto fisico le password scelte.

All’aumentare del numero di sistemi che richiedono autenticazione la soluzione semplificatrice, che l’utente è molto spesso spinto ad adottare, è eleggere una unica password comune a più servizi.

Questa soluzione espone di fatto gli utenti a molteplici inconvenienti.

Se tra i servizi utilizzati ve n’è almeno uno basato sul paradigma username/password, è sufficiente che un hacker intercetti i pacchetti relativi a tale servizio per poter ricavare la password condivisa e sostituirsi all’utente anche negli altri servizi.

Una fonte alternativa di preziose informazioni per l’attaccante è rappresentata dal file, presente sul server, che contiene i digest delle credenziali utente.

La violazione di un server protetto in maniera approssimativa è sufficiente per poter catturare tali informazioni che permettono all’attaccante di avviare un attacco per forza bruta o basato su un vocabolario prestabilito.

Di tutti gli schemi di autenticazione presentati, quello che rappresenta la soluzione più robusta è quello basato su uno schema OTP.

In tal caso non è prevista la memorizzazione del digest delle password sul server, la cui violazione non produce quindi effetti immediati sulla sicurezza delle password utente, eventualmente condivise con altri servizi e/o sistemi, sempre basati su OTP.

Purtroppo l’adozione generalizzata di sistemi OTP, normalmente più complessi degli altri e comunque non esenti da vulnerabilità specifiche, non è una ipotesi sostenibile sull’Internet pubblica, anche a causa dell’elevato numero di piattaforme eterogenee e di amministratori coinvolti.

Non tutti gli amministratori condividono infatti la necessità di introdurre uno schema di autenticazione robusto, affermando che è responsabilità diretta dell’utente scegliere password robuste, variarle nel tempo e soprattutto non riutilizzarle su servizi diversi.

Inoltre la diffusione di servizi che richiedono una autenticazione robusta, se da un lato aumenta il livello di sicurezza complessivo dell’infrastruttura, dall’altro introduce ritardi significativi e complicazioni d’uso che non tutti gli utenti sono disposti a sostenere.

Lo scenario è reso ancor più complesso dal proliferare di meccanismi alternativi di autenticazione adottati dai vari serventi.

Di fatto per ogni nuovo accesso è richiesto all’utente il superamento di una nuova fase di autenticazione e conseguente nuova digitazione della propria password.

Per eliminare questi ritardi, molti programmi offrono l’opzione di far memorizzare temporaneamente al software le credenziali utente dopo che queste sono state digitate una prima volta.

Questa soluzione è comunemente accettata per programmi che controllano lo stato della mailbox utente in numerosi programmi di posta elettronica e viene spesso utilizzata anche nei più comuni browser.

Generalizzare una simile soluzione, affidando la responsabilità di semplificare la procedura di accesso al servizio al singolo programma utilizzato, non rappresenta un approccio corretto.

In ambiente Microsoft il compito di ridurre il numero di password digitate è affidato allo stesso sistema operativo, che nelle richieste di accesso successive al logon prova per prima cosa a utilizzare la stessa password usata con successo per l’autenticazione dell’utente locale.

Quando tale password non è corretta, restituisce un prompt per consentire all’utente l’inserimento di una password alternativa.

L’utente può installare sulla propria piattaforma client programmi addizionali che lavorano congiuntamente agli altri software, che consentono di accrescere le funzionalità di memorizzazione e completamento automatico della procedura di autenticazione.

Prima di installare e utilizzare tali applicativi ogni utente dovrebbe domandarsi quale è l’affidabilità e la robustezza offerta da simili tool per proteggere la password affidatagli.

Si può essere realmente sicuri che il sistema locale non possa essere violato e/o che il software stesso non possa esportare le credenziali all’insaputa dell’utente?

Pur riconoscendo le limitazioni derivanti dall’affidarsi a soluzioni empiriche, come quelle appena descritte, sempre più spesso le organizzazioni chiedono per i loro utenti l’attivazione di procedure che permettano al sistema client di autenticarsi una e una sola volta.

L’obiettivo generale è lasciare che il sistema riutilizzi autonomamente le credenziali fornite dall’utente legittimo per accedere ai diversi servizi, siano essi server locali attestati alla rete aziendale sia server dell’Internet pubblica.

La realizzazione di una simile architettura “semplificatrice”, denominata infrastruttura Single Sign-on, prevede generalmente l’attivazione delle seguenti componenti:

  • un client compatibile;
  • un agent (spesso un proxy applicativo);
  • un AAA server.

Una architettura Single Sign-on prevede innanzitutto che l’utente che si siede fisicamente davanti al sistema sia autenticato tramite inserimento delle proprie credenziali.

Ciò può avvenire anche utilizzando un meccanismo di validazione contenuto nel BIOS della postazione locale ed essere antecedente alla fase di bootstrap del sistema stesso.

Più frequentemente l’autenticazione dell’utente avviene tramite colloquio con un sistema aziendale centrale su cui tutte le credenziali utente sono conservate.

Una volta superata l’autenticazione con il server centrale, la postazione client e l’utente che la utilizza temporaneamente sono univocamente riconosciuti e abilitati all’uso di specifiche risorse e servizi dal sistema AAA server.

Se l’utente desidera accedere a un servizio non deve far altro che contattare il server locale e/o remoto, come abituato a fare nel caso generale.

Con la soluzione di Single Sign-on le richieste di autenticazione vengono intercettate dalla componente agent (proxy intermedio) che provvede a completare il meccanismo di autenticazione, preliminare all’accesso al servizio, autonomamente, senza coinvolgere l’utente finale.

Una simile soluzione rende possibile mantenere password diverse per servizi diversi in quanto il sistema agent contatta il server AAA a ogni richiesta di autenticazione, e il server può restituire credenziali diverse prelevandole da un proprio database interno molto più capiente e affidabile della memoria di un utente comune.

Il server AAA viene interrogato non solo per ottenere le credenziali necessarie ma anche per stabilire ciò che l’utente può richiedere (authorization) e per conservare traccia delle azioni svolte durante l’accesso al servizio (accounting).

Lo schema generale è compatibile con il protocollo Kerberos, ma esistono numerose soluzioni commerciali molto diffuse che implementano in maniera efficace una architettura Single Sign-on anche adottando soluzioni proprietarie.

Indipendentemente dalla soluzione implementata, con il Single Sign-on l’utente deve memorizzare un’unica password (o mantenere un unico token).

Attraverso questa credenziale egli acquisisce accesso alla stazione locale e si fa riconoscere dal server autenticatore centrale.

Ogni altra fase di autenticazione è delegata al server centrale.

Un altro effetto collaterale positivo è che i tempi necessari per accedere ai servizi si riducono sensibilmente in quanto la procedura di autenticazione iniziale è la sola che coinvolge una partecipazione attiva dell’utente (digitazione password), tutte le altre avvengono in maniera trasparente e sono processate alla massima velocità consentita dal sistema informativo.

error: Content is protected !!

Complimenti! Ti sei iscritto alla nostra Newsletter

C'è stato un errore durante l'invio della richiesta. Per favore riprova.

Computer Security will use the information you provide on this form to be in touch with you and to provide updates and marketing.