Shibbboleth è un pacchetto software open source e standardizzato che ha per obbiettivo il web Single Sign On, molto ricco per quello che riguarda lo scambio degli attributi, basato su standards aperti tra cui, prevalentemente, SAML2.
E’ un sistema federato che supporta l’accesso sicuro a risorse attraverso il web: le informazioni relative all’utente vengono trasmesse dall’Identity Provider (IdP) aziendale al Service Provider (SP) esterno che le prepara per la protezione dei dati sensibili e per l’utilizzo da parte delle applicazioni.
Il processo di autenticazione avviene, in buona sostanza, nei seguenti termini:
a) l’utente richiede la connessione ad una risorsa protetta facendo sì che il SP intercetti la richiesta (la risorsa da proteggere è definita nei files di configurazione del web server che la ospita);
b) il SP, basandosi sulla configurazione di cui sopra, determina a quale IdP far riferimento e quale protocollo utilizzare attraverso un meccanismo di “scoperta” noto come servizio WAYF (acronimo di Where Are You From): la richiesta di autenticazione è così delegata al WAYF che la passa all’IdP selezionato dall’utente;
c) come risultato delle azioni precedenti, una richiesta di autenticazione via browser è inviata dal SP all’IdP selezionato dall’utente: l’IdP decide se l’utente può autenticarsi e quali attributi inviare al SP, scelta questa basata prevalentemente sulle caratteristiche del SP che fornisce il servizio e su quelle dell’attributo principal dell’utente;
d) l’IdP impacchetta e firma i dati che trasmette sotto forma di asserzione SAML al SP che la spacchetta e la decodifica eseguendo poi una serie di controlli di sicurezza per decidere infine se il richiedente abbia o meno diritto di accesso alla risorsa desiderata;
e) infine, se il processo di verifica del punto precedente ha esito positivo, l’utente viene finalmente rediretto alla risorsa richiesta.
La figura sotto illustra il processo di autenticazione.
Come si può vedere da quanto sopra esposto, il processo di autenticazione avviene sull’IdP del richiedente e non sul SP che tale risorsa distribuisce; in parole semplici, l’utente si autentica presso la sua propria organizzazione, utilizzando una sola coppia di credenziali per più servizi ed evitando di dover allocare una coppia di credenziali per ogni fornitore di servizi.
Affinché ciò avvenga, occorre che gli attori del processo siano consorziati in quelle che vengono dette Federazioni, istituzioni collaborative di fornitori ed utilizzatori di servizi; si noti che un utilizzatore può essere anche contemporaneamente fornitore: l’università i cui utenti necessitano di accedere a risorse bibliografiche esterne, per esempio, può contemporaneamente consentire l’accesso al suo wifi a utenti di altri enti, purché federati.
In Italia tale obbiettivo è raggiunto dalla Federazione IDEM-GARR-AAI (IDEM = IDEntity Management), per maggiori delucidazioni in merito alla quale si rimanda al sito ufficiale IDEM-GARR-AAI.
L’Universita di Cagliari ha aderito alla fase pilota del progetto sin dalla sua nascita avvenuta nel 2008 ed ora, dal marzo 2010, è a pieno titolo membro della Federazione IDEM-GARR-AAI, mettendo a disposizione un IdP per l’accesso ai servizi offerti dalla Federazione ed avendo in cantiere la realizzazione in tempi non immediati di un SP in maniera da diventare anche fornitore di servizi e non soltanto fruitore.
E’ rappresentata nell’Assemblea della Federazione dall’Ing. Roberto Porcu in qualità di referente organizzativo e dal Dott. Stefano Manfredda in qualità di referente tecnico.
Per eventuali chiarimenti, informazioni e dettagli è possibile rivolgersi al Dott. Stefano Manfredda allo 0706755020 o scrivere un’e-mail a idem-helpATunica.it
Per riderci un po’ sopra …
Quello che segue è l’estratto di un botta e risposta tra Peter Schobel e Scott Cantor, due dei massimi guru di Shibboleth (Cantor in particolare ne è lo sviluppatore, il creatore), a proposito degli attributi scripted; gli attributi scripted sono attributi che anziché essere passati da un server LDAP, sono direttamente generati dall’Identity Provider a partire da attributi LDAP noti e definiti da questi attraverso uno script. Si usano (ed è il caso nostro) per trasmettere attributi obbligatori ma non rilasciati nativamente dalla Active Directory di Microsoft.