Differences

This shows you the differences between two versions of the page.

--- cn:ccr:aai:doc:loa [2016/04/14 08:09] – enrico@infn.it
+++ cn:ccr:aai:doc:loa [2021/02/23 08:04] (current) – enrico@infn.it
@@ Line 1: / Line 1: @@
+====== Level of Assurance ======
+Il "livello di garanzia" (LoA) di una Identità Digitale a cui INFN-AAI fa riferimento, è definito all'interno del //framework// descritto in un paio di documenti del **NIST**[1] e di **ITU-T ISO/IEC**[2]
+Anche se tali documenti descrivono appunto l'intero //framework// -- che tiene conto non solo della **garanzia** di una Identità Digitale, ma anche del livello di sicurezza dell'intero sistema di transazioni che concorrono al corretto utilizzo di un sistema informatizzato -- qui ci limiteremo a descrivere la parte relativa al **LoA** della Identità Digitale.
+===== INFN-AAI LoA VS SPID =====
+A differenza di quanto descritto nei due documenti di riferimento, il Sistema Pubblico delle identità Digitali promosso dal Governo Italiano e realizzato (attraverso tre partner commerciali) dall'AgID, usa una numerazione differente che non dà spazio al livello più basso.
+Essendo l'INFN una Pubblica Amministrazione che dovrà conformarsi ai dettami dell'AgID e di SPID[3], ma dovendo comunque permettere accessi a risorse informatiche anche a Visitatori o utenti esterni, INFN-AAI, in accordo con il Servizio Sistema Informativo, ha ripreso le definizioni dei LoA di ISO/IEC-29115[4] aggiungendo ai livelli previsti da SPID il livello a garanzia più bassa, ma traslando numericamente tutti i livelli in modo da avere una numerazione compatibile con quella definita da SPID.
+===== INFN-AAI LoA  =====
+Per esigenze legate alla fruizione di servizi web INFN da parte di utenti esterni (ad esempio accesso ad agenda.infn.it) è diventato necessario distinguere le Identità Digitali presenti in GODiVA in base al tipo di “user vetting”, ed assegnare ad ogni Identità Digitale un definito LoA (Level of Assurance).
+Per non andare in completo conflitto con quanto previsto da SPID che prevede i livelli
+  * livello 1 (corrispondente al LoA2 dell’ISO-IEC 29115):
+  * livello 2 (corrispondente al LoA3 dell’ISO-IEC 29115);
+  * livello 3 (corrispondente al LoA4 dell’ISO-IEC 29115):
+abbiamo deciso di definire i nostri livelli in modo analogo a quanto definito dallo standard ISO/IEC-29115 in quanto ci saranno in GODiVA, Identità Digitali che devono essere assegnate al LoA1 dell’ISO-IEC 29115 (Little or no confidence in the asserted identity)
+Questo significa che:
+  -LoA definiti per INFN-AAI saranno:
+    -LoA1 —> LoA1 dell’ISO-IEC 29115
+    -LoA2 —> LoA2 dell’ISO-IEC 29115 —> livello 1 SPID
+    -LoA3 —> LoA3 dell’ISO-IEC 29115 —> livello 2 SPID
+    -LoA4 —> LoA4 dell’ISO-IEC 29115 —> livello 3 SPID
+  -tutti gli SP che adesso accettano semplicemente l’autenticazione (senza effettuare alcun controllo autorizzativo) per fornire accesso agli utenti, **DOVRANNO** essere modificati e dovranno controllare *ALMENO* il LoA (a meno che, come nel caso di agenda.infn.it, non debbano permettere, per disegno, l’accesso a utenti auto-registrati, della cui identità nessuno può essere sicuro).
+==== INFN-AAI LoA1 (LoA1 dell’ISO-IEC 29115) ====
+Alcuni servizi web come [[http://agenda.infn.it|Agenda InDiCO]] o i servizi web per il //recruiting// devono essere fruibili anche da utenti non autenticati, ma la necessità di legare la registrazione ad una conferenza gestita via Agenda InDiCo alla possibilità di accedere alla rete wireless come Visitatore via TRIP nel sito ospitante la conferenza o la necessità di poter riutilizzare documentazione già inviata da parte di un utente esterno che vuole sottoscrivere domande per più posizioni, rende necessario permettere l'accesso con autenticazione anche a questi servizi web ed anche per utenti **esterni** all'INFN.
+Per questo motivo è necessario prevedere un tipo di registrazione che permetta a chiunque di registrare la propria Identità Digitale in GODiVA, anche se su tale Identità Digitale non può essere definito nessun livello di certezza (il controllo sull'indirizzo e-mail indicato in fase di registrazione non permette di fare alcuna affermazione sulla veridicità di quanto il registrante dichiara, specialmente si vengono usati indirizzi del tipo gmail.com o simili).
+Tale auto-registrazione durante la quale l'utente:
+  - Inserisce i propri dati anagrafici e l'indirizzo e-mai
+  - Certifica il fatto di avere accesso alla casella e-mail indicata in fase di registrazione rispondendo ad un e-mail che il sistema gli invia
+produce una Identità Digitale con valore LoA1, corrispondente al livello LoA1 descritto in ISO/IEC 29115[2] (Little or no confidence in the asserted identity).
+<del>A tale Identità Digitale in GODiVA corrisponderà un account in INFN-AAI con uid=NCxxxxxx (N:==iniziale del Nome; C:==iniziale del Cognome; xxxxxx:==numero intero di sei cifre compreso il segno, tra -99999 e 999999) per il quale l'utente potrà impostare la propria password usando l'apposito servizio web di INFN-AAI che invia un codice di sicurezza all'indirizzo e-mail registrato per tale Identità Digitale ed indicato dall'utente nel form di reset-password.</del>
+Per tale Identità Digitale non viene definita una vera e propria username in quanto il nostro IdP permette l'utilizzo dell'indirizzo e-mail registrato al posto della username.
+Dal punto di vista della "certezza" dell'Identità Digitale, tutto quello che si può dire è che esiste una corrispondenza tra una casella di posta elettronica e tale Identità Digitale.
+In altre parole, anche se non c'è alcuna certezza della vera identità di un utente LoA1, si è abbastanza sicuri del fatto che ad ogni accesso autenticato fatto da tale utente, corrisponda la stessa persona (non vi è certezza di questo in quanto non sono noti i criteri con cui tale utente protegge l'accesso a tale casella di posta elettronica) ed è per questo motivo che gli utenti LoA1 possono accedere **soltanto** ai servizi web **pubblici**, come quelli descritti all'inizio del paragrafo.
+==== INFN-AAI LoA2 (LoA2 dell’ISO-IEC 29115) ====
+Il livello LoA2 dell’ISO-IEC 29115 richiede che ci sia una qualche certezza della identità e che quindi venga in qualche modo effettuato un controllo sulla corrispondenza tra l'Identità Digitale e la persona fisica ed è compatibile con credenziali del tipo username/password.
+A questo livello, la prova dell'identità può essere effettuata anche attraverso informazioni provenienti da fonti autoritative.
+Per INFN-AAI le fonti autoritarie di verifica di identità sono di due tipologie:
+  - Interne all'INFN
+    * tutti gli uffici che gestiscono le prese di servizio, le associazioni e le ospitalità (tipicamente gli uffici del personale e di direzione dell'INFN) oltre ai servizi calcolo e reti delle varie strutture. In altre parole, l'Identità Digitale definita in uno qualunque di questi uffici o servizi corrisponde, per INFN-AAI, all'identità della persona a cui si riferisce. La verifica di tale corrispondenza, fatta appunto in ognuno dei suddetti uffici o servizi, può avvenire sia "de visu" che remotamente, verificando la corrispondenza tra quanto riportato su un documento di riconoscimento con foto.
+  - Esterne o Federate
+    * L'INFN, attraverso il gestore di Identità Digitali di INFN-AAI, aderisce alla federazione GARR-IDEM e, attraverso questa, alle inter-federazioni. L'accesso ad un sevizio web opportunamente configurato (SP SAML in federazione IDEM e quindi in eduGAIN) permetterebbe all'utente della federazione di essere autenticato dalla propria istituzione. In virtù degli accordi di federazione, l'istituzione di appartenenza garantisce la corrispondenza tra l'Identità Digitale del proprio utente e l'utente stesso e quindi anche in questo caso possiamo considerare valida la prova dell'identità, effettuata attraverso una fonte autoritativa. I servizi web federati (i ServiceProvider SAML registrati nella federazione IDEM) dovranno quindi accettare autenticazioni esterne via SAML ed assegnare all'utente esterno un profilo locale legato all'Identità Federata ovvero una UID, sempre legata alla Identità Federata, che sia abilitata **soltanto** ad accedere al servizio web federato.
+In altre parole, gli account di Dipendenti, Associati ed Ospiti istituzionali INFN devono considerarsi LoA2, insieme a quelli derivanti da Identità Federate **limitatamente per i servizi web federati**
+Nel documento in cui si descrivono i vari  [[cn:ccr:aai:doc:ruoli-godiva|Ruoli assegnati alle Identità Digitali in GODiVA]] viene evidenziato che oltre agli Ospiti istituzionali, nelle varie strutture INFN, sono attivi anche account per altri tipi di Ospiti, ossia tutto il personale che, in base ad accordi tra enti e/o collaborazioni scientifiche, hanno diritto ad accedere alle risorse informatiche dell'INFN.
+Anche tali account devono essere considerati LoA2, FIXME ma -- non essendoci in generale un flusso informatizzato che garantisce l'identità personale di tali utenti -- è necessario che ogni struttura si faccia garante della loro identità personale, conservando copia del documento di riconoscimento. FIXME :!: Stiamo re-introducendo il decreto Pisanu ?!? :!:
+==== INFN-AAI LoA3 (LoA3 dell’ISO-IEC 29115) ====
+==== INFN-AAI LoA4 (LoA4 dell’ISO-IEC 29115) ====
+===== Riferimenti =====
+----
+[1] [[https://doi.org/10.6028/NIST.SP.800-63-3|NIST Special Publication 800-63-2 Electronic Authentication Guideline]]
+[2] [[https://www.itu.int/rec/T-REC-X.1254-201209-I/en|Text for ITU-T Recommendation X.1254]] **-- Information Technology -- Security techniques -- Entity authentication assurance framework**
+[3] [[http://www.agid.gov.it/sites/default/files/circolari/spid-modalita_attuative_v1.pdf|SPID Modalità Attuative]]
+[4] [[https://www.iso.org/standard/45138.html|ISO/IEC DIS 29115]]