SAML: spieghiamo in sintesi come funziona il framework XML per SSO e Co.

Il Federated Identity Management (FIM) è una delle soluzioni più importanti per rendere accessibili a tutte le aziende applicazioni web e strutture cloud senza perdere di vista la sicurezza. Linee guida e protocolli standardizzati garantiscono ai singoli utenti l’accesso ai diversi servizi, anche se non vengono impiegate banche dati comuni in locale. Inoltre in questo modo si può integrare anche il rinomato Single Sign-on (SSO), grazie al quale un unico accesso permette l’utilizzo di più applicazioni. Per realizzare una simile struttura di sicurezza, molte aziende si affidano al framework XML SAML (Security Assertion Markup Language).

Security Assertion Markup Language, abbreviato SAML, è un framework open source basato su XML per lo scambio di informazioni di autenticazione e autorizzazione. A partire dal 2001 è stato sviluppato dalla Security Services Technical Committee dell’OASIS (Organisation for the Advancement of Structured Information Standards) e lanciato nel novembre 2002 nella sua prima versione (SAML v1.0). Nel corso del tempo il team ha apportato diverse modifiche al progetto, creando le versioni rivisitate SAML 2.0 e 2.1 (anche 1.1). Lo standard SAML contiene più componenti che mettono a disposizione tutte le funzioni rilevanti per la descrizione e la trasmissione di informazioni relative alla sicurezza, rappresentando la base ottimale per la Federated Identity Management (FIM).

SAML può essere utilizzato anche per fare dichiarazioni sulle caratteristiche e le autorizzazioni di un utente in confronto ad altri utenti o aziende partner ma soprattutto sulle applicazioni (queste ultime definite in ASML anche come service provider). Per fare ciò il cosiddetto identity provider (banca dati centrale dell’utente), che salva le relative informazioni utente, ricorre ad asserzioni in formato XML. Altre componenti di un ambiente verificato basato su standard SAML sono sei diversi protocolli, nonché binding e profili.

Un’asserzione SAML può contenere una o più dichiarazioni riguardanti le caratteristiche (identità, attributi) e le autorizzazioni di un utente. Viene creata dal suo identity provider, quindi dalla sua banca dati utente, dove viene utilizzato l’XLM come linguaggio dichiarativo. Ogni asserzione contiene una firma digitale che deve essere testata e verificata dal service provider, cioè dalla relativa applicazione. In questo modo sono garantite l’integrità e l’autenticità dell’asserzione, definita anche token SAML. Dopo aver effettuato la verifica, il service provider analizza il contenuto e decide se e quali accessi accordare all’utente.

I tre tipi di dichiarazioni seguenti sono specifici per le asserzioni nello standard SAML 2.0:

• Authentication statement: attraverso l’Authentication statement l’identity provider informa l’applicazione che l’utente si è autenticato. In seguito, la tipologia di dichiarazione in una asserzione può dare anche informazioni sul momento in cui l’autenticazione ha avuto luogo e il metodo utilizzato per l’applicazione.
• Attribute statement: si tratta di attributi collegati con il relativo utente e la cui applicazione può essere suddivisa in token SAML.
• Authorization decision statement: quando le Authorization decision statement sono contenute in un’asserzione SAML, l’utente o ha accesso alle risorse specifiche o gli viene negato tale accesso.

La specifica del SAML 2.0 definisce una serie di protocolli domanda/risposta che permettono all’applicazione di richiedere o interrogare un’asserzione o di invitare un utente ad autentificarsi. Qui di seguito i protocolli nei dettagli:

• Authentication request protocol: l‘Authentication request protocol definisce con messaggi di tipo <AuthnRequest> la necessità di interrogare un utente scelto con un’asserzione con Authentication statement. Sulla base di questo protocollo le informazioni passano dalla banca dati al service provider, dove viene utilizzato il diffuso SAML 2.0 Web Browser SSO Profile (più informazioni nel paragrafo “Profili”).
• Assertion query and Request protocol: l’Assertion query and Request protocol contenuto nel framework è utilizzato per richieste che possono essere richiamate in generale con le esistenti asserzioni SAML. La richiesta da parte dell’asserzione può avvenire sulla base di diversi parametri come ad esempio il tipo di dichiarazione ricevuta.
• Single logout protocol: il Single logout protocol definisce quelle richieste che provocano la disconnessione di tutte le sessioni aperte di un utente. Tali messaggi possono essere inviati sia dallo stesso utente che dall’identity o service provider: si tratta di quest’ultimo quando la sessione dell’utente è scaduta.
• Artifact resolution protocol: se i messaggi SAML devono essere trasportati tramite un canale sicuro o in una dimensione a risparmio risorse, si utilizza l’Artifact resolution protocol. Esso permette l’invio di referenze tramite asserzioni, che possono essere definite anche artefatti, nettamente più piccole in confronto ai messaggi veri e propri. Il protocollo permette inoltre di annullare queste referenze per ricevere il messaggio originale.
• Name identifier management protocol: questo protocollo mette a disposizione i mezzi per modificare il valore o il formato di un nome che indica l’identità di un utente. L’autore della richiesta può essere o il service provider o l’identity provider. Inoltre con il Name identifier management protocol è possibile eliminare i collegamenti tra il service provider e l’identity provider creati per l’autenticazione dell’identità originaria dell’utente.
• Name identifier mapping protocol: il Name identifier mapping protocol definisce i messaggi di domanda/risposta per la comunicazione tra due service provider. Sulla base di questo tipo di messaggi un’applicazione può richiedere all’identity provider un identificatore a favore di un utente per poter accedere ad un’altra applicazione.

Le mapping (cioè le trasformazioni) dello scambio di messaggi SAML in standard messaging o protocolli di comunicazione vengono definiti binding di protocollo SAML o semplicemente binding. Il binding SOAP ad esempio definisce come avviene lo scambio di messaggi SAML in un ambiente SOAP, mentre l’HTTP redirect binding stabilisce come possono essere inviati i messaggi di protocollo SAML attraverso il processo di trasmissione http. Altri binding predefiniti nello standard SAML 2.0 sono:

• Reverse SOAP Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML URI Binding

Come standard generale, SAML è caratterizzato dalla sua flessibilità che dimostra che il framework è adatto per numerosi scenari d’utilizzo. Affinché determinate applicazioni supportino l’utilizzo di SAML, bisogna limitare in parte questa flessibilità: per farlo entrano in azione i cosiddetti profili, che riuniscono asserzioni, protocolli e binding per specifici casi d’applicazione. Uno dei profili più usati è il suddetto SAML 2.0 Web Browser SSO Profile, specifico per la realizzazione di un’autenticazione SSO SAML. Esso contiene tutte le componenti decisive per definire la comunicazione delle garanzie di autenticazione tra identity e service provider necessaria per l’accesso ad un browser di internet. Inoltre il framework offre i seguenti profili:

• Enhanced Client and Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Identifier Management Profile
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile

Più di 24 aziende ed organizzazioni si sono adoperate per l’ideazione e lo sviluppo di SAML 2.0, prima del suo lancio nel marzo 2005 come versione ufficiale successiva a SAML 1.0 e 1.1. Oltre ai numerosi miglioramenti alle funzionalità preesistenti, il framework conteneva anche funzionalità completamente nuove, come quelle tratte dal Liberty Alliance Identity Federation Framework (ID-FF) 1.2 e Shibboleth-Architektur sviluppato da Internet2.

Di seguito riportiamo gli adeguamenti più importanti che il framework ha subito nei due “grandi” release (“major release”):

• Cancellazione di alcuni elementi datati come <AuthorityBinding> o <RespondWith> e vecchi formati di identificazione
• Implementazione della firma XML e la cifratura XML (secondo lo standard W3C)
• Sostituzione dell’AssertionID-attribut con un generico attributo ID XML
• Introduzione del management di sessione per supportare le disconnessioni automatiche di tutte le applicazioni (ad esempio in caso di lunga assenza)
• Adeguamento dei metadati, per facilitare l’utilizzo di SAML (tra cui anche le istanze coinvolte come identity provider e service provider)
• Implementazione di meccanismi che permettono ai provider di comunicare le linee guida e le impostazioni sulla privacy
• Migliore supporto dei dispositivi mobili
• Implementazione dei protocolli già elencati prima (in SAML 1.0 e 1.1 esistevano solo l’Assertion Query e il Request Protocol)
• Ottimizzazione del profilo (ad es. accorpamento del profilo “Browser/Artifact” e “Browser/Post” in “SAML 2.0 Web Browser SSO Profile”)

Trovate una lista dettagliata delle differenze tra SAML 2.0 e SAML 1.1. sul sito della community SAML saml.xml.org.

Il campo d’utilizzo del framework SAML è di facile definizione: con il relativo know-how è possibile realizzare un’istanza centrale di autenticazione sulla base di linguaggi dichiarativi, caratterizzata dall’efficienza e un alto standard di sicurezza. La sicurezza in particolare è garantita dal fatto che le singole applicazioni non devono memorizzare o sincronizzare alcun dato utente, il che riduce considerevolmente il numero di possibili perdite di sicurezza. L’obiettivo principale del framework è quello di associare questo alto livello di sicurezza con la migliore esperienza utente possibile, motivo per cui supporta anche il Single Sign-On grazie ai relativi protocolli e formati di messaggio.

Il processo SSO di SAML, che permette l’utilizzo di diverse applicazioni sulla base di un’unica registrazione, non è richiesto solo all’interno dei processi di applicazione interni delle aziende: il pratico accesso per registrazione unica è oggi utilizzato da diversi servizi web, in particolare per l’online banking e le app mobili. Spesso l’utente neanche si accorge che utilizzando tali servizi sta in realtà utilizzando più applicazioni diverse. Un cliente che accede al sito internet della propria banca, ad esempio, è probabile che abbia accesso a più di un sistema di back-end quando ad esempio apre il libretto di risparmio, il deposito e il conto della carta di credito. Grazie alla tecnologia SAML, tuttavia, gli sembra di usare un unico programma.