Il Security Assertion Markup Language (SAML) è uno standard aperto che consente la condivisione delle credenziali di sicurezza da più computer in una rete. Descrive un framework che consente a un computer di eseguire alcune funzioni di sicurezza per conto di uno o più altri computer:

  • Autenticazione: determinare che gli utenti sono chi affermano di essere
  • Autorizzazione: determinare se gli utenti hanno il diritto di accedere a determinati sistemi o contenuti

SAML si riferisce alla variante del linguaggio XML utilizzata per codificare tutte queste informazioni, ma il termine può anche coprire vari messaggi di protocollo e profili che fanno parte dello standard. SAML 2.0 è stato introdotto nel 2005 e rimane la versione attuale dello standard, mentre la versione precedente 1.1 è ora in gran parte inutilizzata. SAMLDiffs offre un ottimo riassunto sulla differenza tra le due versioni.

A cosa serve SAML?

SAML è un modo per implementare il Single Sign-On (SSO), che infatti è di gran lunga il caso d’uso più comune di SAML. SSO, come suggerisce il nome, consente a un utente di accedere una volta a più servizi come siti Web, app cloud o SaaS, condivisioni di file e così via. In uno scenario SSO, tutti questi servizi esternalizzano le proprie funzionalità di autenticazione e autorizzazione a un unico sistema che invia a tali servizi le informazioni sull’identità dell’utente. I documenti scritti in SAML sono un modo per trasmettere le informazioni.

Che cos’è un provider SAML?

Nel gergo SAML, un provider è un’entità, generalmente un server o un altro computer, all’interno di un sistema che aiuta l’utente ad accedere ai servizi che desidera. I sistemi che forniscono servizi SAML sono genericamente chiamati fornitori di servizi; il tipo più importante di provider di servizi è un provider di identità.

Abbiamo accennato a ciò che fa un provider di identità: è l’entità all’interno del sistema che si assicura che l’utente sia veramente chi afferma di essere e, così facendo, fornisce l’autenticazione. Può anche determinare a quali servizi, se presenti, quell’utente è autorizzato ad accedere attraverso varie entità nel sistema.

SAML è uno standard aperto, quindi chiunque può creare un’implementazione commerciale o open source che fornisca servizi di autenticazione in linea con esso. In generale, questa funzionalità è incorporata in un prodotto di gestione delle identità e degli accessi (IAM), sebbene tale funzionalità IAM possa a sua volta essere inclusa in un sistema o una piattaforma di infrastruttura più onnicomprensivi. I fornitori attuali includono:

  • Active Directory Federation Services (ADFS)
  • Auth0
  • Azure AD (Microsoft Azure Active Directory)
  • NetIQ Access Manager
  • Okta
  • OneLogin
  • OpenAM
  • Ping Identity
  • Salesforce
  • Shibboleth
  • SimpleSAMLphp

Che cos’è un’asserzione SAML?

Un’asserzione SAML è il documento XML mediante il quale tutte le informazioni di cui abbiamo discusso vengono trasmesse da un computer all’altro. Una volta che un provider di identità ha determinato che siete chi dite di essere e avete quindi il diritto di accedere al contenuto o ai servizi che vi interessano, invia un’asserzione SAML al server che può effettivamente fornirvi quei servizi. Un’asserzione SAML può essere crittografata per una maggiore sicurezza. Per ulteriori informazioni su tutti questi termini, consultate il glossario ufficiale di OASIS.

Come funziona l’autenticazione SAML?

Tutto questo potrebbe sembrare un po’ astratto, quindi ecco un esempio più pratico di come si svolgerebbe una transazione di autenticazione SAML. Un’illustrazione grafica è fornita nella figura qui sotto. Lo user agent nella maggior parte dei casi è un browser web.

security-assertion-markup-language-saml-explainer-100738529-large

Immaginate di essere l’utente in un ambiente con single sign-on e state cercando di accedere a qualche risorsa su un server. La sequenza degli eventi è la seguente:

  1. Si tenta di accedere alla risorsa sul server, che nella terminologia SAML è un fornitore di servizi. Il fornitore di servizi verifica se siete già autenticati all’interno del sistema. Se lo siete, andate al passaggio7; in caso contrario, il fornitore di servizi avvia il processo di autenticazione.
  2. Il provider di servizi determina il provider di identità appropriato per voi e vi reindirizza a quel provider, in questo caso il servizio Single Sign-On.
  3. Il vostro browser invia una richiesta di autenticazione al servizio SSO; il servizio vi identifica.
  4. Il servizio SSO restituisce un documento XHTML, che include le informazioni di autenticazione necessarie al provider di servizi in un parametro SAMLResponse.
  5. Il parametro SAMLResponse viene passato al provider di servizi.
  6. Il fornitore di servizi elabora questa risposta e crea un contesto di sicurezza per voi, vi fa accedere e vi dice dove si trova la risorsa richiesta.
  7. Con queste informazioni, ora potete richiedere nuovamente la risorsa che vi interessa.

Se volete dare un’occhiata più da vicino alla natura dei messaggi che vengono passati avanti e indietro in una transazione SAML, controllate questi esempi di OneLogin. È possibile esaminare il codice XML completo per i tipi di asserzioni passati dal provider di identità al provider di servizi nello scenario descritto sopra.

Implementazione di SAML

Noterete che quanto detto finora non spiega l’intero processo. Ad esempio, non c’è spiegazione di come SAML sappia qual è il provider di identità appropriato o come il provider di identità determini che siete chi dite di essere. Queste mancanze però non dipendono da noi: lo standard SAML, infatti, non definisce il modo in cui accadono questi passaggi, lasciando all’IT un ampio margine di manovra su come impostare le cose.

Come notato sopra, ad esempio, più tecnologie possono essere utilizzate per l’effettiva parte di autenticazione e le tecnologie scelte forniranno i dettagli di come effettivamente implementerete SAML nel vostro ambiente. Ma indipendentemente dalla scelta che farete, le asserzioni SAML trasporteranno i dati di autenticazione e autorizzazione da un provider all’altro.

Vantaggi dell’autenticazione SAML

Il vantaggio più importante di SAML come base per una soluzione SSO è che si tratta di uno standard aperto. Come abbiamo visto, ciò significa che può essere implementato da un’ampia varietà di fornitori IAM e integrato in sistemi onnicomprensivi come Salesforce. Significa anche che fornitori diversi possono comunicare tra loro purché aderiscano allo standard SAML. Poiché SAML è un “dialetto” XML, è anche molto flessibile. Tutti i tipi di dati possono essere trasmessi in un documento SAML, purché possa essere reso in XML.

SAML e OAuth: qual è la differenza?

OAuth è uno standard un po’ più recente di SAML, sviluppato congiuntamente da Google e Twitter a partire dal 2006. È stato sviluppato in parte per compensare le carenze di SAML sulle piattaforme mobili ed è basato su JSON anziché su XML. A parte il supporto mobile tutt’altro che stellare di SAML, qual è la differenza tra i due?

Come abbiamo visto, lo standard SAML definisce come i provider possono offrire servizi sia di autenticazione che di autorizzazione. OAuth, invece, si occupa solo di autorizzazione. OpenID Connect è uno standard ancora più recente, sviluppato nel 2014, che fornisce servizi di autenticazione ed è sovrapposto a OAuth.

Un’altra importante differenza tra SAML e OAuth sono i loro casi d’uso. Sebbene in teoria SAML sia stato progettato per l’uso su Internet aperto, in pratica è più spesso distribuito all’interno di reti aziendali per il Single Sign-On. OAuth, al contrario, è stato progettato da Google e Twitter per la scalabilità di Internet.

Conoscere meglio SAML

Ecco alcuni tutorial SAML approfonditi e perfetti per approfondire l’argomento: