SAML: spie­ghia­mo in sintesi come funziona il framework XML per SSO e Co.

Il Federated Identity Ma­na­ge­ment (FIM) è una delle soluzioni più im­por­tan­ti per rendere ac­ces­si­bi­li a tutte le aziende ap­pli­ca­zio­ni web e strutture cloud senza perdere di vista la sicurezza. Linee guida e pro­to­col­li stan­dar­diz­za­ti ga­ran­ti­sco­no 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ù ap­pli­ca­zio­ni. Per rea­liz­za­re una simile struttura di sicurezza, molte aziende si affidano al framework XML SAML (Security Assertion Markup Language).

Security Assertion Markup Language, ab­bre­via­to SAML, è un framework open source basato su XML per lo scambio di in­for­ma­zio­ni di au­ten­ti­ca­zio­ne e au­to­riz­za­zio­ne. A partire dal 2001 è stato svi­lup­pa­to dalla Security Services Technical Committee dell’OASIS (Orga­ni­sa­tion for the Advan­ce­ment of Structured Infor­ma­tion 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 ri­vi­si­ta­te SAML 2.0 e 2.1 (anche 1.1). Lo standard SAML contiene più com­po­nen­ti che mettono a di­spo­si­zio­ne tutte le funzioni rilevanti per la de­scri­zio­ne e la tra­smis­sio­ne di in­for­ma­zio­ni relative alla sicurezza, rap­pre­sen­tan­do la base ottimale per la Federated Identity Ma­na­ge­ment (FIM).

SAML può essere uti­liz­za­to anche per fare di­chia­ra­zio­ni sulle ca­rat­te­ri­sti­che e le au­to­riz­za­zio­ni di un utente in confronto ad altri utenti o aziende partner ma so­prat­tut­to sulle ap­pli­ca­zio­ni (queste ultime definite in ASML anche come service provider). Per fare ciò il co­sid­det­to identity provider (banca dati centrale dell’utente), che salva le relative in­for­ma­zio­ni utente, ricorre ad as­ser­zio­ni in formato XML. Altre com­po­nen­ti di un ambiente ve­ri­fi­ca­to basato su standard SAML sono sei diversi pro­to­col­li, nonché binding e profili.

Un’as­ser­zio­ne SAML può contenere una o più di­chia­ra­zio­ni ri­guar­dan­ti le ca­rat­te­ri­sti­che (identità, attributi) e le au­to­riz­za­zio­ni di un utente. Viene creata dal suo identity provider, quindi dalla sua banca dati utente, dove viene uti­liz­za­to l’XLM come lin­guag­gio di­chia­ra­ti­vo. Ogni as­ser­zio­ne contiene una firma digitale che deve essere testata e ve­ri­fi­ca­ta dal service provider, cioè dalla relativa ap­pli­ca­zio­ne. In questo modo sono garantite l’integrità e l’au­ten­ti­ci­tà dell’as­ser­zio­ne, definita anche token SAML. Dopo aver ef­fet­tua­to la verifica, il service provider analizza il contenuto e decide se e quali accessi accordare all’utente.

I tre tipi di di­chia­ra­zio­ni seguenti sono specifici per le as­ser­zio­ni nello standard SAML 2.0:

• Au­then­ti­ca­tion statement: at­tra­ver­so l’Au­then­ti­ca­tion statement l’identity provider informa l’ap­pli­ca­zio­ne che l’utente si è au­ten­ti­ca­to. In seguito, la tipologia di di­chia­ra­zio­ne in una as­ser­zio­ne può dare anche in­for­ma­zio­ni sul momento in cui l’au­ten­ti­ca­zio­ne ha avuto luogo e il metodo uti­liz­za­to per l’ap­pli­ca­zio­ne.
• Attribute statement: si tratta di attributi collegati con il relativo utente e la cui ap­pli­ca­zio­ne può essere suddivisa in token SAML.
• Au­tho­ri­za­tion decision statement: quando le Au­tho­ri­za­tion decision statement sono contenute in un’as­ser­zio­ne SAML, l’utente o ha accesso alle risorse spe­ci­fi­che o gli viene negato tale accesso.

La specifica del SAML 2.0 definisce una serie di pro­to­col­li domanda/risposta che per­met­to­no all’ap­pli­ca­zio­ne di ri­chie­de­re o in­ter­ro­ga­re un’as­ser­zio­ne o di invitare un utente ad au­ten­ti­fi­car­si. Qui di seguito i pro­to­col­li nei dettagli:

• Au­then­ti­ca­tion request protocol: l‘Au­then­ti­ca­tion request protocol definisce con messaggi di tipo <Au­thn­Re­que­st> la necessità di in­ter­ro­ga­re un utente scelto con un’as­ser­zio­ne con Au­then­ti­ca­tion statement. Sulla base di questo pro­to­col­lo le in­for­ma­zio­ni passano dalla banca dati al service provider, dove viene uti­liz­za­to il diffuso SAML 2.0 Web Browser SSO Profile (più in­for­ma­zio­ni nel paragrafo “Profili”).
• Assertion query and Request protocol: l’Assertion query and Request protocol contenuto nel framework è uti­liz­za­to per richieste che possono essere ri­chia­ma­te in generale con le esistenti as­ser­zio­ni SAML. La richiesta da parte dell’as­ser­zio­ne può avvenire sulla base di diversi parametri come ad esempio il tipo di di­chia­ra­zio­ne ricevuta.
• Single logout protocol: il Single logout protocol definisce quelle richieste che provocano la di­scon­nes­sio­ne 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 re­so­lu­tion protocol: se i messaggi SAML devono essere tra­spor­ta­ti tramite un canale sicuro o in una di­men­sio­ne a risparmio risorse, si utilizza l’Artifact re­so­lu­tion protocol. Esso permette l’invio di referenze tramite as­ser­zio­ni, che possono essere definite anche artefatti, net­ta­men­te più piccole in confronto ai messaggi veri e propri. Il pro­to­col­lo permette inoltre di annullare queste referenze per ricevere il messaggio originale.
• Name iden­ti­fier ma­na­ge­ment protocol: questo pro­to­col­lo mette a di­spo­si­zio­ne i mezzi per mo­di­fi­ca­re 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 iden­ti­fier ma­na­ge­ment protocol è possibile eliminare i col­le­ga­men­ti tra il service provider e l’identity provider creati per l’au­ten­ti­ca­zio­ne dell’identità ori­gi­na­ria dell’utente.
• Name iden­ti­fier mapping protocol: il Name iden­ti­fier mapping protocol definisce i messaggi di domanda/risposta per la co­mu­ni­ca­zio­ne tra due service provider. Sulla base di questo tipo di messaggi un’ap­pli­ca­zio­ne può ri­chie­de­re all’identity provider un iden­ti­fi­ca­to­re a favore di un utente per poter accedere ad un’altra ap­pli­ca­zio­ne.

Le mapping (cioè le tra­sfor­ma­zio­ni) dello scambio di messaggi SAML in standard messaging o pro­to­col­li di co­mu­ni­ca­zio­ne vengono definiti binding di pro­to­col­lo SAML o sem­pli­ce­men­te binding. Il binding SOAP ad esempio definisce come avviene lo scambio di messaggi SAML in un ambiente SOAP, mentre l’HTTP redirect binding sta­bi­li­sce come possono essere inviati i messaggi di pro­to­col­lo SAML at­tra­ver­so il processo di tra­smis­sio­ne http. Altri binding pre­de­fi­ni­ti nello standard SAML 2.0 sono:

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

Come standard generale, SAML è ca­rat­te­riz­za­to dalla sua fles­si­bi­li­tà che dimostra che il framework è adatto per numerosi scenari d’utilizzo. Affinché de­ter­mi­na­te ap­pli­ca­zio­ni sup­por­ti­no l’utilizzo di SAML, bisogna limitare in parte questa fles­si­bi­li­tà: per farlo entrano in azione i co­sid­det­ti profili, che riu­ni­sco­no as­ser­zio­ni, pro­to­col­li e binding per specifici casi d’ap­pli­ca­zio­ne. Uno dei profili più usati è il suddetto SAML 2.0 Web Browser SSO Profile, specifico per la rea­liz­za­zio­ne di un’au­ten­ti­ca­zio­ne SSO SAML. Esso contiene tutte le com­po­nen­ti decisive per definire la co­mu­ni­ca­zio­ne delle garanzie di au­ten­ti­ca­zio­ne tra identity e service provider ne­ces­sa­ria 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 Iden­ti­fier Ma­na­ge­ment Profile
• Artifact Re­so­lu­tion Profile
• Assertion Query/Request Profile
• Name Iden­ti­fier Mapping Profile

Più di 24 aziende ed or­ga­niz­za­zio­ni si sono adoperate per l’ideazione e lo sviluppo di SAML 2.0, prima del suo lancio nel marzo 2005 come versione ufficiale suc­ces­si­va a SAML 1.0 e 1.1. Oltre ai numerosi mi­glio­ra­men­ti alle fun­zio­na­li­tà pre­e­si­sten­ti, il framework conteneva anche fun­zio­na­li­tà com­ple­ta­men­te nuove, come quelle tratte dal Liberty Alliance Identity Fe­de­ra­tion Framework (ID-FF) 1.2 e Shib­bo­leth-Ar­chi­tek­tur svi­lup­pa­to da Internet2.

Di seguito ri­por­tia­mo gli ade­gua­men­ti più im­por­tan­ti che il framework ha subito nei due “grandi” release (“major release”):

• Can­cel­la­zio­ne di alcuni elementi datati come <Au­tho­ri­ty­Bin­ding> o <Re­spond­With> e vecchi formati di iden­ti­fi­ca­zio­ne
• Im­ple­men­ta­zio­ne della firma XML e la cifratura XML (secondo lo standard W3C)
• So­sti­tu­zio­ne dell’As­ser­tio­nID-attribut con un generico attributo ID XML
• In­tro­du­zio­ne del ma­na­ge­ment di sessione per sup­por­ta­re le di­scon­nes­sio­ni au­to­ma­ti­che di tutte le ap­pli­ca­zio­ni (ad esempio in caso di lunga assenza)
• Ade­gua­men­to dei metadati, per fa­ci­li­ta­re l’utilizzo di SAML (tra cui anche le istanze coinvolte come identity provider e service provider)
• Im­ple­men­ta­zio­ne di mec­ca­ni­smi che per­met­to­no ai provider di co­mu­ni­ca­re le linee guida e le im­po­sta­zio­ni sulla privacy
• Migliore supporto dei di­spo­si­ti­vi mobili
• Im­ple­men­ta­zio­ne dei pro­to­col­li già elencati prima (in SAML 1.0 e 1.1 esi­ste­va­no solo l’Assertion Query e il Request Protocol)
• Ot­ti­miz­za­zio­ne del profilo (ad es. ac­cor­pa­men­to del profilo “Browser/Artifact” e “Browser/Post” in “SAML 2.0 Web Browser SSO Profile”)

Trovate una lista det­ta­glia­ta delle dif­fe­ren­ze 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 de­fi­ni­zio­ne: con il relativo know-how è possibile rea­liz­za­re un’istanza centrale di au­ten­ti­ca­zio­ne sulla base di linguaggi di­chia­ra­ti­vi, ca­rat­te­riz­za­ta dall’ef­fi­cien­za e un alto standard di sicurezza. La sicurezza in par­ti­co­la­re è garantita dal fatto che le singole ap­pli­ca­zio­ni non devono me­mo­riz­za­re o sin­cro­niz­za­re alcun dato utente, il che riduce con­si­de­re­vol­men­te il numero di possibili perdite di sicurezza. L’obiettivo prin­ci­pa­le del framework è quello di associare questo alto livello di sicurezza con la migliore espe­rien­za utente possibile, motivo per cui supporta anche il Single Sign-On grazie ai relativi pro­to­col­li e formati di messaggio.

Il processo SSO di SAML, che permette l’utilizzo di diverse ap­pli­ca­zio­ni sulla base di un’unica re­gi­stra­zio­ne, non è richiesto solo all’interno dei processi di ap­pli­ca­zio­ne interni delle aziende: il pratico accesso per re­gi­stra­zio­ne unica è oggi uti­liz­za­to da diversi servizi web, in par­ti­co­la­re per l’online banking e le app mobili. Spesso l’utente neanche si accorge che uti­liz­zan­do tali servizi sta in realtà uti­liz­zan­do più ap­pli­ca­zio­ni 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 tec­no­lo­gia SAML, tuttavia, gli sembra di usare un unico programma.