un fenomeno da normare e gestire - webhome < main

ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA

FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Specialistica in Scienze di Internet

IDENTITÀ DIGITALE E SITI WEB FEDERATI

Un fenomeno da normare e gestire

Tesi per il corso di studio

Laboratorio Interdisciplinare

a.a. 2008-09

Presentata da Paolo Zini Matr. 314063

Identità digitale e siti web federati

Pag . i

Sommario

1 Introduzione ................................................................................ 1

2 Concetti di base........................................................................... 3

2.1 Identità digitale ....................................................................................3

2.1.1 Aspetti teorici ......................................................................................3

2.1.2 L’interpretazione tecnologica .............................................................5

2.2 Autenticazione ......................................................................................5

2.2.1 Rassegna dei principali metodi e tecniche.........................................6

3 Federazione di identità digitali ............................................10

3.1 Principali metodi di federazione ....................................................11

3.2 Profili di federazione.........................................................................12

3.2.1 Profilo 1: Service Provider Hub........................................................12

3.2.2 Profilo 2: Identity Provider Hub.......................................................13

3.2.3 Profilo 3: Multi-Provider Cross-Domain ..........................................15

3.3 Casi d’uso delle federazioni di identità.........................................16

3.3.1 Caso d’uso 1: Internal cross-domain SSO........................................16

3.3.2 Caso d’uso 2: External secure Internet SSO ...................................18

3.3.3 Caso d’uso 3: Attribute Exchange ....................................................18

3.3.4 Caso d’uso 4: Federated identity provisioning ................................19

3.3.5 Caso d’uso 5: Federated identity Web services ...............................19

4 Standard è bello….....................................................................20

4.1 Rassegna dei principali standard di federazione web ..............21

4.1.1 SAML.................................................................................................22

Laboratorio Interdisciplinare a.a. 2008-09

Pag. ii

4.1.2 Shibboleth ......................................................................................... 22

4.1.3 WS-* .................................................................................................. 23

4.1.4 Liberty Alliance ................................................................................ 23

4.2 Quale standard usare........................................................................ 24

5 SAML (Secure Assertion Markup Language) .................... 25

5.1 Cos’è SAML .......................................................................................... 25

5.2 I vantaggi ............................................................................................. 26

5.3 Terminologia....................................................................................... 26

5.4 Come usare SAML. I profili ............................................................. 28

5.4.1 Profili per il SSO............................................................................... 28

6 Conclusioni ................................................................................ 33

7 Biblio/Sitografia........................................................................ 35

7.1 Bibliografia.......................................................................................... 35

7.2 Sitografia ............................................................................................. 35

7.2.1 Principali standard........................................................................... 35

7.2.2 Altri standard e iniziative minori .................................................... 36

7.2.3 Altri siti ............................................................................................. 38


Pag . iii

Indice delle figure

Figura 1 - Profilo 1, SP Hub.................................................................................13

Figura 2 - Profilo2, IdP Hub ................................................................................14

Figura 3 - Profilo 3, Multi Cross..........................................................................15

Figura 4 - Caso d'uso 1: Internal cross-domain SSO..........................................17

Figura 5 - External secure Internet SSO............................................................18

Figura 6 - Evoluzione degli standard per la federazione delle identità ............22

Figura 7 - Diagramma di sequenza di un SSO via web browser .......................29

Figura 8 - Diagramma di sequenza del profilo ECP...........................................30

Figura 9 - Diagramma di sequenza del profilo di Single Logout .......................31

Figura 10 - Diagramma di sequenza del profilo Name Identifier......................32


Claim

L’esponenziale crescita di servizi erogati via web sta influendo con la stessa forza sulla proliferazione delle identità elettroniche, o digitali. Chiunque oggi utilizzi Internet, per professione o per svago, possiede necessariamente diverse identità con differenti livelli di accreditamento, per operare in contesti completamente differenti.

Questo sempre più ampio ricorso all’impiego di identità digitali comporta una complessa gestione tanto da parte di chi si occupa di erogare i servizi, quanto dell’utente stesso quando si trova a dover ricordare e fornire le proprie credenziali di riconoscimento. Queste ultime sono funzione del metodo e/o della tecnica utilizzata per l’autenticazione.

Risulta quindi indispensabile adottare tecnologie che vengano incontro sia ai service provider, sia agli utilizzatori; questo è tuttora la sfida a cui nuove tecnologie web e specifici standard cercano di dare una risposta nel massimo rispetto dei principi di usabilità e interoperabilità.


Pag. 1

1 Introduzione

I computer di ieri davano sicuramente meno preoccupazioni ai responsabili della sicurezza informatica rispetto ad oggi.

Innanzi tutto la (quasi) totale assenza di connessioni di rete costituiva una notevole barriera fisica.

Con il successo di Internet, e in particolare delle tecnologie connesse alla rete delle reti, sempre più persone, applicazioni e servizi, si ritrovano a usufruire e a condividere informazioni su canali di comunicazione intrinsecamente insicuri che connettono i luoghi più remoti del pianeta. Il tutto in modo trasparente agli utilizzatori.

Ormai l’isolamento non è più un’opzione. Ognuno di noi necessita di potersi collegare a tutto e a tutti, per i motivi più disparati. Stiamo vivendo in modo concitato il brusco cambiamento tra l’era del possesso, in cui la proprietà era il fulcro del modello, all’era dell’accesso, dove il nuovo paradigma di condivisione delle risorse meglio si adatta alla nuova concezione di fare business.

Così troviamo fornitori che necessitano di colloquiare elettronicamente con le aziende manifatturiere, addetti degli uffici vendite che cercano di migliorare le relazioni con i propri clienti e così via.

Ormai ogni organizzazione, pubblica o privata che sia, e al proprio interno i propri reparti o unità, richiedono una capillare connessione con i propri interlocutori. Ma la cosa veramente importante è che tali conversazioni avvengano in un contesto sicuro.

Più in generale è possibile dire che gli utenti, e le rispettive organizzazioni di appartenenza, richiedono che siano garantiti i tre principi fondamentali della sicurezza informatica:

• Confidenzialità, intesa come la capacità di un sistema di rendere inintelligibile un messaggio a chi non è autorizzato. Di solito si utilizza la crittografia, ma è l’identità digitale che ha in sé le credenziali necessarie per fare ciò;

• Integrità, intesa come la capacità di un sistema di garantire che il messaggio non sia stato alterato. Associato a tecnologie di firma elettronica, garantisce l’identità digitale del mittente;

• Disponibilità, intesa come la possibilità di poter accedere alle informazioni nel momento in cui se ne ha bisogno.

Per i dipartimenti IT è cruciale capire come le proprie organizzazioni intendano gestire e controllare le identità elettroniche non solo dei propri


Pag . 2

dipendenti ma anche di tutte le controparti con cui quotidianamente si interfacciano.

La risposta tecnologica a questo tipo di problema è quella di federare i siti

web che hanno, a qualche titolo, interessi in comune. Questa sfida, attualmente in atto, si basa principi metodi e fondamenta tecniche descritte nel capitolo 2.

Dal capitolo 3 si inizia a trattare l’argomento principale di questo elaborato:

le federazioni di identità digitali. Oltre a darne una definizione nel contesto ICT, viene riportato una prima lista di metodi possibili di implementazione. Il capitolo si chiude con la descrizione dei differenti profili e casi d’uso.

La necessità di federare sistemi eterogenei di varie organizzazioni, piccole o

grandi, pubbliche o private, impone di dettare delle regole comuni o, meglio ancora, dei veri e propri standard. In tema di federazione di identità digitali vi è stato negli anni recenti un certo fermento come è testimoniato nel capitolo 4.

Come si vedrà in seguito, ad oggi lo standard, o per meglio dire il frame

work più utilizzato è SAML, nella sua versione 2.0. Il capitolo 5 cerca di sintetizzare pregi e difetti di questo insieme di specifiche di federazione, mostrando anche alcuni casi d’uso con i relativi diagrammi di sequenza.

Al termine, nel capitolo 6, si prova a tirare delle conclusioni sul fenomeno

delle identità digitali. Per quanto riguarda la bibliografia, dato l’argomento particolarmente

innovativo, trovare pubblicazioni specifiche è impegnativo. Sono stati impiegati più che altro testi teorici che in qualche modo trattano la materia più dal punto di vista filosofico. La maggior parte del materiale proviene da siti web autorevoli e il capitolo 7 ne riporta un nutrito elenco.


Pag. 3

2 Concetti di base

Questo capitolo intende descrivere alcuni concetti fondamentali per la comprensione del problema della gestione delle identità digitali.

Ovviamente il dominio è quello della comunicazione digitale, pure se alcuni principi possono essere validi anche se non strettamente confinati all’interno di un contesto elettronico.

2.1 Identità digitale

Per identità digitale si intende la rappresentazione elettronica di un set di asserzioni fatte da un soggetto digitale riguardo se stesso o un altro soggetto.

Un’identità digitale è articolata in due parti:

• Chi uno è (identità) • Le credenziali che ognuno possiede (gli attributi di tale identità)

Le credenziali corrispondono ad un set di proprietà che possono differire di parecchio in funzione dell’utilizzo che se ne intende fare.

Un esempio più semplice di identità digitale consiste, ad esempio, ad una coppia di attributi corrispondenti a uno username e una password associata. 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 e ha implicazioni sia legali che tecniche.

2.1.1 Aspetti teorici

In generale, non è possibile identificare al 100% un individuo: prendiamo il caso di due gemelli, gli attributi fisici non basterebbero, così come il semplice nome.

In realtà, quello che ci garantisce una certa univocità è la singola esperienza che ogni individuo lascia in noi. Incrociando tali ricordi, riusciamo a identificare un soggetto con una precisione tanto più alta quanto più sono le informazioni raccolte da noi sul suo conto, direttamente e indirettamente.


Pag . 4

Si può affermare che l’identità coincide con reputazione e questo non è qualcosa che necessariamente possiede l'individuo quanto piuttosto un insieme di informazioni che le persone attribuiscono al soggetto.

Purtroppo quando ci muoviamo in un contesto on-line, le apparenze sono difficilmente disponibili. Ecco che allora vi è la necessità di creare nomi e apparenze artificiali. Queste non corrispondono necessariamente uno a uno con le persone fisiche in quanto queste possono possederne diverse; inoltre tali identità spesso coincidono con soggetti che nulla hanno a che fare con gli esseri umani: computer, proxy, web services, ecc.

Un'identità individuale non è costruita da un individuo ma è il prodotto delle sue relazioni con gli altri. Così, partizionando le proprie relazioni, un soggetto può creare distinte identità.

Da questa sintetica escursione concettuale, possiamo definire, sempre in linea teorica le caratteristiche salienti di un sistema di gestione delle identità:

• Un'identità corrisponde a una lista definita di nomi di altre identità con le quali ha avuto una o più relazioni in passato, e i relativi attributi associati;

• Le identità sono entità autonome e interattive, sia on-line (http/soap/...) che near-line (email);

• Ogni identità possiede un nome non-unico, leggibile e “umano” (es.: Paolo Zini);

• Ogni identità possiede un’unica apparenza (es.: una public key universale, qualcosa come una primary key);

• Ad ogni identità è possibile richiedere se si identifica in quel dato nome e, se così è, se accetta l’attribuzione dell’apparenza collegata (vedi punto precedente);

• Ad ogni identità è possibile richiedere le proprie misure soggettive di reputazione di un’altra identità;

• Ad ogni identità è possibile richiedere di rivelare una o più identità ben note con le quali ha avuto relazioni in passato;

• Quando due identità interagiscono la prima volta, si scambiano un messaggio (es. la public key) in modo tale che ognuna possa dimostrare all’altra di essere il titolare di tale identità. Questo avviene usando la propria chiave privata1;

• Immediatamente dopo la creazione di una relazione, le identità possono scambiarsi dettagli relativi ai propri attributi: indirizzi, sito web, …;

1 In realtà il processo è più articolato per prevenire casi di man-in-the-middle-attack.


Pag. 5

• Se l’identità X sospetta che A conosca B, X può chiedere ad A di corroborare l’identità di B, interagendo immediatamente con B e confermando la conoscenza del messaggio segreto scambiato in precedenza.

2.1.2 L’interpretazione tecnologica

L'identità digitale è l'insieme delle informazioni e delle risorse concesse da un sistema informatico ad un particolare utilizzatore.

Nel mondo dei web services, anche un’applicazione che richiede un servizio può essere vista come identità digitale e per questo motivo necessita di possedere adeguate proprietà che le permettano di accedere alle risorse richieste. In questo caso, poiché non vi è un’interazione umana, la gestione dell’identità deve essere ancor più accurata in quanto non vi è la possibilità di interagire con un vero e proprio utente. Tutto deve risolversi in modo automatico ed ogni possibile deviazione del flusso procedurale deve essere contemplato.

2.2 Autenticazione

L’autenticazione è un processo che l’obiettivo di determinare se un utente o un’identità digitale è realmente chi dichiara di essere.

I primi sistemi di autenticazioni si basavano su tre differenti paradigmi:

qualcosa che l’utente conosceva (ad esempio una password, un pin, ecc); qualcosa che l’utente possedeva (ad esempio token, smart card, ecc); qualcosa che aveva a che fare con le proprietà biometriche dell’utente

(esempio impronte digitali, retina oculare, voce, ecc).

Il processo di autenticazione è basato sulla misura del rischio che, implicitamente, include anche la dimensione del danno nel caso di violazione.

Informazioni, applicazioni e sistemi ad alto rischio richiedono metodi ed, eventualmente, combinazioni più accurate che confermino l’identità digitale dell’utente rispetto a sistemi e informazioni che, dalla prospettiva del rischio, richiedono accertamenti più blandi.

Un più approfondito accertamento o, in alternativa, una combinazione dei metodi sopra riportati viene detta strong authentication.


Pag . 6

2.2.1 Rassegna dei principali metodi e tecniche

Di seguito vengono brevemente riportati i principali metodi di autenticazione.

2.2.1.1 Password Authentication

È il metodo di autenticazione maggiormente diffuso. È un metodo poco sicuro che richiede all’utente di ricordare una coppia di informazioni userid-password.

La sicurezza in questo caso è funzione di alcuni criteri che vanno dalla lunghezza della password ai caratteri usati per la sua composizione, passando dalla durata di validità della password stessa. Talvolta le password particolarmente complesse da scoprire sono maldestramente custodite da incauti utenti a fianco del monitor, sotto la tastiera, nel primo cassetto. Altre volte l’utente per pigrizia cognitiva, imposta la password con una data (la propria o altrui data di nascita o di matrimonio, il nome di qualcuno, ecc).

Tutto ciò rende la vita facile agli hacker che, con attacchi di tipo a dizionario, o con del buon social engineering, riescono in poco tempo a scoprire tali password.

2.2.1.2 Lightweight Directory Access Protocol (LDAP) Authentication

Questa architettura è molto diffusa laddove è necessario centralizzare la gestione dell’autenticazione.

I servizi di directory LDAP come Active Directory, Sun One Directory, Novell e-Directory, tanto per citarne alcuni, forniscono un modo economico e veloce per identificare i soggetti digitali comparabili ai tradizionali database, con i quali talora si integrano nei sistemi di identificazione più articolati.

2.2.1.3 Access Control Authentication

È un processo che garantisce ad una identità riconosciuta di accedere fisicamente ad una risorsa.

Con l’impiego di LDAP e di SSO, vedi in seguito, molte aziende integrano i sistemi di controllo accessi fisici con i sistemi di rilevazione presenza oltre agli accessi alle risorse digitali, il tutto in sistema per la gestione delle identità LDAP. Questo riduce il numero di identità provider.


Pag. 7

2.2.1.4 Network Authentication

L’autenticazione di rete è un processo mirato a garantire ad un soggetto identificato di poter accedere alle risorse distribuite della propria organizzazione. Quasi tutti questi meccanismi sono basati su LDAP. Per citarne alcuni: MS-Windows, Linux, Solaris, IBM AIX, HPUX.

2.2.1.5 Biometric Authentication

Questo tipo di autenticazione si basa sul riconoscimento di un nostro attributo fisico opportunamente digitalizzato per un suo successivo riconoscimento.

I più diffusi tipi di autenticazione biometrica prendono in esame le impronte digitali, il palmo della mano, la retina oculare.

Anche l’analisi del DNA sta prendendo sempre più piede in quei contesti dove l’accesso a determinate risorse o luoghi è un fattore particolarmente critico.

Spesso l’utilizzo della biometria è associato ad altre tecniche più convenzionali in modo da realizzare la cosiddetta Strong Authentication.

2.2.1.6 Strong Authentication

Per Strong Authentication si intende un più alto livello di autenticazione. Di solito è ottenuta combinando due o più sistemi di autenticazione visti in precedenza.

2.2.1.7 Transaction Authentication

Questo tipo di processo di autenticazione usa altri fattori determinanti diversi da quelli visti finora. Usato molto da istituzioni finanziarie per transazioni ad alto rischio, il metodo consiste nel controllare anche informazioni relative al sistema sottostante del cliente come l’indirizzo IP, qualche caratteristica saliente dell’hardware, la data e l’ora.

Qualora uno o più di queste informazioni non corrispondano con l’identità collegata, la transazione viene annullata e vengono emessi tutti i messaggi di allerta del caso.

2.2.1.8 PKI Authentication

Questo metodo si fonda su una particolare infrastruttura gerarchica chiamata appunto PKI (Public Key Infrastructure).


Pag . 8

L’identità del soggetto viene fornita attraverso un certificato digitale emesso da una cosiddetta Certification Authority (CA).

Vengono usate le firme digitali e il livello di autenticazione è variabile in funzione del processo di identificazione fisica svolto all’inizio da una Registration Authority.

I certificati digitali stanno diventando sempre più importanti al giorno d’oggi per verificare e identificare gli utenti nei sistemi SSO, nella gestione documentale e nei web service come si vedrà in seguito nel capitolo relativo a SAML.

2.2.1.9 Security Token Authentication

L’autenticazione via token fa parte della famiglia “qualcosa che si possiede”. In effetti in questo caso il processo termina positivamente quando l’utente dimostra di possedere un particolare dispositivo hardware, ad esempio il secureID di RSA o di molti istituti bancari.

Quando l’utente richiede il login ad un sistema così protetto, deve digitare oltre alle proprie credenziali un numero random che appare sul token; la sequenza dei numeri è nota solo al server che deve verificare l’identità, con una certa tolleranza temporale per evitare problemi di sincronizzazione.

I costi di questo sistema sono comunque non irrilevanti, tanto in termini di costi diretti, quanto in termini di comodità d’uso.

2.2.1.10 Smart Card Authentication

Le smart card sono a tutti gli effetti dei token. La differenza è che in questo caso l’utente non deve digitare il numero “magico” come nei token visti primi, ma è la smart card stessa che provvede ad auto identificarsi.

Solitamente le smart card contengono un certificato digitale oltre ad altri attributi del soggetto. Questo le ha rese appetibili anche a molte amministrazioni pubbliche che le impiegano per fornire servizi avanzati ai propri cittadini o imprese.

2.2.1.11 Wireless Authentication

L’autenticazione dei dispositivi wireless è diventata oggi una delle problematiche più cruciali per le organizzazioni che annoverano collaboratori mobili.

Spesso i metodi autenticazione usati sono insicuri o facilmente violati.


Pag. 9

Vi sono tuttavia diversi modi per aumentare la sicurezza con cui è possibile determinare se l’utente o terminale collegato è proprio quello che dice di essere.

2.2.1.12 Document Authentication

Anche se formalmente separati, i sistemi di autenticazione per l’accesso ai documenti sono sempre più integrati con i meccanismi di autenticazione delle identità digitali dell’azienda.

Le vecchie modalità di protezione dei documenti basate su password o quant’altro ora sono rimpiazzati dai sistemi visti sopra che garantiscono un più alto livello di confidenzialità al patrimonio documentale di un’organizzazione.

2.2.1.13 Single Sign On Authentication

Il SSO è un processo che permette di ridurre drasticamente il numero di volte che l’utente deve fornire le proprie credenziali di autenticazione. In questo modo è possibile implementare un sistema di autenticazione più robusto spostando l’onere della fornitura delle credenziali dall’utente, con tutti i problemi visti in precedenza, ad una architettura appositamente progettata.

Un sistema di SSO permette all’utente di fornire credenziali minimali per l’accesso alle risorse e, qualora successivi accessi riguardino risorse con una policy di protezione più severa, il sistema automaticamente, e solo allora, richiederà all’utente ulteriori credenziali idonee alla fruizione delle informazioni richieste.

Questo sistema di autenticazione è uno degli scenari tipici dei sistemi web federati.


Pag . 10

3 Federazione di identità digitali

Nel campo dell'ICT, la federazione di identità assume due significati generali:

• L'unificazione virtuale delle informazioni utente di un soggetto, detto anche Principal, memorizzate su diversi sistemi di gestione delle identità distribuiti nei diversi sistemi di autenticazione della federazione. I dati di uno stesso soggetto sono collegati tra loro mediante l'uso di un token comune, tipicamente una username;

• Un processo di autenticazione di un utente che si sviluppa trasversalmente sui diversi sistemi IT delle varie organizzazioni federate.

Si può dire quindi che la federazione di identità elettroniche permette la cosiddetta Autenticazione Federata, che consiste nel dare fiducia ad una identità che richiede una risorsa appoggiandosi su un partner noto o un sito affidabile, appartenente alla stessa federazione il quale garantisce sull’identità richiedente.

Questo permette di scambiare informazioni in modo sicuro tra partner, clienti, fornitori e ogni altro stakeholder eventualmente interessato, e autorizzato, alla condivisione delle risorse.

Il concetto di federazione di identità è assimilabile al collegamento mutuo

tra i sistemi di identificazione dei singoli service provider al fine di creare una sovrastruttura che consenta di accertarsi dell’autenticità di un utente senza dovere chiedere ripetutamente le credenziali di accesso.

Un classico esempio è rappresentato da un sottoinsieme di imprese che si

occupano di turismo e che, opportunamente federate, decidono di erogare diversi servizi complementari tra loro, alla propria potenziale clientela.

Ecco che allora un turista potrebbe essere visto come passeggero aereo così come ospite di un albergo. Inoltre questo soggetto potrebbe aver necessità di prenotare ingressi a musei o accedere a eventi artistici e culturali e via discorrendo.

Con un adeguato sistema di gestione delle identità federate, tale utente potrà accedere alle varie risorse distribuite fisicamente in domini di sicurezza distinti, in modo del tutto trasparente senza dover ogni volta autenticarsi a questo o a quel sistema.

Protocolli che permettono questo sono tanti, com’è possibile vedere nel

capitolo 4.1. Tali protocolli, in combinazione con i sistemi di Single Sign On, migliorano

di molto la User Experience in quanto non è più necessario ricordarsi e fornire


Pag. 11

continuamente le proprie credenziali di autenticazione.

Come si vedrà in seguito, gli standard per la federazione delle identità identificano tipicamente due ruoli funzionali nelle transazioni:

• L’Identity Provider (IdP), che si occupa di fornire a richiesta, l’identità dell’utente o servizio che richiede l’accesso a una risorsa;

• Il Service Provider (SP), che potrebbe essere rappresentato da un fornitore di servizi SaaS2 o da un vendor BPO3.

La federazione di identità digitali permette ad entrambe le organizzazioni di definire una relazione fiduciaria dove SP fornisce l’accesso ad una risorsa dopo avere autenticato l’utente richiedente tramite un IdP.

3.1 Principali metodi di federazione

Ci sono 4 principali metodi per realizzare una federazione di identità digitali:

1. Proprietario: sono in molti che tentano di implementare una propria

soluzione fino a quando si accorgono della curva di apprendimento troppo lunga e del rischio di incompatibilità con applicazioni esterne e partner che cercano di connettersi e di accedere alle risorse. Solitamente è un metodo che si applica a soluzioni interne, mono-partner, in quanto dotate di scarsa, se non nulla, scalabilità;

2. Open Source, un’evoluzione dei quella proprietaria che permette una maggiore scalabilità nel numero di partner grazie all’utilizzo di librerie condivise nella comunità. Sono però spesso carenti in funzionalità chiave come l’integrazione di specifici partner, raramente supportano la comunicazione standard e richiedono un notevole e continuo sforzo per la manutenzione;

3. Stack vendor, approccio basato sull’affidamento ad un particolare vendor della gestione delle identità digitali. È connotato da una scarsa capacità di connettersi ad altri sistemi federati che non utilizzino la stessa suite;

2 Software-as-a-Service, paradigma di erogazione di servizi che ha preso il posto dei modelli

ASP. 3 Business-Process Outsourcing, paradigma di gestione dei processi aziendale che prevede

l’outsourcing di un intero processo aziendale e non solo di una parte di esso.


Pag . 12

4. Federazione standard-based, il metodo di maggior successo che consiste nello scegliere un fornitore che si occupi solo di fornire servizi di SSO sicuro, attraverso la federazione delle identità, alle varie applicazioni e partner. Questi provider forniscono solitamente funzionalità avanzate e server stand-alone per la vera e propria implementazione del modello.

3.2 Profili di federazione

Oggi possiamo individuare fondamentalmente tre profili, o architetture di federazione, basate sul concetto di Hub. I progetti più semplici partono sempre con uno dei primi due modelli, dove vengono concentrate le funzionalità di service provider o di Identity Provider.

Progetti più complessi prevedono una configurazione ibrida dei due metodi sopra citati.

3.2.1 Profilo 1: Service Provider Hub

Questa struttura è ideale per quegli SP che vogliono connettere e integrare le proprie applicazioni e servizi alle organizzazioni esterne e per quelle organizzazioni che intendono proteggere le transazioni dei propri utenti quando accedono a tali servizi.


Pag. 13

Figura 1 - Profilo 1, SP Hub

Come mostrato in Figura 1, in un Service Provider Hub, l’SP è

architetturalmente situato nel mezzo dei vari Identity Provider e costituisce una relying party per le asserzioni di identità fatte dagli utenti autorizzati.

Le principali caratteristiche di un SP Hub sono: • SP accetta le identità dei loro clienti (IdP) con un ampio grado di

interoperabilità; • Le organizzazioni (IdP) desiderano estendere le identità dei loro addetti

a quelle entità che ospitano i loro SaaS o servizi on-demand; • L’autenticazione degli utenti avviene presso gli IdP ed è propagata

tramite specifiche asserzioni di autenticazione all’SP a cui si chiede l’accesso.

3.2.2 Profilo 2: Identity Provider Hub

Questa struttura è ideale per quelle organizzazioni che ritengono strategico


Pag . 14

mantenere centralizzato il controllo delle identità dei propri utenti, ma che nel contempo necessitano accedere a risorse distribuite presso differenti service provider.

Figura 2 - Profilo2, IdP Hub

Messo in evidenza dalla Figura 2, in pratica questo profilo è speculare al

precedente. IdP Hub è progettato per consentire un’autenticazione centralizzata dall’IdP il quale si preoccupa di fornire le necessarie credenziali dei propri utenti ai diversi SP a cui è necessario accedere.

Le organizzazioni aventi un gran numero di utenti tipicamente si affidano a

questo tipo di architettura, la quale possiede le seguenti caratteristiche: • Autenticazione centralizzata; • Capacità di adattamento ai differenti meccanismi di autenticazione dei

diversi service provider;


Pag. 15

• Possibilità, da parte dei service provider, di agire loro stessi da IdP memorizzando e propagando gli attributi pertinenti degli utenti e delle loro interazioni passate.

3.2.3 Profilo 3: Multi-Provider Cross-Domain

Questa struttura è ideale per le organizzazioni di grandi dimensioni che ritengono strategico mantenere centralizzato il controllo delle identità dei propri utenti, ma che nel contempo necessitano di accedere a risorse distribuite presso differenti service provider.

Anche graficamente, è facilmente apprezzabile come questo profilo risulti essere un complesso mix tra i due profili visti in precedenza.

Figura 3 - Profilo 3, Multi Cross

In tale scenario, messo in evidenza in Figura 3, ogni entità agisce al tempo

stesso sia come Identity Provider, emettendo asserzioni sull’identità digitale,


Pag . 16

sia come Service Provider, cioè come utilizzatore delle asserzioni dell’IdP. Per le grandi organizzazione questo è uno scenario abituale in quanto

quotidianamente devono gestire molti domini di sicurezza eterogenei delle proprie sedi e dei propri stakeholder. Questo crea una continua sfida nell’assicurare l’accesso alle risorse ai soli autorizzati. Di riflesso, la gestione delle diverse credenziali di accesso rende complesso anche il lavoro degli addetti IT.

In questo scenario le federazioni di identità digitali interne, cioè legate alla propria organizzazione, utilizzano protocolli standard per mettere in relazione identità e utenti in funzione dei vari domini di sicurezza delle organizzazioni esterne.

Questa portabilità attraverso i diversi domini di sicurezza avviene anche nei casi di federazione esterna quando un IdP è chiamato ad autenticare, e quindi ad autorizzare o meno, un’identità esterna che intende accedere ad una risorsa del proprio dominio.

Le principali caratteristiche di questo profilo sono: • Le organizzazioni che ricorrono al cross-domain authentication sono

tipicamente strutture mature e dotate di opportune risorse di gestione, pena l’impossibilità di progettare e implementare sistemi così complessi;

• Le diverse entità in gioco in questo profilo si trovano a interfacciare tanto gli IdP quanto gli SP continuamente.

3.3 Casi d’uso delle federazioni di identità

Dopo avere brevemente descritto le principali architetture possibili, di seguito vengono descritti gli usi tipici per cui normalmente vengono impiegati i sistemi di gestione di identità federati.

Esistono molti casi d’uso differenti, ma sicuramente i più implementati sono i seguenti:

• Internal cross-domain SSO; • External secure Internet SSO; • Attribute Exchange; • Federated identity provisioning; • Federated identity Web services.

Di seguito vengono brevemente descritti tali contesti d’uso.

3.3.1 Caso d’uso 1: Internal cross-domain SSO

Questo caso d’uso è normalmente usato per ridurre al minimo la ridondanza


Pag. 17

dei login da parte degli utenti che necessitano di passare con una certa ripetibilità da un dominio di sicurezza all'altro. Il tutto senza dover installare e configurare particolari sistemi proprietari che renderebbero difficoltosa l'interoperabilità tra domini.

Spesso questo caso d'uso è associato alle intranet e ai portali aziendali e consente di evitare la centralizzazione del controllo di autenticazione lasciando liberi i gestori dei vari domini di sicurezza aziendali di gestire le credenziali dei propri utenti. Ovviamente questo caso d'uso trova una maggiore giustificazione all'interno di quelle organizzazioni distribuite geograficamente e connotate da una struttura ben definita.

La sequenza delle azioni è la seguente: un utente si connette ad

un'applicazione o, più in generale, ad una risorsa appartenente al proprio dominio di sicurezza. La prima volta l'autenticazione è necessaria, fino alla scadenza decisa dalla policy aziendale. Se tale dominio risulta essere federato con un altro dominio di sicurezza, l'utente ha la possibilità di ottenere l'accesso a risorse di questo secondo contesto senza la necessità di ripresentare le proprie credenziali.

Figura 4 - Caso d'uso 1: Internal cross-domain SSO

Come schematizzato nella Figura 4, sarà cura del IdP del secondo dominio

richiedere a quello di provenienza le credenziali e di valutare se autorizzare o meno l'accesso all'utente.


Pag . 18

3.3.2 Caso d’uso 2: External secure Internet SSO

Questo caso d’uso è fondamentalmente un'estensione del caso precedente in quanto si applica a quei contesti in cui diverse organizzazioni si federano in Figura 5.

Per quanto riguarda la cosiddetta User Experience, questo permette di estendere ulteriormente, rispetto al caso precedente, le potenzialità di accesso dell'utente il quale, in modo del tutto trasparente e senza ulteriori login, ha a disposizione risorse residenti in altri domini di sicurezza al di fuori della propria organizzazione di appartenenza.

Figura 5 - External secure Internet SSO

Questo caso d'uso è detto Internet SSO in quanto al giorno d'oggi si utilizza

Internet per la maggior parte delle comunicazioni, ma dal punto di vista concettuale questo caso d'uso può essere implementato anche su reti private che tipicamente sono utilizzate dagli istituti finanziari e bancari.

3.3.3 Caso d’uso 3: Attribute Exchange

Questo caso d’uso è praticamente un estensione del servizio di SSO federato. L'utente viene definito presso il proprio IdP con diversi attributi, talora non tutti necessari per operazioni, per così dire, a basso rischio. Qualora un utente si sia autenticato utilizzando credenziali minimali, in base al principio di ****, potrebbe non essere autorizzato ad accedere a risorse che richiedano un livello di autenticazione più forte. Questo indipendentemente dal dominio di sicurezza che protegge la risorsa richiesta. Esso potrebbe essere lo stesso


Pag. 19

dominio di partenza, un dominio diverso ma della stessa organizzazione (vedi caso d'uso 1) oppure un contesto completamente esterno (vedi caso d'uso 2).

In questo scenario, il Service Provider incaricato ad autorizzare l'accesso alla risorsa, richiederà all'IdP preposto, ulteriori e più forti attributi dell'utente che sta richiedendo la risorsa.

3.3.4 Caso d’uso 4: Federated identity provisioning

Questo caso d’uso è un'estensione del caso precedente con la differenza che lo scambio degli attributi degli utenti avviene a prescindere dalla richiesta di accedere ad una determinata risorsa. In modo dinamico o batch, questo scenario consiste nell'aggiornare le informazioni, o attributi, degli utenti da un dominio all'altro. L'aggiornamento non solo prevede l'aggiunta di nuovi utenti, ma anche la modifica di alcuni loro attributi e, nel caso, l'intera cancellazione.

Questo caso d'uso agisce in modo del tutto asincrono con i casi visti in precedenza.

Viene utilizzato dagli amministratori di sistema in base a determinate policy della federazione.

3.3.5 Caso d’uso 5: Federated identity Web services

Questo caso d’uso prevede l'integrazione delle identità digitali con i web service. Questo significa che è possibile verificare le identità sia di chi avvia una transazione, sia del web service che è chiamato ad effettuarla.

Quando un utente inizia una sessione autenticandosi al proprio dominio di sicurezza tramite un browser, il sistema di federazione crea un apposito token il quale permetterà all'utente di avviare l'applicazione web remota. Questa, inserisce il token associato all'utente nelle diverse chiamate SOAP ai web service coinvolti nella transazione.


Pag . 20

4 Standard è bello…

… è per questo motivo che ce ne esistono tanti.

In ambito ICT, uno standard rappresenta una base di riferimento, un paradigma codificato per la produzione di tecnologie fra loro compatibili e interoperabili, che siano componenti hardware, software o infrastrutture di rete. Generalmente il termine standard, di derivazione anglosassone, è usato in ambiente informatico, mentre il resto dei settori tecnologici usa il termine norma.

Diversi enti a livello internazionale come l'ISO (International Organization for Standardization), l'IEEE (Institute of Electrical and Electronics Engineers) o l’OASIS (Organization for the Advancement of Structured Information Standards) propongono, concordano e ratificano le norme nei diversi ambiti.

Prima di essere considerato tale dalla comunità internazionale, ed essere preso a buon diritto come modello di riferimento, uno standard passa attraverso una serie di fasi di analisi e accreditamento:

• L'analisi delle esigenze dell'utenza da parte delle università e dei settori che si occupano di ricerca e sviluppo per le varie aziende produttrici, dà luogo alla ricerca di soluzioni per i problemi e le necessità eventualmente riscontrate.

• Quando possibile, delle specifiche tecniche vengono emesse sottoforma di descrizioni documentate estremamente dettagliate.

• Il testing e l'utilizzo di tali specifiche da parte della comunità internazionale dei produttori e dei laboratori di ricerca evidenzia le soluzioni migliori. A questo gli enti internazionali possono cominciare a scegliere cosa scartare e cosa mantenere dei vari contributi, producendo l'insieme delle specifiche finali.

• Le specifiche finali vengono accreditate come standard internazionale da un ente scientifico. Il risultato è un documento che descrive il modello cui le ditte di settore dovranno attenersi, pena l'incompatibilità dei loro prodotti tecnologici.

Anche per la gestione delle identità federate troviamo diversi standard, più o meno diffusi, che nel tempo sono stati sviluppati con le intenzioni più diverse, dai gruppi di interesse più disparati.


Pag. 21

4.1 Rassegna dei principali standard di federazione web

Indipendentemente dai profili e dagli scenari d'uso visti in precedenza, l'approccio migliore per affrontare il problema di gestione delle identità digitali consiste nell'adottare soluzioni standard; sistemi basati su standard normalmente danno la possibilità di implementare un appropriato grado di interoperabilità che è il vero punto cruciale della federazione.

Spesso gli standard si misurano l'un l'altro durante il loro ciclo di vita e vi è un confronto, talora anche solo a distanza, con gli altri rispettivi standard. Questo porta, con una certa frequenza, ad un buon livello di interoperabilità.

Prendere in esame tutti gli standard, o anche le sole iniziative di formazione nel campo dell’identità digitale, può risultare difficile oltre che noioso e sicuramente non esaustivo.

Per gli standard e le iniziative in questo settore si rimanda ad un apposito paragrafo all'interno della linkografia.

I tre standard maggiormente adottati oggi sono:

• Security Assertion Markup Language (SAML); • WS-* (“WS-star”) suite of specifications; • Liberty Alliance protocols (ID-FF).

A questi va aggiunto Shibboleth che, come si vedrà in seguito, è un’implementazione open source basata su SAML.

Nella Figura 6 viene messa in evidenza l’evoluzione nel tempo dei diversi standard e la loro integrazione, o separazione.


Pag . 22

Figura 6 - Evoluzione degli standard per la federazione delle identità

4.1.1 SAML

SAML viene approfondito nel prossimo capitolo. È comunque importante mettere in evidenza che questo standard, arrivato alla versione 2.0 attraverso una maturazione abbastanza rapida ma non priva di ostacoli e di trattative con altre iniziative con cui talora si è alleata – vedi WS-* -, altre volte le ha inglobate – è il caso di ID-FF e di Shibboleth.

4.1.2 Shibboleth

Questa iniziativa, open source, è nata sull’onda di Internet 24 per fornire uno strumento di collaborazione peer-to-peer utilizzando un’infrastruttura per la federazione di identità digitali basata su SAML.

Shibboleth è stata particolarmente adottato dagli ambienti accademici e, più in generale, dalle comunità scientifiche di tutto il mondo.

4 Internet2 o UCAID (University Corporation for Advanced Internet Development) è un consorzio non-profit che sviluppa tecnologie e applicazioni avanzate per la rete, spesso per trasferimenti ad alta velocità


Pag. 23

L’ultima versione, la 2.0, è basata sulla versione 2.0 di SAML.

4.1.3 WS-*

Questa suite di specifiche nasce dalla collaborazione di varie organizzazioni commerciali delle quali alcune sono note come Microsoft, IBM, versino, e RSA Security.

Alcuni di questi protocolli sono stati sottomessi e ratificati da organizzazioni di standard come OASIS.

Come detto, WS-* può essere visto come una suite di specifiche modulari per rendere più sicuri i web service. In particolare, i protocolli contenuti ad oggi sono:

• WS-Trust; • WS-Federation; • WS-Policy.

Quest’ultimo consiste in un insieme di meccanismi, in via di evoluzione, che permettono la stratificazione dei vari livelli di competenze quali l’autenticazione, l’autorizzazione e le policy da adottare per l’accesso intra e cross domain.

4.1.4 Liberty Alliance

La Liberty Alliance è un’organizzazione di imprese che si occupa fondamentalmente di supportare il meccanismo di Microsoft chiamato Passport.

Microsoft Passport è costituito da due servizi:

• un accesso singolo, in un servizio che consente ai membri di utilizzare un singolo nome e una password per accedere a un numero crescente di siti partecipanti

• un servizio portafoglio che possono utilizzare i membri per effettuare acquisti in linea veloci e semplice.

Fin dall’inizio, la Liberty Alliance ha definito diversi protocolli per favorire tanto la federazione delle identità quanto quelle dei web service.

Questi protocolli includono il framework per la federazione delle identità (ID-FF) e il framework per la federazione dei web service (ID-WSF).

ID-FF è atto recentemente incorporato nella versione 2.0 di SAML.


Pag . 24

Liberty Alliance ha assunto ultimamente anche il ruolo di certificatore di conformità e di interoperabilità dei venditori dei prodotti che si dichiarano conformi alle proprie specifiche. Questo servizio di certificazione è esteso anche ad altri standard come SAML.

4.2 Quale standard usare

Come si è visto, standard per la gestione e la federazione delle identità digitali ve ne sono diversi, tutti ormai con un buon grado di maturazione e, soprattutto, diffusione.

È allora importante formulare dei criteri di massima per facilitare la scelta, come di seguito riportati:

• SAML è il protocollo maggiormente utilizzato per le federazioni di identità digitale basate su browser web, in particolare nell’ambito del business-to-business. Il predominio sul mercato di SAML ha provocato, tra l’altro, il ricongiungimento con Liberty ID-FF, assorbito nella versione 2.0, come si può notare nella Figura 6. Anche WS-* nei propri stack di sicurezza accetta ora i security token di SAML;

• Negli anni 2003-4, molte aziende implementavano il protocollo Liberty ID-FF. Dato che, come si è visto, tale protocollo è confluito in SAML 2.0, si consiglia ai progettisti di sistemi di federazione di identità digitali che hanno come requisiti l’adozione di Liberty ID-FF, di adattare tali specifiche a SAML;

• Le specifiche Liberty ID-WSF, aggiunte anch’esse in SAML 2.0, focalizzavano la loro intenzione sui web service che richiedevano la federazione d’identità. Benché non più aggiornate, queste specifiche potrebbero essere ancora adottate per usi interni, in quanto di facile implementazione;

• La componibilità, o modularità, dichiarata di WS-* che lo renderebbe interoperabile con altri standard, non è così ben definita. Se si desidera attivare la gestione delle identità sia a livello client sia a livello web service, si consiglia di rimanere in famiglia OASIS con SAML 2.0 e, lato web service, con WS-Trust (vedi linkografia);

• OpenID (vedi linkografia) è un meccanismo per l’SSO relativamente nuovo che è stato progettato per facilitare il cosiddetto blog commenting.Sebbene OpenID si basi su un modello SSO decentralizzato, non è ancora ritenuto sufficientemente sicuro per i modelli B2B. Il continuo ricorrere a IdP di terze parti, oltre a essere un freno alle prestazione, comporta un abbassamento del livello complessivo della sicurezza inaccettabile per i contesti business.


Pag. 25

5 SAML (Secure Assertion Markup Language)

Come si è visto nel capitolo precedente, SAML rappresenta oggi lo standard più diffuso.

Quella che segue è una rielaborazione della documentazione ufficiale disponibile sul sito OASIS all’indirizzo:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

5.1 Cos’è SAML

SAML è un framework basato su XML prodotto da OASIS Security Services Technical Committee che consente, mediante piattaforme per Web Service, lo scambio di informazioni per l’autenticazione e per l’autorizzazione fra reti e siti Web federati.

I siti web federati rappresentano organizzazioni legate tra loro da un rapporto di sviluppo economico-sociale, sulla base di accordi di business e tramite la protezione di informazioni personali degli utenti attraverso domini sicuri per la creazione d’interazioni più scorrevoli tra i domini.

Grazie a questo standard, tali aziende potranno rendere i propri network e servizi online fra loro interoperabili e accessibili mediante un unico processo di autenticazione degli utenti.

SAML permette alle aziende di implementare, ad esempio, soluzioni di SSO che consentano agli utenti di visitare diversi siti Web accedendo alle risorse protette contenutevi senza dover fornire ogni volta le proprie credenziali.

Oltre a questo, SAML rende possibile includere informazioni di sicurezza in documenti usati nelle transazioni d'affari.

Questo è particolarmente importante per i Web service, dove la sicurezza è cruciale.

SAML permette alle business entities5 di emettere assertions6 riguardo l’identità, gli attributi, e i diritti di un subject7 indirizzate ad altre entità, come ad esempio un socio di una compagnia o un’altra enterprise application8.

5 Server che rappresentano le aziende 6 Le assertions SAML contengono pacchetti d’informazioni sicure. Sono

solitamente trasferite dagli identity providers ai service providers. Esse


Pag . 26

5.2 I vantaggi

I vantaggi di SAML sono molteplici:

• L’indipendenza dalla piattaforma utilizzata; • Non è più necessario mantenere sincronizzate le informazioni utente tra

le diverse directory. Ogni dominio gestisce gli attributi necessari al contesto d’uso;

• Miglioramento dell’esperienza online per l’utente finale, fornendo semplicità e sicurezza delle informazioni introdotte;

• Riduzione del costo d’amministrazione per i service provider, poiché l’atto di autenticazione può essere riusato senza bisogno di mantenere le informazioni d’account;

• Riduzione del rischio di trasferimento delle informazioni tramite meccanismi di sicurezza come firme digitali (XML Signature), cifratura (XML Encryption), crittografia (SSL e TLS), codifica, etc.

5.3 Terminologia

Per meglio comprendere i vari profili d’uso e le tecniche di impiego di SAML, è necessario definirne univocamente i principali elementi.

Le assertion SAML contengono pacchetti d’informazioni sicure scambiati tra autorità SAML utilizzate per prendere decisioni di access control. Sono forniti tre tipi di statement:

• Authentication statement: assicura al SP l’autenticazione del Principal tramite l’IdP;

• Attribute statement: dichiara che un soggetto è associato a determinati attributi;

• Authorization Decision statement: dichiara che il soggetto ha l’autorizzazione ad effettuare determinate azioni sulla risorsa specificata mostrando una prova.

contengono statements utilizzati dai service providers per prendere decisioni di access control

7 Un subject è un’entità di cui si richiede l’autenticazione, spesso è un utente umano

8 Applicazione che si occupa di recuperare informazioni da database, gestendo l'interazione concorrente da parte di un elevato numero di utenti e interagendo con altre applicazioni aziendali


Pag. 27

I protocolli SAML definiscono come gli elementi SAML sono impacchettati all’interno di richieste e risposte SAML, incluse le assertion. Dettano le regole di elaborazione, di produzione e consumo di tali elementi. Per la maggior parte, il protocollo SAML è un semplice protocollo richiesta-risposta. SAML 1.1 non specifica altri protocolli oltre al primo tra quelli elencati sotto:

• Assertion Query and Request Protocol; • Authentication Request Protocol; • Artifact Resolution Protocol; • Name Identifier Management Protocol; • Single Logout Protocol; • Name Identifier Mapping Protocol.

L’insieme delle specifiche relative alle assertion e ai protocolli prende il nome di SAMLCore.

I binding SAML determinano come richieste e risposte SAML sono mappate su protocollo di comunicazione standard.

Un SAML Artifact è un oggetto dati strutturato, di piccole dimensioni a lunghezza fissa, che punta ad un messaggio SAML normalmente più grande, di lunghezza variabile. Questi artefatti sono stati progettati per essere inclusi in un URL e convogliati in messaggi http. In questo modo, un SP può indicare ad uno user agent dove reperire un certo messaggio SAML. L’agente in questo modo deferenzia l’artefatto e si va a pescare il messaggio direttamente dal content provider che possiede la risorsa.

In SAML 2.0 sono aggiunte nuove specifiche che descrivono i seguenti binding:

• SAML SOAP Binding (basato su SOAP 1.1). • Reverse SOAP (PAOS) Binding • HTTP Redirect (GET) Binding. • HTTP POST Binding. • HTTP Artifact Binding. • SAML URI Binding.

I profili SAML descrivono in dettaglio come le assertion, i protocolli ed i binding SAML sono combinati per supportare un particolare caso d’uso.

Nel paragrafo successivo i profili vengono descritti più


Pag . 28

5.4 Come usare SAML. I profili

Con la versione 2.0, SAML introduce numerosi profili, oltre a quelli visti nel capitolo 3.2. In tutti i casi SAML supporta i seguenti profili:

• SSO Profiles o Web Browser SSO Profile o Enhanced Client or Proxy (ECP) Profile o Identity Provider Discovery Profile o Single Logout Profile o Name Identifier Management Profile

• Artifact Resolution Profile • Assertion Query/Request Profile • Name Identifier Mapping Profile • SAML Attribute Profiles

In questa ricerca i profili sono descritti sommariamente. Per un’analisi più approfondita sui profili SAML si rimanda al sito di OASIS e in particolare al documento ufficiale scaricabile liberamente al seguente indirizzo:

http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.

Di questo documento ne viene riportata una sintesi, accompagnata da diagrammi di sequenza tratti sempre dallo stesso documento.

Per ragioni anche pratiche di impiego, vengono descritti solamente i profili che hanno a che fare con il SSO.

5.4.1 Profili per il SSO

SAML definisce una serie di profili per supportare il SSO di browser standard e di altri client avanzati.

Tra questi il più utilizzato è senza dubbio il profilo per il SSO dei Web Browser.

5.4.1.1 Web Browser SSO Profile

Lo scenario tipico di questo profilo vede l’utente web richiedere l’accesso ad una risorsa presso un service provider previa autenticazione all’IdP; quando invocato, quest’ultimo produce un’asserzione di autenticazione che viene utilizzata dall’SP nel proprio dominio di sicurezza.


Pag. 29

Per la sua implementazione, sono usati messaggi di protocollo <AuthnRequest> in combinazione con HTTP Redirect, HTTP POST e HTTP Artifact binding.

È sottointeso che l’utente stia usando un browser standard.

Come è possibile vedere dal diagramma di sequenza in Figura 7, possono esserci più messaggi scambiati tra i vari attori prima di accedere alla risorsa richiesta.

Figura 7 - Diagramma di sequenza di un SSO via web browser

5.4.1.2 Enhanced Client or Proxy (ECP) Profile

Per ECP si intende un’entità di sistema, o più genericamente un processo, in grado di contattare in modo appropriato un IdP.

Un Enhanced Client potrebbe essere un browser ma anche un generico user agent, mentre per Enhanced Proxy si intende un emulatore di un Enhanced Client (ad esempio un gateway WAP).


Pag . 30

Uno scenario tipico è il seguente: un Principal9, utilizzando un EPC, richiede l’accesso ad una risorsa presso un service provider previa autenticazione all’IdP; quando invocato, quest’ultimo produce un’asserzione di autenticazione che viene utilizzata dall’SP per creare un contesto di sicurezza dedicato. A tale contesto è possibile anche associare un nome se passato come parametro.

Nella Figura 8 è riportato il diagramma di sequenza di questo articolato profilo.

Figura 8 - Diagramma di sequenza del profilo ECP

5.4.1.3 Identity Provider Discovery Profile

Questo profilo è utilizzato da un SP per scoprire a quale IdP è associato il Principal che richiede una risorsa protetta.

9 Entità la cui identità può essere autenticata


Pag. 31

Questo sistema si basa su un cookie scritto nel dominio di sicurezza che è comune tanto all’IdP che al SP, nel quale è contenuta una lista di IdP conosciuti.

5.4.1.4 Single Logout Profile

Una volta che il Principal è stato identificato, potrebbe essere aperta una sessione tra IdP e Principal mediante cookie o altri mezzi. In questo modo l’IdP può fornire successivamente ai vari SP richiedenti le asserzioni di identificazioni utilizzando direttamente le informazioni di sessione. Gli SP, ed eventualmente gli altri IdP chiamati in causa durante il ciclo di vita della sessione, diventano di fatto parte di questa sessione e l’IdP che gestisce questo prende il nome di Session Authority.

Nel momento in cui l’utente decide di abbandonare la sessione, tale authority si preoccupa di eliminare le informazioni condivise e di chiudere la sessione.

Nel diagramma riportato in Figura 9, è possibile notare come alcuni messaggi tra partecipanti alla stessa sessione possono essere scambiati direttamente bypassando lo User Agent.

Figura 9 - Diagramma di sequenza del profilo di Single Logout


Pag . 32

5.4.1.5 Name Identifier Management Profile

Lo scenario tipico di questo profilo è rappresentato da un IdP che permette ad un Principal e a uno o più SP di scambiarsi informazioni via Form Html. Questo consente loro di condividere per un dato tempo informazioni relative ai Name Identifier.

In questo modo un IdP può informare un SP di un avvenuta modifica nel formato o nel valore di uno o più identificativi.

Alternativamente potrebbe essere un SP che reputa necessario applicare un proprio alias ad un identificativo.

In ultimo, uno dei provider coinvolti potrebbe segnalare che un dato identificativo non è più valido.

Nel diagramma riportato in Figura 10, è possibile notare come alcuni messaggi tra partecipanti alla stessa sessione possono essere scambiati direttamente bypassando lo User Agent.

Figura 10 - Diagramma di sequenza del profilo Name Identifier


Pag. 33

6 Conclusioni

Un’adeguata gestione federata delle identità digitali permette alle organizzazioni, come imprese e service provider, di scambiare informazioni tra partner, clienti e fornitori in modo sicuro riducendo al minimo i pesanti costi di autenticazione.

Vi sono indubbi vantaggi tanto sul piano tecnologico, quanto su quello economico e sociale.

Utilizzando metodi e tecniche standard, la federazione di identità consente di ridurre i costi di approvvigionamento ripetuto aumentando sensibilmente il livello di sicurezza, problemi tipici delle architetture applicative proprietarie.

Le organizzazioni che hanno adottato software per la gestione di tali sistemi hanno visto aumentare la possibilità di collaborazione con i propri stakeholder e di creare più facilmente nuove alleanze. Questo grazie alla riduzione dei costi associati all’integrazione dei servizi outsource dei vari attori della rete.

Federare le organizzazioni significa anche integrare in modo logico i propri sistemi di autenticazione allargando a tutto il partenariato la capacità di scambiare informazione in modo sicuro e circoscritto. Questi nuovi confini virtuali consentono, in modo del tutto trasparente all’utente finale, di migliorare la produttività, l’efficienza e di creare un prezioso vantaggio competitivo.

Volendo riassumere i vantaggi sul piano tecnologico, si può dire che la federazione di identità digitali permette di:

• Rendere più facile l’acceso via internet agli utenti che utilizzano risorse esterne;

• Migliorare la User Experience attraverso tecniche di SSO e di approvvigionamento just-in-time;

• Ridurre i tempi e i costi per l’integrazione di applicazioni di autenticazione;

• Eliminare applicazioni SSO proprietarie e/o non scalabili, spesso sviluppate in casa;

• Migliorare le interazioni online;

• Debellare problemi di sicurezza come il phishing o il man-in-the-middle attack.


Pag . 34

Il concetto dell'identità digitale si evolverà per includere la possibilità di esprimere tutte le varie interazioni umane in cui sarà coinvolta l’identità personale. Tale evoluzione sarà guidata da fattori economici, politici e sociali.

L'identità digitale fornirà nuovi strumenti, ma non cambierà gli aspetti fondamentali di ciò che è l'identità. Piuttosto l'identità digitale restituirà la facilità d’uso e l’attendibilità delle transazioni basate sull’identità che esistevano quando le interazioni erano faccia a faccia con persone che già si conoscevano (o entrambi erano conosciute da terzi) e nel contempo tutelerà la sicurezza e la responsabilità nelle transazioni.

Per contro, l’implementazione di una gestione simile non è un’impresa facile e questo ne rende lenta e macchinosa l’adozione.

Innanzi tutto le infrastrutture necessarie possono essere spesso particolarmente complesse, anche in termini organizzativi. Molti partner potrebbero non possedere i sufficienti requisiti per potere essere integrati.

E anche qualora i problemi tecnici fossero risolti, vi sono talora problemi di tipo legale che possono complicare la federazione; mantenere e gestire informazioni legate alle identità digitali creano forti implicazioni giuridiche, dalle norme sulla protezione dei dati personali agli accordi sul livello di servizio degli identity e service provider.

Infine gli aspetti culturali. Non tutte le imprese, e in particolare il loro management, capiscono bene il problema e quindi faticano a vedere i benefici futuri che si celano dietro i costi, a volte ingenti, immediati.

Come dice Rifkin nel suo trattato “L’era dell’accesso”, stiamo ormai vivendo una nuova era capitalistica in cui non è importante possedere asset e difenderli strenuamente, bensì condividerli con i propri partner favorendone l’accesso reciproco.

C’è bisogno senza dubbio di creare la giusta sensibilizzazione, magari prendendo spunto dalle buone pratiche che ormai sono numerose e che testimoniano la validità di tali sistemi e di questo nuovo approccio all’accesso e alla condivisione.


Pag. 35

7 Biblio/Sitografia

Questo capitolo è suddiviso in due parti: nella prima sono riportati i testi consultati per la realizzazione di questo elaborato; nella seconda sono elencati i siti consultati.

A causa della particolare caratteristica di innovatività dell’argomento, l’accesso a fonti web è risultato di gran lunga più proficuo di quanto non lo sia il mondo bibliografico. Da qui il netto sbilanciamento tra le due sezioni.

7.1 Bibliografia

Diritto all'anonimato - Anonimato, nome e identità personale A cura di: Finocchiaro Giusella Cedam, 2008 L’era dell’accesso Jeremy Rifkin Mondadori, 2001 Security in a Web Services World IBM White paper disponibile su:

https://www.ibm.com/developerworks/webservices/library/specification/ws-secmap/?S_TACT=105AGX04&S_CMP=LP

7.2 Sitografia

Questa sezione è suddivisa in due parti. La prima è dedicata ai link relativi agli standard e alle iniziative non

7.2.1 Principali standard

Liberty Alliance Project:

http://www.projectliberty.org

SAML:

http://www.oasis-open.org/committees/security/


Pag . 36

Shibboleth:

http://shibboleth.internet2.edu

WS-Security:

http://www.oasis-open.org/committees/wss/

7.2.2 Altri standard e iniziative minori

Higgins Framework, A new open source protocol that allows a user to control which identity information is to be released to an enterprise or with diverse identity management systems.

http://www.eclipse.org/higgins/

iNames Project, is a new service offering a centralized user controlled identity data store as well as providing authentication trust between enterprises.

http://www.inames.net/

MicroID is a new Identity layer to the web and Microformats that allows anyone to simply claim verifiable ownership over their own pages and content hosted anywhere.

http://microid.org

OpenID is an open, decentralized, free framework for user-centric digital identity that uses URI (also called a URL or web address) as a means of identity authentication.

http://openid.net/

OpenSAML is a set of open source (Apache 2 licensed) C++ & Java libraries meant to support developers working with the Security Assertion Markup


Pag. 37

Language (SAML). Additionally, various development groups have found the framework created to support OpenSAML 2 useful for their own work.

http://www.opensaml.org

SXIP is a commercially available product that offers users the ability to control their own identity information and authentication in use with blogs and other applications.

http://www.sxip.com/

XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Web Services Federation is a relatively new protocol to establish identity trust between disparate systems. This protocol is sponsored by IBM and Microsoft but not yet submitted to OASIS.

http://www.ibm.com/developerworks/library/specification/ws-fed/

Windows CardSpace (codenamed InfoCard), is Microsoft's client software for the Identity Metasystem. CardSpace is an instance of a class of identity client software called an Identity Selector. CardSpace stores references to users' digital identities for them, presenting them to users as visual Information Cards. CardSpace provides a consistent UI that enables people to easily use these identities in applications and web sites where they are accepted.

http://en.wikipedia.org/wiki/Windows_CardSpace

WS-Security is an OASIS standard that specifies how SOAP messages can have their integrity and confidentiality ensured. WS-Security defines a framework for securing SOAP messages, with the specifics being defined in


Pag . 38

profiles determined by the nature of the security token used to carry identity information.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.

The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.

Using the extensions defined in WS-Trust, applications can engage in secure communication designed to work within the Web services framework.

http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html

7.2.3 Altri siti

Authentication World.com

http://www.authenticationworld.com/

Federation of Identities in a Web Services World

http://www.ibm.com/developerworks/webservices/library/specification/ws-fedworld/?S_TACT=105AGX04&S_CMP=LP

Microsoft Passport

http://www.passport.net

OASIS

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security


Pag. 39

Wikipedia

http://www.wikipedia.com

un fenomeno da normare e gestire - webhome < main

Documents