Caratteristiche e Differenza tra CAS, OpenID e SAML

CAS

Il Central Authentication Service (CAS) è un meccanismo di autenticazione sviluppato presso Yale, a partire dal 2004 è sviluppato e mantenuto da JASIG (Java Administratrion Special Interest Group), organizzazione non-profit con l’obiettivo di gestire progetti opensource di interesse per gli enti di formazione superiore.

Il protocollo CAS è stato progettato per permettere l’autenticazione di applicazioni web con la possibilità di condividere una medesima sessione di lavoro (Single Sign-On) senza richiedere ogni volta l’immissione di credenziali.

Il sistema CAS può supportare diverse tecnologie per il riconoscimento dell’utente, dall’inserimento di una password all’uso di un certificato client. Il funzionamento si basa sulla presenza di un server di autenticazione (CAS server), a cui il browser dell’utente si rivolge dopo essere stato rimandato dall’applicazione che ha cercato di raggiungere.

L’applicazione deve essere stata precedentemente registrata nella configurazione del CAS Server dal CAS Administrator, permettendo così di procedere con l’autenticazione. Al momento della registrazione sono anche determinati parametri di funzionamento quali la partecipazione o meno al contesto di SSO ed eventuali informazioni aggiuntive da rilasciare all’applicazione richiedente quando si autentica un utente.

Ad autenticazione avvenuta il browser dell’utente riceve un Service Ticket da presentare all’applicazione, quest’ultima lo riceve e usa il CAS Client (componente software che implementa il CAS Protocol) per comunicare col CAS Server e validare la richiesta. Se il CAS Server risponde correttamente, l’utente che ha presentato il Service Ticket inizia una sessione di lavoro. Nel caso in cui l’utente visiti una seconda applicazione nel contesto di SSO l’interazione iniziale viene ignorata passando immediatamente alla validazione del Service Ticket, consentendo all’utente di accedere alla seconda applicazione in modo trasparente.

OpenID e SAML

OpenID e SAML (Security Assertion Markup Language), come il protocollo CAS, non sono sistemi di autenticazione in senso stretto, bensì un’estensione dei sistemi tradizionali nel contesto del Web. A differenza del Central Authentication Service queste due tecnologie permettono di spingersi al di fuori del perimetro dell’organizzazione, consentendo l’interazione di identità esterne con i servizi locali e viceversa, costituendo un sistema federato di identità.

OpenID è un sistema utilizzato da grandi provider di servizi come Yahoo!, Google, WordPress. Inizialmente adottato anche da Facebook, è stato in seguito sostituito da Facebook Connect. Si basa sul principio di decentralizzazione dei ruoli di Identity Provider e Service Provider, non richiede meccanismi di trust esplicito per funzionare, motivo per cui è adottato soprattutto in contesti dove l’esigenza è distinguere correttamente gli utenti ma non necessariamente avere certezza sulla loro identità.

Si tratta di un sistema snello volto a risolvere il problema della proliferazione degli account, consentendo agli utenti di riutilizzare la propria identità registrata presso un OpenID provider, offrendo alle applicazioni la possibilità di affrancarsi dalla gestione delle anagrafiche affidandosi al protocollo. L’estrema decentralizzazione spinge però sulle applicazioni l’onere di supportare i diversi provider, motivo per cui la scena attuale vede una polarizzazione del supporto solo su pochi provider molto diffusi (Google, Facebook).

SAML (Security Assertion Markup Language) standard OASIS per lo scambio di dati relativi ad autenticazione, autorizzazione e dati sull’identità in formato XML per contro segue un approccio più strutturato. Gli elementi costituenti sono i seguenti:

• asserzioni: elementi di base dei messaggi che possono essere scambiati;
• protocolli: le modalità di aggregazione delle asserzioni per la comunicazione tra le entità coinvolte;
• binding: modalità di trasferimento dei messaggi scambiati;
• profili: istruzioni per l’aggregazione di asserzioni, protocolli e binding per poter coprire uno specifico caso d’uso.

Il profilo di interesse in questo contesto è il Web browser SSO profile dove avviene la sequenza dei messaggi tra lo User Agent (il browser utilizzato dall’utente), il Service Provider (l’applicazione o risorsa a cui l’utente vuole accedere) e l’Identity Provider (il fornitore di identità).

Al completamento dello scambio l’utente avrà una sessione autenticata che potrà permettergli di accedere ad altre risorse, facenti parte dello stesso contesto di SSO, senza inserire di nuovo le credenziali.
Nel caso di SAML il contesto di Single Sign-On è determinato dalle relazioni di trust in vigore tra Service Provider, Identity Provider e gli altri componenti della federazione. Infatti per IDP e SP è possibile determinare relazioni di trust punto-punto, con l’ovvio limite della scalabilità al crescere dei partecipanti, oppure inserirsi in un contesto centralizzato che raccoglie gruppi di risorse e fornitori di identità che prende il nome di federazione di identità.

Le federazioni di identità sono normalmente operate da realtà nazionali che si occupano di interloquire con i partecipanti e gestire un servizio centralizzato di condivisione dei metadati. Queste informazioni sono l’elemento fondante delle relazioni di trust e permettono di mantenere aggiornato l’elenco dei partecipanti al crescere delle entità.

In un’infrastruttura federata di autenticazione si inserisce un elemento necessario per poter individuare quale IDP utilizzare per verificare l’identità di un utente che richiede l’accesso a un Service Provider SAML. Il Discovery Service o WAYF (Where Are You From) è un componente software con cui interagisce l’utente per scegliere l’IDP di appartenenza, in modo da poter effettuare l’autenticazione e procedere con l’accesso al SP.

L’impostazione centralizzata ha diversi vantaggi ma presenta anche alcuni svantaggi quali la complessità di manutenzione e la costituzione di un Single Point of Failure per l’operatività della federazione, inoltre il processo di adesione può essere anche molto lento, a seconda del livello di formalità (e del ruolo) con cui si vuole entrare a farne parte. Questo livello di precisione nell’operatività ha fortunatamente il pregio di selezionare partecipanti e utenze con un livello di affidabilità mediamente elevato.