Login centralizzato con il protocollo CAS
Per “login centralizzato” si intende la condivisione da parte di più applicazioni web di un servizio di autenticazione degli utenti che garantisca l’acesso ad ogni applicazione attraverso un’unica login.
Consideriamo alcuni scenari:
- La Intranet di un’azienda è dotata di una serie di applicazioni web ad accesso protetto i cui utenti devono essere autenticati attraverso il servizio di Active Directory con il quale vengono gestiti gli accessi di tutte le altre applicazioni aziendali.
- Un’organizzazione vuol pubblicare su Internet alcune applicazioni o siti web ad accesso condiviso (vd. Google Apps ) in modo che un utente, una volta eseguito l’accesso su una qualsiasi delle applicazioni, possa accedere a tutte le altre senza dover inserire nuovamente username e password.
- In una SOA (Service-Oriented Architecture) alcuni Web Sevice devono comunicare con gli altri attraverso l’HTTP e condividere le credenziali per poterlo fare.
Come possiamo implementare un sistema di autenticazione centralizzata in questi (eterogenei) scenari? Prendiamo in considerazione una delle possibili soluzioni: l’utilizzo di un servizio basato sul protocollo CAS.
Central Authentication Service (CAS)
Sviluppato dall’Università di Yale e diventato nel 2004 un progetto JA-SIG, CAS è un protocollo divenuto abbastanza maturo ed utilizzato; il suo funzionamento di base prevede un server ed un client ed è rappresentato dallo schema seguente:
- L’utente tenta di accedere ad una pagina protetta
- Il CAS client reindirizza il browser alla pagina di login sul CAS server
- Il CAS server valida username e password su un datasource
- Il browser viene rimandato alla pagina richiesta inizialmente con un service ticket
- Il service ticket garantisce la persistenza delle credenziali su tutte le altre applicazioni
Datasource
La forza di questo protocollo risiede nella possibilità di utilizzare qualsiasi datasource per la gestione degli utenti. Può essere usato un DBMS, Active Directory, un servizio LDAP, un file XML etc. Gli utenti possono essere addirittura autenticati con i propri account Gmail. Il controllo può essere anche effettuato su più datasource ordinati per priorità: ad esempio possiamo controllare le credenziali dell’utente sul un nostro database e, in caso di autenticazione fallita, proseguire il controllo su Gmail.
Implementazione CAS in Ruby
Esistono implementazioni in Ruby sia del server che del client. Entrambi sono installabili come gemme e permettono di costruire e configurare l’intera infrastruttura. Il server viene fornito con gli authenticator più comuni (SQL, LDAP, ActiveDirectory, Google) che possono essere modificati con poche righe di codice. E’ molto semplice personalizzare anche l’aspetto grafico della pagina di login del server, così da adattarla al look and feel delle applicazioni che ne condividono il servizio.
