Sistema Federato Interregionale di Autenticazione

PROGETTO ICARTask inf-3Sitema Federato interregionale di Autenticazione
Michele Manzotti
Fausto Marcantoni
Barbara Re
Università di Camerino

2
Chi siamo
Prof. Fausto Marcantoni
fausto.marcantoni@unicam.it
Corso: Reti di Elaboratori/Lab. Reti di Elaboratori
– Laurea Informatica 3° Anno
Istruttore CCNA – CISCO
Certificazione OPST (OSSTMM PROFESSIONAL SECURITY TESTER)
OSSTMM - Open Source Security Testing Methodology Manual
Dott. Michele Manzotti
michele.manzotti@studenti-unicam.it
Certificato CCNA – CCNA – Security CISCO
Certificazione OPST (OSSTMM PROFESSIONAL SECURITY TESTER)
OSSTMM - Open Source Security Testing Methodology Manual

3
Agenda – Prima parte
Identità digitale ed identità digitale federata
Concetto di riconoscimento dell’identità di un soggetto
Concetto di autorizzazione dell’utente
Concetto di condivisione dell’identità digitale
Concetto di profilo e qualifiche
Differenti profili di federazione
Dominio fruitore, erogatore, certificatore, profilazione (IDP – SP)
Tecnologie abilitanti e standard di riferimento secondo il modello ICAR
Modello di coopearzione: relazioni ed interazioni intra e inter-dominio
Casi d’uso del sistema: aggiornamento del profilo, registrazione e accesso al servizio
Architettura ICAR
Sviluppi futuri

4
Agenda – Seconda parte
Scenari Applicativi in fase di test
Installazione di un IdP
Installazione di un Sp
Installare l’infrastruttura ICAR
Integrazione dei sistemi
Integrazione IdP e Sp
Integrazione con l’infrastruttura ICAR
Sviluppi Futuri
Autenticazione tramite SmartCard
Autenticazione tramite Google

5
Identità digitale ed identità federata

6

7
Identità Digitale
L'identità digitale è l'insieme delle informazioni e delle risorse concesse da un sistema informatico ad un particolare utilizzatore del suddetto. (Wikipedia).
L'identità digitale può essere definita come l’esclusiva percezione della
propria vita, che però è sempre collegata ad un corpo mediante il quale la persona si relaziona con la società.
Per identità digitale si intende un insieme di informazioni che consentono di distinguere una entità da un'altra in modo univoco: in una identità digitale, questo insieme di informazioni è espresso in forma.

8
Caratteristiche dell’identità
La rappresentazione dell’identità digitale deve essere tanto più completa quanto è complessa la transazione in cui è coinvolta.
Infatti il grado di affidabilità e le quantità di informazioni richiesti possono variare in modo molto significativo a seconda del tipo di transazione.
Un’identità digitale è articolata in due parti:
Chi uno è (identità)
Le credenziali che ognuno possiede (gli attributi di tale identità)

9
Caratteristiche dell’identità
Le credenziali possono essere numericamente e qualitativamente molto variegate e hanno differenti utilizzi.
L’identità digitale completa è abbastanza complessa e ha implicazioni sia legali che tecniche. Comunque, l’identità digitale più semplice consiste in un ID (o username) e una parola di identificazione segreta(o password). In questo caso lo username è l’identità, mentre la password è chiamata credenziale di autenticazione.
Ma l’ identità digitale può essere complessa come una vera e propria identità umana.

10
Identity Management
Si intende un insieme di processi (decisionali, organizzativi, procedurali, informatizzati) e una infrastruttura di supporto (per memorizzare/conservare, trasmettere,
proteggere) che permette di:
CREARE
GESTIRE/MODIFICARE
USARE
ELIMINARE
le identità digitali parziali rispettando la legge (cioè i diritti delle
persone, in particolare il diritto alla privacy e il diritto all’onore).

11
Caratteristiche dell’Identity Management
Autenticazione: non solo tramite l’uso di username e password, ma attraverso l’uso di certificati
Confidenzialità: capacità del sistema di impedire che una terza parte intercetti e sfrutti dati che si stanno ricevendo o trasmettendo
Autorizzazione: restringere l’accesso ad informazioni private o consentire l’accesso a servizi specifici
Integrità dei dati: per essere sicuri che nessuno intercetti i dati che si stanno scambiando, può essere importante sapere che nessuno li abbia alterati durante la trasmissione
Prova della fonte: è possibile effettuare specifiche transazioni in cui i dati inviati con la firma digitale sono codificati in modo da dimostrare che i dati sono effettivamente stati inviati
Non repudio: fornire la prova incontestabile di una avvenuta spedizione o di una avvenuta ricezione di dati in rete

12
Identità digitale parziale

13
Insieme di proprietà (attributi) di una persona che sono tecnicamente, immediatamente e operativamente accessibili relativi ad un contesto
Insieme di dati dati personali che possono essere memorizzati e collegati tramite applicazioni informatiche
In ogni contesto esistono attributi necessari ed altri non necessari

14
In certi contesti la persona vuole rimanere anonima, in altri contesti preferisce presentarsi con uno pseudonimo, in altri casi è necessario rivelare l’identità reale
E’necessario poter collegare tra loro le identità digitali parziali relative ad una stessa persona
Problematiche non banali da gestire

15
Trattamento dei dati personali
In Italia il trattamento dei dati personali, quindi anche delle identità digitali parziali, è regolato dal Decreto legislativo 30 giugno 2003, n. 196 -Codice in materia di protezione dei dati personali (Testo unico privacy)
I sistemi di Identity Management devono essere progettati in modo da rispettare la legge, in particolare proteggendo i dati (Art.1)
Principio di necessità nel trattamento dei dati: I sistemi informativi e i programmi informatici sono configurati riducendo al minimo l'utilizzazione di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune modalità che permettano di identificare l'interessato solo in caso di necessità. (Art. 3)

16
Le 7 leggi dell’identità
Controllo da parte dell’utente e consenso
Rivelazione minima e per uso prestabilito
L’utente comprende la ragionevolezza del trasferimento
L’utente può usare uno pseudonimo
Fonte: Low of Identity

17
Le 7 leggi dell’identità
Il sistema deve essere pluralista rispetto ad operatori e tecnologi
Azione umana integrata nel sistema
Semplicità e usabilità delle molte identità digitali parziali
Fonte: Low of Identity

18
Indicazioni Europee
Fonte: Luigi Reggi

19
Identità digitale federata
La Federazione è un accordo, tra organizzazioni e fornitori di risorse, con il quale i partecipanti decidono di fidarsi reciprocamente, delle informazioni che si scambiano nei processi di autorizzazione e autenticazione, sulla base di regole e linee di condotta stabilite per gestire le relazioni di fiducia.
La gestione dell’identità può essere sempre meno vista come un problema solo interno alle singole organizzazioni: le persone infatti, mentre effettuano transazioni, “si spostano” sempre più attraverso i confini di diversi ambiti di responsabilità corrispondenti ad altrettante organizzazioni.

20
Identità digitale federata
Il paradigma di identità digitale federata nasce come risposta all’esigenza che le organizzazioni hanno di cooperare condividendo dati, partendo dal presupposto che il traguardo di una identità digitale “unica”, trasversale ai vari domini, è poco realistico.

21
Vantaggi dell’identità digitale federata
Eliminazione del problema di discordanze relativo alla gestione delle identità in sistemi disgiunti
Ridotto il numero di credenziali da conoscere
Ridotto il carico dovuto alla disattivazione dei client che non hanno più diritto
L'organizzazione può modificare più velocemente i diritti di accesso basandosi sui ruoli

22
Vantaggi dell’identità digitale federata
Capacità di gestire rapidi cambiamenti
es. utenti per uno o pochi giorni
es. attivazione di molti nuovi servizi anche federati o in cloud
Governance più efficace
perché è finalmente possibile applicare le policy (non solo enunciarle)
Aiuta a rispettare le leggi
es. diritti privacy
Soddisfazione dell’utenza
grazie all’accesso facile e sicuro a numerose risorse

23
Svantaggi
Necessario un ente per la gestione delle policy della federazione
Limitato alle risorse web
Possibile difficoltà d’integrazione con web application specifiche

24

25

26
Access Management
Permettere alle organizzazioni di:
Dare ai propri utenti l’accesso alle risorse migliorando la loro padronanza e usabilità (user experience)
Controllare l’accesso degli utenti alle risorse e alle applicazioni on-line
Con le seguenti condizioni:
Proteggere i dati personali dell’utilizzo non autorizzato
Proteggere le informazioni riservate dall’accesso da parte di utenti non autorizzati

27
Access Management
Si esplicita in un complesso di applicazioni e sistemi che vengono utilizzati per gestire l’autenticazione degli utenti, l’accesso (o la restrizione dell’accesso) alle risorse, i profili, le password, e altri attributi che aiutano a definire ruoli e profili degli utenti.

28
Access Management

29
Access Management
All’interno della propria organizzazione:
Ognuno segue una propria logica di gestione degli accessi
Diversi database con svariate tipologie di autenticazione
Specifici ruoli
Personalizzazione del concetto di identità digitale
Tuttavia ogni organizzazione
Necessità di interoperare con le altre
Un soggetto può far parte di diverse organizzazioni
Sistemi di autenticazioni differenti
Accesso alla risorse in modo sicuro

30
Access Management

31

32

33
La federazione nella PA
L’identità digitale federata nasce come esigenza che i vari enti della pubblica amministrazione hanno di cooperare condividendo dati
Federare due o più sistemi di identity management significa fare si che i rispettivi linguaggi non siano più stranieri l’uno all’altro attraverso l’utilizzo di un insieme comune di regole e di grammatiche che le rendono interoperabili
L’effettiva utilità giunge quando si può riporre fiducia nell’identità digitale a prescindere da chi la emette

34
La federazione nella PA
Dall’interoperabilità si arriva all’utilità se c’è anche un modello tecnico-organizzativo che supporti la fiducia tra le parti
L’utilizzo della federazione permette l’eliminazione degli utenti duplicati e l’utilizzo di servizi protetti anche da differenti organizzazioni
L’obiettivo è assicurare la trasparenza del livello applicativo dei servizi offerti dai singoli domini rispetto alle specifiche modalità di interazione utilizzate all’interno delle singole comunità
ogni soggetto viene riconosciuto da diverse entità

35

36

37
Profilo Utente
Rappresenta una entità all’interno di una singola organizzazione
Composto da un insieme di attributi che ne descrivono le caratteristiche
In base agli attributi vengono permesse determinate azioni
Limitazione degli accessi
In ottica di federazione il profilo dell’utente viene costruito sulla base delle organizzazioni alle quali appartiene

38
Dominio fruitore, erogatore certificatore, profilazione

39
Dominio fruitore, erogatore certificatore, profilazione

40
Progetto ICAR
Il progetto ICAR ha avuto il merito di vedere nell’identità federata il presupposto per accrescere l’impatto dei servizi e-Government.
Il task INF-3 ha il compito di attuare questo presupposto attivando la federazione dell’identità digitale tra le regioni.

41
Definizione del modello logico di riferimento
Lo scenario di riferimento di un Sistema Federato di Cooperazione è quello tipico di una rete regionale, ovvero una comunità a cui afferiscono uno o più domini in grado di offrire differenti tipologie di servizi ai proprio utenti, e che possono dialogare con altri domini anche se appartenenti ad altre reti regionali.
Il modello proposto si basa sulla federazione tra community network che comunicano tra loro attraverso la rete Internet.

42
In un contesto di questo tipo, i servizi definiti da ciascun dominio facente capo a una specifica comunità possono essere resi disponibili agli altri domini della comunità, così come ai domini appartenenti a comunità diverse, attraverso una interfaccia di dominio.
L’interfaccia di dominio costituisce concettualmente il punto di ingresso per l’accesso alle risorse applicative offerte dal dominio.

43
L’interfaccia di dominio è costituita da:
Il portale gestisce l’interazione tra tali servizi e gli utenti umani
Il portale rappresenta il punto di accesso utilizzato dalle applicazioni software che vogliono accedere ai servizi esposti dall’amministrazione. Inoltre accordi di trust rappresentano gli strumenti in grado di rendere valide queste autenticazioni verso le altre amministrazioni

44
Domini ed Entità Interagenti
Il modello per la gestione federata delle entità si compone di due concetti principali

45
Domini
Nei modelli architetturali che caratterizzano l’organizzazione dei sistemi informativi della Pubblica Amministrazione è stato da tempo introdotto, ed è comunemente adottato, il concetto di dominio informatico
Il dominio rappresenta il sistema informativo di una amministrazione in senso lato ed in particolare definisce il perimetro di sicurezza informatica di responsabilità di una amministrazione

46
Elenco dei domini
Di seguito verranno descritti quattro tipi di dominio distinti:
Dominio di profilazione
Dominio fruitore
Dominio erogatore
Dominio certificatore

47
Dominio di Profilazione
Un dominio viene detto di profilazione per un
dato utente quando in esso è stata eseguita la
procedura di riconoscimento iniziale, durante
la quale a quell’utente sono state richieste
alcune informazioni che da quel momento in
poi sono state memorizzate in una struttura dati chiamata “profilo utente”. Tale struttura viene gestita da una entità detta Profile Authority.

48
Dominio Fruitore
Un dominio si dice fruitore relativamente ad un’interazione di accesso ad un servizio, quando in essa ha origine la richiesta di tale servizio
In questo specifico contesto, il dominio fruitore viene a coincidere di fatto con lo stesso utente richiedente come un comune browser web

49
Dominio Erogatore
Un dominio viene detto erogatore relativamente ad un’interazione di accesso ad un servizio, quando in esso è presente il fornitore del servizio richiesto
In tale dominio, potranno essere presenti ulteriori entità, come quella incaricata di verificare che il richiedente possieda tutti i requisiti necessari per l’accesso al servizio indicato, eventualmente ottenendoli da terze parti fidate

50
Dominio Certificatore
Un dominio viene detto certificatore relativamente
ad un’interazione di accesso ad un servizio, quando
in esso sono presenti uno o più soggetti certificatori,
detti anche authority, in grado di asserire la validità di
uno o più attributi contenenti nel profilo gestito della
Profile Autority del dominio di profilazione dell’utente.
Per questo motivo il profilo, oltre a contenere i dati veri e propri relativi all’utente, dovrebbe memorizzare dei riferimenti a tutte le authority coinvolte, che fanno capo ad uno o più domini certificatori.

51
Dominio Certificatore
All’interno del dominio certificatore operano un certo numero di entità che espongono servizi atti a certificare alcune informazioni contenute nel profilo degli utenti
Tali entità sono chiamate authority e hanno la caratteristica di godere della fiducia di altre entità presenti nei vari domini coinvolti
Questo significa che le “descrizioni” prodotte da un’authority, relativamente alla validità o invalidità delle informazioni nei profili utente sono considerate vere per definizione, da parte di coloro che si fidano di tale authority
Si possono distinguere almeno tre tipologie di authority
Certification Authority
Attribute Autority
Profile Authority

52
Certification Authority
Sono le authority abilitate a certificare l’identità di un utente nel processo di autenticazione
Un utente viene dotato di un certo numero di credenziali, da parte di ciascuna certification authority a cui fa capo. In questo modo, diverse certification authority possono certificare diversi tipi di credenziali, come ad esempio credenziali costituite da un nome utente e password, oppure da codice fiscale e PIN
Un utente potrebbe avere un profilo contenente credenziali certificate da più di una certification authority

53
Profile Authority (PA)
Sono le entità incaricate della gestione dell’archivio dei profili utente presenti nei domini di profilazione. Ad esse è demandato il compito di rispondere alle richieste di attributo formulate dal dominio erogatore, per la verifica dell’identità e/o del livello di autorizzazione
La Profile Authority, fa parte del dominio di profilazione dell’utente di cui gestisce il profilo e può essere interrogata remotamente da parte di domini diversi, come il dominio erogatore

54
Attribute Authority (AA)
Sono le authority abilitate a certificare alcuni degli attributi nel profilo di un utente ed utilizzati nel processo di autorizzazione
Un utente in generale è dotato di un certo numero di attributi che, insieme alle credenziali, concorrono a formare il suo profilo
Ad esempio, residenza, professione, titolo di studio, iscrizione ad un albo e sono in generale certificate da authority presenti in domini diversi

55
Attribute Authority (AA)
Una Attribute Authority è in grado di fornire certificazioni di attributo relative ai subject conosciuti
tutti gli attributi conosciuti di un determinato subject
certificazione del valore (o dei valori) di uno o più attributi relativi ad uno specifico subject
In generale, le Attribute Authorities (AA) non si comportano come Identity Provider e non sono in grado di certificare l’identità di un utente/subject
Una AA non è in grado di fornire token di autenticazione agli altri componenti della federazione

56
Shibboleth
Progetto inter-universitario del gruppo MiddlewareArchitectureCommitteeforEducation MACE, appartenente al consorzio Internet2
Le sue finalità sono la progettazione, la specifica e l’implementazione Open Source di sistemi per la condivisione inter-istituzionale di risorse web soggette a controllo di accesso.
Pacchetti per l’installazione:
Identity Provider
Service Provider
Discovery Service

57
Architettura

58
Single Sign On

59
Standard sul formato e scambio di credenziali
X.509: Standard ITU-T per le infrastrutture a chiave pubblica PKI.
SAML: Standard basato su XML per la creazione di tokens di sicurezza.

60
Identity Provider
Un Identity Provider è un’entità della federazione ICAR/SHIBBOLETH in grado di fornire asserzioni sull’identità digitale sugli utenti/subject conosciuti
riceve richieste di autenticazione con l’indicazione dell’insieme dei metodi di autenticazione ritenuti accettabili dal richiedente
produce token di autenticazione che certificano l’avvenuto riconoscimento di un subject secondo una specifica modalità (Es. username/pwd, HardwareToken, etc.)
Il token di autenticazione prodotto può eventualmente includere anche un insieme di attestazioni del valore degli attributi che caratterizzano il profilo dell’utente mantenuto dal quell’Identity Provider

61
Identity Provider
Normalmente un IdP non è in grado di comportarsi da Attribute Authority
Può produrre attestazioni di attributo soltanto a seguito dell’avvenuta autenticazione di un utente e congiuntamente al token di autenticazione
La produzione del token di autenticazione tipicamente prevede l’interazione con il browser utente

62
Identity Provider
gestisce l'autenticazione, il Single Sign On (SSO) ed il rilascio degli attributi delle identità contenute per il sistema di Identity Management.
Essenzialmente è una applicazione java dentro un J2EE (tomcat). Può essere presente un web server come reverse proxy.
Le funzioni:
Autenticazione e SSO porta 443: redige l'utente a una form di login o ritrasmette le in informazioni di avvenuta autenticazione
Attribute Authority (AA) porta 8443: rilascia gli attributi degli utenti autenticati

63
Service Provider
l'ente presso il quale è gestita la risorsa web a cui l'utente fa richiesta e che ha il compito di proteggerla attraverso una qualche forma di policy di accesso
il Fornitore di un certo servizio a cui l’utente vuole accedere il quale deve fornire il componente di Shibboleth denominato Service Provider
protegge l'accesso alle risorse web (anche autorizzazione, grazie agli attributi rilasciati dall'IdP)

64
Service Provider
Essenzialmente è un demone in C++ con il quale il web server dialoga (mod_shib2 - link)
Intercetta le richieste a risorse protette e ridirige l'utente sull WAYF (Where are you from? Servizio di discovery dell’IdP) o all'IdP
Ricevute le informazioni di autenticazione apre una connessione verso lo AA dell'IdP per reperire gli attributi
ogni risorsa il cui accesso deve essere protetto richiede un SP, quindi ogni servizio Web accessibile agli utenti della federazione richiede un SP.

65
Identity Provider e Service Provider
IdP e SP possono cooperare secondo diversi profili, ciascuno dei quali definisce l’ambito fiduciario e contrattuale che lega le due tipologie
Profilo “Multi Provider”

66
Esempio di federazione

67
3
4
5
7
2
1
10
6
9
8
Handle
13
Handle
11
8
Attributi
12
Attributi
10

68
Architettura ICAR
Sviluppi futuri

69
Architettura ICAR
Sviluppi futuri

Autenticazione
70
Relazioni ed Interazioni con Shibboleth
Utente
Risorsa
1. Richiesta di accesso
3. Determinazione del Gestore di Identitàdi appartenenza
2. Redirezione
5. Autenticazione
Gestore Identità
Servizio
WAYF
4. Redirezione

71
Rilascio Attributi
Utente
Risorsa
8. Rilascio attributi
7. Richiesta Attributi
6. Credenzili (Handle)
Gestore Identità
Servizio
WAYF

72
Accesso alla Risorsa
Utente
Risorsa
10. Accesso alla risorsa
9. Autorizzazione
Gestore Identità
Servizio
WAYF

73
Protocollo SAML 2.0
La comunicazione avviene secondo lo standard SAML 2.0
Security Assertion Markup Language (SAML) è uno standard informatico per lo scambio di dati di autenticazione e autorizzazione (dette asserzioni) tra domini di sicurezza distinti, tipicamente un identity provider (entità che fornisce informazioni di identita) e un service provider (entità che fornisce servizi). Il formato delle asserzioni SAML e basato su XML. SAML è mantenuto da OASIS Security Services Technical Committee.

74
Protocollo SAML 2.0
SAML definisce sullo standard XML-base:
definizioni, protocolli, modalita' di connessione, profili
SAML assertion contiene un pacchetto di informazioni di sicurezza
SAML protocol si riferisce a COSA viene trasmesso
SAML binding determina la modalita' di richiesta o risposta standard
HTTP Artifact Binding usa ARP (Artifact Resolution Protocol) e SAML SOAP Binding per risolvere un messaggio per referenza

75
Protocollo SAML 2.0
SAML profile e' una manifestazione concreta di una combinazione particolare di definizioni, protocolli e modalita‘ di connessione che identificano una particolare struttura (IdP o SP)
I profili sono racchiusi nei RUOLI
Identity Provider
Service Provider
Attribute Authority
Attribute Consumer
Policy Decision Point

76
Metadati
Sono informazioni su informazioni
Dati che riguardano i dati
Descrizioni di oggetti elaborabili automaticamente detti “machine understandable” relativi ad una risorsa
Informazioni di carattere descrittivo, strutturale, amministrativo, tecnico-gestionale relative ad un oggetto o ad un insieme di oggetti

77
Metadati: le finalità
I profili SAML2 richiedono che una federazione si accordi per quanto riguarda le entità che ne fanno parte, le risorse, il supporto e gli endpoint che esplicano effettivamente i servizi federati
In questo contesto i metadati servono per descrivere tutte queste informazioni in un modo standardizzato
E' un modo ordinato di annotare i servizi, le entità le URI di riferimento e i ruoli che riflettono i profili SAML
Le macchine che offrono i servizi, sia di autenticazione che di risorse, accedono a questo elenco per comprendere come capire chi ha diritto a fare cosa, come deve farlo e dove sono le sue credenziali

78
Metadati: gli attori
Gli IdP si assicurano che l'SP sia autentico tramite una lista di 'trusted' SP
Gli IdP trovano informazioni relative agli endpoint degli SP dove mandare le info
Gli SP verificano la firma di una assertion tramite la chiave pubblica dell' IdP
Gli SP risolvono referenze tramite una lista di endpoint relativi all'Artifact Resolution Service

79
Metadati: ruoli
I metadati sono raggruppati secondo i diversi ruoli
Un ruolo è la combinazione di protocolli SAML e profili supportati dalle singole entità
Ogni ruolo è descritto da un elemento derivato dal tipo base RoleDescriptor
I RoleDescriptor sono raggruppati dentro l'elemento contenitore EntityDescriptor, unità primaria dei metadati
Più EntityDescriptor possono essere raggruppati in gruppi nidificati, tutti sotto l'elemento EntitiesDescriptor
Sono inoltre descritti e stabiliti tutti i sistemi supportati per stabilire un ambiente di fiducia fra gli attori

80
Metadati: ruoli

81
Metadati in SAML 2.0

82
Architettura ICAR
Sviluppi futuri

83
Architettura ICAR
Sviluppi futuri

84
Accesso al Servizio
Il caso d’uso principale è quello per l’accesso al servizio, che coinvolge tre attori: Service Requester, una o più Authority e un SP
Il richiedente contatta il fornitore che fa uso di un certo numero di authority certificatrici per convalidare l’accesso
Questo use case si compone di tre fasi autenticazione, autorizzazione e fruizione vera e propria del servizio

85
Accesso al Servizio
Si noti la particolarità per cui un SP può essere a sua volta un servirce requester. Un richiedente infatti, come già detto può essere sia un utente che opera mediante un browser web per contattare il front-end di un servizio, che il front-end dello stesso servizio,che deve contattare un certo numero di fornitori di servizi di back-end per completare la procedura di accesso

86
Registrazione e aggiornamento del profilo
Un secondo caso d’uso è quello che permette ad un nuovo utente di registrarsi presso una certa authority al fine della creazione di un nuovo profilo contenente almeno gli attributi base utili ai fini della procedura di autenticazione
Nel caso generale, tuttavia, il profilo verrà popolato anche con un certo numero di dati, ad esempio quelli anagrafici, ma potrà essere esteso anche in un secondo momento
Quest’ultima attività viene riassunta nel caso d’uso denominato “Aggiornamento del profilo” per cui un utente può accreditarsi con i nuovi attributi (o qualifiche) presso una AA

87
Architettura ICAR
Sviluppi futuri

88
Architettura ICAR
Sviluppi futuri

89
Architettura ICAR

90
Architettura ICAR

91
Architettura ICAR

92
Architettura ICAR in Regione MarcheIpotesi di ambiente
ICAR
Altre Regioni
Regione Marche
Cohesion
OpenLDAPo
Active Directory

93
Architettura ICAR in Regione Marche
?
2: From?
3: Retrieve from IdP
1: Service Request
5: Authentic.
Altre Regioni
4: Service Request
Regione Marche
Regione Marche
Cohesion
OpenLDAP

94
Architettura ICAR
Sviluppi futuri

95
Architettura ICAR
Sviluppi futuri

96
Stato dell’arte
L’infrastruttura di task Inf 03 ICAR è funzionante
Realizzato IdP di test
Realizzato un Sp di test
Autenticazione tramite Shibboleth
Integrazione con i maggiori CMS: Joomla e Wordpress

97
Sviluppi futuri
Autenticazione mediante SmartCard (carta raffaello)
Costituzione di una federazione di testing con le altre Regioni
Integrazione con i servizi di Google
….

98
Conclusioni
Entrare in un’ottica federata significa:
Condividere problematiche comuni
Assumere diversi ruoli a seconda della provenienza
Diminuire il carico di storage degli utenti
Essere a norma di legge

99
Riferimenti
Videohttp://www.youtube.com/watch?v=wBHiASr-pwk (UK)http://www.servizi.garr.it/index.php/it/news-idem/126-provafilmato (IT)
Strategie e politicheeuropee per la societàdell’informazionehttp://www.slideshare.net/rejus/strategie-e-politiche-europee-per-linnovazione-il-ruolo-dei-fondi-strutturali-comunitari-4004323
Idem e Icarhttps://www.idem.garr.it/index.php/it/documentihttp://www.progettoicar.it/ViewCategory.aspx?catid=ebf043b8e557434c89add91686c1f455

100
Th@nk for your Attention!
Michele Manzotti
Dipartimento di Informatica e Matematica
Università di Camerino
Via Madonna delle Carceri, 9
62032 - Camerino (Macerata) – ITALY
eMail: michele.manzotti@s tudenti.unicam.it
Web: http://manzotti.eu
http://conferences.cs.unicam.it/icarplusformazione
100

Sistema Federato Interregionale di Autenticazione

by michelemanzotti on Jun 29, 2010

Accessibility

Tags

Upload Details

Usage Rights

2 Embeds 50

Statistics

Sistema Federato Interregionale di Autenticazione — Presentation Transcript

http://www.manzotti.eu	45
http://manzotti.eu	5