Login centralizzato tra applicazioni Rails

In un articolo precedente ho affrontato la questione del login centralizzato tra più applicazioni attraverso il protocollo CAS (Central Authentication Service). La soluzione presentata risulta una buona scelta nel momento in cui si debba gestire un’autenticazione comune tra applicazioni eternogenee, web o desktop, scritte in Rails, Java, PHP, Python o .NET.

Se però consideriamo una suite di applicazioni sviluppate in Ruby on Rails su uno stesso dominio, possiamo “giocare” con la gestione delle sessioni per condividere le credenziali degli utenti tra le applicazioni della suite.

Tipicamente, infatti, il controllo degli accessi viene implementato attraverso il salvataggio in sessione di un identificativo dell’utente, in seguito all’inserimento da parte di quest’ultimo di username e password validi. La condivisione dell’autenticazione, quindi, si riconduce alla condivisione delle sessioni tra le applicazioni.

Rails e le sessioni

In Rails una sessione è una struttura simile ad un hash (coppie chiave-valore) che permette di rendere persistenti i dati tra una richiesta e l’altra. In sessione può essere salvato ogni tipo di dato, dal momento in cui questi vengono serializzati in una delle seguenti opzioni di storage:

1. CookieStore (default)
2. ActiveRecordStore
3. SQLSessionStore
4. DRBStore
5. MemCacheStore

I criteri di scelta del tipo di session storage variano in funzione dei requisiti di spazio, sicurezza e performance. La soluzione basata sui cookie, ad esempio, è caratterizzata da un limite di storage di 4K ma da una velocità molto superiore rispetto alle altre. Questo è il motivo per cui è stata scelta come opzione di default. L’integrità dei dati è supportata dalla crittazione delle informazioni attraverso un algoritmo di digest (SHA1) e una chiave segreta univoca per ogni applicazione. Due applicazioni, quindi, condividono la stessa sessione se condividono la stessa chiave.

Login centralizzato

Consideriamo una suite di applicazioni identificate da sottodomini diversi dello stesso dominio:

• app1.example.com
• app2.example.com
• app3.example.com

Per fare in modo che le applicazioni condividano la sessione, è sufficiente specificare in ogni environment.rb la stessa configurazione:

 1 config.action_controller.session = {
 2 :session_key => '_example_session',
 3 :secret => 'shared_secret_long_string'
 4 }
 5 
 6 # rails 2.3
 7 config.action_controller.session[:domain] = '.example.com'
 8 
 9 # per le versioni di rails precedenti alla 2.3
 10 # ActionController::Base.session_options[:session_domain] = '.example.com'

Supponiamo che app1 contenga il model User e la logica di autenticazione. Una volta effettuato l’accesso, anche app2 e app3 vedono lo stesso user_id in sessione. A questo punto basta definire in app1 e app2 il model User connesso al database di app1:

 1 class User < ActiveRecord::Base
 2 self.abstract_class = true 
 3 establish_connection(
 4 :adapter => "mysql",
 5 :host => "localhost",
 6 :username => "ateapick",
 7 :password => "supersecret",
 8 :database => "app1"
 9 ) 
 10 end

Un caso di studio: formula-brake.com

Di recente abbiamo implementato un’autenticazione centralizzata su una serie di webapp aziendali per Formula, uno dei nostri clienti. In particolare, una delle applicazioni (security.formula-brake.com) ha un’area riservata per la gestione di tutti gli utenti aziendali e dei loro privilegi ed una parte pubblica che funge da gateway di autenticazione per tutte le altre applicazioni.

Per la gestione delle sessioni utente abbiamo utilizzato authlogic, un’ottima gemma realizzata dal bravissimo Ben Johnson di Binary Logic.

Per passare da una webapp all’altra, esiste infine un header condiviso con i link a tutte le applicazioni della suite, sulla falsa riga di quello presente su Google.

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:

1. L’utente tenta di accedere ad una pagina protetta
2. Il CAS client reindirizza il browser alla pagina di login sul CAS server
3. Il CAS server valida username e password su un datasource
4. Il browser viene rimandato alla pagina richiesta inizialmente con un service ticket
5. 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.