Cosa è un’identità digitale ?

L’Identità Digitale è l’insieme dei dati, delle informazioni o attributi che si riferiscono ad una specifica persona all’interno di un determinato sistema informatico e ne costituiscono la sua rappresentazione virtuale utilizzabile durante le interazioni digitali con altre persone o sistemi informatici.

SPID: a cosa serve e come è fatto

SPID, il Sistema Pubblico di Identità Digitale, è la soluzione che permette di accedere a tutti i servizi online della Pubblica Amministrazione con un’unica Identità Digitale utilizzabile da computer, tablet e smartphone.

Il sistema definisce tre livelli di sicurezza, corrispondenti ad altrettanti livelli specificati nella norma internazionale ISO-IEC 29115:

  • Primo livello garantisce con un buon grado di affidabilità l’identità accertata nel corso dell’attività di autenticazione. A tale livello è associato un rischio moderato e compatibile con l’impiego di un sistema di autenticazione a singolo fattore (cioè soltanto digitando UserID e password). Corrisponde al Level of Assurance LoA2 dello standard ISO/IEC DIS 29115;
  • Secondo livello garantisce con un alto grado di affidabilità l’identità accertata nel corso dell’attività di autenticazione. A tale livello è associato un rischio ragguardevole e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori, non necessariamente basato su certificati digitali (password e OTP associati alla digitazione di una UserID). Corrisponde al Level of Assurance LoA3 dello standard ISO/IEC DIS 29115;
  • Terzo livello garantisce con un altissimo grado di affidabilità l’identità accertata nel corso dell’attività di autenticazione. A tale livello è associato un rischio altissimo e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori basato su certificati digitali e criteri di custodia delle chiavi private su dispositivi che soddisfano i requisiti dell’Allegato 3 della Direttiva 1999/93/CE. Corrisponde al Level of Assurance LoA4 dello standard ISO/IEC DIS 29115.

Il sistema, basato sul framework SAML (Security Assertion Markup Language), è composto da 3 entità:

  • Gestore delle identità (Identity Provider) che si occupa della gestione degli utenti e della procedura di autenticazione;
  • Fornitore di servizi (Service Provider) che, dopo aver richiesto l’autenticazione dell’utente all’Identity Provider, ne gestisce l’autorizzazione sulla base degli attributi restituiti dal Gestore dell’identità, ed eroga il servizio richiesto (accesso al portale e/o ai servizi esposti);
  • Gestore di attributi qualificati (Attribute Authority o AA) che fornisce attributi qualificati sulla base dell’utente autenticato.

Ciascuna di queste entità è descritta da un file di metadati, che ne riporta il certificato X509, gli endpoint e le altre informazioni necessarie alla comunicazione con le altre entità.

La trasmissione dei messaggi tra le entità coinvolte, può avvenire secondo le due modalità previste dallo standard SAML: HTTP-Redirect e HTTP-POST.

Nel caso di HTTP-Redirect, la richiesta viene veicolata con le seguenti modalità:

  1. L’entità mittente invia allo User Agent (tipicamente il browser dell’utente) un messaggio HTTP di redirezione, cioè avente uno status code con valore 302 («Found») o 303 («See Other»).
  2. Il Location Header del messaggio HTTP contiene l’URI di destinazione del servizio esposto dall’entità destinataria.
  3. Il browser dell’utente elabora quindi tale messaggio HTTP-Redirect indirizzando una richiesta HTTP con metodo GET al servizio dell’entità destinataria sotto forma di URL con tutti i sopraindicati parametri contenuti nella query string.

Nel caso di HTTP-POST, l’entità mittente invia allo User Agent un messaggio HTTP con status code avente valore 200 («OK»):

  1. Il messaggio HTTP contiene un form HTML all’interno del quale è trasportato un costrutto SAML codificato come valore di un hidden form control di nome SAMLRequest oppure SAMLResponse. Rispetto al binding HTTP-Redirect, l’utilizzo di un form HTML permette di superare i limiti di dimensione della query string. Pertanto, l’intero messaggio SAML in formato XML può essere firmato in accordo alla specifica XML Digital Signature. Il risultato a valle della firma è quindi codificato in formato Base64.
  2. Il form HTML contiene un secondo hidden form control di nome RelayState che contiene il corrispondente valore del Relay State, cioè della risorsa originariamente richiesta dall’utente e alla quale dovrà essere trasferito il controllo al termine della fase di autenticazione
  3. Il form HTML è corredato da uno script che lo rende auto-postante all’indirizzo indicato nell’attributo action
  4. Il browser dell’utente elabora quindi la risposta HTTP e invia una richiesta HTTP POST verso il servizio dell’entità destinataria.

Il meccanismo alla base: SSO (Single Sign-On)

Il meccanismo di autenticazione ha inizio con la selezione, da parte dell’utente, del Gestore delle Identità con cui intende effettuare l’accesso (Aruba, InfoCert, IntesaID, PosteID, SielteID e TIMid per citare i più conosciuti); tale selezione avviene all’interno del sito del Fornitore di Servizi mediante un bottone ufficiale «Entra con SPID». Il Fornitore di Servizi prepara di conseguenza una <AuthnRequest> da inoltrarsi al Gestore delle Identità, dove l’utente viene reindirizzato per effettuare l’autenticazione. Eseguita l’autenticazione, l’utente torna presso il sito del Fornitore di Servizi con un’asserzione firmata dal Gestore delle Identity contenente gli attributi richiesti (ad es. nome, cognome, codice fiscale, email) che il Fornitore di Servizi può usare per autorizzare l’utente in base alle proprie policy ed erogare il servizio richiesto. Di seguito un grafico riepilogativo del flusso di comunicazione tra le parti coinvolte:

Il messaggio AuthnRequest è inviato dal Service Provider, per tramite dello User Agent, al SingleSignOnService dell’Identity Provider ed ha la funzione di avviare il flusso di autenticazione. Può essere inoltrato da un Service Provider all’Identity Provider usando il binding HTTP-Redirect o il binding HTTP-POST. Il messaggio deve essere conforme allo standard SAML v2.0.
Il messaggio <Response> (la risposta ricevuta) viene inviata dall’Identity Provider al Service Provider e può essere trasmessa solo tramite il binding HTTP-POST.

Obblighi di legge

Registro

Il Registro SPID è il repository di tutte le informazioni relative alla entità aderenti a SPID e costituisce l’evidenza del cosiddetto circle of trust in esso stabilito. La relazione di fiducia su cui si basa la federazione stabilita in SPID si realizza per il tramite dell’intermediazione dell’Agenzia, terza parte garante, attraverso il processo di accreditamento dei gestori dell’identità digitale, dei gestori degli attributi qualificati e dei fornitori di servizi. L’adesione a SPID costituisce l’instaurazione di una relazione di fiducia con tutti i soggetti già aderenti, accreditati dall’Agenzia, sulla base della condivisione dei livelli standard di sicurezza dichiarati e garantiti da SPID. L’adesione al patto di fiducia tra le entità aderenti (gestori dell’identità digitale, gestori degli attributi qualificati e fornitori di servizi) si evidenzia nella presenza di tali entità nel Registro SPID gestito dall’Agenzia. Il federation registry contiene la lista delle entità che hanno superato il processo di accreditamento e quindi facenti parte della federazione SPID.

Log

Ai fini della tracciatura l’Identity Provider dovrà mantenere un Registro o Log delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la tripla composta dell’identificativo dell’identità digitale (spidCode) interessata dalla transazione, dalla <AuthnRequest> e della relativa <Response>. Il comma 2 dell’articolo 13 del DPCM obbliga i fornitori di servizi (Service Provider) alla conservazione per ventiquattro mesi delle informazioni necessarie a imputare alle singole identità digitali le operazioni effettuate sui propri sistemi. A tal fine un Service provider dovrà mantenere un Registro delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la coppia formata dalla <AuthnRequest> e della relativa <Response>.

La nostra esperienza

PosteID è il gestore di identità che abbiamo scelto e provato trovandolo versatile ed immediato sia per quanto riguarda la registrazione iniziale che per l’utilizzo quotidiano.

La creazione di un identità digitale SPID tramite il gestore di identità PosteID è immediato ed è riassunto nella seguente figura:

La richiesta di adesione, dal sito delle Poste, si effettua in pochi minuti e ti permette di scegliere tra diversi metodi di riconoscimento. Secondo noi il più immediato è il riconoscimento di persona (tra l’altro gratuito) recandosi in un ufficio postale.

Una volta perfezionata la richiesta, completando il riconoscimento, basterà attendere pochi minuti per ricevere via email le istruzioni per procedere al semplice setup iniziale dell’app.

 

 

PosteID gestisce l’autenticazione su tutti e 3 i possibili livelli di sicurezza SPID richiesti dai service provider:

 

Di seguito, il grafico riepilogativo per lo specifico flusso di richiesta, riconoscimento e rilascio credenziali adottato da PosteID:

 

Noi alla IES Solutions abbiamo sempre mantenuto alti standard per quanto riguarda la sicurezza anche dal punto di vista dell’autenticazione/autorizzazione sui nostri prodotti, utilizzando già da anni meccanismi di SSO e token per l’autenticazione/autorizzazione inter-piattaforma fornendo, nello specifico, anche il supporto di autenticazione tramite SPID.