Sistema Federato Interregionale di Autenticazione

PROGETTO ICARTask inf-3

Sitema Federato interregionale di Autenticazione

Michele ManzottiFausto Marcantoni

Barbara Re

Università di Camerino

2

Chi siamo

Prof. Fausto [email protected]: Reti di Elaboratori/Lab. Reti di Elaboratori – Laurea Informatica 3° AnnoIstruttore CCNA – CISCOCertificazione OPST (OSSTMM PROFESSIONAL SECURITY TESTER)

OSSTMM - Open Source Security Testing Methodology Manual

Dott. Michele [email protected] CCNA – CCNA – Security CISCOCertificazione OPST (OSSTMM PROFESSIONAL SECURITY TESTER)

OSSTMM - Open Source Security Testing Methodology Manual

mailto:[email protected]


http://images.google.com/imgres?imgurl=http://www.isecom.org/pix/opst_logo100.jpg&imgrefurl=http://www.isecom.org/projects/opst.shtml&usg=__Bbqsbb47cfIZUTTWXYA7VhOviSg=&h=97&w=100&sz=18&hl=en&start=4&um=1&itbs=1&tbnid=G8FDvXU1XwFzSM:&tbnh=80&tbnw=82&prev=/images%3Fq%3Dopst%26um%3D1%26hl%3Den%26tbs%3Disch:1

3

Agenda – Prima parteIdentità 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à digitale federata





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à

1. Controllo da parte dell’utente e consenso

2. Rivelazione minima e per uso prestabilito

3. L’utente comprende la ragionevolezza del trasferimento

4. L’utente può usare uno pseudonimo

Identità digitale ed identità federata Fonte: Low of Identity

http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf

17

Le 7 leggi dell’identità

5. Il sistema deve essere pluralista rispetto ad operatori e tecnologi

6. Azione umana integrata nel sistema

7. Semplicità e usabilità delle molte identità digitali parziali

Identità digitale ed identità federata Fonte: Low of Identity

http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf

18

Indicazioni Europee

Identità digitale ed identità federata Fonte: Luigi Reggi

http://www.slideshare.net/rejus/strategie-e-politiche-europee-per-linnovazione-il-ruolo-dei-fondi-strutturali-comunitari-4004323

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àIdentità digitale ed identità federata

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 dominiDi 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 CertificatoreUn 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 AuthorityIdentità digitale ed identità federata

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 Middleware Architecture Committee for Education 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 ServiceIdentità digitale ed identità federata

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 ProviderIdentità digitale ed identità federata

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.Identità digitale ed identità federata

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

Identity Provider e Service Provider• Esempio di federazione


67

Identity Provider e Service Provider


Handle

Handle

Attributi

Attributi

12

3

4

5

6

7

8 910

11

12

13

8

10

68





• Sviluppi futuri


69





• Sviluppi futuri


• Autenticazione

70

Relazioni ed Interazioni con Shibboleth


UtenteRisors

a

Gestore

Identità

Servizio

WAYF

1. Richiesta di accesso

2. Redirezion

e

3. Determinazione del Gestore di

Identitàdi appartenenza

5. Autenticazion

e

4. Redirezione

71

Relazioni ed Interazioni con Shibboleth• Rilascio Attributi


UtenteRisors

a

Gestore

Identità

Servizio

WAYF6. C

redenzili

(Handle)

8. Rila

scio attributi

7. Richiesta

Attributi

72

Relazioni ed Interazioni con Shibboleth• Accesso alla Risorsa


UtenteRisors

a

Gestore

Identità

Servizio

WAYF

9. Autorizzazione

10. Accesso alla risorsa

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





• Sviluppi futuri


83





• 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





• Sviluppi futuri


88





• Sviluppi futuri


89

Architettura ICAR


90

Architettura ICAR


91

Architettura ICAR


92

Architettura ICAR in Regione MarcheIpotesi di ambiente


Cohesion

OpenLDAPo

Active Directory

Regione Marche

Altre Regioni

ICAR

93

Architettura ICAR in Regione Marche


CohesionOpenLD

AP

Regione Marche

Altre RegioniRegione

Marche

2: From??

3: Retrieve from IdP

4: S

ervi

ce R

eques

t

5: A

uth

enti

c.1: Service Request

94





• Sviluppi futuri


95





• 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 politiche europee per la società dell’informazione http://www.slideshare.net/rejus/strategie-e-politiche-europee-per-linnovazione-il-ruolo-dei-fondi-strutturali-comunitari-4004323

• Idem e Icar https://www.idem.garr.it/index.php/it/documenti http://www.progettoicar.it/ViewCategory.aspx?catid=ebf043b8e557434c89add91686c1f455

http://www.youtube.com/watch?v=wBHiASr-pwk

http://www.servizi.garr.it/index.php/it/news-idem/126-provafilmato

http://www.servizi.garr.it/index.php/it/news-idem/126-provafilmato




https://www.idem.garr.it/index.php/it/documenti

http://www.progettoicar.it/ViewCategory.aspx?catid=ebf043b8e557434c89add91686c1f455

http://www.progettoicar.it/ViewCategory.aspx?catid=ebf043b8e557434c89add91686c1f455

100100

Th@nk for your Attention!

Michele Manzotti

Dipartimento di Informatica e MatematicaUniversità di Camerino

Via Madonna delle Carceri, 9 62032 - Camerino (Macerata) – ITALY

eMail: michele.manzotti@s tudenti.unicam.itWeb: http://manzotti.eu

http://conferences.cs.unicam.it/icarplusformazione

mailto:michele.manzotti@s


http://manzotti.eu/



Date post:	17-May-2015
Category:	Documents
Upload:	michelemanzotti
View:	2,617 times
Download:	6 times

Sistema Federato Interregionale di Autenticazione

Documents