29.06.2013 Views

InterDataNet: una soluzione infrastrutturale per il Read-Write Web of ...

InterDataNet: una soluzione infrastrutturale per il Read-Write Web of ...

InterDataNet: una soluzione infrastrutturale per il Read-Write Web of ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Coordinatore<br />

UNIVERSITÀ DEGLI STUDI DI FIRENZE<br />

Facoltà di Ingegneria<br />

Dipartimento di Elettronica e Telecomunicazioni<br />

Dottorato di Ricerca in<br />

Telematica e Società dell’Informazione - XXII ciclo<br />

ING-INF/05<br />

<strong>InterDataNet</strong>: <strong>una</strong> <strong>soluzione</strong><br />

<strong>infrastrutturale</strong> <strong>per</strong> <strong>il</strong><br />

<strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

Pro<strong>of</strong> <strong>of</strong> concept dell’architettura<br />

Pr<strong>of</strong>. Dino Giuli,<br />

Università degli Studi di Firenze<br />

Tesi di Dottorato di Ricerca di<br />

Davide Chini<br />

31 dicembre 2009<br />

Su<strong>per</strong>visori<br />

Pr<strong>of</strong>. Franco Pirri,<br />

Università degli Studi di Firenze<br />

Dr Ing. Maria Chiara Pettenati,<br />

Università degli Studi di Firenze<br />

Dr Ing. Samuele Innocenti,<br />

Università degli Studi di Firenze


Ringraziamenti<br />

Il guardare indietro a questi tre anni vissuti durante l’es<strong>per</strong>ienza del dottorato<br />

mi suscita <strong>una</strong> sensazione particolare. Particolare <strong>per</strong>ché se da un lato<br />

mi “sembra ieri” <strong>il</strong> giorno della discussione della tesi di laurea, dall’altro lato<br />

mi rendo conto che in questo <strong>per</strong>iodo sono accaduti eventi che hanno completamente<br />

rivoluzionato la mia vita, sia <strong>per</strong> quanto concerne <strong>il</strong> <strong>per</strong>corso di studi,<br />

con <strong>il</strong> completamento della presente dissertazione, che pr<strong>of</strong>essionali, con la soddisfazione<br />

di essere riuscito a trovare un lavoro confacente alle mie aspettative,<br />

ma principalmente sentimentali.<br />

Ed è proprio grazie al “Dottorato di Ricerca in Telematica e Società dell’Informazione”<br />

che ho conosciuto Lucia, mia attuale compagna nonché futura<br />

moglie. Senza di lei questo lavoro non sarebbe stato possib<strong>il</strong>e ed <strong>il</strong> mio unico<br />

rammarico è <strong>il</strong> non riuscire ad esprimerle tutto <strong>il</strong> mio riconoscimento. Il suo<br />

supporto, sia morale che tecnico, è stato fondamentale <strong>per</strong> <strong>il</strong> raggiungimento<br />

dei risultati presentati in questo lavoro e va quindi a lei <strong>il</strong> ringraziamento più<br />

particolare.<br />

Lucia non è stata senz’altro l’unica a condividere con me i momenti di difficoltà.<br />

Anzi, mi ritengo estremamente fort<strong>una</strong>to in quanto non ci siamo mai<br />

ritrovati soli: i nostri affetti più cari mi/ci hanno sempre sostenuto, senza mai<br />

smettere di credere in me.<br />

Ringrazio quindi i miei meravigliosi genitori, Mara e Freido e mio fratello<br />

Michele, che non si sono mai tirati indietro <strong>per</strong> cercare di aiutarmi, in tutti i<br />

modi possib<strong>il</strong>i. Ringrazio inoltre i genitori di Lucia ed i miei amici più veri, che<br />

hanno condiviso con noi tutti i problemi che abbiamo dovuto su<strong>per</strong>are.<br />

Per quanto riguarda la sfera accademica un doveroso ringraziamento va al<br />

Pr<strong>of</strong>. Dino Giuli <strong>per</strong> gli incoraggiamenti, l’aiuto morale e materiale che mi ha<br />

fornito nei momenti difficoltà, e <strong>per</strong> aver creduto in me fino alla fine, andando<br />

oltre al ruolo che ricopre. Ringrazio <strong>il</strong> Pr<strong>of</strong>. Franco Pirri, <strong>per</strong> la stima e la fiducia<br />

pr<strong>of</strong>essionale e <strong>per</strong>sonale di cui mi ha onorato e <strong>per</strong> tutti i confronti costruttivi<br />

che hanno <strong>per</strong>messo di arricchire <strong>il</strong> mio bagaglio di conoscenze e di migliorare<br />

notevolmente la mia impostazione nell’affrontare i problemi.<br />

Ringrazio <strong>il</strong> Dr. Ing. Maria Chiara Pettenati, <strong>per</strong> la disponib<strong>il</strong>ità, <strong>il</strong> sostegno,<br />

i preziosi suggerimenti ed i fondamentali contributi al presente lavoro. Ringrazio<br />

inoltre <strong>il</strong> Dr. Ing. Samuele Innocenti <strong>per</strong> <strong>il</strong> lavoro svolto nel corso degli anni, fondamentale<br />

<strong>per</strong> <strong>il</strong> raggiungimento dei risultati presentati in questa dissertazione<br />

e <strong>per</strong> <strong>il</strong> supporto che ha continuato a fornire in via informale in questo ultimo<br />

anno, dopo la discussione della sua tesi di dottorato.<br />

Ringrazio l’Ing. Riccardo B<strong>il</strong>lero che, sebbene all’inizio del suo <strong>per</strong>corso di<br />

ricerca, si è dimostrato estremamente disponib<strong>il</strong>e nell’<strong>of</strong>frirmi supporto e gli


auguro che <strong>il</strong> suo <strong>per</strong>corso sia pr<strong>of</strong>icuo quanto lo è stato <strong>il</strong> mio. Ringrazio anche<br />

<strong>il</strong> collega nonché amico Luca Capannesi, <strong>per</strong> <strong>il</strong> supporto tecnico, l’efficienza e<br />

la competenza con cui amministra i sistemi del “Laboratorio Integrato delle<br />

Tecnologie della Telematica e Radar & Radiocomunicazioni” del “Dipartimento<br />

di Elettronica e Telecomunicazioni”.<br />

Ringrazio inoltre gli ex-studenti che con le loro tesi di laurea hanno lavorato<br />

sul progetto <strong>InterDataNet</strong>, in ordine temporale: Niccolò Francini, Fernando<br />

Franco, Marc Hausmann, Stefano Cigheri, Ivan Zappia, Michela Paolucci, Luca<br />

Bertelli, Cristiano Costantini e Maddalena Barlotti. Ringrazio infine anche<br />

tutti gli studenti dei corsi di “Telematica” e “Sistemi Telematici” che con i loro<br />

elaborati hanno contribuito agli sv<strong>il</strong>uppi del progetto.<br />

Concludendo, ringrazio l’Ing. Ugo Paternostro e l’Arch. F<strong>il</strong>ippo Severi, che,<br />

come miei datori di lavoro durante <strong>il</strong> <strong>per</strong>iodo più critico del dottorato (quello<br />

finale), si sono dimostrati estremamente disponib<strong>il</strong>i <strong>of</strong>frendomi tutte le agevolazioni<br />

necessarie <strong>per</strong> terminare la ricerca senza dover scendere a compromessi.<br />

Firenze, 31 dicembre 2009<br />

Davide Chini


Non contraddire alla verità,<br />

ma vergognati della tua ignoranza.<br />

SIRACIDE 4,25<br />

<strong>InterDataNet</strong> has Su<strong>per</strong> Cow Powers.<br />

Ispirato ad un noto Easter Egg di APT


A Lucia


Indice<br />

Introduzione 1<br />

I Contesto O<strong>per</strong>ativo 5<br />

1 Stato dell’arte: <strong>il</strong> <strong>Web</strong> 6<br />

1.1 L’architettura del World Wide <strong>Web</strong> . . . . . . . . . . . . . . . . . 7<br />

1.2 Uniform Resource Identifier . . . . . . . . . . . . . . . . . . . . . 23<br />

1.2.1 La grammatica . . . . . . . . . . . . . . . . . . . . . . . . 23<br />

1.2.2 URI relative . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />

1.2.3 Uniform Resource Locator . . . . . . . . . . . . . . . . . . 25<br />

1.2.4 HTTP-URIs . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />

1.3 REpresentational State Transfer . . . . . . . . . . . . . . . . . . 29<br />

1.3.1 Sintesi delle proprietà . . . . . . . . . . . . . . . . . . . . 31<br />

1.4 Resource Oriented Architecture . . . . . . . . . . . . . . . . . . . 32<br />

1.5 <strong>Web</strong>DAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />

1.6 <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data . . . . . . . . . . . . . . . . . . . . . . . 35<br />

2 Stato dell’arte: federazione su larga scala 43<br />

2.1 Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . 44<br />

2.1.1 Servizio di ri<strong>soluzione</strong> . . . . . . . . . . . . . . . . . . . . 45<br />

2.1.2 Architettura distribuita e federata del DNS . . . . . . . . 47<br />

Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />

Server di nomi autoritativi . . . . . . . . . . . . . . . . . 48<br />

Chacing Name Server . . . . . . . . . . . . . . . . . . . . 49<br />

I Record Type . . . . . . . . . . . . . . . . . . . . . . . . 50<br />

2.1.3 Funzionalità avanzate . . . . . . . . . . . . . . . . . . . . 53<br />

Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />

Aggiornamenti dinamici . . . . . . . . . . . . . . . . . . . 54


Indice<br />

Trasferimenti di zona incrementali (IXFR) . . . . . . . . . 55<br />

Split DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />

TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />

SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />

DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 57<br />

2.1.4 Funzionamento del sistema . . . . . . . . . . . . . . . . . 57<br />

2.2 Lightweight Directory Access Protocol . . . . . . . . . . . . . . . 59<br />

2.2.1 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />

2.2.2 Directory federate . . . . . . . . . . . . . . . . . . . . . . 63<br />

2.2.3 Replicazione . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />

2.2.4 Sorgenti dati legacy . . . . . . . . . . . . . . . . . . . . . 65<br />

3 Principi e tecnologie <strong>per</strong> la sicurezza 67<br />

3.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />

3.2 Autorizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71<br />

3.2.1 Architettura di riferimento <strong>per</strong> l’autorizzazione . . . . . . 72<br />

3.2.2 Approcci <strong>per</strong> la gestione delle autorizzazioni . . . . . . . . 75<br />

Problemi noti . . . . . . . . . . . . . . . . . . . . . . . . . 76<br />

3.2.3 Role Based Access Control . . . . . . . . . . . . . . . . . 77<br />

RBAC0 (modello di base) . . . . . . . . . . . . . . . . . . 78<br />

RBAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<br />

RBAC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />

RBAC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82<br />

3.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83<br />

3.4 Tecnologie <strong>per</strong> l’AAA . . . . . . . . . . . . . . . . . . . . . . . . 84<br />

3.4.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . 84<br />

Elementi di <strong>una</strong> PKI . . . . . . . . . . . . . . . . . . . . . 85<br />

Le Certification Authority . . . . . . . . . . . . . . . . . . 85<br />

Le Policy delle PKI . . . . . . . . . . . . . . . . . . . . . 87<br />

R<strong>il</strong>ascio, gestione e revoca dei certificati . . . . . . . . . . 87<br />

3.4.2 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90<br />

Il processo di autenticazione OpenID . . . . . . . . . . . . 90<br />

Punti critici di OpenID . . . . . . . . . . . . . . . . . . . 98<br />

3.4.3 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . 100<br />

Terminologia e concetti . . . . . . . . . . . . . . . . . . . 100<br />

Il funzionamento di Kerberos . . . . . . . . . . . . . . . . 103<br />

Analisi della sicurezza e sv<strong>il</strong>uppi di Kerberos . . . . . . . 107<br />

3.4.4 Extensible Authentication Protocol . . . . . . . . . . . . . 108<br />

3.4.5 Radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111<br />

Autenticazione e autorizzazione . . . . . . . . . . . . . . . 111<br />

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 115<br />

Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />

vi


Indice<br />

Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . 117<br />

3.4.6 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 118<br />

Connessione e sessione . . . . . . . . . . . . . . . . . . . . 119<br />

Gestione degli errori . . . . . . . . . . . . . . . . . . . . . 128<br />

Radius e Diameter a confronto . . . . . . . . . . . . . . . 129<br />

II <strong>InterDataNet</strong>: basi teoriche 131<br />

4 <strong>InterDataNet</strong> Information Model 132<br />

4.1 Nella direzione dell’Information Model . . . . . . . . . . . . . . . 135<br />

4.1.1 Osservazioni sul modello . . . . . . . . . . . . . . . . . . . 136<br />

4.2 I nodi informativi . . . . . . . . . . . . . . . . . . . . . . . . . . . 138<br />

4.2.1 Informazioni atomiche . . . . . . . . . . . . . . . . . . . . 139<br />

4.2.2 Informazioni primitive . . . . . . . . . . . . . . . . . . . . 141<br />

4.3 Relazioni strutturali tra nodi e documenti . . . . . . . . . . . . . 142<br />

4.4 Strutturare con criteri di responsab<strong>il</strong>ità . . . . . . . . . . . . . . 143<br />

4.5 Identificazione di nodi e documenti . . . . . . . . . . . . . . . . . 144<br />

4.6 Storico dei documenti . . . . . . . . . . . . . . . . . . . . . . . . 146<br />

4.6.1 La propagazione delle modifiche . . . . . . . . . . . . . . 150<br />

4.6.2 I parametri di versione . . . . . . . . . . . . . . . . . . . . 152<br />

5 <strong>InterDataNet</strong> Service Architecture 156<br />

5.1 IDN-SA: vista d’insieme . . . . . . . . . . . . . . . . . . . . . . . 160<br />

5.1.1 IDN-Node ed interfaccia <strong>per</strong> la loro manipolazione . . . . 160<br />

5.1.2 Identificazione degli IDN-Node . . . . . . . . . . . . . . . 161<br />

5.1.3 Attraversamento dei livelli . . . . . . . . . . . . . . . . . . 165<br />

5.1.4 Imbustamento di dati e metadati . . . . . . . . . . . . . . 166<br />

5.2 IDN naming system . . . . . . . . . . . . . . . . . . . . . . . . . 168<br />

5.3 Storage Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 171<br />

5.3.1 Integrazione di sistemi legacy . . . . . . . . . . . . . . . . 173<br />

5.3.2 LS (ri<strong>soluzione</strong> inversa) . . . . . . . . . . . . . . . . . . . 174<br />

5.4 Replica Management . . . . . . . . . . . . . . . . . . . . . . . . . 174<br />

5.4.1 LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176<br />

5.5 Information History . . . . . . . . . . . . . . . . . . . . . . . . . 176<br />

5.5.1 Version Traversing Algorithm . . . . . . . . . . . . . . . . 177<br />

5.5.2 HNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177<br />

5.6 Virtual Repository . . . . . . . . . . . . . . . . . . . . . . . . . . 178<br />

5.6.1 Resource Aggregation Service . . . . . . . . . . . . . . . . 179<br />

5.6.2 LDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181<br />

5.6.3 Identity Service . . . . . . . . . . . . . . . . . . . . . . . . 183<br />

Identità e pr<strong>of</strong><strong>il</strong>o utente . . . . . . . . . . . . . . . . . . . 185<br />

vii


Indice<br />

Access Control List (ACL) . . . . . . . . . . . . . . . . . 186<br />

5.7 Diagrammi di sequenza dell’interazione fra livelli . . . . . . . . . 190<br />

5.7.1 Accesso ad <strong>una</strong> risorsa preesistente. . . . . . . . . . . . . 190<br />

5.7.2 Aggiornamento di <strong>una</strong> risorsa preesistente. . . . . . . . . 192<br />

5.7.3 Creazione di <strong>una</strong> nuova risorsa (caso POST). . . . . . . . 194<br />

5.7.4 Creazione di <strong>una</strong> nuova risorsa (caso PUT). . . . . . . . . 195<br />

5.8 Tipi delle entità definite in IDN . . . . . . . . . . . . . . . . . . . 197<br />

6 Scenari Applicativi 201<br />

6.1 Scenario: Pubblica Amministrazione . . . . . . . . . . . . . . . . 202<br />

6.1.1 La patente di guida . . . . . . . . . . . . . . . . . . . . . 202<br />

Esempio: r<strong>il</strong>ascio della patente . . . . . . . . . . . . . . . 204<br />

Esempio: variazione della residenza . . . . . . . . . . . . . 208<br />

6.2 Scenario: sorveglianza marittima . . . . . . . . . . . . . . . . . . 211<br />

6.2.1 Descrizione del contesto . . . . . . . . . . . . . . . . . . . 211<br />

6.2.2 Lo scenario gestito con IDN . . . . . . . . . . . . . . . . . 215<br />

6.3 Discussione critica degli scenari . . . . . . . . . . . . . . . . . . . 219<br />

III <strong>InterDataNet</strong>: pro<strong>of</strong> <strong>of</strong> concept 223<br />

7 Dettagli relativi all’implementazione 224<br />

7.1 Il livello applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . 225<br />

7.1.1 phpIDNadmin . . . . . . . . . . . . . . . . . . . . . . . . 225<br />

7.2 <strong>InterDataNet</strong> Service Architecture . . . . . . . . . . . . . . . . . 238<br />

7.2.1 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . 238<br />

7.2.2 IDN-PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . 240<br />

Ut<strong>il</strong>izzo di mod rewrite . . . . . . . . . . . . . . . . . . . 241<br />

Autenticazione, autorizzazione ed accounting . . . . . . . 242<br />

Gestione delle richieste . . . . . . . . . . . . . . . . . . . . 243<br />

Conclusioni 249<br />

Bibliografia 254<br />

viii


Elenco delle figure<br />

2.1 Richiesta di ri<strong>soluzione</strong> <strong>per</strong> l’accesso ad <strong>una</strong> pagina <strong>Web</strong>. . . . . 46<br />

2.2 Record Type del DNS. . . . . . . . . . . . . . . . . . . . . . . . . 53<br />

2.3 Struttura del Domain Name System. . . . . . . . . . . . . . . . . 57<br />

2.4 Esempio di funzionamento del DNS. . . . . . . . . . . . . . . . . 58<br />

2.5 Esempio di entry LDAP. . . . . . . . . . . . . . . . . . . . . . . . 60<br />

2.6 Esempio di Directory Information Tree. . . . . . . . . . . . . . . 61<br />

3.1 Esempio di un client che si connette ad <strong>una</strong> rete protetta da un<br />

sistema di AAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74<br />

3.2 Esempio di ruoli gerarchici del modello RBAC1. . . . . . . . . . . 80<br />

3.3 Architettura di un sistema di accounting. . . . . . . . . . . . . . 84<br />

3.4 Struttura gerarchica delle CA di <strong>una</strong> PKI. . . . . . . . . . . . . . 86<br />

3.5 Flowchart di autenticazione OpenID. . . . . . . . . . . . . . . . . 92<br />

3.6 Schermate di esempio relative ad <strong>una</strong> autenticazione OpenID. . . 93<br />

3.7 State diagram della procedura di autenticazione OpenID. . . . . 94<br />

3.8 Sequence diagram <strong>per</strong> l’autenticazione checkid-immediate. . . . . 95<br />

3.9 Sequence diagram <strong>per</strong> l’autenticazione checkid-setup. . . . . . . . 96<br />

3.10 Autenticazione intra-realm in Kerberos. . . . . . . . . . . . . . . 105<br />

3.11 Autenticazione cross-realm in Kerberos. . . . . . . . . . . . . . . 108<br />

3.12 Scenario di accesso ad <strong>una</strong> rete tramite Radius. . . . . . . . . . . 112<br />

3.13 Pacchetto Radius. . . . . . . . . . . . . . . . . . . . . . . . . . . 113<br />

3.14 AVP Radius. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113<br />

3.15 Flusso di accounting. . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />

3.16 Scenario di roaming tramite Radius. . . . . . . . . . . . . . . . . 117<br />

3.17 Sessione e connessione in Diameter. . . . . . . . . . . . . . . . . . 119<br />

3.18 Translation Agent Diameter. . . . . . . . . . . . . . . . . . . . . 120<br />

3.19 Una tipica connessione Diameter. . . . . . . . . . . . . . . . . . . 122<br />

3.20 Funzione di accounting in Diameter. . . . . . . . . . . . . . . . . 123


Elenco delle figure<br />

3.21 Pacchetto Diameter. . . . . . . . . . . . . . . . . . . . . . . . . . 124<br />

3.22 AVP Diameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126<br />

3.23 Funzioni di autenticazione e autorizzazione in NASREQ. . . . . . 127<br />

4.1 Esempio di documento IDN. . . . . . . . . . . . . . . . . . . . . . 143<br />

4.2 Esempio di relazioni tra documenti IDN-IM. . . . . . . . . . . . . 145<br />

4.3 Generazione delle revisioni. . . . . . . . . . . . . . . . . . . . . . 148<br />

4.4 Merge di due nodi. . . . . . . . . . . . . . . . . . . . . . . . . . . 149<br />

4.5 Esempio di propagazione delle modifiche. . . . . . . . . . . . . . 151<br />

4.6 Esempio di elemento recente rispetto al nodo di partenza. . . . . 153<br />

4.7 Esempi di “last” relativi al branch. . . . . . . . . . . . . . . . . . 154<br />

4.8 Espressione regolare <strong>per</strong> definire gli identificativi di versione. . . 155<br />

4.9 Convenzione sui nomi dei nodi nello storico. . . . . . . . . . . . . 155<br />

5.1 Relazione tra IDN-IM e IDN-SA. . . . . . . . . . . . . . . . . . . 157<br />

5.2 Spazi dei nomi delle risorse IDN. . . . . . . . . . . . . . . . . . . 159<br />

5.3 Nomi di risorse replicate. . . . . . . . . . . . . . . . . . . . . . . 163<br />

5.4 Interazione request/response applicata ad IDN. . . . . . . . . . . 166<br />

5.5 Imbustamento di dati e metadati. . . . . . . . . . . . . . . . . . . 167<br />

5.6 Sistema dei nomi di <strong>InterDataNet</strong> (ri<strong>soluzione</strong> diretta). . . . . . . 169<br />

5.7 Gerarchia delle risorse “nome” di <strong>InterDataNet</strong>. . . . . . . . . . . 170<br />

5.8 Storage Interface e Legacy Storage Interface. . . . . . . . . . . . 174<br />

5.9 Revisioni successive di documenti UEVM. . . . . . . . . . . . . . 179<br />

5.10 Creazione controllata e non di alias. . . . . . . . . . . . . . . . . 182<br />

5.11 GET di <strong>una</strong> risorsa: accesso (diagramma di sequenza). . . . . . . 190<br />

5.12 PUT di <strong>una</strong> risorsa: aggiornamento (diagramma di sequenza). . . 192<br />

5.13 POST di <strong>una</strong> risorsa: creazione (diagramma di sequenza). . . . . 194<br />

5.14 PUT di <strong>una</strong> risorsa: creazione (diagramma di sequenza). . . . . . 196<br />

6.1 Possib<strong>il</strong>e rappresentazione IDN di <strong>una</strong> patente di guida. . . . . . 204<br />

6.2 Interfaccia di un’applicazione <strong>per</strong> la creazione di patenti IDN. . . 206<br />

6.3 Identificazione degli enti responsab<strong>il</strong>i. . . . . . . . . . . . . . . . . 207<br />

6.4 Effetti dell’aggiornamento della residenza. . . . . . . . . . . . . . 209<br />

6.5 Esempio di interazione. . . . . . . . . . . . . . . . . . . . . . . . 217<br />

7.1 Diagramma dei casi d’uso di phpIDNadmin. . . . . . . . . . . . . 227<br />

7.2 Creazione di <strong>una</strong> nuova PIU. . . . . . . . . . . . . . . . . . . . . 228<br />

7.3 Modifica di un nodo esistente partendo dalla visualizzazione di<br />

un documento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229<br />

7.4 Visualizzazione della sola radice di un documento. . . . . . . . . 230<br />

7.5 Visualizzazione di un documento completo. . . . . . . . . . . . . 232<br />

7.6 Invocazione primitiva HTTP GET. . . . . . . . . . . . . . . . . . 234<br />

7.7 Invocazione primitiva HTTP POST. . . . . . . . . . . . . . . . . 235<br />

x


Elenco delle figure<br />

7.8 Invocazione primitiva HTTP PUT. . . . . . . . . . . . . . . . . . 236<br />

7.9 Invocazione primitiva HTTP DELETE. . . . . . . . . . . . . . . 238<br />

7.10 XML-Schema degli IDN-Node. . . . . . . . . . . . . . . . . . . . 239<br />

7.11 Esempio di content semplice. . . . . . . . . . . . . . . . . . . . . 240<br />

7.12 Ut<strong>il</strong>izzo di mod rewrite. . . . . . . . . . . . . . . . . . . . . . . . 241<br />

7.13 Processazione delle richieste (diagramma di sequenza). . . . . . . 244<br />

7.14 Demultiplexer e handler delle richieste (diagramma delle classi). . 245<br />

7.15 Astrazione delle risorse (diagramma delle classi). . . . . . . . . . 246<br />

xi


Introduzione<br />

È tipico degli esseri umani condividere e manipolare dati ed informazioni<br />

attraverso documenti, sia nella vita lavorativa che in generale nella normale<br />

vita quotidiana.<br />

Il <strong>Web</strong> è diventato <strong>il</strong> modo dominante attraverso <strong>il</strong> quale, ogni giorno, m<strong>il</strong>ioni<br />

di utenti creano, gestiscono ed interconnettono documenti contenenti dati ed<br />

informazioni. Grazie alla sua interfaccia semplice ed uniforme basata su URI<br />

(Uniform Resource Identifier) <strong>per</strong> trattare documenti distribuiti come risorse<br />

identificab<strong>il</strong>i ed interrelazionab<strong>il</strong>i a livello globale [BLFM05], <strong>il</strong> <strong>Web</strong> è diventato<br />

oggi “<strong>il</strong> più grande costrutto informativo nella storia dell’umanità” [Tru09].<br />

L’innovazione introdotta dal <strong>Web</strong> è stata dirompente poiché ha <strong>per</strong>messo<br />

la nascita di un nuovo paradigma nella gestione dei documenti distribuiti. Il<br />

collegamento i<strong>per</strong>testuale, la semplicità del linguaggio di markup HTML e del<br />

protocollo HTTP ed <strong>il</strong> fatto di essere un “unico <strong>Web</strong>” [Aye06] sono state le chiavi<br />

dell’innovazione e quindi del suo successo.<br />

Ma quali saranno gli elementi che contraddistingueranno <strong>il</strong> <strong>Web</strong> del futuro?<br />

Molti <strong>per</strong>corsi di ricerca sono stati a<strong>per</strong>ti <strong>per</strong> sv<strong>il</strong>uppare un <strong>Web</strong> “migliore”<br />

dell’attuale <strong>Web</strong> <strong>of</strong> Documents: fra questi ampio interesse ha suscitato <strong>il</strong> f<strong>il</strong>one<br />

connesso al Semantic <strong>Web</strong>, <strong>il</strong> cui obiettivo è introdurre nuove tecnologie rispetto<br />

al <strong>Web</strong> di oggi in modo da creare informazioni che potranno essere “comprese”<br />

anche dalle macchine.<br />

Dalla fine degli anni ’90, la comunità scientifica è stata molto attiva nello<br />

sv<strong>il</strong>uppare soluzioni e proposte e si è confrontata con l’importante gap che deve<br />

essere colmato <strong>per</strong> muoversi dal <strong>Web</strong> <strong>of</strong> Documents alla visione proposta del<br />

Semantic <strong>Web</strong>. Lungo questo cammino è emerso <strong>per</strong>ò che <strong>per</strong> realizzare tale<br />

visione è necessario imporre un cambiamento di paradigma nella struttura delle<br />

informazioni. La strada <strong>per</strong> realizzare <strong>il</strong> Semantic <strong>Web</strong> comporta prima la realizzazione<br />

di <strong>una</strong> transizione intermedia: tale transizione è stata chiamata <strong>Web</strong><br />

<strong>of</strong> Data.


Introduzione<br />

La comunità scientifica, che fa capo al movimento detto Linked Data, sta<br />

proponendo <strong>una</strong> realizzazione del <strong>Web</strong> <strong>of</strong> Data basandosi su quattro principi<br />

fondamentali, chiamati Linked Data Principles.<br />

Il <strong>Web</strong> <strong>of</strong> Data così realizzato, è un <strong>Web</strong> costituito da dati ut<strong>il</strong>izzab<strong>il</strong>i direttamente<br />

da applicazioni s<strong>of</strong>tware, a cui è stato dato un significato semantico<br />

esplicito, e che sono pubblicati on-line ed interconnessi tra dataset diversi e<br />

distribuiti [Hea08].<br />

La <strong>soluzione</strong> adottata si basa sui protocolli e sull’infrastruttura del <strong>Web</strong> <strong>of</strong><br />

Documents, estendendone soltanto <strong>il</strong> modello delle informazioni attraverso l’introduzione<br />

di RDF (Resource Description Framework) <strong>per</strong> descrivere le risorse,<br />

cioè i dati. Pur rivoluzionando <strong>il</strong> paradigma nel passare da <strong>Web</strong> di documenti<br />

a <strong>Web</strong> di dati, l’approccio Linked Data non modifica strutturalmente la condizione<br />

del <strong>Web</strong> come <strong>Web</strong> prevalentemente di tipo “read” e non “read-write”. La<br />

capacità di “write” è attualmente concreta solo limitatamente alle singole applicazioni<br />

che <strong>of</strong>frono soluzioni ad-hoc <strong>per</strong> uno specifico problema di dominio, come<br />

testimoniato dall’interazione in scrittura a livello di wiki, blog, social network,<br />

eccetera.<br />

Oltre a ciò, lo stato dell’arte nello sv<strong>il</strong>uppo del <strong>Web</strong> dimostra che i risultati<br />

raggiunti dal movimento Linked Data costituiscono ancora solamente un pro<strong>of</strong><br />

<strong>of</strong> concept dei principi su cui si basano e questo è anche confermato dal fatto<br />

che <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data così ottenuto, pur avendo avuto <strong>una</strong> grande diffusione in<br />

termini di volume di dati pubblicati, non è entrato a far parte delle tecnologie<br />

di uso comune.<br />

In questo lavoro si presenta <strong>InterDataNet</strong>, la visione e la progettazione di un<br />

modello <strong>infrastrutturale</strong> <strong>per</strong> <strong>il</strong> read-write <strong>Web</strong> <strong>of</strong> data.<br />

<strong>InterDataNet</strong> (IDN) costituisce <strong>una</strong> <strong>soluzione</strong> concettuale <strong>per</strong> un’infrastruttura<br />

che mira a realizzare uno spazio decentralizzato e scalab<strong>il</strong>e dove pubblicare<br />

dati interconnessi. L’architettura IDN ha come fine di promuovere l’indirizzab<strong>il</strong>ità<br />

globale delle risorse così come <strong>una</strong> serie di servizi base <strong>per</strong> la collaborazione<br />

(controllo dell’authorship, versioning e gestione delle repliche) in modo da <strong>per</strong>mettere<br />

la gestione di dati strutturati distribuiti ed eterogenei grazie ad un riuso<br />

su scala globale.<br />

I fondamenti dell’idea di <strong>InterDataNet</strong> si sostanziano in un insieme di principi<br />

che mirano a fornire le caratteristiche generali dell’informazione in modo astratto<br />

ovvero indipendentemente dalla specifica <strong>soluzione</strong> implementativa.<br />

I principi fondanti di <strong>InterDataNet</strong> sono i tre seguenti:<br />

• Principio 1: Contenitore-Contenuto. I documenti sono contenitori mentre<br />

i dati ed i metadati costituiscono <strong>il</strong> loro contenuto. I dati ed i metadati<br />

sono importanti al pari della struttura che li contiene.<br />

2


Introduzione<br />

• Principio 2: Identificatori Globali. Ad ogni dato sono assegnati degli<br />

identificatori gestiti da un sistema globale <strong>per</strong> l’identificazione attraverso<br />

<strong>il</strong> quale sia possib<strong>il</strong>e effettuare <strong>il</strong> recu<strong>per</strong>o delle informazioni. Sia i contenitori<br />

che i contenuti (ovvero documenti e dati/metadati) possono avere<br />

uno o più nomi con validità locale o globale. Al momento della creazione<br />

un documento o un dato ha un nome locale, che diventa globale <strong>una</strong> volta<br />

che l’autore decide di assegnarne la visib<strong>il</strong>ità ad un certo insieme di utenti<br />

(ovvero singolo utente, gruppi specifici, etc.).<br />

• Principio 3: Coo<strong>per</strong>azione. Sia i documenti che i dati sono arricchiti di<br />

un insieme di metadati/attributi che ab<strong>il</strong>itano la coo<strong>per</strong>azione. In sintesi<br />

si asserisce che <strong>il</strong> modello dell’informazione costituito dall’insieme “datimetadati-struttura”<br />

deve essere ab<strong>il</strong>itante alla coo<strong>per</strong>azione.<br />

I principi fondanti devono trovare loro concretizzazione nelle soluzioni concettuali<br />

e conseguentemente tecnologiche, vale a dire in IDN-IM (IDN Information<br />

Model), che rappresenta <strong>il</strong> modello dell’informazione, ed in IDN-SA<br />

(IDN Service Architecture), che rappresenta l’architettura introdotta a livello<br />

<strong>infrastrutturale</strong> <strong>per</strong> la gestione di informazione espressa tramite IDN-IM.<br />

Nel presente lavoro verrà descritto <strong>il</strong> modello IDN-IM e riportata la progettazione<br />

di IDN-SA, inoltre verrà proposto un pro<strong>of</strong> <strong>of</strong> concept del sistema<br />

finalizzato a dimostrarne la fattib<strong>il</strong>ità e la fondatezza dei principi costituenti.<br />

In particolare la tesi è organizzata nel modo seguente:<br />

• la prima parte, costituita da tre capitoli, introduce <strong>il</strong> contesto o<strong>per</strong>ativo.<br />

Nel primo capitolo si <strong>il</strong>lustrano l’architettura del <strong>Web</strong> attuale e le tecnologie<br />

su cui si basa; al termine del capitolo è presente un paragrafo che<br />

affronta le principali tematiche a<strong>per</strong>te allo state dell’arte che trattano l’evoluzione<br />

del <strong>Web</strong>. Il secondo capitolo descrive <strong>il</strong> DNS (Domain Name<br />

System) e LDAP (Lightweight Directory Access Protocol) <strong>per</strong> introdurre<br />

<strong>il</strong> problema della federazione su larga scala e come è stato affrontato in<br />

questi specifici contesti. Infine <strong>il</strong> terzo capitolo fornisce <strong>una</strong> panoramica<br />

relativa alla sicurezza in ambiente distribuito descrivendo in dettaglio autenticazione,<br />

autorizzazione ed accounting e le più note tecnologie <strong>per</strong> la<br />

relativa implementazione;<br />

• la seconda parte, anch’essa costituita da tre capitoli, è dedicata alla descrizione<br />

del sistema <strong>InterDataNet</strong> ed alle sue ricadute applicative. In<br />

particolare <strong>il</strong> quarto capitolo descrive l’<strong>InterDataNet</strong> Information Model,<br />

<strong>il</strong> quinto capitolo la progettazione dell’<strong>InterDataNet</strong> Service Architecture<br />

ed infine <strong>il</strong> sesto capitolo introduce alcuni scenari applicativi;<br />

3


Introduzione<br />

• la terza ed ultima parte è costituita dal settimo capitolo ed affronta la descrizione<br />

del pro<strong>of</strong> <strong>of</strong> concept che è stato integralmente realizzato durante<br />

lo svolgimento del presente lavoro di tesi.<br />

4


Parte I<br />

Contesto O<strong>per</strong>ativo


Capitolo<br />

1<br />

Stato dell’arte: <strong>il</strong> <strong>Web</strong><br />

Il <strong>Web</strong>, ut<strong>il</strong>izzato ormai da m<strong>il</strong>ioni di utenti, è <strong>il</strong> più vasto esempio mai esistito<br />

di aggregazione di documenti e, in generale, di dati. Le tecnologie su cui<br />

si basa sono relativamente semplici ed a basso costo ed è proprio la semplicità<br />

ad essere stato uno dei fattori chiave che ne hanno decretato <strong>il</strong> successo su<br />

scala globale. Semplicità non significa <strong>per</strong>ò “banalità”, tutt’altro: la semplicità<br />

con cui è possib<strong>il</strong>e interagire con <strong>il</strong> <strong>Web</strong> (grazie al protocollo HTTP), pubblicare<br />

informazioni creando interconnessioni fra documenti (tramite HTML) con<br />

scalab<strong>il</strong>ità (a livello mondiale), affidab<strong>il</strong>ità e sicurezza (solo <strong>per</strong> citare alcune<br />

delle caratteristiche di maggior r<strong>il</strong>ievo) derivano dall’essere riusciti a realizzare<br />

un paradigma, e quindi un’architettura, fondati su concetti eleganti e, in alcuni<br />

casi, articolati.<br />

Chiaramente la diffusione che ha avuto, probab<strong>il</strong>mente addirittura su<strong>per</strong>iore<br />

alle più rosee aspettative dei pionieri che hanno inizialmente contribuito alla sua<br />

realizzazione, e gli anni di es<strong>per</strong>ienza che hanno portato alla sua maturazione<br />

hanno <strong>per</strong>messo di evidenziarne alcuni limiti.<br />

Il limite principale emerso riguarda <strong>il</strong> fatto che <strong>il</strong> <strong>Web</strong>, come conosciuto<br />

oggi, è fruib<strong>il</strong>e esclusivamente dagli umani e le macchine non riescono, in modo<br />

autonomo, a sfruttare l’immenso patrimonio informativo che <strong>of</strong>fre.<br />

Per cercare di su<strong>per</strong>are questa limitazione la comunità che si occupa dello sv<strong>il</strong>uppo<br />

del <strong>Web</strong> ha inizialmente cercato di renderlo “semantico” (Semantic <strong>Web</strong>)<br />

ut<strong>il</strong>izzando l’infrastruttura lato rete preesistente, introducendo un framework<br />

<strong>per</strong> la descrizione delle risorse (RDF, Resource Description Framework) che <strong>per</strong>mettesse<br />

di creare rappresentazioni (delle risorse stesse) agevolmente trattab<strong>il</strong>i


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

dai calcolatori elettronici ed infine cercando di applicare le tecnologie allo stato<br />

dell’arte già esistenti nel mondo dell’intelligenza artificiale su scala globale.<br />

Questo approccio, detto “A.I.-driven”, non ha <strong>per</strong>messo di risolvere <strong>il</strong> problema,<br />

ma i risultati ottenuti sono senz’altro di interesse in quanto hanno <strong>per</strong>messo<br />

di evidenziare che esistono delle lacune a livello <strong>infrastrutturale</strong> che devono<br />

essere necessariamente colmate <strong>per</strong> raggiungere i traguardi prefissati.<br />

L’attenzione si è quindi spostata sull’infrastruttura stessa del <strong>Web</strong> ed attualmente<br />

le ricerche stanno proseguendo nel f<strong>il</strong>one detto “<strong>Web</strong>-driven”.<br />

Il presente capitolo inizia con la descrizione dell’architettura del <strong>Web</strong> e dei<br />

suoi principi fondanti <strong>per</strong> poi passare ad analizzare come le ricerche si siano<br />

mosse e si stanno muovendo nella direzione di far evolvere <strong>il</strong> <strong>Web</strong> stesso da un<br />

sistema principalmente orientato alla pubblicazione di risorse fruib<strong>il</strong>i da esseri<br />

umani a piattaforma <strong>per</strong> la collaborazione ut<strong>il</strong>izzab<strong>il</strong>e sia dagli umani che dalle<br />

macchine.<br />

1.1 L’architettura del World Wide <strong>Web</strong><br />

Nel seguito di questo paragrafo si farà ampio riferimento ai seguenti termini,<br />

di cui si riporta la definizione ([W3C04]):<br />

• principio; un principio architetturale è un regola fondamentale che viene<br />

applicata ad un grande numero di situazioni. I principi architetturali<br />

includono:<br />

– separation <strong>of</strong> concerns;<br />

– generic interface;<br />

– self-descriptive syntax;<br />

– visible semantics;<br />

– network effect;<br />

• vincolo; nel progetto del <strong>Web</strong>, alcune scelte sono arbitrarie come i nomi<br />

<strong>per</strong> i tag“p”ed“li”nell’HTML, la scelta del carattere“:” negli URI o <strong>il</strong> raggruppamento<br />

dei bit in ottetti. I vincoli possono essere imposti <strong>per</strong> ragioni<br />

tecniche, di strategia o di altra natura con l’obiettivo di raggiungere nel<br />

sistema delle proprietà interessanti quali l’accessib<strong>il</strong>ità, la validità globale,<br />

la fac<strong>il</strong>ità nel realizzare successive modifiche, l’efficienza e l’estensib<strong>il</strong>ità<br />

dinamica;<br />

• good practice; <strong>per</strong>mettono di incrementare <strong>il</strong> valore del <strong>Web</strong> poiché costituiscono<br />

strategie e/o approcci e/o attività che a seguito di ricerche e<br />

valutazioni si sono dimostrate efficaci, efficienti, sostenib<strong>il</strong>i ed in grado di<br />

condurre in modo affidab<strong>il</strong>e al risultato auspicato.<br />

7


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Uno dei più importanti obiettivi del <strong>Web</strong>, fin dalle sue origini, è stato quello<br />

di realizzare <strong>una</strong> comunità che fosse in grado di condividere informazioni con<br />

ogni sua parte. Per raggiungere questo obiettivo è stato adottato un unico<br />

sistema di identificazione universale conosciuto con <strong>il</strong> nome di URI (Uniform<br />

Resource Identifier). Gli URI rappresentano la pietra d’angolo dell’architettura<br />

del <strong>Web</strong> poiché rappresentano un metodo di identificazione comune a tutto <strong>il</strong><br />

<strong>Web</strong>. La validità universale degli URI promuove su larga scala <strong>il</strong> network effect<br />

ovvero che <strong>il</strong> valore di un identificatore aumenta via via che è usato in modo<br />

consistente (vedi ad esempio all’interno di un hy<strong>per</strong>link). Dunque gli identificatori<br />

universali sono alla base di un principio del <strong>Web</strong> che si può riassumere in:<br />

“un sistema di nomi universale produce un network effect universale.”<br />

La scelta della sintassi <strong>per</strong> tali identificatori è arbitraria; l’unica cosa realmente<br />

importante è la loro validità universale. Dunque l’ut<strong>il</strong>izzo di URI come<br />

sistema di identificazione rappresenta <strong>una</strong> good practice <strong>per</strong> <strong>il</strong> <strong>Web</strong> che può<br />

essere sintetizzata affermando che: “<strong>per</strong> beneficiare ed incrementare <strong>il</strong> valore<br />

del <strong>Web</strong> è opportuno fornire URI come identificatori di risorse”. Per maggiori<br />

appr<strong>of</strong>ondimenti sugli URI vedi <strong>il</strong> paragrafo 1.2.<br />

Se nel <strong>Web</strong> si intende condividere <strong>una</strong> risorsa occorre che essa sia identificata<br />

da uno o più URI; questo <strong>per</strong>mette di creare link i<strong>per</strong>testuali che indicano la<br />

risorsa e, in generale, di distribuire gli URI come mezzo <strong>per</strong> <strong>per</strong>mettere l’accesso<br />

alle risorse.<br />

Se <strong>per</strong> definizione un URI identifica <strong>una</strong> risorsa è bene precisare cosa si intende<br />

con <strong>il</strong> termine risorsa. In generale <strong>il</strong> termine è ut<strong>il</strong>izzato <strong>per</strong> qualsiasi<br />

cosa che può essere identificata da un URI. In modo del tutto convenzionale<br />

nel <strong>Web</strong> vengono indicate come risorse pagine <strong>Web</strong>, immagini, cataloghi, video,<br />

eccetera. È possib<strong>il</strong>e raggruppare concettualmente tutte queste risorse con <strong>il</strong><br />

termine risorse informative. In realtà <strong>il</strong> termine risorsa ha un significato più<br />

ampio rispetto a quanto si potrebbe pensare associandolo esclusivamente all’insieme<br />

degli elementi che costituiscono le risorse informative. Altre entità come<br />

automob<strong>il</strong>i o cani sono anch’essi risorse, ma non di tipo informativo, in quanto<br />

la loro essenza non è veicolata da un’informazione ad essi associata. Si parla in<br />

questo caso di risorse non informative.<br />

Poiché la validità di un URI è universale, la risorsa identificata da un URI<br />

non dipende dal contesto in cui l’URI appare. Pertanto è necessario introdurre<br />

un vincolo sull’uso degli URI: “un URI può identificare al più <strong>una</strong> singola risorsa<br />

ovvero è necessario assegnare URI diversi a risorse diverse”.<br />

Viceversa è possib<strong>il</strong>e associare più di un URI alla medesima risorsa. Gli URI<br />

che fanno riferimento alla medesima risorsa sono chiamati alias.<br />

Usare lo stesso URI <strong>per</strong> identificare risorse diverse produce <strong>una</strong> collisione<br />

di URI. La presenza di <strong>una</strong> collisione rappresenta un costo che si concretizza<br />

nel processo che è necessario mettere in atto <strong>per</strong> sciogliere le ambiguità r<strong>il</strong>evate.<br />

8


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Sono state individuate delle apposite soluzioni di ordine sociale e tecnologico con<br />

<strong>il</strong> fine di evitare <strong>il</strong> sorgere di collisioni di URI. Prima di introdurre le soluzioni<br />

adottate è necessario specificare <strong>il</strong> significato dei seguenti termini:<br />

• allocazione di un URI. È <strong>il</strong> processo che associa un URI ad <strong>una</strong> risorsa;<br />

• responsab<strong>il</strong>ità su un URI. È la relazione che intercorre fra un URI e l’entità<br />

(ad esempio <strong>una</strong> <strong>per</strong>sona o un’organizzazione) che:<br />

– può allocare l’URI;<br />

– può trasferire la responsab<strong>il</strong>ità ad un’altra entità.<br />

Tramite <strong>una</strong> convenzione a livello sociale la responsab<strong>il</strong>ità su un URI è delegata<br />

dal registro degli schemi degli URI della IANA 1 . I responsab<strong>il</strong>i dei vari<br />

URI hanno anche la responsab<strong>il</strong>ità di non associare uno stesso URI a più risorse<br />

con <strong>il</strong> fine di evitare collisioni.<br />

Un caso a parte costituisce la cosiddetta identificazione indiretta che si può<br />

esemplificare dicendo che l’URI “ma<strong>il</strong>to:nadia@example.com” identifica sia la<br />

casella di posta di Nadia che, indirettamente, la stessa Nadia. L’ut<strong>il</strong>izzo della<br />

identificazione indiretta non necessariamente produce <strong>una</strong> collisione.<br />

URI identici carattere <strong>per</strong> carattere sono, di fatto, lo stesso URI e quindi si<br />

riferiscono alla stessa risorsa, ma, come introdotto precedentemente, <strong>una</strong> data<br />

risorsa può essere identificata da URI diversi. In generale quindi URI differenti<br />

non si riferiscono necessariamente a risorse diverse, ma determinare che URI<br />

diversi si riferiscono alla stessa risorsa comporta normalmente uno sforzo computazionale<br />

elevato. Con l’obiettivo di ridurre risultati di falso negativo o di<br />

falso positivo alcune specifiche descrivono test di equivalenza oltre al confronto<br />

carattere <strong>per</strong> carattere.<br />

Nonostante che l’uso di alias introduca dei benefici in termini di flessib<strong>il</strong>ità<br />

nell’assegnare nomi sono presenti anche degli aspetti negativi. In primo luogo<br />

l’uso di alias può compromettere <strong>il</strong> valore aggiunto descritto da un corollario<br />

della legge di Metcalfe (l’effetto network). Il corollario quantifica <strong>il</strong> valore di<br />

<strong>una</strong> risorsa tramite <strong>il</strong> numero e <strong>il</strong> valore delle risorse che ad essa sono collegate,<br />

indicate con <strong>il</strong> termine network neighbourhood. Se vengono usati due alias <strong>per</strong><br />

<strong>una</strong> stessa risorsa si può ipotizzare che metà delle risorse del network neighbourhood<br />

punteranno ad un URI mentre l’altra metà punterà all’altro URI. Da<br />

queste considerazioni è stata definita la seguente good practice: “i proprietari<br />

degli URI devono evitare di assegnare diversi URI <strong>per</strong> identificare <strong>una</strong> stessa<br />

risorsa”. Anche coloro che ut<strong>il</strong>izzano gli URI devono contribuire a mantenere la<br />

consistenza e da qui è scaturita un’altra good practice: “è opportuno ut<strong>il</strong>izzare<br />

sempre lo stesso URI, identico carattere <strong>per</strong> carattere, <strong>per</strong> riferirsi ad <strong>una</strong> certa<br />

1 Acronimo <strong>per</strong> Internet Assigned Numbers Authority: l’autorità che definisce i parametri<br />

<strong>per</strong> l’ut<strong>il</strong>izzo degli indirizzi IP e dei nomi di dominio e definisce le porte “ben note”.<br />

9


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

risorsa anche da parte di chi non è <strong>il</strong> responsab<strong>il</strong>e, ma solo un ut<strong>il</strong>izzatore”.<br />

Qualora esistano più alias <strong>per</strong> la stessa risorsa è opportuno che i responsab<strong>il</strong>i<br />

degli alias effettuino sempre delle redirection verso l’URI “ufficiale”.<br />

È altresì imporante sottolineare che se differenti risorse hanno la stessa rappresentazione<br />

ciò non significa che gli URI che le identificano siano alias. Si<br />

consideri l’esempio in cui esistono due distinte risorse di cui <strong>una</strong> è un documento<br />

che riporta <strong>una</strong> relazione sulle attuali condizioni meteorologiche a Firenze,<br />

mentre l’altra è un documento che riporta <strong>una</strong> relazione sulle condizioni meteorologiche<br />

a Firenze <strong>per</strong> <strong>il</strong> giorno 1 gennaio del 2000. Queste due risorse hanno<br />

URI diversi, ma <strong>il</strong> fatto che <strong>il</strong> giorno 1 gennaio del 2000 riportino le stesse informazioni<br />

(condividendo la stessa rappresentazione) non fa dei due URI degli<br />

alias.<br />

Gli URI sono suddivisi in diversi schemi. Ogni schema fa capo ad <strong>una</strong> specifica<br />

dove viene definito <strong>il</strong> meccanismo attraverso cui gli identificatori di un<br />

certo schema sono associati alle risorse. Lo schema HTTP-URI è uno dei più<br />

ut<strong>il</strong>izzati e si rimanda al paragrafo 1.2.4 <strong>per</strong> <strong>una</strong> trattazione più estesa dell’argomento.<br />

Ad esempio lo schema HTTP-URI si avvale di server DNS e di server<br />

HTTP (sopra TCP/IP) <strong>per</strong> risolvere gli identificatori ed accedere, ut<strong>il</strong>izzando<br />

la primitiva HTTP GET, a rappresentazioni delle risorse.<br />

Ogni schema <strong>per</strong> gli URI riporta <strong>una</strong> specifica che spiega i dettagli di come<br />

gli identificatori vengono allocati ed associati alle risorse. L’architettura del <strong>Web</strong><br />

<strong>per</strong>mette la definizione di nuovi schemi, ma introdurre nuovi schemi è comunque<br />

un’o<strong>per</strong>azione costosa. Da qui deriva la good practice: “è opportuno riut<strong>il</strong>izzare<br />

in <strong>una</strong> specifica uno schema URI già esistente (piuttosto che crearne uno nuovo)<br />

che fornisca le proprietà richieste <strong>per</strong> gli identificatori e le loro relazioni alle<br />

risorse”.<br />

Il collegamento fra gli schemi dei nomi degli URI e le specifiche degli schemi<br />

è contenuto in un registro gestito dalla IANA. Gli schemi non registrati non<br />

dovrebbero essere ut<strong>il</strong>izzati <strong>per</strong> i seguenti motivi:<br />

• non esiste un metodo condiviso <strong>per</strong> trovare la specifica dello schema;<br />

• qualcun’altro potrebbe usare lo stesso schema <strong>per</strong> altri scopi;<br />

• un s<strong>of</strong>tware general purpose non potrà far niente con URI con schemi di<br />

questo tipo oltre che la mera comparazione fra URI.<br />

Decidere quindi di registrare uno schema nel registro della IANA <strong>per</strong> <strong>per</strong>mettere<br />

ad un s<strong>of</strong>tware di eseguire <strong>una</strong> particolare applicazione dopo aver recu<strong>per</strong>ato<br />

<strong>una</strong> rappresentazione della risorsa è concettualmente sbagliato. Anche<br />

se <strong>il</strong> s<strong>of</strong>tware non può elaborare <strong>una</strong> rappresentazione di <strong>una</strong> risorsa espressa in<br />

un formato a lui non noto, può in ogni caso recu<strong>per</strong>arla (se lo schema è standardizzato).<br />

I dati contenuti possono comunque essere sufficientemente significativi<br />

10


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

da <strong>per</strong>metterne un qualche uso, ma se <strong>il</strong> s<strong>of</strong>tware non gestisce lo schema non<br />

può neanche recu<strong>per</strong>are la rappresentazione.<br />

Viceversa <strong>il</strong> modo previsto <strong>per</strong> costruire applicazioni che gestiscano nuovi<br />

formati dati è l’“Internet media type” (vedi <strong>il</strong> seguito del paragrafo <strong>per</strong> <strong>una</strong><br />

descrizione dell’Internet media type). Può sembrare allettante tentare di indovinare<br />

la natura della risorsa facendo un’ispezione di un URI che la identifica.<br />

Però <strong>il</strong> <strong>Web</strong> è progettato in modo che i s<strong>of</strong>tware agent comunichino lo stato di<br />

<strong>una</strong> risorsa tramite <strong>una</strong> rappresentazione e non tramite identificatori. Per esempio,<br />

l’estensione “.html” alla fine di “http://example.com/page.html” non dà<br />

ness<strong>una</strong> garanzia che le rappresentazioni della risorsa saranno fornite tramite <strong>il</strong><br />

media type di Internet di tipo “text/html”. L’ente che pubblica è libero di allocare<br />

identificatori e definire <strong>il</strong> tipo delle rappresentazioni che saranno restituite.<br />

Il protocollo HTTP non pone restrizioni sul media type sulla base della struttura<br />

dell’URI; <strong>il</strong> proprietario dell’URI è libero di configurare <strong>il</strong> server in modo<br />

che restituisca <strong>una</strong> rappresentazione usando PNG o un qualsiasi altro formato.<br />

Lo stato delle risorse può subire delle mutazioni al passare del tempo. Richiedere<br />

ad un proprietario di URI di pubblicare un nuovo URI <strong>per</strong> ogni cambiamento<br />

nello stato della risorsa comporterebbe un significante numero di riferimenti<br />

rotti. Per garantire maggiore robustezza l’architettura <strong>Web</strong> promuove<br />

l’indipendenza fra un identificatore e lo stato che l’identificatore rappresenta.<br />

Dunque è da considerare good practice: “i s<strong>of</strong>tware agent che fanno uso degli<br />

URI non dovrebbero cercare di realizzare inferenze sulle proprietà delle risorse<br />

identificate”.<br />

Per rispondere alla necessità di identificare <strong>una</strong> risorsa secondaria in modo<br />

indiretto ovvero facendo riferimento alla risorsa primaria e aggiungendo, al nome<br />

della stessa, ulteriori informazioni <strong>per</strong> l’identificazione della risorsa secondaria si<br />

può ut<strong>il</strong>izzare <strong>il</strong> componente dell’URI denominato identificatore di frammento<br />

(fragment identifier). La risorsa secondaria può essere <strong>una</strong> parte o un sottoinsieme,<br />

oppure <strong>una</strong> vista sulle rappresentazioni della risorsa primaria o qualche<br />

altro tipo di risorsa definito o descritto da quelle rappresentazioni.<br />

L’ut<strong>il</strong>izzo di termini quale primario o secondario non vuole essere <strong>una</strong> limitazione<br />

sulla natura della risorsa, semplicemente i termini primario o secondario<br />

indicano l’esistenza di <strong>una</strong> relazione fra le risorse tramite l’uso di un unico URI:<br />

ovvero l’URI con identificatore di frammento.<br />

Rimangono a<strong>per</strong>te ancora delle problematiche connesse all’uso degli identificatori<br />

nel <strong>Web</strong>:<br />

• integrare gli identificativi internazionali;<br />

• determinare se due URI identificano la stessa risorsa nell’ottica delle tecnologia<br />

del Semantic <strong>Web</strong> (vedi <strong>il</strong> caso di “owl:sameAs”).<br />

11


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

La comunicazione delle risorse fra s<strong>of</strong>tware agent in <strong>una</strong> rete coinvolge URI,<br />

messaggi e dati. I protocolli del <strong>Web</strong> (fra cui HTTP, FTP, SOAP, NNTP,<br />

SMTP) si basano sullo scambio di messaggi. Un messaggio può contenere sia dati<br />

che metadati relativi ad <strong>una</strong> risorsa, sia dati che metadati relativi al messaggio<br />

stesso.<br />

I s<strong>of</strong>tware agent possono usare URI <strong>per</strong> accedere alle risorse a cui fanno<br />

riferimento; in questo caso si parla di dereferenziazione dell’URI. Per accesso<br />

si possono intendere cose diverse: la richiesta di accesso alla rappresentazione<br />

della risorsa, la modifica della rappresentazione della risorsa o la distruzione di<br />

<strong>una</strong> o più rappresentazioni della risorsa.<br />

Possono esistere diversi modi <strong>per</strong> accedere ad <strong>una</strong> risorsa tramite uno stesso<br />

URI; <strong>il</strong> contesto dell’applicazione determina quale metodo di accesso l’agent<br />

deve usare. Per esempio, un browser potrebbe usare <strong>una</strong> HTTP GET <strong>per</strong> recu<strong>per</strong>are<br />

<strong>una</strong> rappresentazione di <strong>una</strong> risorsa, mentre <strong>per</strong> controllare solamente<br />

<strong>il</strong> funzionamento di un hy<strong>per</strong>link è sufficiente usare, sullo stesso URI, <strong>il</strong> metodo<br />

HTTP HEAD che <strong>per</strong>mette di determinare quali sono le rappresentazioni<br />

disponib<strong>il</strong>i.<br />

Alcuni schemi di URI pongono delle limitazioni sulle modalità a disposizione<br />

<strong>per</strong> accedere alle risorse [Moa97].<br />

Anche se molti schemi di URI hanno un nome che deriva da un protocollo<br />

ciò non implica che l’uso di quel tipo di URI comporti l’accesso alla risorsa tramite<br />

quel particolare protocollo. Infatti un s<strong>of</strong>tware agent ut<strong>il</strong>izza un URI <strong>per</strong><br />

recu<strong>per</strong>are <strong>una</strong> rappresentazione, ma può accedervi anche attraverso gateway,<br />

proxie, cache e servizi di ri<strong>soluzione</strong> dei nomi in modo indipendente dal protocollo<br />

associato con <strong>il</strong> nome dello schema. In ogni caso molti schemi definiscono<br />

un protocollo di default <strong>per</strong> l’accesso alla risorsa. La dereferenziazione di un<br />

URI implica <strong>una</strong> serie di passi che sono ampiamente descritti in molte specifiche<br />

e che vengono implementati dai s<strong>of</strong>tware agent. Quello che viene ottenuto<br />

alla fine del processo è (in assenza di errori) <strong>una</strong> rappresentazione della risorsa<br />

identificata dall’URI dereferenziato.<br />

Una rappresentazione è costituita dai dati che codificano l’informazione sullo<br />

stato di <strong>una</strong> risorsa. Le rappresentazioni non necessariamente descrivono la risorsa,<br />

o tentano di tratteggiare l’aspetto della risorsa, o rappresentano la risorsa<br />

nel senso comune attribuito alla parola rappresentare. Le rappresentazioni di<br />

<strong>una</strong> risorsa possono essere spedite o ricevute ricorrendo a protocolli di interazione.<br />

Questi protocolli a loro volta determinano la struttura fisica con cui le rappresentazioni<br />

sono effettivamente trasmesse sul <strong>Web</strong>. Per esempio l’HTTP usa<br />

flussi di ottetti definiti tramite gli Internet media types [FB96]. Generalizzando<br />

si introduce la seguente good practice: “i nuovi protocolli creati <strong>per</strong> trasportare<br />

informazioni sul <strong>Web</strong> dovrebbero trasmettere rappresentazioni sotto forma flussi<br />

di ottetti ottenuti tramite gli Internet media types”. Il meccanismo connesso<br />

12


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

agli Internet media types ha <strong>per</strong>ò alcune limitazioni. Per esempio le stringhe<br />

dei media type non comportano <strong>il</strong> versionamento e altri parametri. Gli Internet<br />

media types <strong>per</strong>mettono anche di definire la sintassi e la semantica connessa al<br />

cosidetto fragment identifier che possono essere ut<strong>il</strong>izzate in congiunzione con<br />

l’eventuale rappresentazione. La semantica del fragment identifier è definita<br />

tramite un insieme di rappresentazioni che possono essere recu<strong>per</strong>ate dopo aver<br />

dereferenziato <strong>una</strong> risorsa primaria. Il formato e la ri<strong>soluzione</strong> di un fragment<br />

identifier sono dunque dipendenti dal tipo di rappresentazione che può essere<br />

recu<strong>per</strong>ata e tale recu<strong>per</strong>o è realizzato solo se la risorsa è dereferenziata. Se non<br />

esiste ness<strong>una</strong> semantica collegata alla rappresentazione del fragment identifier<br />

allora la semantica viene considerata sconosciuta e di conseguenza non definisce<br />

come interpretare <strong>il</strong> fragment. L’interpretazione del fragment è realizzata esclusivamente<br />

dal s<strong>of</strong>tware agent che dereferenzia l’URI; <strong>il</strong> fragment identifier non<br />

viene passato ad altri sistemi durante <strong>il</strong> processo di recu<strong>per</strong>o della risorsa. È fac<strong>il</strong>e<br />

comprendere allora come alcuni intermediatori all’interno della architettura<br />

del <strong>Web</strong> (ad esempio i proxy) non abbiano alc<strong>una</strong> interazione con i fragment e<br />

come <strong>il</strong> meccanismo di redirection nell’HTTP non tenga in alcun modo conto<br />

dei fragment.<br />

La content negotiation si riferisce alla possib<strong>il</strong>ità di restituire molteplici rappresentazioni<br />

attraverso lo stesso URI. La content negotiation fra l’agent richiedente<br />

e <strong>il</strong> server <strong>per</strong>mette di determinare quale rappresentazione deve essere<br />

restituita (di solito l’obiettivo è restituire la rappresentazione migliore che l’agent<br />

possa gestire). HTTP è un protocollo che <strong>per</strong>mette ai provider di rappresentazioni<br />

di effettuare la content negotiation anche in congiunzione con<br />

un URI nei quali è presente <strong>il</strong> fragment identifier. Ad esempio <strong>il</strong> proprietario<br />

dell’URI “http://weather.example.com/tuscany/map#florence” può ut<strong>il</strong>izzare<br />

la content negotiation <strong>per</strong> fornire due diverse rappresentazioni della risorsa<br />

identificata. In questo caso possono essere individuate tre diverse situazioni:<br />

1. l’interpretazione di “florence” è definita in modo consistente da entrambe<br />

le specifiche dei due formati di dati;<br />

2. l’interpretazione di “florence” non è definita in modo consistente <strong>per</strong> le<br />

specifiche dei due formati di dati;<br />

3. l’interpretazione di “florence” è definita solo nella specifica di un formato<br />

di dati e non nell’altro.<br />

Chiaramente la prima situazione non pone alcun problema. Il secondo caso<br />

è un errore nella gestione del server, infatti i provider di rappresentazioni non<br />

devono usare la content negotiation in quei casi in cui la semantica dei fragment<br />

identifier non è consistente. L’ultimo caso <strong>per</strong>ò non è errore di gestione del<br />

server, anzi costituisce uno dei modi in cui <strong>il</strong> <strong>Web</strong> riesce a crescere. Il <strong>Web</strong> infatti<br />

è un sistema distribuito in cui formati ed agent sono messi in o<strong>per</strong>a in modo non<br />

13


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

uniforme, dunque gli autori di contenuti possono ut<strong>il</strong>izzare nuovi formati di dati<br />

riuscendo ugualmente ad ottenere ancora <strong>una</strong> soddisfacente retrocompatib<strong>il</strong>ità<br />

<strong>per</strong> tutti gli agent che non li ut<strong>il</strong>izzano. È bene mettere in evidenza che quando<br />

un formato di dati recu<strong>per</strong>ato non definisce la semantica del fragment identifier,<br />

l’agent dovrebbe sempre segnalare un errore all’utente a meno che non sia stato<br />

configurato diversamente dall’utente stesso.<br />

Una comunicazione avvenuta con successo implica anche <strong>una</strong> comprensione<br />

condivisa della semantica dei messaggi scambiati. Possono esserci <strong>per</strong>ò delle<br />

inconsistenze fra i dati e metadati dei messaggi inviati. Sarebbe opportuno<br />

che gli agent riceventi fossero in grado di individuare inconsistenze e realizzare<br />

un’appropriata correzione dell’errore. A tal fine si rende necessaria l’introduzione<br />

di un vincolo: “gli agent non devono ignorare i metadati dei messaggi<br />

ricevuti se non richiesto esplicitamente dall’utente”. A questo si associa la good<br />

practice: “gli amministratori dei server dovrebbero consentire ai creatori delle<br />

rappresentazioni di controllare i metadati associati alle rappresentazioni stesse”.<br />

In particolare i creatori delle rappresentazioni hanno la necessità di poter controllare<br />

<strong>il</strong> content-type (<strong>per</strong> l’estensib<strong>il</strong>ità) e la codifica dei caratteri (<strong>per</strong> <strong>una</strong><br />

corretta internazionalizzazione).<br />

Un’interazione safe (alla lettera un’interazione sicura) è quella che avviene<br />

quando l’agent non deve rispettare alc<strong>una</strong> obbligazione oltre l’interazione stessa.<br />

Le interazioni di tipo unsafe viceversa sono quelle che possono cambiare lo stato<br />

della risorsa e quindi l’utente può essere ritenuto responsab<strong>il</strong>e delle conseguenze<br />

dell’interazione. Un esempio di <strong>una</strong> interazione unsafe può essere la sottoscrizione<br />

ad <strong>una</strong> newsletter, pubblicare un commento o modificare un database. È<br />

bene mettere in evidenza che <strong>il</strong> termine unsafe (alla lettera insicuro) non viene<br />

inteso nel senso di <strong>per</strong>icoloso, ma è solo <strong>il</strong> termine scelto <strong>per</strong> essere <strong>il</strong> naturale<br />

opposto di safe [FGM + 99]. Le interazioni safe sono importanti <strong>per</strong>ché possono<br />

essere effettuate senza vincoli, ad esempio l’utente può recu<strong>per</strong>are <strong>una</strong> pagina<br />

o attraversare link i<strong>per</strong>testuali senza preoccupazioni. Vale dunque <strong>il</strong> seguente<br />

principio: “gli agent non devono sottostare a ness<strong>una</strong> obbligazione mentre recu<strong>per</strong>ano<br />

<strong>una</strong> rappresentazione”. Affinché ciò sia vero è <strong>per</strong>ò necessario rispettare<br />

alcune regole nella pubblicazione di rappresentazioni: ad esempio un URI che<br />

implica l’iscrizione ad <strong>una</strong> ma<strong>il</strong>ing list deve essere evitato in quanto, se viene<br />

seguito attraverso un link i<strong>per</strong>testuale, genera <strong>il</strong> cambiamento dello stato di <strong>una</strong><br />

risorsa e quindi un’interazione unsafe. Il fatto che HTTP GET, <strong>il</strong> metodo di<br />

accesso normalmente ut<strong>il</strong>izzato <strong>per</strong> seguire link i<strong>per</strong>testuali, sia un metodo safe<br />

non implica che tutte le transazioni safe debbano essere fatte attraverso <strong>il</strong><br />

metodo HTTP GET. In alcune situazioni può infatti essere opportuno effettuare<br />

un’interazione safe tramite meccanismi che di solito vengono generalmente<br />

adottati <strong>per</strong> o<strong>per</strong>azioni unsafe (ad esempio HTTP POST).<br />

14


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Il risultato di <strong>una</strong> o<strong>per</strong>azione unsafe (che ha modificato lo stato di <strong>una</strong> risorsa)<br />

potrebbe essere a sua volta <strong>una</strong> risorsa di interesse. Il protocollo HTTP<br />

prevede l’header “Content-Location” <strong>per</strong> specificare l’URI della risorsa presente<br />

del messaggio che contiene tale header qualora differisca dall’URI ut<strong>il</strong>izzato <strong>per</strong><br />

l’accesso. Ad esempio si può considerare <strong>una</strong> o<strong>per</strong>azione POST che, inviando<br />

tutti i dati necessari, effettui la prenotazione di un volo aereo; si consideri inoltre<br />

che <strong>il</strong> sistema fornisca come response alla POST la rappresentazione di <strong>una</strong><br />

risorsa che contenga l’esito della prenotazione. L’esito della prenotazione potrebbe<br />

essere a sua volta <strong>una</strong> risorsa di interesse <strong>per</strong> l’utente, ma egli non può<br />

effettuare <strong>una</strong> nuova POST <strong>per</strong> accedere, in un secondo momento, all’esito della<br />

prenotazione in quanto andrebbe ad effettuerebbe (almeno concettualmente)<br />

<strong>una</strong> nuova prenotazione. Viceversa l’header “Content-Location” ut<strong>il</strong>izzato nella<br />

response che contiene l’esito della prenotazione è un modo <strong>per</strong> fornire all’utente<br />

un URI (diverso da quello ut<strong>il</strong>izzato <strong>per</strong> la POST) della risorsa inviata nella<br />

response stessa, ut<strong>il</strong>izzab<strong>il</strong>e in un secondo tempo <strong>per</strong> accedere nuovamente al<br />

documento con <strong>una</strong> GET.<br />

Un proprietario di un URI può fornire zero o più rappresentazioni autoritative<br />

della risorsa identificata dall’URI, in ogni caso si introduce <strong>una</strong> good<br />

practice: “i proprietari di URI dovrebbero fornire almeno <strong>una</strong> rappresentazione<br />

della risorsa identificata dall’URI”. Per esempio i proprietari di URI in un namespace<br />

XML dovrebbero ut<strong>il</strong>izzarli <strong>per</strong> identificare <strong>il</strong> documento che descrive<br />

<strong>il</strong> namespace. In ogni modo solo <strong>per</strong>ché le rappresentazioni sono disponib<strong>il</strong>i ciò<br />

non implica che è sempre desiderab<strong>il</strong>e recu<strong>per</strong>arle, addirittura talvolta è vero<br />

proprio <strong>il</strong> contrario. Quindi è importante definire <strong>il</strong> seguente principio: “non<br />

dovrebbe essere richiesto di recu<strong>per</strong>are la rappresentazione di <strong>una</strong> risorsa ogni<br />

volta che viene referenziata”. Dereferenziare un URI infatti implica dei costi<br />

di computazione e di larghezza di banda, può inoltre avere implicazioni nella<br />

sicurezza e può imporre <strong>una</strong> latenza significativa nell’applicazione che viene dereferenziata.<br />

Quindi la dereferenziazione di un URI dovrebbe essere evitata se<br />

non è proprio indispensab<strong>il</strong>e.<br />

Il grado di confidenza nelle interazioni via <strong>Web</strong>, allo stesso modo di molte<br />

interazioni fra esseri umani, dipende dalla stab<strong>il</strong>ità e dalla predicib<strong>il</strong>ità. Per <strong>una</strong><br />

risorsa informativa la <strong>per</strong>sistenza dipende dalla consistenza delle rappresentazioni.<br />

È lo stesso provider della rappresentazione che decide quando le rappresentazioni<br />

sono sufficientemente consistenti. Benché la consistenza in questo caso sia<br />

osservab<strong>il</strong>e come risultato del recu<strong>per</strong>o dell’informazione, <strong>il</strong> termine <strong>per</strong>sistenza<br />

dell’URI è usato <strong>per</strong> indicare la proprietà desiderab<strong>il</strong>e che un URI, <strong>una</strong> volta<br />

associato ad <strong>una</strong> risorsa, continui sempre a riferirsi a quella risorsa. Dunque si<br />

introduce la seguente good practice: “un proprietario di URI dovrebbe fornire<br />

rappresentazioni della risorsa identificata in modo consistente e predicib<strong>il</strong>e”.<br />

15


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

La <strong>per</strong>sistenza di un URI è un problema che riguarda la politica adottata dal<br />

proprietario dell’URI. La scelta di un particolare schema di URI non fornisce<br />

alc<strong>una</strong> garanzia che quegli URI saranno o non saranno <strong>per</strong>sistenti. Il protocollo<br />

HTTP è stato progettato <strong>per</strong> fac<strong>il</strong>itare <strong>il</strong> mantenimento della <strong>per</strong>sistenza. Per<br />

esempio <strong>il</strong> meccanismo di redirection in HTTP <strong>per</strong>mette ai server di comunicare<br />

agli agent che sono necessarie altre o<strong>per</strong>azioni <strong>per</strong> portare a termine la<br />

richiesta fatta. Anche la stessa content-negotiation promuove la consistenza in<br />

quanto all’amministratore di un sito non è richiesto di definire nuovi URI <strong>per</strong><br />

poter distribuire nuovi formati di dati. Tutti quei protocolli che non dispongono<br />

di content-negotiation implicano la necessità di introdurre nuovi identificatori<br />

quando si vuole introdurre un nuovo formato. Si noti <strong>per</strong>ò che l’uso improprio<br />

della content-negotiation può condurre a rappresentazioni inconsistenti.<br />

Può essere ragionevole limitare l’accesso ad <strong>una</strong> risorsa, ma la sola identificazione<br />

attraverso l’URI equivale al riferirsi ad un libro con <strong>il</strong> solo titolo. In<br />

alcune circostanze è possib<strong>il</strong>e decidere di mantenere confidenziali gli URI (ad<br />

esempio <strong>per</strong>ché potrebbero veicolare informazioni riservate), ma <strong>il</strong> <strong>Web</strong> fornisce<br />

altri meccanismi <strong>per</strong> controllare l’accesso alle risorse (ad esempio <strong>il</strong> cosidetto<br />

deep linking [Gro03]).<br />

Uno dei punti di forza dell’architettura del <strong>Web</strong> consiste nel poter realizzare<br />

e condividere i link, infatti un utente che ha trovato informazioni interessanti<br />

può condividere la sua es<strong>per</strong>ienza ripubblicando l’URI che ne <strong>per</strong>mette l’accesso.<br />

Per tutte quelle risorse che sono generate su richiesta, la creazione automatica<br />

dell’URI è <strong>una</strong> prassi comune. Gli amministratori dei server web dovrebbero<br />

cercare di rendere gli URI quanto più riusab<strong>il</strong>i possib<strong>il</strong>e in modo da <strong>per</strong>mettere<br />

<strong>una</strong> maggiore diffusione delle informazioni. Nel caso in cui si volesse poi<br />

restringere l’uso delle informazioni connesse ad un particolare URI ad un solo<br />

utente, vedi <strong>il</strong> caso delle applicazioni <strong>per</strong> l’home banking, è necessario ricorrere<br />

a meccanismi adeguati <strong>per</strong> <strong>il</strong> controllo degli accessi.<br />

Una specifica di formato dei dati rappresenta l’accordo raggiunto sulla corretta<br />

interpretazione dei dati. Il primo formato usato sul <strong>Web</strong> fu HTML, ma<br />

l’architetta del <strong>Web</strong> non pone alcun vincolo sul tipo di formato che i provider<br />

di contenuti possono ut<strong>il</strong>izzare. Tale flessib<strong>il</strong>ità è un aspetto importante <strong>per</strong>ché<br />

esiste <strong>una</strong> costante evoluzione nelle applicazioni, che comporta l’ut<strong>il</strong>izzo di nuovi<br />

formati di dati e <strong>il</strong> raffinamento di quelli già esitenti. Nonostante che l’architettura<br />

del <strong>Web</strong> consenta l’adozione di nuovi formati, la creazione e la messa in<br />

o<strong>per</strong>a di questi formati comporta spese considerevoli. Quindi prima di definire<br />

un nuovo formato di dati è opportuno considerare attentamente <strong>il</strong> riut<strong>il</strong>izzo di<br />

un formato già esistente.<br />

I formati di dati si possono suddividere in formati binari e formati testuali.<br />

I fomati binari sono quelli in cui porzioni di dati sono codificate <strong>per</strong> un uso<br />

diretto da parte dei computer. Un formato dati testuale è quello in cui i dati sono<br />

16


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

codificati come <strong>una</strong> sequenza di caratteri. Se un formato di dati è testuale questo<br />

non implica che debba essere connesso ad un media type che inizia con “text/”.<br />

In linea di principio tutti i dati possono essere rappresentati tramite formati<br />

testuali, ma in pratica alcuni tipi di contenuti (ad esempio audio e video) sono<br />

generalmente rappresentati usando formati binari. Il trade-<strong>of</strong>f fra dati testuali e<br />

binari è complesso e dipende dalle applicazioni coinvolte. Di solito l’uso di dati<br />

binari <strong>per</strong>mette di ottenere <strong>una</strong> maggiore compattezza, può essere manipolato<br />

con maggiore rapidità dagli agent in tutti quei casi in cui è possib<strong>il</strong>e caricare<br />

direttamente i dati in memoria con minime conversioni. Dall’altro lato i dati<br />

testuali sono di solito più portab<strong>il</strong>i ed intero<strong>per</strong>ab<strong>il</strong>i. I formati testuali <strong>of</strong>frono<br />

inoltre <strong>il</strong> notevole vantaggio di poter essere direttamente compresi dall’essere<br />

umano.<br />

Nel mondo reale spesso i progettisti di linguaggi interpretano in modo non<br />

totalmente corretto i requisiti, che a loro volta potrebbero modellare in modo<br />

non adeguato la realtà oppure essere in conflitto o cambiare nel tempo. Come<br />

risultato i progettisti di linguaggi spesso scendono a compromessi e non è<br />

infrequente che vengano introdotti meccanismi di estensib<strong>il</strong>ità in modo che sia<br />

possib<strong>il</strong>e aggirare eventuali nuovi problemi in tempo ragionevole. A lungo termine<br />

producono diverse versioni dei loro linguaggi in conseguenza dell’evoluzione<br />

del problema e della loro comprensione di esso. La variab<strong>il</strong>ità che consegue<br />

in specifiche, linguaggi ed implementazioni introduce costi di intero<strong>per</strong>ab<strong>il</strong>ità.<br />

Estensib<strong>il</strong>ità e versioning sono strategie che <strong>per</strong>mettono di aiutare la gestione<br />

della naturale evoluzione dell’informazione sul <strong>Web</strong> e delle tecnologie usate <strong>per</strong><br />

la rappresentazione dell’informazione. Esiste di solito un (lungo) <strong>per</strong>iodo di<br />

transizione durante <strong>il</strong> quale coesistono in uso molteplici versioni di un formato,<br />

di un protocollo o di un agent. Dunque la seguente è <strong>una</strong> good practice: “ogni<br />

versione di <strong>una</strong> specifica <strong>per</strong> un formato dati dovrebbe contenere dei metadati<br />

che <strong>per</strong>mettano di identificarla senza ambiguità”.<br />

Nel caso dell’XML cambiare <strong>il</strong> nome del namespace di un elemento cambia<br />

completamente <strong>il</strong> nome dell’elemento. Dunque in termini pratici ciò significa<br />

che sulle applicazioni dove l’elemento veniva ut<strong>il</strong>izzato dovrà essere effettuato<br />

un upgrade: ciò può comportare costi anche molto elevati.<br />

Ne consegue che si devono tenere bene in considerazione le potenziali conseguenze<br />

che possono scaturire modificando un namespace. Se un vocabolario non<br />

<strong>of</strong>fre punti di estensib<strong>il</strong>ità (ovvero non <strong>per</strong>mette di usare elementi o attributi<br />

da namespace esterni oppure non dispone di meccanismi <strong>per</strong> gestire nomi non<br />

conosciuti all’interno dello stesso namespace) <strong>per</strong> effettuare un aggiornamento<br />

potrebbe essere necessario cambiare <strong>il</strong> namespace. Tutti quei linguaggi che invece<br />

<strong>per</strong>mettono qualche forma di estensib<strong>il</strong>ità senza richiedere <strong>una</strong> variazione<br />

del namespace avranno la possib<strong>il</strong>ità di evolversi in modo più efficace. Si può<br />

dunque definire la seguente good practice: “<strong>una</strong> specifica di formato basata sul-<br />

17


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

l’XML dovrebbe includere anche informazioni sulle politiche che vengono seguite<br />

relativamente agli aggiornamenti del namespace”.<br />

Anche i requisiti cambiano nel tempo. Le tecnologie di successo sono adottate<br />

e adattate dai nuovi utenti. I progettisti di linguaggi possono fac<strong>il</strong>itare<br />

<strong>il</strong> processo di transizione facendo attente scelte circa l’estensib<strong>il</strong>ità durante la<br />

progettazione di un linguaggio oppure la specifica di un protocollo. Nel fare<br />

queste scelte, i progettisti devono attentamente valutare i trade-<strong>of</strong>f fra estensib<strong>il</strong>ità,<br />

semplicità e variab<strong>il</strong>ità. Un linguaggio che non preveda un meccanismo<br />

di estensib<strong>il</strong>ità può essere più semplice e meno variab<strong>il</strong>e <strong>of</strong>frendo, almeno all’inizio,<br />

<strong>una</strong> migliore intero<strong>per</strong>ab<strong>il</strong>ità. Comunque i cambiamenti in linguaggi di<br />

questo tipo sono tipicamente più complessi da apportare rispetto al caso di linguaggi<br />

che prevedono meccanismi <strong>per</strong> l’estensib<strong>il</strong>ità. È quindi da considerarsi<br />

<strong>una</strong> good practice la seguente: “<strong>una</strong> specifica dovrebbe fornire dei meccanismi<br />

che <strong>per</strong>mettano di creare delle estensioni, tenendo presente che l’estensib<strong>il</strong>ità<br />

non deve compromettere <strong>il</strong> rispetto delle specifiche iniziali”. Inoltre è anche <strong>una</strong><br />

good practice: “<strong>una</strong> specifica dovrebbe prevedere <strong>il</strong> comportamento dell’agent<br />

nel caso in cui vengano trovate estensioni sconosciute”. Due strategie che si sono<br />

dimostrate particolarmente ut<strong>il</strong>i <strong>per</strong> la realizzazione di questa good practice<br />

sono le seguenti:<br />

1. “must ignore”: l’agent deve ignorare ogni contenuto non riconosciuto;<br />

2. “must understand”: l’agent gestisce i contenuti non riconosciuti come<br />

errori.<br />

Un approccio estremamente interessante è quello di ammettere entrambe le<br />

forme <strong>per</strong> l’estensione, ma di distinguere esplicitamente fra di loro nella sintassi.<br />

Per quanto riguarda i formati di dati vanno sempre considerati meccanismi<br />

di composizione. Ad esempio è possib<strong>il</strong>e inserire commenti testuali in alcuni<br />

formati di immagini oppure che la semantica <strong>per</strong> combinare documenti RDF<br />

contenenti molteplici vocabolari è ben definita. Quindi è possib<strong>il</strong>e creare un’immagine<br />

in cui è presente un commento espresso in RDF che descrive l’immagine<br />

semanticamente.<br />

Inoltre è buona pratica <strong>per</strong> gli autori creare contenuti che siano in grado di<br />

raggiungere un pubblico <strong>il</strong> più vasto possib<strong>il</strong>e che comprenda utenti che usano<br />

desktop grafici, strumenti portat<strong>il</strong>i e telefoni cellulari, utenti disab<strong>il</strong>i che possono<br />

dover ricorrere a sintetizzatori vocali e, in generale, strumenti ancora nemmeno<br />

immaginati. L’es<strong>per</strong>ienza suggerisce di separare contenuti, presentazione e interazione<br />

<strong>per</strong> promuovere <strong>il</strong> riuso e l’indipendenza del contenuto dallo strumento:<br />

questa affermazione deriva dall’applicazione del principio di ortogonalità. È<br />

<strong>una</strong> good practice: “<strong>una</strong> specifica dovrebbe <strong>per</strong>mettere agli autori di separare <strong>il</strong><br />

contenuto sia dalla presentazione sia dall’interazione”.<br />

18


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Occorre sottolineare che se contenuto, presentazione ed interazione sono<br />

tenuti separati sarà compito del s<strong>of</strong>tware agent ricombinarli insieme.<br />

Una caratteristica fondamentale del <strong>Web</strong> è che <strong>per</strong>mette di realizzare collegamenti<br />

ad altre risorse con estrema semplicità ovvero creando link i<strong>per</strong>testuali<br />

tramite URI assoluti e relativi. Forse proprio questo aspetto ne ha decretato <strong>il</strong><br />

grande successo. Se <strong>una</strong> rappresentazione di <strong>una</strong> risorsa contiene un reference<br />

verso un altra risorsa, tramite l’ut<strong>il</strong>izzo di un URI che identifica l’altra risorsa,<br />

è possib<strong>il</strong>e dire che <strong>il</strong> reference costituisce un link fra le due risorse.<br />

È da considerarsi <strong>una</strong> good practice la seguente: “<strong>una</strong> specifica dovrebbe<br />

<strong>per</strong>mettere di identificare i link verso altra risorse, comprese le risorse secondarie”.<br />

Un formato che <strong>per</strong>mette agli autori di contenuti di ut<strong>il</strong>izzare URI invece<br />

che identificatori locali promuove <strong>il</strong> network effect. È <strong>una</strong> good practice: “<strong>una</strong><br />

specifica dovrebbe <strong>per</strong>mettere di realizzare collegamenti su tutto <strong>il</strong> <strong>Web</strong> e non<br />

solo relativi a documenti locali”. Inoltre un’altra good practice prevede che: “un<br />

formato di dati dovrebbe incorporare i collegamenti i<strong>per</strong>testuali se <strong>il</strong> paradigma<br />

<strong>per</strong> l’interfaccia utente è l’i<strong>per</strong>testo”. Formati di dati che non <strong>per</strong>mettono agli<br />

autori di contenuto di creare link i<strong>per</strong>testuali comportano la creazione di “nodi<br />

terminali” sul <strong>Web</strong>.<br />

Molti formati di dati si basano sul linguaggio XML e quindi sono conformi<br />

con le regole sintattiche definite nella specifica XML [BPSM + 08]. XML <strong>per</strong>mette<br />

di definire formati dati testuali molto adatti nel descrivere oggetti con <strong>una</strong><br />

struttura gerarchica che devono essere elaborati in <strong>una</strong> sequenza particolare.<br />

Alcuni punti a favore dell’uso di formati basati su XML sono:<br />

1. requisiti di avere <strong>una</strong> struttura gerarchica;<br />

2. bisogno di avere <strong>una</strong> grande varietà di tools su <strong>una</strong> grande varietà di<br />

piatt<strong>of</strong>orme;<br />

3. necessità di dati che possono sopravvivere alle applicazioni che li manipolano;<br />

4. possib<strong>il</strong>ità di realizzare internazionalizzazione in modo auto descrittivo<br />

rendendo diffic<strong>il</strong>e eventuale confusione con le opzioni di codifica;<br />

5. r<strong>il</strong>evamento precoce degli errori senza la necessità di dover far dei workaround;<br />

6. contenuto testuale leggib<strong>il</strong>e anche dagli esseri umani;<br />

7. composizione del formato dati con altri formati basati su XML;<br />

8. necessità di vocabolari che possono essere inventati in modo distribuito e<br />

poi combinati a piacere.<br />

19


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Sono state inoltre realizzate s<strong>of</strong>isticate tecniche <strong>per</strong> realizzare link in formato<br />

XML. Ad esempio XPointer 2 <strong>per</strong>mette di fare link ad indirizzi senza avere<br />

un’ancora specifica. Invece XLink 3 <strong>per</strong>mette ai link di avere molteplici punti<br />

di fine e che sono espressi sia inline o in un database di link esterno a tutte le<br />

risorse identificate dai link stessi.<br />

XML <strong>of</strong>fre la possib<strong>il</strong>ità di creare namespace <strong>il</strong> cui fine è di <strong>per</strong>mettere la<br />

realizzazione di vocabolari XML (che definiscono elementi ed attributi) in un<br />

ambiente globale e ridurre <strong>il</strong> rischio di collisioni di nomi in un dato documento<br />

quando più vocabolari sono combinati. I vocabolari XML riducono <strong>il</strong> rischio<br />

di collisioni ricorrendo a sistemi <strong>per</strong> allocare nomi a livello globale: gli URI. È<br />

<strong>una</strong> good practice: “<strong>una</strong> specifica che definisce un vocabolario XML dovrebbe<br />

posizionare tutti i nomi di elementi e i nomi degli attributi globali in un namespace”.<br />

Un altro vantaggio nell’ut<strong>il</strong>izzare URI <strong>per</strong> realizzare namespace XML è<br />

che l’URI può essere usato <strong>per</strong> identificare la risorsa informativa che contiene<br />

informazioni ut<strong>il</strong>i, usab<strong>il</strong>i dall’uomo o dagli agent, circa i termini usati nel namespace.<br />

Questo tipo di risorsa informativa è chiamato “namespace document”<br />

e quando un possessore di namespace fornisce tramite la relativa URI <strong>il</strong> namespace<br />

document, esso è quello autoritativo. Ci sono molte ragioni <strong>per</strong> fornire un<br />

namespace document, <strong>una</strong> <strong>per</strong>sona potrebbe volere:<br />

• capire quali sono gli obiettivi del namespace;<br />

• imparare ad usare <strong>il</strong> vocabolario definito nel namespace;<br />

• capire chi è <strong>il</strong> responsab<strong>il</strong>e del documento e le politiche che vi sono associate;<br />

• richiedere ai responsab<strong>il</strong>i di accedere agli schemi ed ai materiali collaterali<br />

collegati al namespace;<br />

• riportare bug o situazioni che possono essere considerate un errore in<br />

materiale collaterale.<br />

Per quanto riguarda invece un agent potrebbe essere necessario:<br />

• recu<strong>per</strong>are lo schema <strong>per</strong> fare <strong>una</strong> validazione;<br />

• recu<strong>per</strong>are i fogli di st<strong>il</strong>e <strong>per</strong> la rappresentazione;<br />

• recu<strong>per</strong>are ontologie <strong>per</strong> fare inferenze.<br />

A seguito di queste necessità è opportuno seguire la good practice: “<strong>il</strong> responsab<strong>il</strong>e<br />

di un namespace XML dovrebbe mantenere sempre disponib<strong>il</strong>e <strong>il</strong> materiale<br />

sia <strong>per</strong> gli esseri umani che <strong>per</strong> i s<strong>of</strong>tware agent in modo da assecondare<br />

le esigenze di coloro che ut<strong>il</strong>izzano <strong>il</strong> vocabolario del namespace”.<br />

2 http://www.w3.org/TR/xptr/.<br />

3 http://www.w3.org/TR/xlink/.<br />

20


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

Il termine “QName” indica in modo compatto l’espressione “nome qualificato<br />

in documenti XML”. Un nome qualificato è <strong>una</strong> coppia costituita da un URI,<br />

che indica un namespace, ed un nome locale appartenente al namespace. Ne<br />

consegue <strong>il</strong> seguente vincolo: “non si possono ut<strong>il</strong>izzare QName e URI nei valori<br />

degli attribuiti o nel contenuto degli elementi quando questi sono indistinguib<strong>il</strong>i”.<br />

Poiché i QName sono compatti alcuni progettisti di specifiche hanno adottato<br />

la stessa sintassi <strong>per</strong> identificare le risorse. Non esiste <strong>per</strong>ò un modo singolo<br />

universalemente riconosciuto da tutti <strong>per</strong> trasformare un QName in un URI. Ne<br />

consegue la seguente good practice: “<strong>una</strong> specifica in cui i QName sono usati<br />

come identificatori di risorse deve fornire un mapping fra QName e URI”.<br />

Per quanto riguarda i tipi di formati basati su XML usati in Internet la RFC<br />

3023 ([MLK01]) definisce i tipi “application/xml” e “text/xml”, inoltre descrive<br />

<strong>una</strong> convenzione dove i formati basati su XML usano tipi con suffisso “+xml”,<br />

<strong>per</strong> esempio“image/svg+xml”.<br />

Per quanto riguarda l’adozione del formato “text/xml” occorre tenere presente<br />

che esistono due problemi associati ai tipi di formato “text”: primo, <strong>per</strong> i<br />

dati identificati come “text/” gli intermediari <strong>Web</strong> possono realizzare la transcodifica<br />

ovvero convertire <strong>una</strong> codifica di carattere in un’altra. La transcodifica<br />

può essere causa di un documento mal formato. Da queste considerazioni è<br />

possib<strong>il</strong>e evincere la good practice che: “<strong>il</strong> fornitore di <strong>una</strong> rappresentazione<br />

non dovrebbe assegnare un tipo di formato Internet che cominci con “text/” <strong>per</strong><br />

le rappresentazioni basate su XML”. Il secondo problema associato al tipo di<br />

formato “text/” è che questi formati sono considerati codificati in US-ASCII,<br />

a meno che non venga specificato <strong>il</strong> parametro charset. Ma poiché la sintassi<br />

XML è progettata <strong>per</strong> creare documenti autodescrittivi è sempre <strong>una</strong> good<br />

practice che: “<strong>il</strong> fornitore di <strong>una</strong> rappresentazione non specifichi la codifica di<br />

carattere <strong>per</strong> i dati XML negli header del protocollo poiché i dati XML sono<br />

autodescrittivi di <strong>per</strong> sé”.<br />

I progettisti di formati di dati basati su XML dovrebbero inoltre definire<br />

la semantica degli identificatori di frammento <strong>per</strong> quel formato. Il framework<br />

XPointer fornisce un punto di partenza intero<strong>per</strong>ab<strong>il</strong>e. Quando <strong>il</strong> tipo di formati<br />

Internet assegnato alla rappresentazione è “application/xml” non sono specificate<br />

semantiche <strong>per</strong> gli identificatori di frammento e gli autori non dovrebbero<br />

far uso degli identificatori di frammento <strong>per</strong> tali dati. In breve solo conoscendo<br />

che <strong>il</strong> contenuto è XML non si ottengono informazioni sulla semantica degli<br />

identificatori di frammento.<br />

È bene sottolineare che identificazione, interazione e rappresentazione sono<br />

concetti ortogonali, ovvero che le tecnologie usate <strong>per</strong> identificazione, interazione<br />

e rappresentazione possono evolvere indipendentemente. Per esempio:<br />

• le risorse sono identificate tramite URI. Gli URI possono essere pubblicati<br />

21


Stato dell’arte: <strong>il</strong> <strong>Web</strong> L’architettura del World Wide <strong>Web</strong><br />

senza <strong>of</strong>frire ness<strong>una</strong> rappresentazione della risorsa o senza determinare se<br />

<strong>una</strong> qualsiasi rappresentazione è disponib<strong>il</strong>e;<br />

• <strong>una</strong> generica sintassi <strong>per</strong> gli URI <strong>per</strong>mette ai s<strong>of</strong>tware agent di funzionare<br />

senza conoscere le specifiche dello schema URI usato;<br />

• in molti casi è possib<strong>il</strong>e cambiare la rappresentazione della risorsa senza<br />

corrom<strong>per</strong>e i riferimenti alla risorsa stessa (ad esempio usando la content<br />

negotiation).<br />

Quando due specifiche sono ortogonali è possib<strong>il</strong>e cambiarne <strong>una</strong> senza effettuare<br />

dei cambiamenti nell’altra anche se <strong>una</strong> ha delle dipendenze rispetto<br />

all’altra. L’ortogonalità incrementa la flessib<strong>il</strong>ità e la robustezza del <strong>Web</strong>.<br />

L’estensib<strong>il</strong>ità è quella proprietà che promuove l’evoluzione senza sacrificare<br />

l’intero<strong>per</strong>ab<strong>il</strong>ità. Alcuni esempi di tecnologie che <strong>per</strong>mettono di effettuare dei<br />

cambiamenti senza causare problemi sono:<br />

• <strong>il</strong> fatto che gli schemi degli URI sono definiti in modo ortogonale;<br />

• l’uso di un set a<strong>per</strong>to di Internet media types <strong>per</strong> caratterizzare l’interpretazione<br />

dei documenti;<br />

• i modelli di estensib<strong>il</strong>ità previsti nei Cascading Style Sheets (CSS), in<br />

XSLT 1.0 ed in SOAP;<br />

• plug-in <strong>per</strong> gli user agent.<br />

Per quanto riguarda i linguaggi, un linguaggio è detto un subset di un altro<br />

linguaggio se ogni documento nel primo linguaggio è anche un documento valido<br />

nel secondo linguaggio ed ha la stessa interpretazione. Se un linguaggio è un<br />

subset di un altro, quest’ultimo è chiamato linguaggio esteso; la differenza fra i<br />

due linguaggi è detta estensione. Estendere un linguaggio è più conveniente in<br />

termini di intero<strong>per</strong>ab<strong>il</strong>ità che creare un linguaggio incompatib<strong>il</strong>e.<br />

Nei sistemi distribuiti possono avvenire errori e le condizioni d’errore possono<br />

essere ben caratterizzate oppure verificarsi in modo imprevedib<strong>il</strong>e. La “correzione<br />

dell’errore” si ha quando l’agent riesce a riparare alla condizione di errore<br />

e proseguire come se questa non si fosse verificata. Il “recu<strong>per</strong>o dell’errore” si<br />

ha quando l’agent non corregge la condizione d’errore, ma riesce a continuare<br />

nell’elaborazione considerando <strong>il</strong> fatto che è avvenuto un errore. Gli agent che<br />

fanno un recu<strong>per</strong>o di errore realizzando <strong>una</strong> scelta senza <strong>il</strong> consenso dell’utente<br />

non stanno o<strong>per</strong>ando in vece dell’utente.<br />

I progettisti di un protocollo dovrebbero fornire abbastanza informazioni<br />

circa <strong>una</strong> condizione d’errore in modo che un agent possa gestire la condizione<br />

di errore. Inoltre l’es<strong>per</strong>ienza ottenuta (in termini di costi di sv<strong>il</strong>uppo) con la<br />

realizzazione di user agent che gestiscono HTML mal formato hanno convinto<br />

22


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

i progettisti delle specifiche XML a richiedere che gli agent che fruiscono di<br />

contenuti XML non gestiscano documenti mal formati.<br />

1.2 Uniform Resource Identifier<br />

Di fatto tutti i protocolli in uso su Internet sono dotati di un qualche sistema<br />

interno in grado di individuare e localizzare le risorse: in altri termini si può dire<br />

che ogni protocollo individua un insieme di oggetti che possono essere raggiunti<br />

ed acceduti associando loro un nome o un indirizzo. Tali nomi o indirizzi sono<br />

<strong>per</strong>ò validi solo nell’ambito delle risorse accessib<strong>il</strong>i dal protocollo stesso: questo<br />

ambito è comunemente noto come spazio dei nomi. In sintesi ogni protocollo ha<br />

uno schema di denominazione che individua uno spazio dei nomi.<br />

Poiché nel caso del <strong>Web</strong> uno stesso sistema deve poter accedere a risorse<br />

collocate in spazi dei nomi diversi, è necessaria la presenza di uno spazio universale<br />

dei nomi e degli indirizzi che <strong>per</strong>metta di identificare ogni risorsa astraendo<br />

dai requisiti tecnici di ogni singolo protocollo. I membri di tale spazio universale<br />

vengono detti Uniform Resource Identifier (URI). Un URI è <strong>per</strong>tanto <strong>una</strong><br />

stringa che identifica <strong>una</strong> qualunque risorsa (un documento, un’immagine, un<br />

f<strong>il</strong>e scaricab<strong>il</strong>e, etc.) ed eventualmente <strong>per</strong>mette di accedere ad essa mediante<br />

un determinato protocollo, individuab<strong>il</strong>e a partire dallo schema dell’URI stesso.<br />

1.2.1 La grammatica<br />

Come definito nella RFC 1630 [Ber94], la sintassi di un generico URI è<br />

esprimib<strong>il</strong>e nel modo seguente:<br />

:<br />

Un URI è <strong>per</strong>tanto costituito da due parti, separate dal simbolo “:”. La<br />

prima parte è detta schema ed individua uno spazio dei nomi. Come indicato<br />

dal nome stesso, la seconda parte () non ha <strong>una</strong> struttura<br />

generale valida <strong>per</strong> tutti gli URI, ma dipende dallo specifico schema ut<strong>il</strong>izzato.<br />

In ogni caso un ampio sottoinsieme di URI condivide <strong>una</strong> sintassi comune <strong>per</strong><br />

rappresentare eventuali relazioni gerarchiche all’interno dello spazio dei nomi<br />

individuato dallo schema. Questa sintassi consiste di <strong>una</strong> sequenza di cinque<br />

componenti ed è esprimib<strong>il</strong>e nel modo seguente:<br />

://?#fragment<br />

Nel seguito si riporta la semantica relativa ai cinque campi che costituiscono<br />

<strong>il</strong> formato generale di un URI.<br />

• : è lo schema di interpretazione del URI ed è l’unica, delle cinque<br />

componenti, a dover necessariamente comparire in ogni URI. Come<br />

23


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

detto in precedenza, lo schema di un URI individua lo spazio dei nomi cui<br />

esso appartiene. L’elenco degli schemi ammissib<strong>il</strong>i è re<strong>per</strong>ib<strong>il</strong>e all’indirizzo<br />

http://www.iana.org/assignments/uri-schemes.html ed è gestito<br />

dalla IANA.<br />

• : la presenza esplicita di tale segmento individua un’organizzazione<br />

gerarchica nello spazio dei nomi individuato dallo schema. A sua<br />

volta un’autorità può essere espressa come [userinfo@] host [:port].<br />

La parte userinfo non deve essere presente se lo schema non prevede<br />

un’identificazione <strong>per</strong>sonale; la parte host è un nome di dominio o un<br />

indirizzo IP; l’elemento port può essere omesso se ci si riferisce ad <strong>una</strong><br />

porta well-known 4 .<br />

• : è la parte che identifica la risorsa all’interno dello spazio dei nomi<br />

individuato dallo schema e (se presente) dall’authority. Poiché la presenza<br />

di <strong>una</strong> parte authority individua uno spazio dei nomi gerarchico, nei casi<br />

in cui essa è presente <strong>il</strong> path risulta suddiviso in più segmenti, separati<br />

dal carattere “/”, ognuno dei quali appartiene ad un livello distinto della<br />

gerarchia.<br />

• : individua un’ulteriore specializzazione della risorsa all’interno<br />

dello spazio dei nomi identificato dallo schema e dal URI precedente. Di<br />

solito questa parte, compresa tra <strong>il</strong> punto interrogativo e <strong>il</strong> carattere hash<br />

(“#”), contiene dei parametri che specificano un risultato dinamico, quale<br />

ad esempio l’output di <strong>una</strong> query su un motore di ricerca.<br />

• : individua <strong>una</strong> risorsa secondaria, associata a quella identificata<br />

dalle parti precedentemente elencate.<br />

Per concludere, si riportano infine alcuni esempi di URI:<br />

ftp://ftp.klid.dk/ubuntu-cd/hardy/ubuntu-8.04.2-server-amd64.iso<br />

http://www.google.it/search?hl=it&q=ingegneria+firenze&btnG=Cerca&meta=<br />

ma<strong>il</strong>to:davide.chini@unifi.it<br />

telnet://lrst.det.unifi.it<br />

1.2.2 URI relative<br />

La sintassi generale, riportata nel paragrafo precedente, si riferisce unicamente<br />

ad URI assolute che identificano <strong>una</strong> risorsa in maniera totalmente indipendente.<br />

In realtà, come riportato nella RFC 3986 [BLFM05], esistono anche<br />

URI relativi che identificano <strong>una</strong> risorsa facendo sempre riferimento ad un URI<br />

4 L’uso delle porte well-known è riservato ai protocolli di rete standard. Un elenco dei<br />

numeri di porta well-known e dei protocolli ad essi associati è disponib<strong>il</strong>e in un database<br />

on-line re<strong>per</strong>ib<strong>il</strong>e all’indirizzo http://www.iana.org ([Rey02]).<br />

24


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

di base (ad esempio, l’URI assoluto del documento contenente l’URI relativo)<br />

rispetto al quale fornire elementi di differenza.<br />

Da un punto di vista grammaticale la differenza principale tra le due categorie<br />

di URI risiede nel fatto che, diversamente da un URI relativo, un URI<br />

assoluto contiene tutte le parti predefinite dal suo schema esplicitamente precisate.<br />

In particolare in un URI relativo è sicuramente mancante la parte schema.<br />

A titolo di esempio si elencano alcuni URI relativi che fanno riferimento all’URI<br />

di base http://a/b/c/d?q, riportando a fianco di ognuno di essi l’URI assoluto<br />

equivalente:<br />

g = http://a/b/c/g<br />

../g = http://a/g<br />

../../g = http://g<br />

?y = http://a/b/c/d?y<br />

#s = http://a/b/c/d?q#s<br />

Da un punto di vista funzionale va invece detto che la categoria di appartenenza<br />

di un URI influisce notevolmente sulla modalità di ri<strong>soluzione</strong> dell’identificatore<br />

stesso. Infatti la ri<strong>soluzione</strong> di un URI relativo richiede sempre<br />

l’attuazione dei due passi seguenti:<br />

• conversione del URI relativo nella rispettiva forma assoluta;<br />

• ottenimento della risorsa associata all’URI assoluto, determinata al passo<br />

precedente.<br />

Viceversa un URI assoluto può essere immediatamente risolto nella risorsa<br />

ad esso associata.<br />

1.2.3 Uniform Resource Locator<br />

Gli Uniform Resource Locator (URL) sono un sottoinsieme del più generale<br />

insieme degli URI. In particolare un URL codifica formalmente l’indirizzo della<br />

risorsa ad esso associata, rendendola accessib<strong>il</strong>e mediante uno dei protocolli<br />

attualmente in uso su Internet.<br />

Da un punto di vista sintattico la differenza principale tra URI e URL risiede<br />

dunque nel fatto che negli URL gli schemi esplicitano sempre un determinato<br />

protocollo di ri<strong>soluzione</strong>, mentre in un generico URI possono comparire anche<br />

schemi che non indicano alcun protocollo. A tal proposito è assai esemplificativo<br />

<strong>il</strong> caso degli URN che, pur essendo anch’essi un sottoinsieme degli URI, non<br />

specificano alcun protocollo d’accesso alle risorse da essi identificate. Gli schemi<br />

principali, che sono attualmente registrati <strong>per</strong> gli URL, sono i seguenti:<br />

• http: <strong>per</strong> <strong>il</strong> protocollo HTTP:<br />

• ftp: <strong>per</strong> <strong>il</strong> F<strong>il</strong>e Transfer Protocol;<br />

25


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

• gopher: <strong>per</strong> <strong>il</strong> Gopher protocol;<br />

• ma<strong>il</strong>to: <strong>per</strong> gli indirizzi di posta elettronica secondo <strong>il</strong> protocollo MAILTO;<br />

• news: <strong>per</strong> i messaggi dei newsgroup secondo <strong>il</strong> protocollo NNTP;<br />

• wais: <strong>per</strong> <strong>il</strong> protocollo WAIS;<br />

• f<strong>il</strong>e: <strong>per</strong> l’accesso a f<strong>il</strong>e locali;<br />

• telnet, login: <strong>per</strong> sessioni interattive in modalità terminale secondo i<br />

protocolli TELNET e RLOGIN.<br />

1.2.4 HTTP-URIs<br />

Lo schema HTTP-URI <strong>per</strong>mette di identificare ed eventualmente accedere a<br />

risorse in maniera estremamente efficace ed efficiente. Come in ogni URI è possib<strong>il</strong>e<br />

individuare lo schema, che nello specifico vale http o https, l’authority, <strong>il</strong><br />

path, la query ed <strong>il</strong> fragment. L’authority è un nome universale riferito al proprietario<br />

della risorsa che si vuole identificare (<strong>il</strong> soggetto che ha autorità sulla<br />

risorsa stessa) mentre <strong>il</strong> path, che si basa su <strong>una</strong> sintassi gerarchica, <strong>per</strong>mette<br />

di distinguere risorse diverse che fanno capo allo stesso proprietario. Oltre alla<br />

struttura gerarchica del path è possib<strong>il</strong>e introdurre ulteriori parametri flat con<br />

la query. Infine <strong>il</strong> fragment <strong>per</strong>mette di individuare <strong>una</strong> risorsa secondaria associata<br />

a quella identificata dagli altri parametri (e trattata esclusivamente lato<br />

client). Il DNS e i web server sono i sistemi normalmente ut<strong>il</strong>izzati <strong>per</strong> recu<strong>per</strong>are<br />

<strong>una</strong> (o più di <strong>una</strong>) rappresentazione di risorse informative identificate con<br />

HTTP-URI: <strong>il</strong> DNS è incaricato di gestire la prima parte del nome (l’authority)<br />

in modo da <strong>per</strong>mettere all’utente di connettersi con <strong>il</strong> web server autoritativo<br />

sulla risorsa; <strong>il</strong> web server, analizzando la seconda parte (<strong>il</strong> path) del nome ed i<br />

parametri (la query) connessi alla richiesta, è incaricato di recu<strong>per</strong>are e fornire<br />

all’utente la rappresentazione più opport<strong>una</strong> della risorsa. Dunque avendo la necessità<br />

di ricorrere ad un meccanismo <strong>per</strong> l’identificazione e l’accesso alle risorse,<br />

essendo lo schema HTTP-URI uno fra i più ut<strong>il</strong>izzati e diffusi, è sempre opportuno<br />

verificare che lo schema in questione non soddisfi tutti i requisiti imposti<br />

dallo scenario in esame. Infatti la realizzazione di <strong>una</strong> <strong>soluzione</strong> equivalente in<br />

termini di efficacia ed efficienza non è certo un compito semplice. Inoltre può<br />

capitare che al termine del lavoro si riesca a dimostrare che <strong>il</strong> nuovo sistema di<br />

nomi è isomorfo a quello basato su HTTP-URI (ovvero del tutto equivalente ad<br />

esso in termini di espressività e quant’altro) rendendo lo sforzo che è stato fatto<br />

<strong>per</strong> realizzarlo del tutto vano.<br />

Nella maggior parte dei casi l’introduzione di nuovi schemi di URI è sostenuta<br />

dall’affermazione che gli HTTP-URI non sono in grado di soddisfare alcune<br />

esigenze contingenti allo scenario in questione. In realtà spesso si tratta di affermazioni<br />

non corrette basate su <strong>una</strong> non completa conoscenza degli HTTP-URI.<br />

26


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

Per questo motivo questo paragrafo è dedicato ad appr<strong>of</strong>ondire le caratteristiche<br />

ed i requisiti che, più o meno direttamente, gli HTTP-URI possiedono e,<br />

rispettivamente, soddisfano.<br />

Persistenza. Questo requisito può essere inteso in due modi diversi:<br />

• in maniera più blanda, ovvero intendendolo come un modo <strong>per</strong> dare fine<br />

all’errore “404 NOT FOUND”;<br />

• in un modo più rigoroso ovvero intendendolo come la possib<strong>il</strong>ità che la<br />

risorsa identificata rimanga sempre la stessa.<br />

Va sottolineato <strong>per</strong>ò, che raggiungere uno dei gradi di <strong>per</strong>sistenza, sia <strong>il</strong> più<br />

forte che <strong>il</strong> più debole, non è un problema tecnologico, ma semplicemente un<br />

problema di management. È dunque compito degli o<strong>per</strong>atori e dei proprietari<br />

delle risorse decidere quali meccanismi mettere in atto <strong>per</strong> realizzare la <strong>per</strong>sistenza<br />

delle risorse, indipendentemente dallo schema in uso <strong>per</strong> identificarle e/o<br />

raggiungerle. Non esiste quindi alc<strong>una</strong> differenza fra l’ut<strong>il</strong>izzo di HTTP-URI e<br />

altri schemi di URI rispetto a tale problema. Inoltre è possib<strong>il</strong>e fare in modo che<br />

<strong>il</strong> nome stesso <strong>per</strong>metta di capire se esso si riferisce ad <strong>una</strong> risorsa <strong>per</strong>sistente<br />

o meno. A tal fine è sufficiente adottare <strong>una</strong> semplice convenzione nell’uso dei<br />

nomi, <strong>per</strong> esempio usando le iniziali minuscole <strong>per</strong> risorse non <strong>per</strong>sistenti ed<br />

usando invece iniziali maiuscole <strong>per</strong> risorse <strong>per</strong>sistenti.<br />

Libertà di assegnazione. Con questo requisito si vuole raggiungere l’obiettivo<br />

di poter assegnare gli URI senza <strong>una</strong> qualche forma di su<strong>per</strong>visione. Ovviamente<br />

si tratta di un problema che non ha niente a che vedere con la tecnologia,<br />

ma solo con scelte di management. Infatti niente di ciò che potrà essere stab<strong>il</strong>ito<br />

in <strong>una</strong> direttiva impedirà alle <strong>per</strong>sone di realizzare gli URI che vogliono.<br />

Sarà dunque sempre compito di organismi centralizzati indicare delle politiche<br />

affinché <strong>una</strong> determinata struttura degli URI identifichi un certo proprietario<br />

invece che un altro.<br />

Per quanto riguarda gli HTTP-URI gli unici vincoli imposti riguardano la<br />

parte più autoritativa del nome di dominio. Dopo che un ente incaricato ha<br />

assegnato <strong>il</strong> nome, ad esempio “example.com”, a colui <strong>il</strong> quale lo ha richiesto,<br />

esso potrà assegnare tutti i nomi nella gerarchia “example.com” come meglio<br />

crede a patto, ovviamente, di rispettare le specifiche del sistema DNS.<br />

In questo modo potrà definire tutti i nomi del tipo “a-name.example.com”,<br />

“another-name.example.com” e, rispettando la delega, scendere di livello in<br />

modo più o meno arbitrario (“a-name.another-name.example.com”). D’altra<br />

parte <strong>il</strong> responsab<strong>il</strong>e di un nome di dominio può assegnare path, query component<br />

e fragment come meglio crede (a patto di formare HTTP-URI validi sintatticamente)<br />

e <strong>per</strong>tanto si capisce che complessivamente i vincoli da rispettare<br />

nella creazione di HTTP-URI sono realmente minimi.<br />

27


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Uniform Resource Identifier<br />

Indipendenza dal protocollo ut<strong>il</strong>izzato. Gli HTTP-URI non dipendono<br />

dal protocollo di comunicazione più di altri schemi di URI. Infatti se si deve<br />

solo rispondere ad <strong>una</strong> esigenza di identificazione di <strong>una</strong> risorsa gli HTTP-URI<br />

vanno bene come qualsiasi altro tipo di URI in quanto, <strong>per</strong> questo fine, <strong>il</strong> prefisso<br />

“http://” è da considerarsi <strong>una</strong> semplice stringa alfanumerica priva di<br />

significato. Quando occorre invece passare al recu<strong>per</strong>o della risorsa sarà necessario<br />

realizzare un mapping fra <strong>il</strong> generico URI a disposizione e <strong>il</strong> protocollo di<br />

comunicazione ut<strong>il</strong>izzato e, ad oggi, la maggior parte degli schemi fa capo al<br />

protocollo di comunicazione HTTP e dunque si trovano nella stessa condizione<br />

degli HTTP-URI. Se in futuro <strong>il</strong> protocollo HTTP cadrà in disuso, sarà necessario<br />

dover realizzare un nuovo mapping <strong>per</strong> tutti gli schemi URI, non solo <strong>per</strong><br />

gli HTTP-URI.<br />

È bene <strong>per</strong>ò sottolineare che <strong>per</strong> lo streaming di dati multimediali quali<br />

audio, video, etc. l’ut<strong>il</strong>izzo del protocollo HTTP non è ottimale e dunque è<br />

possib<strong>il</strong>e che in questi casi particolari sia auspicab<strong>il</strong>e l’uso di altri schemi.<br />

In ogni caso niente vieta di ut<strong>il</strong>izzare tecniche di redirect e quant’altro che<br />

<strong>per</strong>mettano, partendo da un HTTP-URI, di passare ad altri schemi dopo <strong>una</strong><br />

prima interazione con un web server. In altre parole è possib<strong>il</strong>e identificare<br />

qualunque risorsa con HTTP-URI ed è possib<strong>il</strong>e quantomeno iniziare <strong>il</strong> processo<br />

di accesso partendo da un nome di questo tipo.<br />

Indipendenza dalla locazione. Gli HTTP-URI <strong>per</strong> lungo tempo sono stati<br />

considerati locazioni (ne è effettivamente <strong>una</strong> riprova anche <strong>il</strong> nome che è stato<br />

definito: URL ovvero Uniform Resource Locator), ma non è così sia nei principi,<br />

come ribadito chiaramente nella RFC 3986 [BLFM05], che in pratica attuando<br />

opportune politiche di gestione lato server. Per alcuni esempi è possib<strong>il</strong>e fare<br />

riferimento al noto documento [Ber98].<br />

Nomi Strutturati. Strutturare i nomi in modo da avere <strong>per</strong> essi un significato<br />

standardizzato ed ampiamente condiviso è un requisito raggiungib<strong>il</strong>e anche<br />

usando gli HTTP-URI: è infatti possib<strong>il</strong>e sfruttare <strong>il</strong> path, che segue <strong>una</strong> struttura<br />

gerarchica, <strong>il</strong> query component, che segue <strong>una</strong> struttura in termini di coppie<br />

nome/valore ed <strong>il</strong> fragment <strong>per</strong> veicolare convenzioni.<br />

Accesso uniforme ai metadati. Tramite gli HTTP-URI è possib<strong>il</strong>e accedere<br />

non solo alle risorse, ma anche ai metadati connessi a queste risorse ut<strong>il</strong>izzando<br />

convenzioni sui nomi e/o l’header del messaggio di risposta.<br />

Persistenza degli identificatori. Un namespace, ad esempio, potrebbe essere<br />

<strong>il</strong> seguente: “http://docs.oasis-open.org/ws-rx/wsrm/200602”; tale namespace<br />

sarà stato creato da OASIS, senza l’intervento di terze parti, essendo<br />

<strong>il</strong> dominio “oasis-open.org” di sua proprietà. Inoltre, <strong>una</strong> volta creato, non<br />

28


Stato dell’arte: <strong>il</strong> <strong>Web</strong> REpresentational State Transfer<br />

è necessario che OASIS registri l’URI completo da qualche parte e sarà sempre<br />

OASIS ad avere l’autorità di cambiare <strong>il</strong> nome <strong>per</strong> proprio conto senza dover<br />

sottostare a ness<strong>una</strong> verifica.<br />

Fissato <strong>il</strong> nome, come <strong>per</strong> tutti gli URI, la <strong>per</strong>sistenza di un qualsiasi identificatore<br />

e schema sono compito del proprietario del dominio.<br />

È altresì possib<strong>il</strong>e che <strong>il</strong> dominio cessi di essere proprietà di OASIS a causa<br />

di mancanza di manutenzione o di errori di vario tipo oppure è anche possib<strong>il</strong>e<br />

ipotizzare uno scenario in cui, fra molti anni, OASIS non esisterà più. Il<br />

nome di dominio “oasis-open.org” e gli identificatori HTTP-URI non saranno<br />

più assegnati ed OASIS non produrrà più nessun nuovo URN. In entrambi<br />

i casi gli identificatori connessi a OASIS, se lo fossero stato, non saranno più<br />

dereferenziab<strong>il</strong>i, ma tutto <strong>il</strong> s<strong>of</strong>tware esistente continuerà a lavorare.<br />

Riassumendo, esattamente come accade <strong>per</strong> gli schemi URN-URI, <strong>per</strong> gli<br />

HTTP-URI la <strong>per</strong>sistenza degli identificatori deve essere garantita a livello<br />

organizzativo, e solo marginalmente a livello tecnico, dal responsab<strong>il</strong>e che li<br />

gestisce.<br />

Dereferenziab<strong>il</strong>ità. Ut<strong>il</strong>izzando gli HTTP-URI <strong>per</strong> identificare le risorse è<br />

possib<strong>il</strong>e avvalersi dell’infrastruttura <strong>Web</strong> esistente <strong>per</strong> dereferenziare l’URI ed<br />

accedere alla risorsa stessa. Chiaramente non è detto che l’accesso sia sempre<br />

necessario, come negli esempi summenzionati nei quali si ipotizza l’uso di<br />

HTTP-URI <strong>per</strong> identificare dei namespace. Anche in questo caso <strong>per</strong>ò si possono<br />

ottenere dei benefici in quanto, pur facendo riferimento a risorse astratte (<strong>il</strong><br />

namespace), è possib<strong>il</strong>e <strong>of</strong>frire dei documenti che contengano ut<strong>il</strong>i informazioni<br />

sul namespace stesso.<br />

1.3 REpresentational State Transfer<br />

Diversamente a quanto avviene <strong>per</strong> <strong>il</strong> termine SOA (Service Oriented Architecture)<br />

ed <strong>il</strong> termine <strong>Web</strong> <strong>of</strong> Data, <strong>il</strong> Representional State Transfer, a cui ci<br />

si riferisce con l’acronimo REST, ha <strong>una</strong> origine ed <strong>una</strong> definizione riconosciuta<br />

e legittimata nel capitolo cinque della tesi di dottorato di Roy T. Fielding,<br />

pubblicata nel 2000 [Fie00].<br />

La sopra esposta precisazione è necessaria in quanto REST è stato da molti<br />

male interpretato ed usato erroneamente generando molteplici interpretazioni,<br />

quando l’unica interpretazione è quella di Fielding.<br />

Il REST è uno st<strong>il</strong>e <strong>per</strong> architetture s<strong>of</strong>tware e precisamente è lo st<strong>il</strong>e del<br />

<strong>Web</strong>. È infatti nato durante la stesura del protocollo HTTP di cui Fielding è<br />

coautore [FGM + 99]. Il REST è un modello astratto, ed <strong>il</strong> <strong>Web</strong> è <strong>una</strong> architettura<br />

concreta che si basa sui principi di questo modello. Il modello è definito da un<br />

insieme di vincoli architetturali, che applicati ad un sistema lo rendono RESTful:<br />

29


Stato dell’arte: <strong>il</strong> <strong>Web</strong> REpresentational State Transfer<br />

<strong>il</strong> <strong>Web</strong> è RESTful non soltanto <strong>per</strong>ché rispetta questi vincoli, ma <strong>per</strong>ché è <strong>il</strong> caso<br />

specifico dal quale sono stati dedotti i principi <strong>per</strong> definire <strong>il</strong> modello.<br />

Il primo vincolo che <strong>una</strong> architettura RESTful deve rispettare è l’interazione<br />

tra componenti di tipo client-server. Il sistema è fatto di componenti classificati<br />

come server, che <strong>of</strong>frono servizi e rimangono in ascolto di richieste, oppure client,<br />

i quali fruiscono dei servizi e ut<strong>il</strong>izzano un connettore <strong>per</strong> inviare richieste. Il<br />

concetto di connettore in REST è un elemento che incapsula le attività di accesso<br />

alle risorse e di trasferimento delle loro rappresentazioni.<br />

Il secondo vincolo del REST è l’assenza di stato della interazione clientserver.<br />

Questo concetto è spesso frainteso, poiché anche un servizio o <strong>una</strong> risorsa<br />

possono avere uno stato, ma <strong>il</strong> REST pone questo vincolo specificatamente<br />

sulla comunicazione: ogni richiesta da parte di un client deve contenere tutte<br />

le informazioni necessarie affinché possa essere compresa, e non può trarre<br />

vantaggio da contenuti memorizzati nel server. Lo stato della sessione è quindi<br />

mantenuto interamente nel client. L’applicazione di questo principio migliora<br />

la visib<strong>il</strong>ità, poiché <strong>una</strong> interazione che contiene tutte le informazioni può essere<br />

più fac<strong>il</strong>mente monitorata, ed incrementa l’affidab<strong>il</strong>ità e la scalab<strong>il</strong>ità del<br />

sistema. L’overhead introdotto dalla ripetizione dei dati può <strong>per</strong>ò portare ad<br />

un peggioramento delle prestazioni.<br />

Per migliorare l’efficienza dei sistemi, in REST si usa <strong>il</strong> la cache, ovvero un<br />

client, <strong>per</strong> richieste ripetute, può usare <strong>una</strong> risposta memorizzata in precedenza,<br />

eliminando così la necessità di alcune interazioni. Questo vincolo richiede<br />

che i dati di <strong>una</strong> risposta siano etichettati come cachable o non-cachable,<br />

implicitamente o esplicitamente.<br />

L’architettura <strong>Web</strong> delle origini era definita dall’insieme di vincoli clientcache-stateless-server.<br />

Quello che distingue <strong>il</strong> REST da altre architetture basate<br />

sul networking, è <strong>il</strong> vincolo di interfaccia uniforme tra componenti. Questo<br />

principio disaccoppia le implementazioni dalle funzionalità, semplifica <strong>il</strong> sistema<br />

e migliora la visib<strong>il</strong>ità delle interazioni, ma degrada l’efficienza poiché le informazioni<br />

sono trasferite in <strong>una</strong> forma generalizzata piuttosto che in <strong>una</strong> forma<br />

specificatamente progettata <strong>per</strong> i bisogni applicativi.<br />

Un’interfaccia uniforme è efficiente <strong>per</strong> la trasmissione di i<strong>per</strong>media. Questo<br />

principio impone altri vincoli sulle funzionalità <strong>of</strong>ferte dalla interfaccia di<br />

un sistema RESTful: l’identificazione delle risorse e la loro manipolazione deve<br />

avvenire tramite <strong>una</strong> rappresentazione. Una risorsa è <strong>una</strong> qualsiasi informazione<br />

dotata di nome: un documento, un’immagine, un oggetto non virtuale<br />

(<strong>una</strong> <strong>per</strong>sona, un animale, <strong>una</strong> città). In REST si usano resource identifier <strong>per</strong><br />

identificare particolari risorse coinvolte nelle interazioni tra i componenti del<br />

sistema, i quali compiono azioni su di esse usando <strong>una</strong> resource representation<br />

<strong>per</strong> catturarne lo stato. Una rappresentazione in REST è <strong>una</strong> sequenza di byte<br />

più <strong>una</strong> sequenza di metadati che descrivono questi byte.<br />

30


Stato dell’arte: <strong>il</strong> <strong>Web</strong> REpresentational State Transfer<br />

Un’architettura REST è stratificata. Questo <strong>per</strong>mette di adattare i sistemi<br />

ai requisiti di scalab<strong>il</strong>ità dei grandi network come Internet. La stratificazione<br />

<strong>per</strong>mette alle architetture di essere composte di layer gerarchici, così da disaccoppiarne<br />

i componenti e promuovere l’indipendenza tra stati non adiacenti, ed i<br />

vari strati possono incapsulare servizi legacy od <strong>of</strong>frire nuovi servizi ai client preesistenti.<br />

D’altro canto, la stratificazione incrementa la complessità dei sistemi,<br />

aggiunge overhead ed aumenta la latenza nell’elaborazione dei dati.<br />

L’ultimo vincolo che Fielding aggiunge ad un sistema REST deriva dallo<br />

st<strong>il</strong>e “code-on-demand”, <strong>per</strong> <strong>il</strong> quale un sistema RESTful <strong>per</strong>mette di estendere<br />

le funzionalità scaricando ed eseguendo nuove istruzioni in forma di applet o<br />

script. Questo vincolo è opzionale, <strong>per</strong>ché <strong>per</strong>mette di estendere le funzionalità<br />

limitate dal vincolo di interfaccia uniforme, ma riduce la visib<strong>il</strong>ità del sistema.<br />

Questo termine è stato usato spesso <strong>per</strong> descrivere <strong>una</strong> tipologia di servizi<br />

<strong>Web</strong> non basati su SOAP, ma come abbiamo visto <strong>il</strong> REST non prescrive l’uso<br />

di particolari protocolli o standard e non specifica quali o<strong>per</strong>azioni deve <strong>of</strong>frire<br />

un’interfaccia, purché questa sia uniforme e sia orientata alle risorse. Sotto<br />

questo aspetto REST può essere posto su un piano di confronto con le Service<br />

Oriented Architecture.<br />

1.3.1 Sintesi delle proprietà<br />

Indipendentemente dalla interpretazione della definizione originale o di successive<br />

derivazioni in sintesi REST deve possedere le seguenti proprietà fondamentali:<br />

• Statelessness: la comunicazione deve essere senza stato affinché ogni richiesta<br />

dal client debba contenere tutte le informazioni necessarie al server<br />

<strong>per</strong> interpretare correttamente la richiesta. Si osservi che <strong>il</strong> server può<br />

comunque mantenere uno stato ed ut<strong>il</strong>izzare le informazioni di stato (<strong>per</strong><br />

le istanze) <strong>per</strong> elaborare correttamente la richiesta. La questione importante<br />

è che <strong>il</strong> client non debba dipendere dal server <strong>per</strong> <strong>il</strong> contesto della<br />

richiesta.<br />

• Cacheab<strong>il</strong>ity: ogni risorsa trasferita tra client e server deve essere marcata<br />

come cacheable o altrimenti <strong>il</strong> minimo possib<strong>il</strong>e non-cacheable.<br />

• Uniform interface: un sistema RESTful deve possedere un’interfaccia uniforme<br />

con le seguenti proprietà:<br />

– Identificazione delle risorse: un sistema RESTful conterrà <strong>una</strong> o più<br />

risorse ovvero <strong>il</strong> target del servizio indicato dall’identificatore concettuale<br />

(<strong>il</strong> tempo all’aeroporto di Firenze; <strong>il</strong> prezzo del libro “Divina<br />

Commedia”, etc): un URI nel senso di“Universal Resource Indicator”.<br />

31


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Resource Oriented Architecture<br />

– Manipolazione delle risorse attraverso la rappresentazione: <strong>una</strong> rappresentazione<br />

consiste in <strong>una</strong> serie di byte (es. un numero in formato<br />

testuale della tem<strong>per</strong>atura con in gradi centigradi, <strong>una</strong> immagine<br />

JPEG di <strong>una</strong> co<strong>per</strong>tina di un libro, un documento XML contenente<br />

tutte le informazioni metereologiche, un frammento di XHTML<br />

di <strong>una</strong> lista di attributi di libri). Si noti che non deve esistere <strong>una</strong><br />

relazione biunivoca tra la rappresentazione della risorsa e la risorsa<br />

stessa. La risorsa è disaccoppiata dalla sua rappresentazione.<br />

– Self-Descriptive Messages Meta-data, pure and simple: <strong>una</strong> rappresentazione<br />

di <strong>una</strong> risorsa possiede sia dati che metadati. I metadati<br />

possono essere indipendenti dalla rappresentazione, cioè possono<br />

avere rappresentazioni alternative.<br />

– Hy<strong>per</strong>media as the engine <strong>of</strong> application state: se applicab<strong>il</strong>e, dovrebbero<br />

esistere alcuni tipi di link <strong>per</strong> indicare lo stato successivo<br />

dell’applicazione in riferimento alla rappresentazione corrente inviata<br />

al client. L’esempio più ovvio può essere che <strong>una</strong> request POST<br />

che crea o modifica <strong>una</strong> risorsa deve restituire un puntatore ad <strong>una</strong><br />

rappresentazione di quella risorsa in <strong>una</strong> pagina HTML, oppure in<br />

maniera mutuamente esclusiva uno stato HTTP 302 (Found) o, più<br />

semanticamente, HTTP 303 (See Other).<br />

• Layered: ogni layer di un sistema REST non può agire oltre i confini<br />

del layer a cui è connesso. Ad esempio, <strong>il</strong> client verso <strong>il</strong> quale <strong>il</strong> servizio<br />

RESTful sta rispondendo, può non essere un client nel senso stretto del<br />

termine: può essere un altro server (es. un proxy). Un progettista di<br />

servizi RESTful non deve preoccuparsene, deve trattarlo come un client<br />

ed interpretare solamente le richieste e non chi le formula.<br />

• Vincoli opzionali allo st<strong>il</strong>e REST: un sistema REST può essere vincolato<br />

da code-on-demand. Significa che <strong>il</strong> codice viene scaricato ed eseguito<br />

dal client (es. Javascript, Flash, Java, etc.) come parte integrante della<br />

rappresentazione della risorsa.<br />

1.4 Resource Oriented Architecture<br />

Nel panorama dei <strong>Web</strong> Service [Jos07], RESTful è stato usato come aggettivo<br />

<strong>per</strong> classificare <strong>una</strong> tipologia di servizi basati su un approccio che usa i metodi<br />

HTTP <strong>per</strong> eseguire o<strong>per</strong>azioni remote, in contrapposizione all’approccio tipico<br />

WSDL, SOAP. Questi servizi hanno riscosso un discreto interesse, soprattutto da<br />

32


Stato dell’arte: <strong>il</strong> <strong>Web</strong> Resource Oriented Architecture<br />

parte di sv<strong>il</strong>uppatori orientati alla realizzazione di servizi di largo consumo <strong>per</strong><br />

<strong>il</strong> <strong>Web</strong>, e quindi non interessati alla costruzione di complessi sistemi enterprise 5 .<br />

L’origine di questa definizione discende dalla interpretazione di HTTP, quale<br />

riferimento di interfaccia uniforme, così come richiesto dallo st<strong>il</strong>e REST. Ma molti<br />

servizi etichettati come RESTful non rispettano tutti i vincoli di questo st<strong>il</strong>e<br />

e così i puristi della f<strong>il</strong>os<strong>of</strong>ia REST non esitano a definirli servizi “accidentally<br />

RESTful”, servizi “low REST” o “REST-RPC”.<br />

In questo panorama confuso, si inserisce Resource Oriented Architecture<br />

(ROA). ROA, presentata in [RR07], prescrive delle linee guida <strong>per</strong> realizzare<br />

architetture RESTful. Gli autori adottano questo termine <strong>per</strong> designare architetture<br />

che rispettano i principi del REST, ma mentre quest’ultimo specifica solo<br />

criteri di progettazione generici, le Resource Oriented Architecture sono esplicitamente<br />

legate alle tecnologie del <strong>Web</strong>. Nelle ROA le risorse sono indirizzate<br />

da URI e l’interfaccia uniforme ut<strong>il</strong>izzata è HTTP.<br />

Gli URI in questo contesto devono essere descrittivi, ovvero deve esistere<br />

<strong>una</strong> corrispondenza intuitiva tra questi e le risorse che indirizzano, e devono<br />

possedere uno schema sintattico. La strutturazione dei nomi <strong>per</strong>mette ai client<br />

di costruire gli indirizzi delle risorse alle quali desiderano accedere. Ci sono tre<br />

regole base <strong>per</strong> progettare gli URI:<br />

• si usa <strong>il</strong> path <strong>per</strong> codificare la gerarchia (eg. /parent/ch<strong>il</strong>d);<br />

• quando non sono presenti relazioni gerarchiche si usa la punteggiatura (eg.<br />

/parent/ch<strong>il</strong>d1;ch<strong>il</strong>d2);<br />

• si ut<strong>il</strong>izzano le query <strong>per</strong> le variab<strong>il</strong>i che rappresentano l’input di un<br />

algoritmo (eg. /search?q=jellyfish&start=20).<br />

Nelle ROA ci sono solo poche o<strong>per</strong>azione base che si possono eseguire su <strong>una</strong><br />

risorsa, e queste sono definite dal protocollo HTTP:<br />

• con HTTP GET si recu<strong>per</strong>a la rappresentazione di <strong>una</strong> risorsa;<br />

• HTTP POST serve <strong>per</strong> creare nuove risorse;<br />

• si modificano le risorse ut<strong>il</strong>izzando HTTP PUT;<br />

• HTTP DELETE cancella le risorse.<br />

Le ROA considerano parte dell’interfaccia uniforme anche i seguenti metodi<br />

del protocollo HTTP: HEAD e OPTIONS.<br />

Il vantaggio di questa interfaccia è che <strong>il</strong> metodo GET è safe, quindi <strong>una</strong><br />

richiesta che ut<strong>il</strong>izza questo metodo non cambia nessun stato nel server. GET,<br />

5 È stato evidenziato un difficoltà di base nella implementazione di <strong>Web</strong> Service come<br />

riportato in “Big <strong>Web</strong> Service Are Not Simple” [RR07] e “Am I Stupid or Is Java <strong>Web</strong> Services<br />

Really Hard?” [Han07].<br />

33


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Web</strong>DAV<br />

PUT e DELETE godono della proprietà di idempotenza: un o<strong>per</strong>azione idempotente<br />

su <strong>una</strong> risorsa non cambia lo stato della risorsa se viene ripetuta in maniera<br />

identica. La seconda richiesta e le seguenti lasceranno la risorsa esattamente<br />

nello stato in cui è stata lasciata dalla prima.<br />

La safety e l’idempotenza sono importanti <strong>per</strong>ché <strong>per</strong>mettono ai client di<br />

fare richiesta HTTP affidab<strong>il</strong>i in network che non lo sono. La POST non è né<br />

safe né idempotente.<br />

L’approccio ROA si propone come alternativa semplice ai ben più complessi<br />

<strong>Web</strong> Service basati su SOAP, ma le funzionalità <strong>of</strong>ferte coprono tutti gli aspetti<br />

necessari ai sistemi più complessi e molto lavoro è lasciato nelle mani del programmatore.<br />

Si sta assistendo ad <strong>una</strong> convergenza delle due tecnologie [Vin07],<br />

in particolare le nuove specifiche dei WSDL supportano la definizione delle interfacce<br />

su HTTP in st<strong>il</strong>e ROA [Chi07], e forse in futuro si potranno estendere<br />

alcuni standard dei <strong>Web</strong> Service anche ai servizi sv<strong>il</strong>uppati con questo st<strong>il</strong>e.<br />

1.5 <strong>Web</strong>DAV<br />

World Wide <strong>Web</strong> Distributed Authoring and Versioning (<strong>Web</strong>DAV) fornisce<br />

le specifiche <strong>per</strong> un sistema di authoring collaborativo asincrono basato sull’ut<strong>il</strong>izzo<br />

di Internet [Dus07]. <strong>Web</strong>DAV estende <strong>il</strong> protocollo HTTP, garantendo<br />

l’intero<strong>per</strong>ab<strong>il</strong>ità attraverso un’interfaccia comune <strong>per</strong> l’accesso ai dati. Fra gli<br />

obiettivi di <strong>Web</strong>DAV c’è quello di voler estendere HTTP <strong>per</strong> rendere <strong>il</strong> <strong>Web</strong><br />

realmente “scrivib<strong>il</strong>e”.<br />

<strong>Web</strong>DAV non introduce né un Information Model né un Data Model ovvero<br />

tutte le o<strong>per</strong>azioni definite (sia quelle ereditate direttamente da HTTP che quelle<br />

aggiunte) o<strong>per</strong>ano su risorse generiche, ad esempio f<strong>il</strong>e. Uno degli usi più comuni<br />

del protocollo è infatti quello di esporre lo spazio <strong>Web</strong> in modo da <strong>per</strong>metterne<br />

<strong>il</strong> “montaggio” come f<strong>il</strong>esystem remoto e <strong>per</strong>mettere quindi ai client di ut<strong>il</strong>izzarlo<br />

come se fosse <strong>una</strong> comune condivisione di rete.<br />

Importanti s<strong>of</strong>tware house come ad esempio Micros<strong>of</strong>t, Netscape, Xerox,<br />

IBM e Novell hanno contribuito allo sv<strong>il</strong>uppo di <strong>Web</strong>DAV. Attualmente esistono<br />

diverse soluzioni commerciali ed open source che lo implementano, ad esempio<br />

Sharepoint Portal Server (Micros<strong>of</strong>t), Novel Netware, Zope, Apache mod dav.<br />

La tipologia dei client è molto varia, possono essere integrati in comuni browser<br />

web o essere client dedicati, con o senza interfaccia grafica.<br />

Gli sv<strong>il</strong>uppatori di <strong>Web</strong>DAV (Internet Engineering Task Force) hanno stab<strong>il</strong>ito<br />

le seguenti sei estensioni al protocollo HTTP.<br />

Version Management. Permette <strong>il</strong> salvataggio delle revisioni effettuate sui<br />

documenti e la collaborazione di più utenti nella stesura di questi.<br />

34


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

Advance Collections. Le collection forniscono un meccanismo <strong>per</strong> l’organizzazione<br />

gerarchica delle risorse. Una collection è <strong>una</strong> lista di URI. Il ruolo è<br />

sim<strong>il</strong>e a quello delle directory di un f<strong>il</strong>e system. Una risorsa può avere più URI<br />

e quindi appartenere a più collezioni. A loro volta le collezioni possono essere<br />

ordinate anche indipendentemente dalle proprietà (pro<strong>per</strong>ties).<br />

Access Control. Controlla gli accessi ai documenti attraverso <strong>il</strong> principio<br />

dell’autenticazione. Le applicazioni <strong>Web</strong>DAV devono supportare HTTP Digest<br />

Authentication, appartenente alle specifiche del protocollo HTTP 1.1.<br />

Overwrite Prevention. Le o<strong>per</strong>azioni di scrittura, quando consentite, prevedono<br />

un meccanismo di lock dei documenti. Esistono due tipologie di blocco:<br />

exclusive write lock e shared write lock. Il primo consente la scrittura solo a colui<br />

che ha bloccato la risorsa, mentre <strong>il</strong> secondo <strong>per</strong>mette l’authoring multiutente.<br />

È anche presente un meccanismo di notifica del r<strong>il</strong>ascio delle risorse verso gli<br />

utenti interessati.<br />

Pro<strong>per</strong>ties. Ogni documento ha un insieme di informazioni correlate (metadati),<br />

come ad esempio autore, data di creazione, soggetto, eccetera. Tali<br />

informazioni sono rappresentate con coppie “”. Il nome è <strong>una</strong><br />

URI e <strong>il</strong> valore è codificato in XML. Le proprietà possono essere live o dead.<br />

Nel primo caso è <strong>il</strong> server a gestire la coerenza sintattica e semantica, mentre nel<br />

secondo è <strong>il</strong> client e <strong>il</strong> server si limita a registrare <strong>il</strong> valore delle proprietà parola<br />

<strong>per</strong> parola. In generale l’approccio di <strong>Web</strong>DAV è orientato alla memorizzazione<br />

e ricerca delle informazioni, piuttosto che alla loro semantica.<br />

Namespace Management. <strong>Web</strong>DAV <strong>of</strong>fre la possib<strong>il</strong>ità di copiare, spostare<br />

e ricevere la lista dei documenti nelle collection. La copia consente anche di<br />

cambiare i <strong>per</strong>messi associati alla risorsa. Il recu<strong>per</strong>o delle informazioni può<br />

avvenire sia rispettando l’ordinamento gerarchico delle collection sia applicando<br />

f<strong>il</strong>tri di ricerca sulle proprietà.<br />

1.6 <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

Il <strong>Web</strong> è <strong>una</strong> invenzione relativamente giovane (1989) [Ber89], ma ha subito<br />

fin dalla sua nascita <strong>una</strong> evoluzione continua che ha portato a riconoscere nella<br />

sua storia <strong>il</strong> succedersi di diverse fasi di sv<strong>il</strong>uppo meglio conosciute come <strong>Web</strong> 1.0<br />

e <strong>Web</strong> 2.0. Nonostante che l’ut<strong>il</strong>izzo di sempre nuove tecnologie abbia <strong>per</strong>messo<br />

di modificare in modo radicale l’interazione dell’utente con <strong>il</strong> <strong>Web</strong> (tanto da<br />

parlare di fasi diverse del <strong>Web</strong> tale è stato <strong>per</strong>cepito pr<strong>of</strong>ondo <strong>il</strong> cambiamento)<br />

35


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

in realtà <strong>il</strong> paradigma alla base dell’organizzazione dell’informazione, ovvero<br />

l’i<strong>per</strong>testo, non è mai mutato.<br />

In breve <strong>il</strong> concetto di i<strong>per</strong>testo può essere esemplificato descrivendolo come<br />

l’insieme di un certo numero di documenti collegati tra loro tramite “ancore”<br />

all’interno dei documenti stessi, i cosiddetti collegamenti i<strong>per</strong>testuali. Dunque<br />

<strong>il</strong> <strong>Web</strong>, in ultima analisi, risulta essere costituito da <strong>una</strong> grande quantità di<br />

documenti collegati fra loro.<br />

Alla luce di questa considerazione è possib<strong>il</strong>e affermare che i documenti sono<br />

<strong>il</strong> mezzo principale <strong>per</strong> convogliare informazioni sul <strong>Web</strong>. Ma si tratta di documenti<br />

non strutturati ovvero documenti che <strong>per</strong>mettono la lettura e l’estrapolazione<br />

delle informazioni solo da parte di un utente umano che invece risultano<br />

“<strong>il</strong>leggib<strong>il</strong>i” da applicazioni s<strong>of</strong>tware, in quanto mancanti di un qualsiasi tipo di<br />

struttura predefinita.<br />

L’interesse crescente di cercare di far leggere e manipolare anche da applicazioni<br />

s<strong>of</strong>tware le informazioni a disposizione sul <strong>Web</strong> può essere individuato anche<br />

nel grande successo degli ultimi anni <strong>per</strong> <strong>il</strong> linguaggio XML che <strong>per</strong>mette di<br />

definire delle grammatiche secondo cui è possib<strong>il</strong>e scrivere documenti strutturati<br />

che possano essere “leggib<strong>il</strong>i” sia da essere umani che da applicazioni s<strong>of</strong>tware.<br />

Fra tutti i formati basati su sintassi XML è possib<strong>il</strong>e ricordare <strong>il</strong> famoso RSS<br />

(Really Simple Syndication) che è ampiamente ut<strong>il</strong>izzato <strong>per</strong> la comunicazione<br />

degli aggiornamenti di blog, news e quant’altro.<br />

Allo stesso tempo si sono andate diffondendo le <strong>Web</strong> API (ad esempio le<br />

famose API di Google Maps) che <strong>per</strong>mettono ad applicazioni di interagire con<br />

i dati contenuti in sorgenti diverse tramite <strong>il</strong> <strong>Web</strong> e <strong>il</strong> loro ut<strong>il</strong>izzo ha portato<br />

alla realizzazione di applicazioni di grande successo. Quindi <strong>il</strong> trend di realizzare<br />

un modo <strong>per</strong> la condivisione di informazioni comprensib<strong>il</strong>i <strong>per</strong> applicazioni<br />

s<strong>of</strong>tware è in pieno fermento, <strong>per</strong>ò si è ancora lontani dal realizzare un <strong>Web</strong> che<br />

possa essere gestito in modo automatico dalle applicazioni, in analogia a quanto<br />

viene fatto dagli esseri umani <strong>per</strong> i documenti. Basti pensare che nel caso delle<br />

<strong>Web</strong> API è necessario realizzare soluzioni ad-hoc <strong>per</strong> ogni servizio che si intende<br />

integrare in quanto ogni provider, pur esponendo le funzionalità con strumenti<br />

standard (come i <strong>Web</strong> Service), lo fa tramite API ottimizzate <strong>per</strong> affrontare<br />

lo specifico problema di dominio (ad esempio Flickr e YouTube ut<strong>il</strong>izzano<br />

meccanismi diversi <strong>per</strong> manipolare i tag delle foto e dei video rispettivamente).<br />

In conclusione, osservando <strong>il</strong> panorama dell’attuale stato del <strong>Web</strong>, la possib<strong>il</strong>ità<br />

di liberare i grandi potenziali informativi al suo interno è ancora lontano<br />

dal concretizzarsi.<br />

Nel campo della ricerca scientifica <strong>il</strong> problema esposto è al centro dell’attenzione<br />

da vari anni ed addirittura Tim Berners Lee stesso non ha mai nascosto<br />

che la sua originaria idea del 1989 prevedeva un <strong>Web</strong> di informazioni <strong>per</strong> esseri<br />

umani ed elaboratori automatici. La sua idea era stata tradotta in realtà solo in<br />

36


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

parte e da qui <strong>il</strong> suo crescente impegno nel riuscire a realizzare completamente la<br />

sua visione iniziale. Il progetto di portare a compimento la sua visione originale<br />

del <strong>Web</strong> prese piede in modo più organico a partire dal 2001, anno in cui sancì,<br />

con la pubblicazione del suo storico articolo sullo Scientific American [BHL01],<br />

la sua visione di quello che sarebbe stato <strong>il</strong> <strong>Web</strong> del futuro ovvero <strong>il</strong> cosiddetto<br />

“Semantic <strong>Web</strong>”.<br />

Il Semantic <strong>Web</strong> veniva proposto nell’articolo come un’estensione del <strong>Web</strong><br />

attuale in cui “verrà data <strong>una</strong> struttura al contenuto significativo delle pagine<br />

<strong>Web</strong>” [BHL01]. Nell’articolo <strong>per</strong>ò Berners Lee e gli altri autori non entrano nello<br />

specifico di quale strada seguire <strong>per</strong> la realizzazione degli scenari presentati, ma<br />

misero solo in risalto l’importanza che avrà, nel Semantic <strong>Web</strong>, la rappresentazione<br />

della conoscenza tramite l’uso di ontologie e la codifica delle stesse tramite<br />

<strong>il</strong> linguaggio RDF (Resource Description Framework).<br />

Veniva dunque presentato come di fondamentale importanza l’uso di tutte<br />

quelle conoscenze sv<strong>il</strong>uppate nel mondo della ricerca sull’Intelligenza Artificiale<br />

(Artificial Intelligence, A.I.). Infatti la prima corrente di ricerca predominante<br />

nell’ambito degli studi sul Sematic <strong>Web</strong> (nel <strong>per</strong>iodo dal 2001 al 2007 circa)<br />

fu proprio la cosiddetta corrente “A.I.-driven”. L’attenzione dei ricercatori in<br />

questo <strong>per</strong>iodo fu centrata principalmente sul problema dell’inferenza e della<br />

rappresentazione della conoscenza tramite la realizzazione di ontologie. Purtroppo<br />

<strong>per</strong>ò nonostante l’intenso lavoro a livello mondiale, i risultati ottenuti da<br />

questa corrente non hanno condotto alla concretizzazione di un Sematic <strong>Web</strong> a<br />

livello globale, ma è stata conseguita solo la realizzazione di <strong>una</strong> serie di “semantic<br />

web locali’ che rappresentavano soluzioni ad-hoc <strong>per</strong> contesti particolari<br />

in ambito chiuso. Ut<strong>il</strong>izzando le stesse parole di Berners Lee in <strong>una</strong> recente intervista<br />

è possib<strong>il</strong>e affermare che gli scienziati avevano trascurato l’aspetto <strong>Web</strong><br />

<strong>per</strong> concentrarsi solo sull’aspetto Semantic [Mac09]. Gli scarsi risultati ottenuti<br />

in questa direzione hanno indotto prima <strong>una</strong> riflessione critica sull’approccio<br />

adottato [SHB06] che ha poi comportato un cambio della prospettiva con cui<br />

affrontare <strong>il</strong> problema dando origine ad <strong>una</strong> nuova corrente di ricerca, che può<br />

essere denominata “<strong>Web</strong>-driven” (nel <strong>per</strong>iodo dal 2007 ad oggi).<br />

La corrente “<strong>Web</strong>-driven”ha acquisito sempre maggiori consensi fino a diventare<br />

<strong>il</strong> principale f<strong>il</strong>one di ricerca riuscendo fra l’altro a raggiungere dei risultati<br />

concreti molto più consistenti rispetto al lavoro svolto in precedenza. Il principale<br />

merito che può esserle riconosciuto è quello dell’aver riportato l’attenzione sul<br />

problema di esporre dati in <strong>una</strong> ragnatela globale, dati che poi potranno essere<br />

ut<strong>il</strong>izzati da terze applicazioni (semantiche). È anche opportuno sottolineare<br />

come <strong>il</strong> nuovo f<strong>il</strong>one di ricerca ha ripreso e fatto suo la necessità di realizzare<br />

un cambio di paradigma nell’organizzazione delle informazioni sul <strong>Web</strong> passando<br />

dall’attuale paradigma del “<strong>Web</strong> <strong>of</strong> Documents” al cosiddetto paradigma del<br />

“<strong>Web</strong> <strong>of</strong> Data”. La visione connessa al <strong>Web</strong> <strong>of</strong> Data <strong>per</strong>ò non ha avuto origine<br />

37


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

all’interno della corrente “<strong>Web</strong>-driven”.<br />

Infatti nel 2007 Danny Ayers scriveva che “a <strong>Web</strong> <strong>of</strong> data without semantic<br />

<strong>Web</strong> technologies is entirely conceivable” [Aye07], dunque <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data è<br />

stato <strong>una</strong> visione che <strong>per</strong> anni ha vissuto parallelamente alle ricerche dell’area<br />

del Semantic <strong>Web</strong>.<br />

Nel 2006 Tim Berners Lee, avendo capito la necessità di mettere dei punti<br />

fermi <strong>per</strong> la realizzazione di un effettivo Semantic <strong>Web</strong> globale, produce i<br />

cosiddetti “Linked Data (LD) Principles” ovvero delle regole che <strong>per</strong>mettessero<br />

di definire la struttura dei dati da pubblicare sul <strong>Web</strong> [Ber06]. I principi LD<br />

definiscono quelle che sono le regole di base <strong>per</strong> la struttura dei Linked Data<br />

mettendo in risalto come tutta la tecnologia necessaria fosse già disponib<strong>il</strong>e nel<br />

<strong>Web</strong> attuale e che quindi lo sforzo da fare sarebbe stato relativamente basso <strong>per</strong><br />

trasformare i principi in realtà.<br />

I principi, <strong>il</strong> cui enunciato è riportando in lingua originale, sono i seguenti:<br />

1. Use URIs as names for things.<br />

2. Use HTTP URIs so that people can look up those names.<br />

3. When someone looks up a URI, provide useful information,<br />

using the standards (RDF, SPARQL).<br />

4. Include links to other URIs. So that they can discover more<br />

things.<br />

Il primo principio afferma la necessità di ut<strong>il</strong>izzare URI (Uniform Resource<br />

Identifier, paragrafo 1.2) come nomi <strong>per</strong> identificare quelle che genericamente<br />

Berners Lee indica con <strong>il</strong> termine “things” ovvero cose, oggetti. Il fatto che si<br />

parli di cose indica la volontà di ut<strong>il</strong>izzare i principi Linked Data come regole<br />

di pubblicazione sia <strong>per</strong> le cosiddette risorse informative che <strong>per</strong> le risorse non<br />

informative 6 (vedi [Lew07]) dunque ha in mente un <strong>Web</strong> “allargato” rispetto a<br />

quello attuale.<br />

Il secondo principio specifica che <strong>il</strong> tipo di URI da ut<strong>il</strong>izzare è HTTP-URI.<br />

Come è stato trattato più appr<strong>of</strong>onditamente in 1.2.4 ut<strong>il</strong>izzare gli HTTP-URI<br />

comporta tutta <strong>una</strong> serie di vantaggi, derivanti dal fatto che esiste già un’infrastruttura<br />

funzionante che gestisce questo tipo di identificatori. Però si aprono<br />

anche dei problemi in quanto gli HTTP-URI sono nati in origine <strong>per</strong> identificare<br />

delle pagine <strong>Web</strong> (in generale risorse informative) mentre <strong>il</strong> primo principio parla<br />

di URI <strong>per</strong> identificare cose (in generale risorse informative e risorse non informative).<br />

Questo problema è stato trattato ampiamente dall’attività del gruppo<br />

di lavoro Technical Architecture Group all’interno del W3C che poi risultò nella<br />

stesura della famosa “HTTP-range14 solution” la cui versione definitiva è <strong>per</strong>ò<br />

6 Le risorse informative sono quelle la cui natura è informazione di <strong>per</strong> sé (un articolo<br />

scientifico, <strong>una</strong> pagina web); le risorse non informative sono tutto <strong>il</strong> resto (un’auto, un cane).<br />

Si noti che è normale rappresentare risorse non informative con <strong>una</strong> o più risorse informative<br />

(<strong>una</strong> pagina web che parla di un cane).<br />

38


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

solo del maggio 2007 [Lew07]. L’oggetto del dibattito era sostanzialmente <strong>il</strong><br />

seguente: se gli HTTP URI devono sempre identificare esclusivamente risorse<br />

informative oppure no. Il risultato del lavoro condusse alla famosa <strong>soluzione</strong> del<br />

“303 redirect” ovvero in <strong>una</strong> best practice che prevede di rispondere alla dereferenziazione<br />

di URI <strong>per</strong> <strong>una</strong> risorsa non informativa con lo “status code 303”<br />

dell’HTTP (che significa “see other”) verso un altro URI di <strong>una</strong> risorsa informativa<br />

che contiene <strong>una</strong> rappresentazione della risorsa non informativa oggetto del<br />

procedimento di dereferenziazione. In conseguenza di questa ridefinizione dell’uso<br />

dello “status code 303” le risorse informative dunque non dovrebbero più<br />

produrre questo tipo di risposta alla dereferenziazione <strong>per</strong> mantenere la validità<br />

di questo principio.<br />

Il terzo principio, che è stato rivisto dall’autore nel primo semestre del 2009,<br />

è <strong>il</strong> cosiddetto principio del “follow your nose” ovvero <strong>il</strong> principio che dice di<br />

fornire informazioni ut<strong>il</strong>i a fronte della dereferenziazione di un URI. Il termine<br />

informazioni ut<strong>il</strong>i <strong>per</strong>ò è (forse volutamente) piuttosto generico e può essere<br />

maggioramente chiarificato intendendo che nel caso di <strong>una</strong> risorsa informativa<br />

verrà ovviamente restituita la risorsa stessa mentre a seguito della dereferenziazione<br />

di <strong>una</strong> risorsa non informativa verrà restituita <strong>una</strong> rappresentazione della<br />

risorsa non informativa. Per quanto riguarda la rappresentazione della risorsa<br />

non informativa non veniva specificato inizialmente nel terzo principio quale<br />

formato fosse da adottare e solo in un secondo tempo è stata aggiunta questa<br />

precisazione che <strong>per</strong> Berners Lee era assolutamente su<strong>per</strong>flua. Con le ultime<br />

modifiche vengono adesso indicati gli standard da adottare con cui codificare le<br />

informazioni ut<strong>il</strong>i ovvero gli standard RDF [KC04] e SPARQL [PS08].<br />

Il quarto principio invece riguarda le relazioni fra dati ovvero la necessità di<br />

realizzare collegamenti fra gli URI in modo da avere la possib<strong>il</strong>ità di navigare<br />

da <strong>una</strong> risorsa ad un’altra. Risulta dunque un principio quanto mai importante<br />

considerando che si sta trattando l’argomento “Linked Data”; si intende quindi<br />

realizzare <strong>una</strong> fitta rete di collegamenti al fine di costruire <strong>una</strong> ragnatela mondiale<br />

di dati che possa essere navigata <strong>per</strong> mezzo di browser (appositi) o di altre<br />

applicazioni, in analogia a quello che è oggi possib<strong>il</strong>e fare attraversando pagine<br />

<strong>Web</strong> tramite i collegamenti i<strong>per</strong>testuali. In particolar modo è stata attribuita<br />

maggiore r<strong>il</strong>evanza ai link che collegano elementi che sono parte di diversi dataset<br />

e che quindi “liberino” i dati dai singoli “s<strong>il</strong>os informativi” in cui sono stoccati<br />

e li rendano parte integrante della rete globale.<br />

In conseguenza di questi principi sono state definite <strong>una</strong> serie di best practice<br />

<strong>per</strong> la pubblicazione dei Linked Data dove vengono definite delle metodologie<br />

da seguire <strong>per</strong> tradurre in realtà le regole espresse da Berners Lee [BCH07].<br />

Prende così <strong>il</strong> via un importante progetto, <strong>il</strong> “Linking Open Data (LOD) project”<br />

[BHB09] che ha come obiettivo dimostrare che realizzare la pubblicazione<br />

di Linked Data su larga scala è possib<strong>il</strong>e. Il progetto ottiene un grande successo<br />

39


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

che è reso concretamente visib<strong>il</strong>e tramite la rappresentazione della nuvola LOD<br />

ovvero l’insieme di dati interconnessi dal progetto. I dati pubblicati sono triple<br />

RDF e, ad oggi, si arrivano a contare m<strong>il</strong>ioni di triple RDF fittamente collegate<br />

tramite link RDF. Emerge fin da subito che <strong>il</strong> paradigma del <strong>Web</strong> <strong>of</strong> Data è<br />

<strong>il</strong> nuovo paradigma dominante di questa enorme nuvola LOD. Si intuisce <strong>per</strong>ò<br />

anche <strong>una</strong> serie di problemi legati alla necessità di definire come sarà l’interazione<br />

con un nuovo <strong>Web</strong> di questo tipo ([Hea08]). Ben presto la nuvola LOD<br />

diventa sinonimo di Linked Data che a sua volta diventa sinonimo di <strong>Web</strong> <strong>of</strong> Data.<br />

Infine nel 2008 durante <strong>una</strong> conferenza è lo stesso Berners Lee ad affermare<br />

che <strong>il</strong> “<strong>Web</strong> <strong>of</strong> Data è <strong>il</strong> Semantic <strong>Web</strong> fatto bene”, rendendo dunque <strong>il</strong> <strong>Web</strong> <strong>of</strong><br />

Data a pieno titolo la produzione meglio riuscita del lungo f<strong>il</strong>one di ricerche del<br />

Semantic <strong>Web</strong>.<br />

L’obiettivo iniziale del LOD project era raggiungere la cosiddetta “massa<br />

critica” ovvero <strong>una</strong> quantità tale di dati pubblicati che <strong>per</strong>mettesse di innescare<br />

<strong>il</strong> cosiddetto “network effect” e quindi fosse dato <strong>il</strong> via ad <strong>una</strong> serie di usi, anche<br />

non previsti, dei dati a disposizione di <strong>una</strong> massa sempre maggiore di utenti.<br />

Il network effect, che è quantificato in modo scientifico tramite la famosa legge<br />

di Metcalfe, può essere specificato dicendo che <strong>il</strong> valore di un servizio <strong>per</strong> un<br />

utente cresce con <strong>il</strong> numero di <strong>per</strong>sone che usano tale servizio. Però spesso viene<br />

tracurato un corollario della legge di Metcalfe, <strong>il</strong> corollario dice che <strong>per</strong> far<br />

accadere <strong>il</strong> network effect devono esistere dei link fra gli elementi in gioco; ad<br />

esempio <strong>il</strong> <strong>Web</strong>, se fosse solamente <strong>una</strong> collezione di pagine non interconnesse,<br />

non avrebbe <strong>il</strong> valore che invece ha [HG08]. Dunque, raggiungendo <strong>una</strong> consistente<br />

massa di Linked Data, si sarebbe potuto pensare che <strong>il</strong> “network effect”,<br />

applicato alla nuvola LOD, avrebbe dato vita ad un nuovo <strong>Web</strong>. La nuvola<br />

LOD è effettivamente cresciuta arrivando a dimensioni gigantesche e quindi è<br />

possib<strong>il</strong>e asserire che <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data sia ormai diventato <strong>una</strong> realtà. Ma non è<br />

così, infatti <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data è rimasto tema dell’ambito della ricerca scientifica<br />

senza riuscire ad entrare nell’uso quotidiano; a riprova di questo fatto è l’assoluta<br />

carenza di applicazioni diffuse su larga scala che sfruttino <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data.<br />

Le poche applicazioni esistenti sono essenzialmente applicazioni di ricerca quali<br />

browser come Tabulator oppure motori di ricerca come Sindice.<br />

Ma <strong>per</strong>ché le Linked Data application non hanno preso piede nonostante <strong>il</strong><br />

grande interesse a livello mondiale che è stato suscitato dai Linked Data? I<br />

punti più significativi di debolezza sono sostanzialmente due ovvero che:<br />

• <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data attuale, come è realizzato dal LOD, è di tipo read-only;<br />

• non sono stati tenuti in debita considerazione ad oggi problemi legati al<br />

trust dei dati.<br />

Relativamente al primo punto <strong>il</strong> <strong>Web</strong> <strong>of</strong> Data che è stato realizzato è un<br />

<strong>Web</strong> dove sono pubblicati dati ut<strong>il</strong>izzando le tecnologie a disposizione del <strong>Web</strong><br />

40


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

corrente, dunque dati che possono essere dereferenziati, ma che non è ancora<br />

possib<strong>il</strong>e manipolare in modo uniforme, ad esempio <strong>per</strong> arricchire la nuvola<br />

LOD con nuovi dati ottenuti a seguito dell’elaborazione dei dati a disposizione<br />

(inferenza). Questa limitazione si può individuare proprio nella caratteristica<br />

che ha segnato uno dei grandi vantaggi della realizzazione della nuvola LOD<br />

ovvero l’aver ut<strong>il</strong>izzato l’infrastruttura messa a disposizione dal <strong>Web</strong> corrente.<br />

È noto che <strong>il</strong> processo di pubblicazione è un processo esterno alla struttura del<br />

<strong>Web</strong> e la sensazione del tipico utente <strong>Web</strong> 2.0 di scrivere ed interagire con <strong>il</strong> <strong>Web</strong><br />

in realtà è legata a contesti locali e chiusi e non a<strong>per</strong>ti come quello ipotizzato<br />

dalla visione di un vero <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong>. Ovviamente la necessità di manipolare<br />

ed elaborare i dati è sicuramente un aspetto molto più pressante <strong>per</strong> <strong>il</strong> <strong>Web</strong> <strong>of</strong><br />

Data rispetto al <strong>Web</strong> <strong>of</strong> Documents che è riuscito ad acquisire consenso fra gli<br />

utenti comuni anche senza la possib<strong>il</strong>ità di manipolare i contenuti <strong>per</strong> <strong>una</strong> certa<br />

parte della sua storia iniziale e comunque l’ut<strong>il</strong>izzo di tante applicazioni ad-hoc<br />

può essere <strong>una</strong> <strong>soluzione</strong> valida <strong>per</strong> l’uomo, ma decisamente limitante <strong>per</strong> le<br />

macchine.<br />

In questa direzione si stanno concentrando in questo momento gli sforzi della<br />

ricerca scientifica con <strong>il</strong> fine di realizzare un vero <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data ovvero<br />

riuscire a inserire <strong>il</strong> processo di scrittura, e di conseguenza di pubblicazione,<br />

direttamente all’interno della struttura del <strong>Web</strong> <strong>of</strong> Data. Le soluzioni attuali<br />

<strong>per</strong>ò ([HKO + 09, Ber09]) sembrano ancora poco convincenti poiché si basano su<br />

procedimenti completamente nuovi e che s<strong>of</strong>frono della mancanza di uniformità.<br />

In ogni caso l’attenzione della ricerca internazionale si è indirizzata verso i<br />

problemi tecnici connessi alla realizzazione di applicazioni che manipolano i dati<br />

non prestando attenzione a tutti i problemi legati all’ut<strong>il</strong>izzo dei dati in ambito<br />

socio-economico. Nel primo sforzo di pubblicazione infatti sono stati trascurati<br />

gli aspetti legati all’ut<strong>il</strong>izzo dei dati. Il progetto Linking Open Data infatti si<br />

è rivolto esclusivamente a dataset che sono regolamentati dalla licenza Open<br />

Data Commons 7 <strong>per</strong>ò esistono tutta <strong>una</strong> serie di importanti campi applicativi,<br />

quali quello dell’e-Government fra tutti, in cui invece è necessario introdurre<br />

delle regolamentazioni più stringenti. Un lavoro in questa direzione diviene<br />

sempre più necessario poiché proprio l’e-Government è al momento uno dei<br />

settori in cui si sta rivolgendo gran parte dell’attenzione poiché i governi di<br />

alcuni paesi anglosassoni stanno sempre più interessandosi a rendere i loro dati<br />

disponib<strong>il</strong>i on-line, ma garantendo tutti i requisiti necessari affinché i dati messi<br />

a disposizione si spostino da pura o<strong>per</strong>azione di trasparenza (delle Pubbliche<br />

Amministrazioni sul loro o<strong>per</strong>ato nei confronti del cittadino) alla realizzazione<br />

di <strong>una</strong> serie di servizi mirati che <strong>per</strong>mettano al cittadino, con maggiore fac<strong>il</strong>ità,<br />

di interagire con la P.A. stessa. Proprio i dati relativi al pr<strong>of</strong><strong>il</strong>o dell’utente stanno<br />

diventando oggetto di sempre maggiori attenzioni relativamente alla necessità<br />

7 http://www.opendatacommons.org/.<br />

41


Stato dell’arte: <strong>il</strong> <strong>Web</strong> <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data<br />

di identificare l’utente anche nella dimensione virtuale, dove problemi di privacy<br />

e furti d’identità diventano ogni giorno temi di stringente interesse anche <strong>per</strong> la<br />

pubblica sicurezza.<br />

Allo stesso tempo tutto <strong>il</strong> settore delle applicazioni enterprise necessita di<br />

<strong>una</strong> serie di garanzie sui dati che ad oggi sono lontani dall’essere incontrati<br />

poiché in un <strong>Web</strong> <strong>of</strong> Data nessuno può avere certezze relativamente a come i<br />

dati pubblicati verranno integrati e riusati dunque attualmente le applicazioni<br />

Linked Data si possono rivolgere esclusivamente a settori non business critical.<br />

Se quindi <strong>il</strong> mondo del <strong>Web</strong> <strong>of</strong> Data, declinato secondo i principi LD, ancora<br />

stenta ad entrare nell’uso quotidiano proprio <strong>per</strong> la necessità di ridefinire nuovi<br />

paradigmi di interazione con l’utente finale, da molte parti viene avanzata l’idea<br />

che forse <strong>il</strong> problema dell’insuccesso attuale sia da riscontrarsi proprio nella<br />

struttura dei principi LD che non hanno saputo dare le corrette direzioni <strong>per</strong> la<br />

costruzione del <strong>Web</strong> <strong>of</strong> Data.<br />

Il lavoro di ricerca che sta alla base della presente trattazione condivide la<br />

stessa impostazione critica verso i principi LD e ritiene che sia possib<strong>il</strong>e <strong>una</strong> via<br />

altenativa <strong>per</strong> la realizzazione di un vero <strong>Read</strong>-<strong>Write</strong> <strong>Web</strong> <strong>of</strong> Data. Infatti <strong>il</strong><br />

solo principio che non ha subito critiche è <strong>il</strong> secondo mentre <strong>il</strong> terzo principio o<br />

“follow your nose” è stato quello oggetto delle maggiori contestazioni in quanto<br />

<strong>il</strong> concetto di “useful information” non viene definito di <strong>per</strong> sè, ma solo tramite<br />

l’associazione agli standard tecnologici con cui l’informazione viene fornita. Con<br />

questo approccio si può r<strong>il</strong>evare l’intenzione di inquadrare esclusivamente <strong>il</strong> Linked<br />

Data nel mondo del Semantic <strong>Web</strong>, cosa fra l’altro che è ribadita in modo<br />

implicito fin dal primo principio. In molti hanno <strong>per</strong>ò avanzato l’ipotesi che<br />

anche eliminando <strong>il</strong> requisito di usare gli standard RDF e SPARQL in realtà è<br />

comunque possib<strong>il</strong>e parlare di Linked Data [M<strong>il</strong>09]. La corrente dei puristi <strong>per</strong>ò<br />

non è d’accordo ritenendo che in questo caso si parli invece più genericamente di<br />

“<strong>Web</strong> Integrated Data” poiché l’uso di RDF non vuole rivolgersi esclusivamente<br />

ad <strong>una</strong> <strong>soluzione</strong> tecnologica, ma ad un modello dell’informazione condiviso e<br />

che questo rappresenti un importante punto di unificazione <strong>per</strong> <strong>per</strong>seguire l’obiettivo<br />

di integrare dati provenienti da sorgenti diverse esposte sul <strong>Web</strong>. Ma<br />

cosa si intende esattamente <strong>per</strong> “<strong>Web</strong> Integrated Data”? Ancora non è stata<br />

data <strong>una</strong> definizione precisa, ma un modo <strong>per</strong> pubblicare e manipolare dati tramite<br />

l’ut<strong>il</strong>izzo di API RESTful che segue le regole dei Linked Data senza <strong>per</strong>ò<br />

adottarne gli standard [Dod09] .<br />

42


Capitolo<br />

2<br />

Stato dell’arte: federazione su<br />

larga scala<br />

Per rendere <strong>il</strong> <strong>Web</strong> un ambiente realmente collaborativo, più che un’infrastruttura<br />

<strong>per</strong> la mera pubblicazione di dati, occorre federare i sistemi informativi<br />

di enti ed organizzazioni che, tramite di esso, intendono coo<strong>per</strong>are.<br />

La federazione è la via che <strong>per</strong>mette a singoli enti ed organizzazioni di mantenere<br />

<strong>una</strong> struttura autonoma ed individuale, sia da un punto di vista organizzativo<br />

che tecnologico, ed allo stesso tempo di creare un ambiente virtuale di<br />

collaborazione completamente decentralizzato.<br />

Centralizzazione e scalab<strong>il</strong>ità infatti sono due aspetti che normalmente non<br />

vanno di pari passo. Centralizzare, pur <strong>of</strong>frendo vantaggi in termini di semplificazione<br />

nella gestione e nell’amministrazione di sistemi e dati ed alcune<br />

opportunità che se sfruttate adeguatamente rendono più trattab<strong>il</strong>e <strong>il</strong> problema<br />

della sicurezza, tende a creare un unico punto di accumulazione, non necessariamente<br />

tecnologico ma anche organizzativo, che tende a rappresentare un collo di<br />

bottiglia con la crescita della quantità di dati e del numero di utenti ed accessi.<br />

I database relazionali non verranno trattati nella presente dissertazione in<br />

quanto, pur esistendo varie strategie <strong>per</strong> la loro federazione (seppur sotto alcuni<br />

vincoli o<strong>per</strong>ativi), non prevedono dei meccanismi nativi <strong>per</strong> la delega della responsab<strong>il</strong>ità<br />

che, eventualmente, non siano dipendenti dalle singole piattaforme.<br />

Il altre parole, se pur possib<strong>il</strong>e in via concettuale, la federazione su larga scala<br />

di database eterogenei in cui si abbia <strong>una</strong> completa decentralizzazione sia fisica<br />

che logica è, nella pratica, un’o<strong>per</strong>azione dal costo troppo elevato eventualmen-


Stato dell’arte: federazione su larga scala Domain Name System<br />

te tendente all’infinito (ovvero non sostenib<strong>il</strong>e). Ciò non è <strong>per</strong>ò in contrasto<br />

con <strong>il</strong> fatto che i database relazionali saranno ut<strong>il</strong>izzati, <strong>per</strong> le loro ben note<br />

caratteristiche in termini di prestazioni, scalab<strong>il</strong>ità (a livello locale) e sicurezza,<br />

come s<strong>il</strong>os informativi interni ai singoli enti <strong>per</strong> stoccare le informazioni ed i dati<br />

oggetto della coo<strong>per</strong>azione. La federazione verrà <strong>per</strong>ò effettuata ad un livello<br />

di astrazione più alto, quello delle “risorse” secondo l’accezione introdotta nel<br />

capitolo 1. Questo non solo <strong>per</strong>ché <strong>il</strong> <strong>Web</strong> è l’ambiente distribuito (e federato)<br />

più esteso e scalab<strong>il</strong>e (in termini di utenti, quantità di dati, numero di accessi e<br />

sistemi interconnessi) che sia mai stato realizzato, ma anche <strong>per</strong>ché l’obiettivo<br />

specifico della presente dissertazione è proporre <strong>una</strong> <strong>soluzione</strong> <strong>infrastrutturale</strong><br />

che estenda <strong>il</strong> <strong>Web</strong> nei principi e nelle tecnologie con <strong>il</strong> fine di farlo evolvere da<br />

<strong>Web</strong> di documenti (sostanzialmente read-only) a read-write <strong>Web</strong> <strong>of</strong> data.<br />

Pertanto questo capitolo affronterà la federazione a livello <strong>Web</strong> partendo proprio<br />

dal Domain Name System (DNS), sistema distribuito decentralizzato (sia<br />

fisicamente che logicamente) con <strong>il</strong> quale <strong>il</strong> <strong>Web</strong> stesso ha affrontato e risolto <strong>il</strong><br />

problema della gestione dei nomi. Successivamente verrà <strong>il</strong>lustrato Lightweight<br />

Directory Access Protocol (LDAP) che condivide con <strong>il</strong> DNS la struttura gerarchica,<br />

proprietà ab<strong>il</strong>itante la delega delle responsab<strong>il</strong>ità e, come ha ampliamente<br />

dimostrato DNS nel corso degli anni, in grado di rendere <strong>il</strong> sistema scalab<strong>il</strong>e a<br />

livello globale. Essendo un sistema ideato <strong>per</strong> ospitare directory contenenti dati<br />

generici, LDAP <strong>per</strong>mette di evidenziare ed affrontare <strong>una</strong> serie di problematiche<br />

che DNS non presenta <strong>per</strong> via della sua specificità; <strong>per</strong> citare un esempio su tutti<br />

la gestione (granulare) dei diritti di accesso.<br />

2.1 Domain Name System<br />

Oltre che in ambito commerciale, i concetti bas<strong>il</strong>ari dei database distribuiti<br />

(Distributed Database, DDB) sono stati applicati nella realizzazione di un’applicazione<br />

fondamentale <strong>per</strong> Internet: <strong>il</strong> DNS [Moc87a, Moc87b]. Allo scopo di<br />

assicurare la massima indipendenza tra gli strati che costituiscono l’architettura<br />

di Internet, i nodi della rete possono essere identificati secondo modalità diverse.<br />

A livello applicativo i calcolatori vengono identificati tramite <strong>il</strong> cosiddetto<br />

hostname [HSF85] che è un nome alfanumerico di lunghezza arbitraria. D’altra<br />

parte gli hostname non forniscono alc<strong>una</strong> informazione su quale sia l’effettiva<br />

dislocazione del nodo all’interno della rete, funzionalità che compete ai nomi dei<br />

livelli inferiori della p<strong>il</strong>a protocollare di Internet, nello specifico agli indirizzi IP.<br />

Un indirizzo IP [Pos81] consiste di quattro byte ed è caratterizzato da <strong>una</strong><br />

struttura gerarchica molto rigida. In particolare ciascun indirizzo IP risulta<br />

suddiviso concettualmente in due parti: <strong>il</strong> cosiddetto networkID, che identifica la<br />

rete IP cui è connessa l’interfaccia di rete, e l’hostID, che identifica la particolare<br />

44


Stato dell’arte: federazione su larga scala Domain Name System<br />

interfaccia di rete. Un esempio di indirizzo IP espresso in notazione decimale<br />

puntata 1 è: 192.168.9.101.<br />

2.1.1 Servizio di ri<strong>soluzione</strong><br />

La nascita ufficiale del DNS [ISCI05] risale al 1984 con la pubblicazione della<br />

RFC 920 [PR84] anche se <strong>il</strong> cuore del sistema era stato descritto precedentemente<br />

(nel 1983) nelle RFC 882 e 883 [Moc83a, Moc83b]. A seguito delle prime s<strong>per</strong>imentazioni,<br />

nel 1987 furono pubblicate le RFC 1034 e 1035 [Moc87a, Moc87b]<br />

che andarono ad estendere e modificare <strong>il</strong> sistema dandone la definizione che,<br />

<strong>per</strong> quanto riguarda le funzionalità di base, sopravvive tutt’oggi. Come sarà più<br />

chiaro nel seguito del presente paragrafo, successivamente sono state pubblicate<br />

ulteriori RFC <strong>per</strong> aggiungere funzionalità avanzate (come gli aggiornamenti<br />

dinamici) e <strong>per</strong> colmarne alcune lacune (come gli aspetti legati alla sicurezza).<br />

L’obiettivo principale del DNS (Domain Name System) [Moc87a, Moc87b]<br />

consiste nel fornire un servizio che tratta archivi di nomi <strong>per</strong> tradurre gli hostname<br />

in indirizzi IP e viceversa. Inoltre immagazzina informazioni <strong>per</strong> fare <strong>il</strong><br />

routing delle e-ma<strong>il</strong> ed altri dati ut<strong>il</strong>izzati a livello applicativo.<br />

Il DNS è definito [KR03] come:<br />

• un DDB implementato in <strong>una</strong> gerarchia di server dei nomi;<br />

• un protocollo dello strato di applicazione [Moc87b] che <strong>per</strong>mette agli host<br />

di comunicare con i server dei nomi in modo da ottenere <strong>il</strong> servizio di<br />

traduzione;<br />

• l’insieme di regole che servono <strong>per</strong> delegare le autorità sui nomi.<br />

Il DNS è comunemente impiegato da altri protocolli dello strato applicativo,<br />

in generale dalle applicazioni, <strong>per</strong> tradurre gli hostname forniti dagli utenti in<br />

indirizzi IP ed accedere così ai livelli sottostanti della p<strong>il</strong>a protocollare.<br />

Per avere <strong>una</strong> panoramica generale sul funzionamento del DNS, si consideri <strong>il</strong><br />

caso tipico in cui un browser richieda l’URL http://www.unifi.it/home.html;<br />

affinchè l’applicazione possa inviare un messaggio di richiesta HTTP al server<br />

web www.unifi.it, essa deve re<strong>per</strong>irne l’indirizzo IP.<br />

Come schematizzato in figura 2.1 ciò avviene nel modo seguente:<br />

1. <strong>il</strong> browser passa al lato client locale del DNS l’hostname www.unifi.it;<br />

2. <strong>il</strong> client DNS (local resolver) invia <strong>una</strong> richiesta contenente l’hostname<br />

ad uno dei server DNS noti (nel senso degli indirizzi IP) al client stesso,<br />

passo 1 in figura;<br />

1 La notazione decimale puntata è <strong>una</strong> convenzione secondo cui ciascun byte dell’indirizzo<br />

IP è scritto nella sua forma decimale ed è separato da un punto dagli altri byte.<br />

45


Stato dell’arte: federazione su larga scala Domain Name System<br />

1- richiesta di ri<strong>soluzione</strong> del nome www.unifi.it<br />

2- risposta contenente l'indirizzo IP 150.217.6.125<br />

3- a<strong>per</strong>tura connessione TCP verso 150.217.6.125:80<br />

Client<br />

1<br />

3<br />

2<br />

network<br />

Server DNS<br />

IP: 208.67.222.222<br />

Server <strong>Web</strong><br />

www.unifi.it<br />

Nota: <strong>il</strong> client ha nella propria<br />

configurazione interna l'indirizzo<br />

IP 208.67.222.222 del server DNS IP: 150.217.6.125<br />

Figura 2.1: Richiesta di ri<strong>soluzione</strong> <strong>per</strong> l’accesso ad <strong>una</strong> pagina <strong>Web</strong>.<br />

3. a seguito del processo di ri<strong>soluzione</strong> che interessa <strong>il</strong>/i server DNS, <strong>il</strong> client<br />

riceve <strong>una</strong> risposta contenente l’indirizzo IP corrispondente all’hostname<br />

richiesto, passo 2 in figura;<br />

4. <strong>il</strong> client DNS passa l’indirizzo IP al browser che apre <strong>una</strong> connessione con<br />

<strong>il</strong> processo server HTTP situato a quell’indirizzo IP. Si noti che se non<br />

specificata esplicitamente nell’URI (come nel caso dell’esempio) la porta<br />

ut<strong>il</strong>izzata è quella “ben nota” <strong>per</strong> <strong>il</strong> protocollo in uso ovvero, <strong>per</strong> HTTP,<br />

la 80/TCP, passo 3 in figura;<br />

5. <strong>il</strong> client, ut<strong>il</strong>izzando la connessione a<strong>per</strong>ta al passo precedente, effettua <strong>una</strong><br />

richiesta HTTP di tipo GET specificando l’indirizzo completo della risorsa<br />

(http://www.unifi.it/home.html).<br />

Oltre alla traduzione degli hostname in indirizzi IP, <strong>il</strong> DNS fornisce altri<br />

importanti servizi quali:<br />

• Alias degli HostName. Ad un terminale, identificato con un hostname<br />

canonico complesso da ricordare, possano essere associati uno o più nomi<br />

alternativi (alias), che sono tipicamente caratterizzati da <strong>una</strong> maggiore<br />

mnemonicità. In casi come questo un’applicazione può richiedere ad un<br />

server DNS l’hostname canonico, fornendo un’alias oppure l’indirizzo IP<br />

del terminale.<br />

• Alias dei Server di Posta. Nella maggior parte dei casi i server di posta<br />

sono identificati da un hostname che non coincide con <strong>il</strong> nome di dominio<br />

al quale appartengono le caselle ema<strong>il</strong>; ad esempio la posta <strong>per</strong> <strong>il</strong> dominio<br />

example.com potrebbe essere gestita dal server ma<strong>il</strong>.example.com oppure<br />

46


Stato dell’arte: federazione su larga scala Domain Name System<br />

dai server con nome ma<strong>il</strong>1.example.com e ma<strong>il</strong>2.example.com. Il DNS,<br />

tramite un opportuno campo detto MX (Ma<strong>il</strong> eXchange), <strong>per</strong>mette di<br />

instradare i messaggi di posta (nei quali compare solo <strong>il</strong> nome di dominio)<br />

su uno dei server dedicati allo scopo <strong>per</strong>mettendo quindi di realizzare<br />

soluzioni di gestione della posta molto scalab<strong>il</strong>i. Ovviamente sarà DNS<br />

stesso che, dati gli hostname dei server di posta, <strong>per</strong>metterà al client di<br />

risolverli nei corrispondenti indirizzi IP <strong>per</strong> l’a<strong>per</strong>tura della connessione.<br />

• Alias <strong>per</strong> altri Servizi. Analogamente a quanto accade grazie al record<br />

MX, DNS supporta nativamente la capacità di risolvere l’hostname del<br />

server, o dei server, che, noto <strong>il</strong> dominio, erogano un determinato servizio<br />

[GVE00]. A titolo esemplificativo si può trarre beneficio da questa<br />

funzionalità ut<strong>il</strong>izzando <strong>il</strong> protocollo Jabber <strong>per</strong> la messaggistica istantanea<br />

oppure <strong>il</strong> protocollo SIP molto ut<strong>il</strong>izzato in campo VoIP. In entrambi<br />

gli esempi <strong>il</strong> record SRV <strong>per</strong>mette di andar ad individuare tutti i parametri<br />

necessari <strong>per</strong> la connessione al server di messaggistica istantanea oppure<br />

VoIP <strong>per</strong> raggiungere un utente individuato da un dominio di appartenenza<br />

e da un identificativo locale al dominio stesso, tipicamente espressi in<br />

<strong>una</strong> forma sim<strong>il</strong>e, se non identica, ad un indirizzo di posta elettronica (ad<br />

esempio user_id@example.com).<br />

• Distribuzione del carico. In genere i siti Internet più frequentati sono<br />

replicati su più server web aventi indirizzi IP differenti. Il DNS <strong>per</strong>mette<br />

di associare all’hostname canonico del sito l’intero insieme di tali indirizzi<br />

IP, adottando <strong>una</strong> politica che consente di distribuire <strong>il</strong> traffico degli utenti<br />

tra tutte le repliche.<br />

2.1.2 Architettura distribuita e federata del DNS<br />

Alle origini di Internet <strong>il</strong> DNS era costituito da un’unico server dei nomi<br />

che conteneva tutte le corrispondenze tra hostname e indirizzi IP, gestendo in<br />

maniera centralizzata tutte le richieste di ri<strong>soluzione</strong>. A questa organizzazione<br />

corrispondeva uno spazio dei nomi piano in cui ogni hostname era formato da<br />

<strong>una</strong> semplice sequenza di caratteri senza alc<strong>una</strong> struttura. A causa del progressivo<br />

aumento del numero di terminali, questa <strong>soluzione</strong> centralizzata si rivelò<br />

ben presto inadeguata <strong>per</strong> numerosi motivi tra cui:<br />

• Singolo punto di guasto. Un guasto al server dei nomi avrebbe compromesso<br />

<strong>il</strong> funzionamento dell’intera rete.<br />

• Volume di traffico. Il server dei nomi avrebbe dovuto gestire un numero<br />

eccessivo di richieste.<br />

• Database centralizato distante. Una richiesta di ri<strong>soluzione</strong> avrebbe comportato<br />

attese insostenib<strong>il</strong>i <strong>per</strong> i client geograficamente più lontani.<br />

47


Stato dell’arte: federazione su larga scala Domain Name System<br />

• Manutenzione. Per <strong>il</strong> server dei nomi sarebbe stato assai difficoltoso gestire<br />

le frequenti o<strong>per</strong>azioni d’aggiornamento richieste dalla registrazione<br />

di nuovi terminali.<br />

In sintesi la <strong>soluzione</strong> costituita da un database centralizzato in un unico<br />

server dei nomi rappresentava <strong>una</strong> <strong>soluzione</strong> non scalab<strong>il</strong>e. Per far fronte a<br />

tutto ciò gli sv<strong>il</strong>uppatori della rete hanno scelto di realizzare <strong>il</strong> DNS secondo<br />

un’architettura composta da un gran numero di server dei nomi, organizzati<br />

in modo gerarchico e distribuiti geograficamente in tutto <strong>il</strong> mondo. In questo<br />

modo le correlazioni tra hostname e indirizzi IP non sono più concentrate in un<br />

unico database, ma risultano distribuite attraverso tutti i server dei nomi.<br />

I dati immagazzinati nel DNS sono identificati da nomi di dominio che sono<br />

ordinati dal generico allo specifico secondo un albero che normalmente riflette i<br />

confini amministrativi delle organizzazioni. Ad ogni nodo dell’albero, chiamato<br />

dominio, viene assegnata <strong>una</strong> label. Il nome di dominio di un nodo è costituito<br />

dalla concatenazione di tutte le label sul <strong>per</strong>corso dal nodo al nodo radice. Tutto<br />

ciò è rappresentato in forma scritta come <strong>una</strong> stringa di label elencate da destra<br />

a sinistra e separate dal punto. Si osservi che <strong>una</strong> label deve essere unica solo<br />

entro <strong>il</strong> suo path di dominio.<br />

Ad esempio l’hostname lrst.det.unifi.it è composto da tre domini: quello<br />

di livello massimo è it, poi si ha unifi.it ed infine det.unifi.it, mentre<br />

lrst.det.unifi.it identifica un particolare hostname.<br />

Per scopi amministrativi, lo spazio dei nomi è suddiviso in aree chiamate<br />

zone, ogni zona inizia ad un nodo e si estende giù verso i nodi foglie o verso nodi<br />

dove iniziano nuove altre zone.<br />

Zone<br />

Come è stato affermato in precedenza, <strong>una</strong> zona è un punto di delega nell’albero<br />

DNS. Una zona consiste di elementi contigui dell’albero che organizza<br />

gerarchicamente i domini sui quali un server di nomi ha tutte le informazioni<br />

ed ha autorità. La zona contiene tutti i nomi di dominio da un certo punto in<br />

giù nell’albero ad eccezione di quelli che sono delegati ad altre zone. Un punto<br />

di delega è indicato da uno o più record NS (Name Server) nella zona padre,<br />

che dovrebbe a sua volta essere indicata da un equivalente record NS alla radice<br />

della zona delegata. Una zona può essere mappata direttamente su un singolo<br />

dominio, ma può anche includere solo parte di un dominio <strong>il</strong> resto del quale sarà<br />

delegato ad altri server di nomi.<br />

Server di nomi autoritativi<br />

Ogni zona è servita da almeno un server autoritativo che contiene tutti i dati<br />

<strong>per</strong> la zona. Per rendere <strong>il</strong> DNS tollerante ai guasti, molte zone hanno due o<br />

48


Stato dell’arte: federazione su larga scala Domain Name System<br />

più server autoritativi: un master e zero, uno o più slave.<br />

• Il master primario. Il server autoritativo dove è mantenuta la copia master<br />

dei dati della zona è chiamato server master primario, o semplicemente<br />

primario. Questo server carica i contenuti della zona da un f<strong>il</strong>e locale detto<br />

f<strong>il</strong>e di zona o <strong>il</strong> master f<strong>il</strong>e. Normalmente è questo f<strong>il</strong>e che viene editato<br />

manualmente dagli amministratori (o automaticamente da opportuni<br />

s<strong>of</strong>tware) <strong>per</strong> definire la zona a cui fa riferimento.<br />

• I server slave. Gli altri server autoritativi, detti slave (anche conosciuti come<br />

server secondari), acquisiscono i contenuti della zona da un altro server<br />

ut<strong>il</strong>izzando un processo di replica conosciuto come trasferimento di zona.<br />

Usualmente i dati sono trasferiti direttamente dal master primario, ma è<br />

anche possib<strong>il</strong>e trasferirli da un altro server slave (in questo caso un server<br />

slave può agire come un master <strong>per</strong> un altro slave server subordinato).<br />

• I server stealth (nascosti). Solitamente tutte le zone dei server autoritativi<br />

sono elencate attraverso record NS nella zona padre. Questi record NS<br />

rappresentano la delega della zona dal padre. I server autoritativi sono<br />

anche indicati nel f<strong>il</strong>e stesso di zona al livello top o livello apex della zona.<br />

Un server stealth è un server autoritativo <strong>per</strong> <strong>una</strong> zona, ma che non è<br />

elencato nei record NS di quella zona.<br />

In altre parole un server stealth è in grado di rispondere a qualsiasi interrogazione<br />

che gli viene posta relativamente alla zona sulla quale è autoritativo,<br />

ma non è visib<strong>il</strong>e agli altri server DNS. È quindi possib<strong>il</strong>e interrogarlo<br />

direttamente, ma non sarà raggiungib<strong>il</strong>e <strong>per</strong>correndo l’albero delle deleghe.<br />

I server stealth possono essere quindi ut<strong>il</strong>izzati <strong>per</strong> tenere <strong>una</strong> copia locale<br />

di <strong>una</strong> zona, ad esempio all’interno di <strong>una</strong> rete privata, in modo da<br />

accelerare l’accesso ai record della zona o <strong>per</strong> fare in modo che la zona sia<br />

disponib<strong>il</strong>e anche se tutti i server “ufficiali” siano irragiungib<strong>il</strong>i.<br />

Una configurazione dove <strong>il</strong> server master primario stesso è un server stealth<br />

viene detta con primario nascosto. Tipicamente questa configurazione<br />

viene ut<strong>il</strong>izzata installando <strong>il</strong> master primario dietro ad un firewall e<br />

rendendolo incapace di comunicare direttamente con <strong>il</strong> mondo esterno.<br />

Chacing Name Server<br />

Le librerie di ri<strong>soluzione</strong> fornite dalla maggior parte dei sistemi o<strong>per</strong>ati sono<br />

stub resolver, nel senso che non sono capaci di realizzare un pieno processo di<br />

ri<strong>soluzione</strong> parlando direttamente con i server autoritativi. Per ottenere ciò<br />

si basano su un server di nomi locale al quale si appoggiano <strong>per</strong> soddisfare<br />

49


Stato dell’arte: federazione su larga scala Domain Name System<br />

le richieste di ri<strong>soluzione</strong>. Tale server è detto ricorsivo 2 ed effettua ricerche<br />

ricorsive <strong>per</strong> client locali.<br />

Per migliorare la prestazioni i server ricorsivi memorizzano in <strong>una</strong> memoria<br />

cache i risultati delle ricerche che eseguono, in modo da poter rispondere<br />

istantaneamente a nuove richieste di ri<strong>soluzione</strong> già soddisfatte in precedenza.<br />

Il tempo <strong>per</strong> cui un record può essere mantenuto nella memoria cache è<br />

controllato direttamente tramite <strong>il</strong> campo Time to Live (TTL) associato ad<br />

ogni resource record.<br />

Ogni caching name server non realizza necessariamente la ricerca ricorsiva.<br />

Può infatti inoltrare alcune (o tutte) le richieste che non riesce a soddisfare verso<br />

un altro server che di solito è indicato come forwarder. Possono esistere anche<br />

più di un forwarder che vengono interrogati a turno finché la lista non è stata<br />

esaurita (oppure la risposta non è trovata).<br />

I forwarders sono tipicamente ut<strong>il</strong>izzati quando non si desidera che i server di<br />

un certo sito interagiscano direttamente con <strong>il</strong> resto dei server Internet. Un tipico<br />

scenario è quello in cui si hanno un certo numero di server DNS in rete locale<br />

protetti da un firewall. La configurazione del firewall è tale <strong>per</strong> cui tali server,<br />

incapaci di inviare i pacchetti attraverso <strong>il</strong> firewall stesso, possono farlo verso <strong>il</strong><br />

server (<strong>il</strong> forwarder dello scenario in esame) direttamente connesso alla rete. Un<br />

ulteriore beneficio proveniente dall’ut<strong>il</strong>izzare la strategia di forwarding è che la<br />

macchina centrale riesce a realizzare <strong>una</strong> cache più completa <strong>per</strong> informazioni a<br />

cui tutti i clienti possono accedere.<br />

I Record Type<br />

Anche se inizialmente <strong>il</strong> DNS non supportava un numero molto elevato di<br />

record type, oggi la situazione è cambiata. Con <strong>il</strong> tempo ne è stato aggiunto un<br />

numero considerevole con <strong>il</strong> fine di ut<strong>il</strong>izzare <strong>il</strong> sistema <strong>per</strong> scopi e/o in contesti<br />

inizialmente non prevedib<strong>il</strong>i o previsti. Come è possib<strong>il</strong>e intuire dalla figura 2.2<br />

(che mostra tutti i record type gestiti ufficialmente al 16-07-2009 [IAN09]) <strong>il</strong><br />

processo che ha portato ad avere un numero così elevato di tipi è stato molto<br />

lungo. Questo aspetto <strong>per</strong>mette di sottolineare che <strong>il</strong> DNS, oltre ad avere <strong>una</strong><br />

comprovata scalab<strong>il</strong>ità <strong>per</strong> quel che riguarda <strong>il</strong> suo compito primario (ovvero la<br />

ri<strong>soluzione</strong> di nomi), si è dimostrato molto scalab<strong>il</strong>e anche <strong>per</strong> quanto riguarda la<br />

flessib<strong>il</strong>ità: è infatti riuscito costantemente ad adattarsi alla continua evoluzione<br />

di Internet.<br />

2 Come descritto nel paragrafo 2.1.4, ogni elemento che entra in gioco nel processo di<br />

ri<strong>soluzione</strong> può agire in modo ricorsivo oppure iterativo.<br />

50


Stato dell’arte: federazione su larga scala Domain Name System<br />

TYPE Value and meaning Reference<br />

A 1 a host address [RFC1035]<br />

NS 2 an authoritative name server [RFC1035]<br />

MD 3 a ma<strong>il</strong> destination (Obsolete - use MX) [RFC1035]<br />

MF 4 a ma<strong>il</strong> forwarder (Obsolete - use MX) [RFC1035]<br />

CNAME 5 the canonical name for an alias [RFC1035]<br />

SOA 6 marks the start <strong>of</strong> a zone <strong>of</strong> authority [RFC1035]<br />

MB 7 a ma<strong>il</strong>box domain name (EXPERIMENTAL) [RFC1035]<br />

MG 8 a ma<strong>il</strong> group member (EXPERIMENTAL) [RFC1035]<br />

MR 9 a ma<strong>il</strong> rename domain name (EXP.) [RFC1035]<br />

NULL 10 a null RR (EXPERIMENTAL) [RFC1035]<br />

WKS 11 a well known service description [RFC1035]<br />

PTR 12 a domain name pointer [RFC1035]<br />

HINFO 13 host information [RFC1035]<br />

MINFO 14 ma<strong>il</strong>box or ma<strong>il</strong> list information [RFC1035]<br />

MX 15 ma<strong>il</strong> exchange [RFC1035]<br />

TXT 16 text strings [RFC1035]<br />

RP 17 for Responsible Person [RFC1183]<br />

AFSDB 18 for AFS Data Base location [RFC1183]<br />

X25 19 for X.25 PSDN address [RFC1183]<br />

ISDN 20 for ISDN address [RFC1183]<br />

RT 21 for Route Through [RFC1183]<br />

NSAP 22 for NSAP address, NSAP style A record [RFC1706]<br />

NSAP-PTR 23 for domain name pointer, NSAP style [RFC1348]<br />

SIG 24 for security signature<br />

KEY 25 for security key<br />

[RFC4034]<br />

[RFC3755]<br />

[RFC2535]<br />

[RFC4034]<br />

[RFC3755]<br />

[RFC2535]<br />

PX 26 X.400 ma<strong>il</strong> mapping information [RFC2163]<br />

GPOS 27 Geographical Position [RFC1712]<br />

AAAA 28 IP6 Address [RFC3596]<br />

LOC 29 Location Information [RFC1876]<br />

NXT 30 Next Domain - OBSOLETE<br />

[RFC3755]<br />

[RFC2535]<br />

EID 31 Endpoint Identifier [Patton]<br />

NIMLOC 32 Nimrod Locator [Patton]<br />

SRV 33 Server Selection [RFC2782]<br />

ATMA 34 ATM Address [ATMDOC]<br />

NAPTR 35 Naming Authority Pointer<br />

[RFC2915]<br />

[RFC2168]<br />

51


Stato dell’arte: federazione su larga scala Domain Name System<br />

TYPE Value and meaning Reference<br />

KX 36 Key Exchanger [RFC2230]<br />

CERT 37 CERT [RFC2538]<br />

A6 38 A6 (Ex<strong>per</strong>imental)<br />

[RFC3226]<br />

[RFC2874]<br />

DNAME 39 DNAME [RFC2672]<br />

SINK 40 SINK [Eastlake]<br />

OPT 41 OPT [RFC2671]<br />

APL 42 APL [RFC3123]<br />

DS 43 Delegation Signer [RFC3658]<br />

SSHFP 44 SSH Key Fingerprint [RFC4255]<br />

IPSECKEY 45 IPSECKEY [RFC4025]<br />

RRSIG 46 RRSIG<br />

NSEC 47 NSEC<br />

DNSKEY 48 DNSKEY<br />

[RFC4034]<br />

[RFC3755]<br />

[RFC4034]<br />

[RFC3755]<br />

[RFC4034]<br />

[RFC3755]<br />

DHCID 49 DHCID [RFC4701]<br />

NSEC3 50 NSEC3 [RFC5155]<br />

NSEC3PARAM 51 NSEC3PARAM [RFC5155]<br />

Unassigned 52-54<br />

HIP 55 Host Identity Protocol [RFC5205]<br />

NINFO 56 NINFO [Reid]<br />

RKEY 57 RKEY [Reid]<br />

Unassigned 58-98<br />

SPF 99 [RFC4408]<br />

UINFO 100 [IANA-Reserved]<br />

UID 101 [IANA-Reserved]<br />

GID 102 [IANA-Reserved]<br />

UNSPEC 103 [IANA-Reserved]<br />

Unassigned 104-248<br />

TKEY 249 Transaction Key [RFC2930]<br />

TSIG 250 Transaction Signature [RFC2845]<br />

IXFR 251 incremental transfer [RFC1995]<br />

AXFR 252 transfer <strong>of</strong> an entire zone [RFC1035]<br />

MAILB<br />

253 ma<strong>il</strong>box-related<br />

RRs (MB, MG or MR)<br />

[RFC1035]<br />

MAILA 254 ma<strong>il</strong> agent RRs (Obsolete, see MX) [RFC1035]<br />

* 255 A request for all records [RFC1035]<br />

Unassigned 256-32767<br />

52


Stato dell’arte: federazione su larga scala Domain Name System<br />

TYPE Value and meaning Reference<br />

TA 32768 DNSSEC Trust Authorities<br />

[We<strong>il</strong>er]<br />

2005-12-13<br />

DLV 32769 DNSSEC Lookaside Validation [RFC4431]<br />

Unassigned 32770-65279<br />

Private use 65280-65534<br />

Reserved 65535<br />

Figura 2.2: Record Type del DNS.<br />

Per capire come questa evoluzione sia stata possib<strong>il</strong>e può essere ut<strong>il</strong>e citare,<br />

a titolo esemplificativo, i campi TXT ed SPF. Il campo TXT è stato introdotto<br />

con lo scopo di poter associare <strong>una</strong> o più stringhe testuali ai nomi trattati<br />

dal sistema; questo <strong>per</strong> <strong>per</strong>mettere agli umani di poter interrogare <strong>il</strong> DNS <strong>per</strong><br />

ottenere informazioni descrittive in un formato human-friendly. Non avendo<br />

imposto limitazioni relative all’uso del campo TXT, non è infrequente trovare<br />

in questo tipo di record dei metadati (destinati alle macchine) e non del testo<br />

descrittivo come sarebbe possib<strong>il</strong>e aspettarsi. Nell’esempio in discussione può<br />

essere infatti ut<strong>il</strong>izzato <strong>per</strong> veicolare informazioni, destinate alle macchine, riguardanti<br />

SPF. La RFC 4408 [WS06] che definisce <strong>il</strong> “Sender Policy Framework<br />

(SPF)” 3 definisce anche <strong>il</strong> relativo resource type; in ogni caso la RFC stessa<br />

prevede che esistano, come è ovvio che sia, sia server che resolver non aggiornati<br />

e quindi non in grado di poterlo interpretare.<br />

Per aggirare questo inconveniente la RFC afferma che un dominio SPFcompliant<br />

deve esporre le informazioni definite da SPF in entrambe le modalità<br />

ovvero sia ricorrendo al nuovo campo dedicato che come metadato imbustato<br />

in un generico record TXT. Inoltre un nome di dominio SPF-compliant deve<br />

necessariamente esporre tali informazioni in almeno <strong>una</strong> delle due modalità,<br />

con <strong>il</strong> vincolo che se le usa entrambe esse devono avere contenuti identici. Ad<br />

esempio:<br />

example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"<br />

example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"<br />

2.1.3 Funzionalità avanzate<br />

Le funzionalità descritte nel paragrafo precedente sono state introdotte con<br />

le prime versioni del DNS e vanno a definire le caratteristiche di base del sistema<br />

stesso. Con <strong>il</strong> passare degli anni sono state proposte ed aggiunte nuove funzio-<br />

3 SPF ha l’obiettivo di <strong>per</strong>mettere di verificare, con <strong>una</strong> certa affidab<strong>il</strong>ità, se <strong>una</strong> e-ma<strong>il</strong><br />

è contraffatta o meno. Anche se non è finalizzato a bloccare lo spam direttamente, è uno<br />

strumento ut<strong>il</strong>e <strong>per</strong> combatterlo in quanto fornisce ai proprietari dei domini un metodo <strong>per</strong><br />

dichiarare quali sono i server di posta autorizzati ad inviare ma<strong>il</strong>.<br />

53


Stato dell’arte: federazione su larga scala Domain Name System<br />

nalità, con <strong>il</strong> fine di andare a soddisfare nuovi requisiti o<strong>per</strong>ativi come l’esigenza<br />

di poter aggiornare dinamicamente le zone 4 .<br />

Nei sotto paragrafi seguenti verranno riportate le ulteriori funzionalità di cui<br />

dispone <strong>il</strong> DNS che non rientrano fra le caratteristiche di base del sistema.<br />

Notify<br />

DNS NOTIFY è un meccanismo, introdotto con la RFC 1996 [Vix96], che<br />

<strong>per</strong>mette al server master di rendere noto agli slave che sono state apportate<br />

delle variazioni alla zona in cui sono autoritativi. A seguito della NOTIFY<br />

proveniente dal master, lo slave controllerà che la sua versione della zona sia<br />

quella corrente e, nel caso in cui non lo sia, avvia un trasferimento di zona <strong>per</strong><br />

l’aggiornamento della stessa.<br />

Aggiornamenti dinamici<br />

Gli aggiornamenti dinamici sono un metodo <strong>per</strong> aggiungere, sostituire o eliminare<br />

record in <strong>una</strong> zona inviando al master della stessa opportune query DNS.<br />

Il formato e <strong>il</strong> significato di queste query è specificato nella RFC 2136 [VTRB97].<br />

Gli aggiornamenti dinamici vengono attivati zona <strong>per</strong> zona, inserendo la<br />

clausola allow-update o allow-policy nella dichiarazione di zona.<br />

Durante l’aggiornamento di zone sicure (ovvero che ut<strong>il</strong>izzano DNSSEC, descritto<br />

successivamente) dopo la modifica della zona, <strong>il</strong> server è in grado di<br />

rigenerare tutti i campi necessari (firme) <strong>per</strong> la validità della zona.<br />

A seguito di un aggiornamento dinamico non si ha necessariamente, <strong>per</strong> motivi<br />

di <strong>per</strong>formance, l’aggiornamento del f<strong>il</strong>e di zona. Viceversa gli aggiornamenti<br />

dinamici vengono memorizzati in opportuni f<strong>il</strong>e di journal binari (che <strong>il</strong> server<br />

può gestire in modo molto più efficiente rispetto ai f<strong>il</strong>e testuali che definiscono le<br />

zone). In ogni caso, ad intervalli di tempo più o meno regolari ed ad ogni riavvio<br />

del server, <strong>il</strong> f<strong>il</strong>e di journal viene eliminato andando ad integrare le modifiche<br />

che memorizza nel f<strong>il</strong>e di zona.<br />

I f<strong>il</strong>e di zona <strong>per</strong> zone dinamiche non possono più essere editati manualmente<br />

<strong>per</strong> evitare inconsistenze e conflitti che possono sorgere a seguito delle modifiche<br />

pendenti che si trovano nel f<strong>il</strong>e di journal. Per editare manualmente zone dinamiche,<br />

o<strong>per</strong>azione che in alcuni casi può rendersi necessaria, è possib<strong>il</strong>e agire<br />

nei seguenti modi:<br />

• fermare <strong>il</strong> server DNS, modificare la zona ed infine far ripartire <strong>il</strong> server.<br />

Questo modo di o<strong>per</strong>are garantisce che l’o<strong>per</strong>azione non generi conflitti in<br />

quanto quando <strong>il</strong> server viene fermato esso aggiorna <strong>il</strong> f<strong>il</strong>e di zona sulla<br />

4 Si intende la possib<strong>il</strong>ità di effettuare delle query, ut<strong>il</strong>izzando l’interfaccia standard di interrogazione,<br />

che <strong>per</strong>mettano l’aggiornamento delle zone; l’aggiornamento delle zone modificando<br />

<strong>il</strong> f<strong>il</strong>e di zona con un successivo refresh a caldo dello stesso (senza disservizio) era già presente,<br />

e lo è tutt’ora, in molte implementazioni del DNS.<br />

54


Stato dell’arte: federazione su larga scala Domain Name System<br />

base del contenuto del f<strong>il</strong>e di journal, ma rende non disponib<strong>il</strong>e <strong>il</strong> servizio<br />

di ri<strong>soluzione</strong> <strong>per</strong> tutto <strong>il</strong> tempo necessario ad editare <strong>il</strong> f<strong>il</strong>e;<br />

• inibire temporaneamente gli aggiornamenti dinamici, aggiornare <strong>il</strong> f<strong>il</strong>e di<br />

zona ed infine ripristinare gli aggiornamenti dinamici. Anche questo modo<br />

di o<strong>per</strong>are garantisce che l’o<strong>per</strong>azione non generi conflitti in quanto<br />

inibendo gli aggiornamenti dinamici <strong>il</strong> server allinea, come nel caso precedente,<br />

<strong>il</strong> contenuto del f<strong>il</strong>e di zona alle ultime modifiche registrate nel f<strong>il</strong>e<br />

di journal.<br />

Trasferimenti di zona incrementali (IXFR)<br />

Il protocollo <strong>per</strong> <strong>il</strong> trasferimento della zona in modo incrementale (IXFR, definito<br />

nella RFC 1995 [Oht96]) <strong>per</strong>mette ai server slave di trasferire solamente le<br />

variazioni apportate ad <strong>una</strong> zona, invece di dover trasferirne l’intero contenuto.<br />

Il protocollo IXFR è necessariamente attivo <strong>per</strong> le zone nelle quali si hanno<br />

aggiornamenti dinamici, mentre <strong>per</strong> le altre zone può essere attivato o meno<br />

dall’amministratore delle zone.<br />

Split DNS<br />

La realizzazione di viste diversificate dello spazio DNS verso risolutori appartenenti<br />

a categorie diverse è di solito indicata come Split DNS setup. Ci sono<br />

diverse ragioni <strong>per</strong> cui un’organizzazione vorrebbe configurare <strong>il</strong> DNS secondo<br />

questa modalità.<br />

Una ragione comune <strong>per</strong> installare un sistema DNS in questo modo è quella di<br />

voler nascondere l’informazione relativa alla rete “interna” contenuta nel DNS<br />

ai client “esterni” presenti su Internet. Esistono varie teorie relativamente al<br />

fatto che ciò sia o non sia effettivamente ut<strong>il</strong>e. Le informazioni contenute nel<br />

DNS, associate alla rete interna, possono fuoriuscire in molti modi (attraverso<br />

gli header delle ma<strong>il</strong>, <strong>per</strong> esempio) e potenziali aggressori possono trovare le<br />

informazioni di cui hanno bisogno ut<strong>il</strong>izzando altri mezzi.<br />

TSIG<br />

TSIG (Transaction SIGnature) è un protocollo definito nella RFC 2845<br />

[VGEW00] che, basandosi su chiavi crittografiche condivise e hashing one-way 5 ,<br />

consente di identificare in modo sicuro <strong>il</strong> servizio all’altro lato di <strong>una</strong> connessione.<br />

Nel DNS, TSIG viene usato principalmente <strong>per</strong> la comunicazione fra server<br />

inclusi i trasferimenti di zona, le notifiche ed i messaggi ricorsivi <strong>per</strong> le query,<br />

ma l’ut<strong>il</strong>izzo più tipico è relativo agli aggiornamenti dinamici. Infatti, un server<br />

primario <strong>per</strong> <strong>una</strong> data zona dinamica quasi certamente implementa <strong>una</strong> qualche<br />

5 L’hashing one-way è <strong>una</strong> tecnica che <strong>per</strong>mette di mantenere al sicuro la chiave condivisa<br />

evitando di veicolarla su canali insicuri.<br />

55


Stato dell’arte: federazione su larga scala Domain Name System<br />

forma di controllo degli accessi <strong>per</strong> autorizzare i client ad effettuare gli aggiornamenti.<br />

Una possib<strong>il</strong>e politica è quella di un controllo degli accessi basato sugli<br />

IP, ma <strong>il</strong> supporto crittografico <strong>of</strong>ferto dal TISG apre la strada a soluzioni di<br />

gran lunga su<strong>per</strong>iori.<br />

Il trattamento di messaggi firmati tramite TSIG può dare origine a vari errori.<br />

Se un messaggio firmato è inviato ad un server che non è TSIG-aware, sarà<br />

ottenuto un errore di tipo FORMERR, dato che <strong>il</strong> server non può decodificare <strong>il</strong><br />

messaggio che giunge criptato. Se un server di tipo TISG-aware riceve un messaggio<br />

firmato da <strong>una</strong> chiave sconosciuta, la risposta non sarà firmata e avrà <strong>il</strong><br />

codice di errore posto a BADKEY. Se un server di tipo TSIG-aware riceve un<br />

messaggio con <strong>una</strong> firma che non può validare, la risposta non sarà firmata e<br />

avrà <strong>il</strong> codice di errore posto a BADSIG. Se un server di tipo TISG-aware riceve<br />

un messaggio con un tempo fuori del range <strong>per</strong>messo, la risposta sarà firmata<br />

con <strong>il</strong> codice di errore posto a BADTIME, i valori di tempo saranno aggiustati<br />

in modo che la risposta possa essere verificata con successo. Ovviamente, in<br />

tutti questi casi <strong>il</strong> server considera fallito <strong>il</strong> tentativo di autenticazione da parte<br />

del client.<br />

Nella RFC 2845 che definisce TSIG non vengono citati meccanismi, ad eccezione<br />

di quello manuale, <strong>per</strong> rendere o<strong>per</strong>ativo <strong>il</strong> sistema di autenticazione<br />

basato sulla chiave condivisa andando a distribuire la chiave stessa fra i client<br />

ed i server interessati. La RFC 2930 [Eas00b] ha introdotto <strong>il</strong> TKEY resource<br />

record che può essere ut<strong>il</strong>izzato, in vari modi diversi, <strong>per</strong> condividere e/o cancellare<br />

la chiave condivisa fra i client ed i server DNS. Si noti che la specifica<br />

richiede che TKEY venga ut<strong>il</strong>izzato solo fra server <strong>per</strong> i quali sia già attivo<br />

un meccanismo che fornisca confidenzialità e riservatezza come TSIG, SIG(0)<br />

(descritto in seguito) oppure GSS-API 6 .<br />

SIG(0)<br />

SIG(0), definito nella RFC 2535 [Eas99] che è stata aggiornata dalla RFC<br />

2931 [Eas00a], è un meccanismo che <strong>per</strong>mette di effettuare un controllo degli<br />

accessi del tutto sim<strong>il</strong>e a TSIG con la differenza che, in questo caso, si lavora<br />

con crittografia asimmetrica e si hanno quindi coppie di chiavi pubbliche/private<br />

anziché un’unica chiave condivisa.<br />

Una caratteristica peculiare di SIG(0) è che garantisce al client <strong>una</strong> autenticazione<br />

basata su transazioni: questo significa che <strong>il</strong> client ha la garanzia che<br />

le response che riceve sono state generate dal server al quale ha effettuato la<br />

request ed a queste correlate.<br />

6 Generic Security Service - Application Program Interface [Lin00, Wra00].<br />

56


Stato dell’arte: federazione su larga scala Domain Name System<br />

DNSSEC<br />

TSIG e SIG(0) sono due meccanismi di autenticazione fra client e server,<br />

ma non <strong>of</strong>frono garanzie relativamente ai dati contenuti nelle zone in gestione<br />

ai vari server in gioco. La realizzazione di zone sicure è resa possib<strong>il</strong>e attraverso<br />

le estensioni DNS Security (DNSSEC-bis) definite nelle RFC 4033 [AAL + 05] e<br />

RFC 4470 [WI06]. Lo scopo è quello di proteggere la rete da certi tipi di attacco<br />

come l’avvelenamento della cache dei server dei nomi 7 .<br />

2.1.4 Funzionamento del sistema<br />

Nella figura 2.3 viene <strong>il</strong>lustrata <strong>una</strong> piccola parte della gerarchia dei nomi di<br />

dominio di Internet; come si vede Google, che è un’organizzazione commerciale,<br />

è registrata come google.com, mentre <strong>il</strong> dipartimento di “Computer Science”<br />

dell’università di Berkeley è registrato come cs.berkeley.edu.<br />

in-addr<br />

arpa com edu<br />

google<br />

www<br />

colorado<br />

cs<br />

www<br />

org<br />

uk<br />

berkeley interdatanet<br />

cs www<br />

Figura 2.3: Struttura del Domain Name System.<br />

Verrà ora introdotto un esempio <strong>per</strong> spiegare <strong>il</strong> funzionamento del DNS.<br />

Nell’esempio viene fatto riferimento a tre tipi di server di nomi:<br />

• locale, ovvero interno all’organizzazione nella quale risiedono i client che<br />

effettuano le richieste di ri<strong>soluzione</strong>;<br />

• radice, ovvero in grado di rispondere alle richieste di ri<strong>soluzione</strong> riguardanti<br />

lo spazio dei nomi nel dominio principale detto radice. Il compito dei server<br />

7 Attacco che consiste nell’inviare al server DNS dei record alterati fraudolentemente (facendogli<br />

credere che siano autentici) <strong>per</strong> alterarne <strong>il</strong> comportamento: <strong>il</strong> server manterrà nella<br />

cache tali informazioni e le diffonderà, fino al termine della validità della cache, agli utenti che<br />

ne faranno richiesta.<br />

it<br />

57


Stato dell’arte: federazione su larga scala Domain Name System<br />

radice è quindi quello di indirizzare le richieste relative ai domini di primo<br />

livello 8 a server DNS su di essi autoritativi.<br />

• autoritativo, definito nel paragrafo 2.1.2.<br />

Ciascun Internet Service Provider (ISP) di accesso ha un server dei nomi<br />

locale al quale invia le richieste di ri<strong>soluzione</strong> ricevute dai terminali dei propri<br />

utenti. Se la query è relativa ad un elemento definito in <strong>una</strong> zona su cui tale<br />

server è autoritativo oppure è in cache ed è ancora valida <strong>il</strong> server dei nomi<br />

locale potrà fornire immediatamente la risposta al client.<br />

Server dei<br />

nomi locale<br />

dns.toscana.org<br />

1<br />

2<br />

6<br />

Server dei nomi radice<br />

5<br />

Host richiedente<br />

browser.toscana.org<br />

Figura 2.4: Esempio di funzionamento del DNS.<br />

3<br />

4<br />

Server dei<br />

nomi assoluto<br />

dns.unifi.it<br />

In caso contrario <strong>il</strong> server dei nomi locale si comporta come un client DNS<br />

e invia la richiesta ad un server dei nomi radice. Se quest’ultimo è in grado di<br />

rispondere (e lo è nei casi citati al punto precedente) lo farà, altrimenti si hanno<br />

due possib<strong>il</strong>ità:<br />

1. <strong>il</strong> server dei nomi radice conosce l’indirizzo IP di un server autoritativo<br />

sulla zona relativamente alla quale è stata effettuata la query;<br />

2. <strong>il</strong> server dei nomi radice conosce l’indirizzo IP di un server dei nomi intermedio<br />

che, a sua volta, possiede l’indirizzo IP di un server autoritativo.<br />

8 I domini di primo livello sono: it, com, net, org, etc.<br />

58


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

Si osservi che in quest’ultimo caso i server intermedi possono essere ben<br />

più di uno e non è necessario raggiungerne uno autoritativo <strong>per</strong> ottenere<br />

la risposta in un server qualunque fra quelli intermedi contattati potrebbe<br />

averla in cache e fornirla (ovviamente se la richiesta giunge entro <strong>il</strong> tempo<br />

di validità della cache) interrompendo l’algoritmo di ri<strong>soluzione</strong>.<br />

Nella procedura appena descritta e schematizzata in figura 2.4, si è assunto<br />

che tutte le richieste di ri<strong>soluzione</strong> fossero di tipo ricorsivo <strong>per</strong> cui se un client<br />

S1 (ad esempio browser.toscana.org) inoltra <strong>una</strong> richiesta di ri<strong>soluzione</strong> ad<br />

un server S2 (ad esempio dns.toscana.org), allora quest’ultimo ottiene la correlazione<br />

richiesta in vece di S1 (<strong>il</strong> quale esso stesso provvederà a fornirla nel<br />

momento in cui la ottiene).<br />

In realtà <strong>il</strong> protocollo DNS prevede anche la presenza di richieste di tipo<br />

iterativo in cui, a differenza del caso precedente, se S2 non è in grado di fornire<br />

<strong>una</strong> risposta alla query, allora invia ad S1 l’indirizzo IP del successivo server<br />

dei nomi da contattare. Ovviamente nella catena di richieste ci possono essere<br />

richieste sia di tipo iterativo che di tipo ricorsivo. Solitamente tutte le richieste<br />

della catena sono ricorsive, eccetto quella fatta al server dei nomi radice che è<br />

iterativa: questa politica <strong>per</strong>mette infatti di snellire <strong>il</strong> carico di lavoro dei server<br />

radice, i quali devono gestire un numero di richieste assai maggiore rispetto agli<br />

altri server dei nomi.<br />

2.2 Lightweight Directory Access Protocol<br />

Il protocollo LDAP (RFC 4510 [Zei06b]) è uno standard a<strong>per</strong>to <strong>per</strong> la gestione<br />

di un servizio di directory in ambiente distribuito. Esso costituisce <strong>una</strong><br />

versione semplificata del protocollo X.500, definito dall’International Standard<br />

Organization (OSI), a differenza del quale risulta <strong>per</strong>fettamente compatib<strong>il</strong>e con<br />

la suite protocollare TCP/IP. Gli oggetti memorizzati in <strong>una</strong> directory LDAP<br />

sono detti entry e possono essere univocamente referenziati mediante un nome,<br />

detto distinguished name (DN, RFC 4514 [Zei06a]). Le informazioni relative ai<br />

vari oggetti sono contenute in un insieme di attributi che vengono definiti all’interno<br />

di uno schema relativo alla directory sotto forma di coppie campo-valore.<br />

Ogni entry ha associati uno o più objectClass che, tramite lo schema, definiscono<br />

quali attributi l’entry deve avere (obbligatori), quali attributi l’entry può avere<br />

(opzionali) ed <strong>il</strong> loro tipo. Un semplice esempio di entry è riportato in figura 2.5.<br />

Nel loro complesso gli elementi di <strong>una</strong> directory presentano <strong>una</strong> struttura<br />

gerarchica ad albero 9 , detta DIT (Directory Information Tree), che tipicamente<br />

riflette l’ambito di competenza dell’organizzazione cui fa capo <strong>il</strong> sevizio di<br />

9 Nella teoria dei grafi si definisce albero un grafo non orientato, connesso e privo di cicli;<br />

due nodi qualsiasi di un albero sono connessi da uno ed un solo cammino.<br />

59


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

dn: uid=davide.chini,ou=People,dc=example,dc=com<br />

objectClass: top<br />

objectClass: <strong>per</strong>son<br />

objectClass: organizationalPerson<br />

objectClass: inetOrgPerson<br />

objectClass: posixAccount<br />

objectClass: shadowAccount<br />

cn: Davide Chini<br />

sn: Chini<br />

givenName: Davide<br />

uid: davide.chini<br />

uidNumber: 2009<br />

gidNumber: 513<br />

homeDirectory: /home/davide.chini<br />

loginShell: /bin/zsh<br />

gecos: System User<br />

userPassword: {SSHA}pug8DWwTQnKQQQpaDe1cPCpxwYdVnv8M<br />

Figura 2.5: Esempio di entry LDAP.<br />

directory. In figura 2.6 è riportato un estratto di un DIT in cui, come foglia,<br />

compare l’entry di figura 2.5.<br />

Le directory LDAP non supportano transazioni o i complessi meccanismi di<br />

roll-back tipici dei database relazionali. Sono tendenzialmente in sola lettura:<br />

gli aggiornamenti, quando <strong>per</strong>messi, avvengono in un numero molto più piccolo<br />

rispetto alle letture. Questa limitazione è necessaria <strong>per</strong> poter ottimizzare la<br />

directory <strong>per</strong> rispondere efficientemente a consistenti accessi in lettura ed a<br />

interrogazioni di ricerca che possono interessare tutti i valori contenuti nelle<br />

foglie (<strong>per</strong> questo motivo è possib<strong>il</strong>e prevedere indici <strong>per</strong> l’ottimizzazione delle<br />

ricerche sui campi più critici).<br />

Anche la replicazione dei server LDAP, che normalmente viene messa in atto<br />

<strong>per</strong> incrementare la scalab<strong>il</strong>ità relativamente al numero di accessi <strong>per</strong> unità di<br />

tempo e la disponib<strong>il</strong>ità, è agevolata dalla natura write-once-read-many-times<br />

dei dati contenuti nelle directory. Normalmente si ammette la presenza di un<br />

certo tempo di propagazione (che dipende dall’applicazione che ut<strong>il</strong>izza i dati<br />

presenti della directory) <strong>per</strong> le modifiche fra le varie repliche.<br />

Una peculiarità della struttura ad albero di LDAP è quella di <strong>per</strong>mettere<br />

<strong>una</strong> divisione dei dati in più sottoparti, ottenute secondo criteri logici. Questa<br />

caratteristica è assai importante poiché consente di limitare le o<strong>per</strong>azioni di<br />

ricerca a sottoporzioni dell’albero, riducendo notevolmente i tempi e la complessità<br />

degli algoritmi di ricerca e di accesso. Inoltre questa caratteristica <strong>per</strong>mette<br />

di distribuire l’albero in un numero anche elevato di server LDAP, a beneficio<br />

della scalab<strong>il</strong>ità della struttura.<br />

Da un punto di vista funzionale <strong>il</strong> protocollo LDAP segue un paradigma di<br />

tipo client-server secondo la dinamica seguente: un client LDAP si connette a<br />

un server LDAP, richiedendo delle informazioni e/o fornendo i dati necessari <strong>per</strong><br />

accedere alla directory. A questo punto si hanno varie possib<strong>il</strong>ità:<br />

60


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

Organisation<br />

Unit<br />

The<br />

Organisation<br />

dc=net dc=com dc=DE<br />

dc=example<br />

ou=People ou=Servers<br />

uid=davide.chini Person<br />

Figura 2.6: Esempio di Directory Information Tree.<br />

1. <strong>il</strong> server contiene l’informazione richiesta e la comunica immediatamente<br />

al client;<br />

2. <strong>il</strong> server non contiene al suo interno l’informazione richiesta, ma è in grado<br />

di fornire al client un referral (l’indirizzo) di un successivo server LDAP. In<br />

questo caso <strong>il</strong> client può connettersi al nuovo server LDAP ed effettuare di<br />

nuovo l’interrogazione. Si noti che le ACL vengono implementate a livello<br />

di singolo server e quindi non è detto che credenziali valide <strong>per</strong> <strong>il</strong> primo<br />

server lo siano anche <strong>per</strong> <strong>il</strong> secondo server;<br />

3. <strong>il</strong> server è configurato <strong>per</strong> seguire i referral (modalità chaining). In questo<br />

caso provvederà esso stesso ad interrogare <strong>il</strong> nuovo server in modo da <strong>of</strong>frire<br />

al client o la risposta all’interrogazione effettuata o un messaggio di<br />

errore. Oltre ad un meccanismo di autenticazione convenzionale, secondo<br />

<strong>il</strong> quale <strong>il</strong> server che agisce da client dispone di un account <strong>per</strong> l’accesso<br />

al secondo server con tutti i diritti necessari <strong>per</strong> svolgere correttamente le<br />

o<strong>per</strong>azioni di chaining, è previsto un meccanismo <strong>per</strong> la gestione delle identità<br />

in modalità proxy: <strong>il</strong> server che agisce da client si autentica al nuovo<br />

server con un utente creato ad-hoc al quale viene assegnato <strong>il</strong> <strong>per</strong>messo di<br />

effettuare interrogazioni a nome di altri utenti. Le ACL vengono gestite<br />

sul server di destinazione, sia quelle degli utenti convenzionali che quelle<br />

61


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

dell’utente proxy <strong>per</strong> ab<strong>il</strong>itare in modo selettivo quali sono le identità che<br />

tale utente può im<strong>per</strong>sonare;<br />

4. <strong>il</strong> server non è in grado di trattare la richiesta e risponde con un messaggio<br />

di errore.<br />

Complessivamente l’ut<strong>il</strong>izzo del protocollo LDAP comporta i seguenti vantaggi:<br />

• possib<strong>il</strong>ità di ottimizzare la gestione delle informazioni all’interno di un’organizzazione;<br />

• semplicità d’implementazione e chiarezza delle API 10 ;<br />

• supporto nativo <strong>per</strong> la gestione di informazioni replicate;<br />

• possib<strong>il</strong>ità di limitare l’accesso ai dati mediante <strong>il</strong> meccanismo delle liste<br />

d’accesso (Access Control List);<br />

• possib<strong>il</strong>ità di essere integrato con altri servizi (ad esempio ssh, POP3,<br />

Samba, etc.) in modo da fornire loro un supporto alla gestione unificata<br />

ed universale;<br />

• supporto <strong>per</strong> la crittografia in modo da <strong>per</strong>mettere <strong>una</strong> consultazione<br />

sicura dei dati.<br />

2.2.1 ACL<br />

La gestione delle ACL entra in gioco qualora si intenda regolamentare l’accesso<br />

alle informazioni contenute in <strong>una</strong> directory LDAP. La nota implementazione<br />

open source OpenLDAP 11 <strong>per</strong>mette l’implementazione di ACL molto granulari.<br />

A tal riguardo è ut<strong>il</strong>e menzionare la configurazione dinamica, introdotta recentemente<br />

in OpenLDAP. Questa caratteristica <strong>per</strong>mette di configurare a runtime<br />

<strong>il</strong> server OpenLDAP tramite query LDAP. Questo risultato è stato ottenuto<br />

esponendo i parametri di configurazione come entry LDAP in un opportuno sotto<br />

albero del DIT dal nome cn=config. Nel caso delle ACL ciò significa poter<br />

generare nuove ACL, modificare quelle esistenti e rimuovere quelle non più valide<br />

mano a mano che evolvono i dati nella directory, mantenendo quindi sempre<br />

coerenti le liste di accesso con le informazioni a cui fanno riferimento.<br />

Le regole si applicano a tre categorie di entry: tutte le entry del sotto-albero<br />

gestito dal server; tutte le entry <strong>il</strong> cui DN normalizzato 12 soddisfa <strong>una</strong> data<br />

10 API è l’acronimo di Application Program(ming) Interface ed indica un insieme di procedure<br />

rese disponib<strong>il</strong>i al programmatore e solitamente raggruppate in modo da formare un set<br />

di strumenti specifici <strong>per</strong> lo svolgimento di un determinato compito.<br />

11 http://www.openldap.org.<br />

12 Si intende un DN che contiene solamente gli spazi strettamente necessari (nessuno spazio<br />

extra) nel quale le componenti sono separate da virgole.<br />

62


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

espressione regolare; tutte le entry nello scope del dato DN. Lo scope può essere:<br />

base (esclusivamente l’elemento indicato dal DN), one (tutti gli elementi al di<br />

sotto, di un solo livello, di quello indicato dal DN), subtree (tutto <strong>il</strong> sotto-albero<br />

radicato nell’elemento indicato dal DN) oppure ch<strong>il</strong>dren (tutti gli elementi al di<br />

sotto di quello indicato dal DN). Inoltre gli elementi possono essere identificati<br />

tramite <strong>una</strong> classica espressione di ricerca LDAP.<br />

La granularità non si ferma al livello degli entry, ma si spinge a quella dei singoli<br />

attributi. Senza entrare nel dettaglio è possib<strong>il</strong>e indicare attributi secondo<br />

modalità più o meno articolate sui quali applicare le ACL. Ad esempio, un ut<strong>il</strong>izzo<br />

tipico di questa funzionalità riguarda l’attributo password che normalmente<br />

viene lasciato a disposizione degli anonimi esclusivamente <strong>per</strong> l’autenticazione<br />

(non può essere letto), scrivib<strong>il</strong>e dal proprietario e nascosto a tutti gli altri.<br />

I livelli di accesso che possono essere forniti sono i seguenti:<br />

• none. Nessun livello di accesso: <strong>per</strong> l’utente l’elemento è inesistente;<br />

• disclose. Nessun livello di accesso, ma l’utente può stab<strong>il</strong>ire se l’elemento<br />

esiste;<br />

• auth. Il sistema può ut<strong>il</strong>izzare l’elemento <strong>per</strong> l’autenticazione (tipicamente<br />

viene applicato alla password che l’utente ut<strong>il</strong>izza <strong>per</strong> autenticarsi ad<br />

LDAP);<br />

• compare. L’elemento non può essere letto direttamente, ma può essere<br />

ut<strong>il</strong>izzato <strong>per</strong> comparazioni;<br />

• search. L’elemento viene indicato nell’insieme dei risultati di <strong>una</strong> ricerca<br />

che lo riguarda;<br />

• read. L’elemento può essere letto;<br />

• write. L’elemento può essere modificato/rinominato;<br />

• manage. L’elemento può essere amministrato.<br />

2.2.2 Directory federate<br />

Come introdotto nel paragrafo precedente è possib<strong>il</strong>e realizzare directory<br />

arbitrariamente complesse che si sv<strong>il</strong>uppano trasversalmente fra organizzazioni,<br />

eventualmente a livello globale.<br />

Questo importante traguardo è raggiungib<strong>il</strong>e implementando la directory<br />

andando a federare <strong>il</strong> numero opportuno di server LDAP in quanto è ovvio che<br />

nessun sistema centralizzato può ambire ad un risultato sim<strong>il</strong>e.<br />

La federazione avviene ut<strong>il</strong>izzando in modo opportuno i referral e le ACL:<br />

partendo da server LDAP autoritativi su un particolare sotto-albero del DIT<br />

è possib<strong>il</strong>e inserire gli opportuni riferimenti (referral su<strong>per</strong>iori e subordinati) ai<br />

63


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

server autoritativi che gestiscono i sotto-alberi al di sopra ed al di sotto della<br />

gerarchia (rispettivamente).<br />

Le ACL entrano in gioco, e vengono inizialmente introdotte anche se nel tempo<br />

possono essere aggiornate, al momento della federazione fra due o più server<br />

LDAP. I responsab<strong>il</strong>i dei singoli server hanno quindi la facoltà di decidere con<br />

quali modalità <strong>per</strong>mettere la federazione, in altre parole hanno <strong>il</strong> controllo completo<br />

dei dati in loro possesso in quanto, come descritto nel paragrafo 2.2.1, possono<br />

scegliere con estrema granularità quali informazioni condividere e secondo<br />

quali modalità.<br />

2.2.3 Replicazione<br />

La replicazione entra in gioco nel momento in cui si intende:<br />

• aumentare la disponib<strong>il</strong>ità delle informazioni contenute nel DIT;<br />

• far scalare <strong>il</strong> sistema al crescere del numero di accessi.<br />

LDAP prevede un protocollo nativo <strong>per</strong> la replicazione, detto LDAP Content<br />

Synchronization protocol, di recente introduzione con la RFC 4533 [ZC06].<br />

Tale meccanismo, noto come Sync Replication in OpenLDAP, <strong>of</strong>fre replicazione<br />

stateful con supporto sia alla sincronizzazione pull che push. Nel primo caso è<br />

<strong>il</strong> consumer (server che deve essere sincronizzato) che <strong>per</strong>iodicamente interroga<br />

<strong>il</strong> provider (server che mantiene i dati aggiornati) in ricerca di aggiornamenti,<br />

nel secondo caso è <strong>il</strong> provider che, in corrispondenza di modifiche, notifica al<br />

consumer gli aggiornamenti necessari.<br />

Data la natura lato consumer del meccanismo di replicazione, se <strong>il</strong> server<br />

è configurato <strong>per</strong> o<strong>per</strong>are da provider, è possib<strong>il</strong>e aggiungere nuove repliche a<br />

caldo senza impattare sul funzionamento del provider stesso.<br />

I consumer Syncrepl sono repliche in sola lettura. Nel caso in cui le scritture<br />

non possano essere evitate sono previsti due meccanismi <strong>per</strong> renderle possib<strong>il</strong>i.<br />

Il primo prevede la definizione di un opportuno update referral nel consumer da<br />

restituire al client in corrispondenza di richieste di aggiornamento. In questo<br />

modo <strong>il</strong> client può seguire <strong>il</strong> referral e ripetere la richiesta di aggiornamento<br />

al server master. Si noti che tale server non è necessariamente <strong>il</strong> provider del<br />

consumer che ha restituito l’update referral in quanto è possib<strong>il</strong>e creare catene<br />

di repliche del tipo: server S (read/write) provider del consumer C1, C1 (read<br />

only) provider del consumer C2, C2 (read only) provider del consumer C3 eccetera.<br />

Il secondo meccanismo prevede la configurazione del consumer in modalità<br />

chaining. In questo caso l’update referral non viene restituito al client, ma viene<br />

ut<strong>il</strong>izzato direttamente dal consumer <strong>per</strong> propagare l’aggiornamento al master<br />

in modo del tutto trasparente al client.<br />

In ogni caso l’implementazione presente in OpenLDAP è molto flessib<strong>il</strong>e<br />

e questo ha <strong>per</strong>messo l’introduzione di meccanismi di replicazione alternativi<br />

64


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

e/o più evoluti rispetto alla RFC, come <strong>il</strong> Delta-syncrepl replication. Questo<br />

meccanismo infatti, a differenza del Sync Replication da cui deriva, è in grado<br />

di trasferire solamente gli attributi effettivamente modificati senza la necessità<br />

di trasferire l’intero entry che li contiene.<br />

Un’ulteriore evoluzione è la replicazione N-Way Multi-Master che ut<strong>il</strong>izza<br />

Syncrepl <strong>per</strong> replicare dati fra provider “master” multipli. Questo approccio,<br />

senz’altro valido <strong>per</strong> evitare single-points-<strong>of</strong>-fa<strong>il</strong>ure e <strong>per</strong> migliorare la disponib<strong>il</strong>ità,<br />

può <strong>per</strong>ò mettere a repentaglio la consistenza dal DIT in caso di problemi<br />

di vario tipo.<br />

La replicazione MirrorMode è <strong>una</strong> <strong>soluzione</strong> ibrida che <strong>of</strong>fre la consistenza del<br />

singolo master con la disponib<strong>il</strong>ità del multi-master. In questa configurazione<br />

si crea un multi-master fra due provider, ma si ut<strong>il</strong>izza un frontend esterno<br />

<strong>per</strong> distribuire le letture fra entrambi i server ed indirizzare le scritture ad uno<br />

solo di essi. In caso di problemi ad uno dei server, <strong>il</strong> frontend ut<strong>il</strong>izza l’altro<br />

<strong>per</strong> tutte le o<strong>per</strong>azioni fino a quando <strong>il</strong> provider guasto non viene ripristinato e<br />

ri-sincronizzato (o<strong>per</strong>azione che avviene automaticamente grazie a Syncrepl).<br />

2.2.4 Sorgenti dati legacy<br />

OpenLDAP ut<strong>il</strong>izza i cosiddetti backend <strong>per</strong> l’accesso fisico ai dati. Sono<br />

suddivisi in tre categorie, sulla base delle modalità con cui trattano i dati che<br />

<strong>of</strong>frono al sistema:<br />

• backend <strong>per</strong> lo storage fisico. Questi backend, fra cui back-bdb, back-hdb<br />

e back-ldif, servono <strong>per</strong> lo storage fisico dei dati in modo ottimizzato e/o<br />

nativo. I primi due infatti, basati sul noto Berkeley DB, sono i backend<br />

predefiniti <strong>per</strong> lo storage ut<strong>il</strong>izzati in modo nativo da OpenLDAP, mentre<br />

<strong>il</strong> terzo <strong>per</strong>mette lo storage in modalità testuale nel formato nativo di<br />

interscambio dati, ldif;<br />

• backend di tipo Proxy. Questi backend, tra i quali back-ldap, back-passwd<br />

e back-sql, sono stati introdotti <strong>per</strong> l’interfacciamento del sistema verso<br />

altre sorgenti dati. In questo caso infatti non si va a memorizzare i dati<br />

localmente ed internamente ad OpenLDAP, ma si va a trattare dati gestiti<br />

da altri sistemi. Ad esempio, back-ldap è da considerarsi un proxy puro,<br />

nel senso che ut<strong>il</strong>izza come sorgente dati un altro server LDAP; backpasswd<br />

<strong>per</strong>mette di accedere al database delle password degli utenti Unix<br />

ad esempio <strong>per</strong> riesporlo tramite <strong>il</strong> protocollo LDAP e <strong>per</strong>metterne la<br />

fruizione, in modo standardizzato, ad applicazioni remote, mentre back-sql<br />

è stato introdotto <strong>per</strong> riesporre in formato LDAP dati legacy memorizzati<br />

in server SQL;<br />

• backend dinamici. Queste sorgenti dati, ad esempio back-config, back-<strong>per</strong>l,<br />

back-shell e back-sock, <strong>per</strong>mettono la generazione di dati on-the-fly. Ad<br />

65


Stato dell’arte: federazione su larga scala Lightweight Directory Access Protocol<br />

eccezione di back-config che è <strong>il</strong> backend <strong>per</strong> la configurazione dinamica del<br />

sistema (descritto brevemente nel paragrafo 2.2.1), gli altri sono interfacce<br />

arbitrarie verso linguaggi di programmazione, che <strong>per</strong>mettono quindi lo<br />

sv<strong>il</strong>uppo di strati s<strong>of</strong>tware atti a svolgere qualunque tipo di o<strong>per</strong>azione a<br />

partire da interrogazioni LDAP.<br />

66


Capitolo<br />

3<br />

Principi e tecnologie <strong>per</strong> la<br />

sicurezza<br />

Gli accessi <strong>il</strong>legittimi ai dati memorizzati sui sistemi di elaborazione, la compromissione<br />

o <strong>il</strong> furto di questi, l’intercettazione di comunicazioni con contenuti<br />

riservati, rappresentano <strong>una</strong> grave minaccia, sempre più diffic<strong>il</strong>e da contrastare.<br />

La costante a<strong>per</strong>tura di nuove reti verso Internet, unita alla rapida crescita di<br />

connessioni di tipo <strong>per</strong>manente, anche tra utenze private, ha creato un fert<strong>il</strong>e<br />

terreno <strong>per</strong> questo genere di minacce. A causa della continua partecipazione in<br />

rete di nuovi sistemi e servizi, sono cresciuti esponenzialmente i possib<strong>il</strong>i bersagli<br />

da attaccare.<br />

I rischi legati alla comunicazione di informazioni su <strong>Web</strong> coinvolgono interessi<br />

sociali, politici ed economici. All’aumentare degli interessi e del numero<br />

di partecipanti cresce anche <strong>il</strong> numero di malintenzionati che intendono trarre<br />

fac<strong>il</strong>mente dei benefici in modo fraudolento o non eticamente corretto.<br />

All’aumentare del rischio c’è quindi <strong>una</strong> sensib<strong>il</strong>izzazione verso <strong>il</strong> concetto<br />

di “sicurezza” in quanto è nell’indole umana attuare delle azioni a seguito di<br />

<strong>una</strong> valutazione (in modo più o meno consapevole) del rapporto benefici/rischi<br />

sui servizi usati. All’aumentare del rischio <strong>il</strong> rapporto scende e questo potrebbe<br />

rallentarne notevolmente la diffusione o <strong>il</strong> successo.<br />

D’altronde i benefici apportati dal <strong>Web</strong> sono indiscutib<strong>il</strong>i anche se è stato<br />

necessario, al fine di trasformare opportunità potenziali in vantaggi concreti,<br />

applicare strategie e tecnologie convenienti <strong>per</strong> rendere la sicurezza delle reti di


Principi e tecnologie <strong>per</strong> la sicurezza Autenticazione<br />

computer “accettab<strong>il</strong>e” 1 .<br />

Alla luce di questo si rende necessario implementare efficaci politiche di sicurezza<br />

capaci di contrastare dinamicamente questi <strong>per</strong>icoli, che minano sia<br />

la sicurezza del singolo utente privato, sia quella delle grandi reti informatiche<br />

aziendali. Poiché questo problema è contraddistinto da un’elevata dinamicità, in<br />

cui è protagonista <strong>una</strong> continua evoluzione secondo tempistiche e modalità assolutamente<br />

imprevedib<strong>il</strong>i, essere esaustivi diventa estremamente difficoltoso e di<br />

conseguenza si cercherà di contrastare questa limitazione mediante l’esposizione<br />

dei concetti chiave alla base di ogni tecnica.<br />

È inoltre opportuno sottolineare come la sicurezza sia un problema da affrontare<br />

in modo trasversale su tutti i livelli che compongono <strong>una</strong> rete di comunicazione<br />

e non solo a livello applicativo.<br />

Le tecnologie in uso nelle reti di computer da prima dell’avvento di Internet<br />

fino ad oggi vengono classificate come <strong>per</strong> l’autenticazione, <strong>per</strong> l’autorizzazione<br />

oppure <strong>per</strong> l’accounting (termini che figurano <strong>per</strong> la prima volta in <strong>una</strong> pubblicazione<br />

scientifica dell’IEEE del 1983 [LNS83]). Ovviamente l’evoluzione dell’ICT<br />

è stata tale <strong>per</strong> cui le singole tecnologie hanno subito trasformazioni nel tempo<br />

<strong>per</strong> adattarsi ai nuovi scenari.<br />

Infatti l’autenticazione <strong>per</strong>mette di dare risposta alla domanda “chi o cosa<br />

sei?”; dopo aver stab<strong>il</strong>ito chi (o cosa) è <strong>il</strong> soggetto di interesse, l’autorizzazione<br />

<strong>per</strong>mette di <strong>of</strong>frire <strong>una</strong> risposta alla domanda “cosa gli è <strong>per</strong>messo fare?”; infine,<br />

l’“accounting”, <strong>of</strong>frendo risposta alla domanda “chi ha fatto (o ha tentato<br />

di fare) cosa?”, <strong>per</strong>mette di tracciare le azioni degli utenti [Con07a, Con07b].<br />

Da un punto di vista prettamente funzionale quest’ultimo punto potrebbe sembrare<br />

di minor importanza rispetto agli altri due, ma in molti scenari garantire<br />

trasparenza e tracciab<strong>il</strong>ità è un requisito imposto a livello organizzativo (spesso<br />

dalla legge) e <strong>per</strong>tanto l’accounting <strong>per</strong>mette di soddisfare tale necessità.<br />

3.1 Autenticazione<br />

Lo scopo di un sistema di autenticazione è quello di <strong>per</strong>mettere l’identificazione<br />

certa di un determinato soggetto, un umano oppure un dispositivo hardware<br />

e/o un agente s<strong>of</strong>tware. In ogni caso durante la fase di autenticazione molti<br />

elementi entrano in gioco, ma sostanzialmente possono essere raggruppati in tre<br />

categorie:<br />

• <strong>il</strong> principal stesso, ovvero l’utente, <strong>il</strong> dispositivo, l’agente s<strong>of</strong>tware che deve<br />

essere identificato;<br />

1 È doveroso sottolineare che “accettab<strong>il</strong>e” non significa “migliore possib<strong>il</strong>e”. Questo <strong>per</strong>ché<br />

soluzioni troppo spinte tendono a risultare molto costose ed a limitare eccessivamente l’utente<br />

nelle azioni che può compiere.<br />

68


Principi e tecnologie <strong>per</strong> la sicurezza Autenticazione<br />

• le credenziali che esso invia <strong>per</strong> identificarsi, ovvero <strong>una</strong> password o chiave<br />

condivisa, <strong>una</strong> one-time password, un certificato digitale, delle caratteristiche<br />

biometriche;<br />

• le informazioni di contesto, ovvero la locazione, la data e l’ora del giorno,<br />

lo stato del s<strong>of</strong>tware, eccetera.<br />

Il principal. Il principal è l’entità che richiede di essere autorizzata ad eseguire<br />

alcune o<strong>per</strong>azioni. Generalmente è <strong>una</strong> combinazione fra utente, dispositivi<br />

e/o agenti s<strong>of</strong>tware. Per quanto riguarda l’utente esso può essere contraddistinto,<br />

oltre che da un nome, da gruppi e/o ruoli, dagli indirizzi e-ma<strong>il</strong> e fisico e<br />

quant’altro. In alcune applicazioni critiche possono essere incluse informazioni<br />

più dettagliate. Per esempio, in <strong>una</strong> rete scolastica potrebbe essere aggiunto<br />

l’orario dei corsi della classe frequentata dallo studente.<br />

Nel caso in cui l’entità sia un dispositivo o un agente s<strong>of</strong>tware la situazione,<br />

pur cambiando <strong>il</strong> tipo di informazioni inviate, è equivalente.<br />

Inoltre esiste spesso la situazione in cui, <strong>per</strong> <strong>una</strong> data transazione, è necessario<br />

realizzare un livello di autenticazione multiplo: prima <strong>il</strong> dispositivo che<br />

l’utente sta ut<strong>il</strong>izzando e successivamente l’utente stesso.<br />

Le credenziali. Esistono quattro tipoligie principali di credenziali:<br />

• le chiavi condivise o password;<br />

• le password one-time;<br />

• i certificati digitali;<br />

• le caratteristiche biometriche.<br />

Il primo elemento della lista, la chiave condivisa o password, è sicuramente<br />

quello più ut<strong>il</strong>izzato data la sua semplicità ed immediatezza. Il rovescio della<br />

medaglia è che, <strong>per</strong> vari motivi, è tendenzialmente meno sicuro degli altri metodi.<br />

Ad esempio sono critiche lo modalità di condivisione della chiave che, se non<br />

svolte con la dovuta riservatezza, possono mettere a repentaglio la sicurezza del<br />

sistema. Se la chiave è <strong>una</strong> password scelta da un utente umano può risultare<br />

debole ed essere quindi violata con estrema semplicità, solo <strong>per</strong> citare alcune<br />

criticità del meccanismo.<br />

Alcuni protocolli noti <strong>per</strong> l’autenticazione con chiave condivisa sono <strong>il</strong> Password<br />

Authentication Protocol (PAP) ed <strong>il</strong> Challenge Handshake Authentication<br />

Protocol (CHAP) [Sim96].<br />

Mentre <strong>il</strong> PAP invia sul canale la chiave in chiaro e questo lo rende debole<br />

ad attacchi che prevedono sniffing 2 del traffico, <strong>il</strong> CHAP basa <strong>il</strong> meccanismo di<br />

2 Si definisce sniffing l’attività di intercettazione passiva dei dati in transito in <strong>una</strong> rete<br />

telematica.<br />

69


Principi e tecnologie <strong>per</strong> la sicurezza Autenticazione<br />

autenticazione su un meccanismo di handshake attraverso <strong>il</strong> quale è possib<strong>il</strong>e<br />

evitare di inviare la password in chiaro. Il meccanismo di handshake funziona<br />

nel modo seguente:<br />

• dopo aver stab<strong>il</strong>ito la connessione, <strong>il</strong> client invia <strong>il</strong> proprio identificativo<br />

al server, <strong>il</strong> quale risponde con <strong>una</strong> domanda di “sfida” (<strong>il</strong> challenge),<br />

tipicamente un numero casuale;<br />

• <strong>il</strong> client riceve <strong>il</strong> numero, lo compone (secondo <strong>una</strong> modalità nota sia al<br />

client che al server) con la chiave condivisa, calcola l’hash (MD5, SHA1,<br />

etc.) ed invia <strong>il</strong> risultato al server;<br />

• <strong>il</strong> server esegue le medesime o<strong>per</strong>azioni e se <strong>il</strong> risultato è lo stesso rispetto<br />

a quello ricevuto dal client ciò significa che <strong>il</strong> client conosce la chiave<br />

condivisa.<br />

Ad oggi comunque <strong>il</strong> PAP risulta molto ut<strong>il</strong>izzato alla luce del fatto che<br />

spesso si ricorre a canali sicuri <strong>per</strong> garantire la riservatezza della comunicazione<br />

e <strong>per</strong>tanto la password, se pur inviata in chiaro sul canale, risulterà protetta dal<br />

canale stesso.<br />

Un secondo e largamente ut<strong>il</strong>izzato tipo di credenziali sono le OTP (one-time<br />

password). Al momento del login gli utenti fanno riferimento al proprio <strong>per</strong>sonale<br />

token <strong>per</strong> ottenere l’opport<strong>una</strong> OTP da ut<strong>il</strong>izzare <strong>per</strong> l’accesso. Il token<br />

è generalmente realizzato come dispositivo hardware o in forma di s<strong>of</strong>tware. Il<br />

token, sincronizzato con l’opportuno token-server, è progettato <strong>per</strong> fornire <strong>una</strong><br />

one-time password apparentemente causale. Tale password può essere inviata<br />

in chiaro in quanto è ut<strong>il</strong>izzab<strong>il</strong>e solamente <strong>una</strong> volta e in ogni caso, dopo un<br />

tempo variab<strong>il</strong>e che può essere dell’ordine dei 30 secondi, <strong>una</strong> nuova password<br />

viene generata <strong>per</strong> l’accesso al sistema. Quando <strong>una</strong> OTP è associata ad un<br />

Personal Identification Number (PIN) si ha un sistema di autenticazione a due<br />

vie poiché oltre ad un qualcosa che si possiede (<strong>il</strong> token) è necessario fornire<br />

anche qualcosa che si conosce (<strong>il</strong> PIN). A tal riguardo, <strong>una</strong> variante del sistema<br />

OTP prevede l’uso di password card, ovvero di carte con un elenco stampato e<br />

numerato di one-time password. In questo scenario tipicamente l’utente effettua<br />

<strong>una</strong> pre-identificazione con PIN e <strong>per</strong> l’esecuzione di o<strong>per</strong>azioni critiche <strong>il</strong> sistema<br />

richiede <strong>una</strong> determinata password fra quelle a disposizione nella password<br />

card.<br />

Un terzo tipo di credenziali è rappresentato dai certificati digitali. I certificati<br />

digitali possono essere memorizzati internamente al client oppure su opportuni<br />

supporti removib<strong>il</strong>i come le smartcard. Una trattazione più dettagliata relativa a<br />

questo tipo di credenziale verrà riportata nel paragrafo 3.4.1. In ogni caso si basa<br />

su crittografia a chiave asimmetrica in cui entra in gioco <strong>una</strong> terza parte fidata<br />

che garantisce l’identità dei soggetti in gioco. Anche <strong>per</strong> i certificati digitali vale<br />

quanto detto <strong>per</strong> le OTP: bloccando <strong>il</strong> certificato dell’utente con un opportuno<br />

70


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

PIN si ab<strong>il</strong>ita <strong>una</strong> autenticazione a due vie. Infatti non è sufficiente possedere<br />

<strong>il</strong> certificato dell’utente <strong>per</strong> identificarsi, ma bisogna essere a conoscenza anche<br />

del PIN.<br />

Infine, l’ultimo tipo di credenziale e attualmente <strong>il</strong> meno diffuso prevede l’uso<br />

di caratteristiche biometriche dell’utente. In questo caso non si è di fronte né a<br />

qualcosa che l’utente possiede, né a qualcosa che l’utente conosce bensì a qualche<br />

caratteristica fisica dell’utente stesso. Per esempio è possib<strong>il</strong>e ut<strong>il</strong>izzare come<br />

caratteristiche biometriche <strong>il</strong> risultato di <strong>una</strong> opport<strong>una</strong> scansione delle impronte<br />

digitali, dell’iride, sistemi di riconoscimento facciale e quant’altro. Anche in<br />

questo caso è possib<strong>il</strong>e combinare questo tipo di credenziale con uno o più dei<br />

precedenti <strong>per</strong> dar vita a sistemi di autenticazione a due o più fattori.<br />

I dati di contesto. L’ultimo elemento che normalmente viene considerato<br />

<strong>per</strong> l’autenticazione (ed eventualmente l’autorizzazione) è l’insieme dei dati di<br />

contesto, come l’indirizzo di rete da cui proviene la richiesta, data ed ora del<br />

giorno, carico dei sistemi, eccetera. A questo elenco è stato recentemente aggiunto<br />

lo stato del s<strong>of</strong>tware del client: ad esempio, si potrebbe pensare di escludere<br />

dall’accesso quei client che hanno <strong>il</strong> sistema o<strong>per</strong>ativo out-<strong>of</strong>-date ovvero non<br />

opport<strong>una</strong>mente aggiornato con le ultime patch di sicurezza. IETF ed <strong>il</strong> Trusted<br />

Computing Group (TCG) hanno emesso vari standard proprio <strong>per</strong> normare<br />

questo tipo di scenario ([Zap06]).<br />

3.2 Autorizzazione<br />

Risolto <strong>il</strong> problema di determinare chi (autenticazione) sta richiedendo <strong>una</strong><br />

certa azione, occorre capire se tale soggetto è autorizzato a richiederla o meno<br />

(autorizzazione). Per quanto riguarda l’autenticazione nel paragrafo 3.1 sono<br />

stati introdotti vari protocolli e metodologie che <strong>per</strong>mettono, al variare di un<br />

certo trade-<strong>of</strong>f fra semplicità e sicurezza, di affrontare <strong>il</strong> problema. In questo<br />

paragrafo quindi, parlando di autenticazione, verrà dato <strong>per</strong> scontato che <strong>il</strong> problema<br />

sia già stato risolto ut<strong>il</strong>izzando uno o più dei protocolli e delle metodologie<br />

citate nel paragrafo 3.1.<br />

Generalmente <strong>il</strong> controllo degli accessi viene attuato ogni volta che <strong>una</strong> risorsa<br />

informatica necessita di essere protetta. Controllarne l’accesso consente di<br />

escludere accessi fraudolenti o scorretti, di preservare l’integrità e la riservatezza<br />

e di lasciare inalterata la disponib<strong>il</strong>ità della risorsa <strong>per</strong> chi è autorizzato. Formalmente<br />

l’accesso è la capacità di agire su <strong>una</strong> certa risorsa mentre <strong>il</strong> controllo<br />

d’accesso è la modalità con la quale viene regolata la capacità di agire su <strong>una</strong><br />

risorsa. In particolare tale modalità definisce i meccanismi che consentono di<br />

concedere e revocare diversi tipi di <strong>per</strong>messi e di vietare o consentire l’accesso<br />

alla risorsa in base ai <strong>per</strong>messi assegnati. Pertanto <strong>il</strong> controllo degli accessi può<br />

71


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

essere definito come un processo con <strong>il</strong> quale viene esplicitamente consentito o<br />

negato l’accesso ad <strong>una</strong> specifica risorsa. Lo studio sul controllo degli accessi<br />

è piuttosto recente e ha avuto inizio negli anni ’70. Infatti in quegli anni iniziavano<br />

ad essere impiegati i primi sistemi di condivisione dei dati in ambito<br />

commerciale, governativo e m<strong>il</strong>itare, dove era necessario garantire la sicurezza<br />

delle informazioni condivise.<br />

Un modello di controllo degli accessi deve consentire <strong>una</strong> fac<strong>il</strong>e gestione dei<br />

<strong>per</strong>messi <strong>per</strong> l’accesso alle risorse informatiche da parte dell’amministratore del<br />

sistema, facendo riferimento all’organizzazione aziendale interna. Tuttavia un<br />

modello deve tenere conto di alcuni principi bas<strong>il</strong>ari che sono i seguenti:<br />

• least priv<strong>il</strong>ege, ossia ad ogni soggetto devono essere assegnati solo i <strong>per</strong>messi<br />

strettamente necessari <strong>per</strong> l’esecuzione dei suoi compiti all’interno<br />

dell’organizzazione. Quindi tale principio del “minimo priv<strong>il</strong>egio” ha <strong>per</strong><br />

obiettivo quello di non <strong>per</strong>mettere che un soggetto abbia l’autorizzazione<br />

di svolgere azioni dannose <strong>per</strong> <strong>il</strong> sistema o non necessarie rispetto ai<br />

compiti assegnati. Anche se i soggetti possono avere differenti livelli di<br />

priv<strong>il</strong>egio in instanti diversi, risulta fondamentale stab<strong>il</strong>ire che i <strong>per</strong>messi,<br />

<strong>una</strong> volta concessi, non <strong>per</strong>sistano oltre <strong>il</strong> tempo <strong>per</strong> cui sono necessari;<br />

• separation <strong>of</strong> duty, ossia ad uno stesso individuo non devono essere concessi<br />

tutti i premessi necessari <strong>per</strong> eseguire specifici compiti, che potrebbero<br />

danneggiare <strong>il</strong> sistema. Tale principio di“separazione dei compiti”consente<br />

di evitare che un individuo sia in grado di recare danni all’organizzazione<br />

<strong>per</strong> interessi <strong>per</strong>sonali e può essere attuato in modo statico o dinamico.<br />

Nel caso statico vengono assegnati a priori ad ogni individuo un insieme di<br />

<strong>per</strong>messi, mentre nel caso dinamico l’assegnazione viene eseguita durante<br />

tutto l’arco di funzionamento del sistema;<br />

• data abstraction, ossia i principi di sicurezza devono essere definiti in termini<br />

di possib<strong>il</strong>ità di manipolazione di entità afferenti al dominio applicativo.<br />

3.2.1 Architettura di riferimento <strong>per</strong> l’autorizzazione<br />

In questo paragrafo viene proposta un’architettura <strong>per</strong> l’autorizzazione nella<br />

quale si vanno ad individuare i vari attori in gioco e gli elementi infrastrutturali<br />

adibiti ad applicare le regole <strong>per</strong> l’autorizzazione. Gli elementi chiave che si<br />

trovano nell’architettura in discussione sono i seguenti:<br />

• l’utente. È <strong>il</strong> soggetto (umano e meno) che intende svolgere l’azione;<br />

• <strong>il</strong> client. È lo strumento ut<strong>il</strong>izzato dall’utente <strong>per</strong> richiedere <strong>il</strong> servizio. Il<br />

client potrebbe essere esso stesso l’utente dell’interazione: ad esempio si<br />

pensi ad un PC portat<strong>il</strong>e che tenta di accedere ad <strong>una</strong> rete wireless;<br />

72


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

• <strong>il</strong> Policy Enforcement Point (PEP). Una volta stab<strong>il</strong>ito se la richiesta debba<br />

essere soddisfatta o meno, <strong>il</strong> PEP è responsab<strong>il</strong>e di applicarla. Esempi<br />

di PEP sono i VPN concentrator, i firewall, gli switch Ethernet, gli accesspoint<br />

wireless fino a, salendo nella p<strong>il</strong>a OSI, i proxy e le applicazioni come<br />

web server e quant’altro;<br />

• <strong>il</strong> Policy Information Point (PIP). È un repository contenente informazioni<br />

di vario tipo necessarie o di aus<strong>il</strong>io <strong>per</strong> decidere se <strong>of</strong>frire o negare<br />

l’accesso. Può essere un database di device ID, <strong>una</strong> directory LDAP, un<br />

one-time password token server o qualsiasi altro sistema in grado di <strong>of</strong>frire<br />

dati r<strong>il</strong>evanti legati alla richiesta d’accesso;<br />

• <strong>il</strong> Policy Decision Point (PDP). È <strong>il</strong> motore del sistema di accesso. Riceve<br />

i dati legati alla richiesta d’accesso dal PEP, interroga gli opportuni PIP<br />

<strong>per</strong> collezionare tutte le informazioni necessarie e decide quindi se la richiesta<br />

d’accesso debba essere soddisfatta o meno. In alcuni casi, sulla base<br />

dell’applicazione e dei protocolli in gioco, può non limitarsi a prendere<br />

<strong>una</strong> decisione binaria del tipo access o deny, ma può fornire al PEP risposte<br />

più o meno articolate che contengono le informazioni necessarie <strong>per</strong><br />

<strong>per</strong>mettere accessi condizionati. Ad esempio si pensi ad un VPN concentrator<br />

che riceve <strong>una</strong> richiesta di associazione alla VPN da un dato client:<br />

<strong>il</strong> PDP potrebbe <strong>per</strong>mettere al concentrator di far associare <strong>il</strong> client alla<br />

VPN, ma sotto la condizione che non tutto <strong>il</strong> traffico generato dal client<br />

sia ammesso (ab<strong>il</strong>itando, ad esempio, <strong>il</strong> client ad eccedere solo ad un sotto<br />

insieme di host raggiungib<strong>il</strong>i dal concentrator);<br />

• <strong>il</strong> sistemi di Accounting e Reporting. Questi elementi, che possono essere<br />

dedicati o parte integrante del PDP, <strong>per</strong>mettono di tracciare le azioni<br />

svolte sotto la su<strong>per</strong>visione dei sistemi <strong>per</strong> l’AAA. In altre parole salvano<br />

sotto forma di log chi ha fatto cosa, quando e da dove. Ovviamente, in<br />

base al contesto, possono essere memorizzate anche ulteriori informazioni,<br />

ma quelle citate <strong>of</strong>frono già un livello di monitoraggio e controllo in linea<br />

di massima adeguato.<br />

È ut<strong>il</strong>e osservare che gli elementi citati sono più da considerarsi come entità<br />

logiche che come sistemi fisicamente distinti. Anzi, nelle implementazioni più<br />

comuni si trovano sistemi fisici che implementano PEP/PDP, PDP/PIP ed anche<br />

PEP/PDP/PIP.<br />

A titolo esemplificativo si consideri adesso lo scenario rappresentato in figura<br />

3.1.<br />

In questo esempio si intende mostrare come si sv<strong>il</strong>uppa l’interazione fra i vari<br />

elementi nell’ipotetico scenario di un client che intende accedere dall’esterno alla<br />

rete aziendale, protetta con sistemi di AAA, tramite VPN.<br />

73


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

PEP<br />

8<br />

3<br />

Client PEP<br />

PDP<br />

4<br />

PIP<br />

1<br />

PEP<br />

9<br />

6<br />

Rete di<br />

produzione<br />

2<br />

Acct.<br />

Figura 3.1: Esempio di un client che si connette ad <strong>una</strong> rete protetta da un<br />

sistema di AAA.<br />

1. l’utente, essendo all’esterno del <strong>per</strong>imetro della rete aziendale, intende<br />

ut<strong>il</strong>izzare la connessione VPN <strong>per</strong> accedere ai servizi interni dell’azienda.<br />

Il client dell’utente provvederà quindi ad instaurare <strong>una</strong> connessione<br />

con <strong>il</strong> VPN concentrator inviando al PEP (<strong>il</strong> concentrator stesso) tutte le<br />

informazioni necessarie <strong>per</strong> l’autenticazione;<br />

2. <strong>il</strong> PEP colleziona tutte le informazioni necessarie e le invia al PDP. In alcuni<br />

casi <strong>il</strong> PEP si limita ad inoltrare le informazioni ricevute direttamente<br />

al PDP senza ness<strong>una</strong> elaborazione;<br />

3. <strong>il</strong> PDP interroga tutti i PIP opportuni, nello specifico si può ipotizzare che<br />

<strong>il</strong> PIP sia un unico server LDAP e che le informazioni <strong>per</strong> l’autenticazione<br />

siano <strong>il</strong> CN (lo username) e la password (un LDAP SimpleSecurityObject);<br />

4. <strong>il</strong> PIP restituisce access o deny sulla base del fatto che la coppia CNpassword<br />

sia corretta o no ed eventuali ulteriori informazioni relative al<br />

client e/o all’utente ut<strong>il</strong>i al PDP <strong>per</strong> prendere la decisione. Queste informazioni<br />

aggiuntive possono includere i ruoli/gruppi dell’utente, la data<br />

dell’ultimo accesso, la data di scadenza dell’account e quant’altro;<br />

5. <strong>il</strong> PDP elabora tutte le informazioni in gioco: quelle ricevute dal PEP, dai<br />

PIP, i ruoli ed <strong>il</strong> livello di fiducia sui PEP e sui PIP, la data corrente e<br />

quant’altro e prende la decisione;<br />

6. <strong>il</strong> PDP invia al PEP <strong>il</strong> risultato della decisione ed eventuali vincoli da<br />

applicare nel caso in cui sia di tipo access. Ad esempio potrebbe imporre<br />

che a quel client debba essere assegnato un certo indirizzo IP o limitare,<br />

7<br />

5<br />

PIP<br />

PIP<br />

74


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

più o meno direttamente, le possib<strong>il</strong>ità di accesso agli elementi interni della<br />

rete;<br />

7. <strong>il</strong> PDP invia inoltre l’esito della transazione al sistema di accounting;<br />

8. <strong>il</strong> PEP applica le politiche imposte dal PDP e, in caso affermativo, invia<br />

un messaggio del tipo “authentication successful” al client. Anche <strong>il</strong> PEP<br />

potrebbe essere configurato <strong>per</strong> inviare informazioni relative all’avvenuta<br />

connessione del client al sistema di accounting;<br />

9. <strong>il</strong> client (l’utente) può accedere quindi alla rete aziendale tramite <strong>il</strong> PEP.<br />

3.2.2 Approcci <strong>per</strong> la gestione delle autorizzazioni<br />

Dopo l’autenticazione che <strong>per</strong>mette di stab<strong>il</strong>ire chi è che sta richiedendo <strong>una</strong><br />

determinata azione, l’autorizzazione entra in gioco <strong>per</strong> stab<strong>il</strong>ire con esattezza se<br />

<strong>il</strong> soggetto riconosciuto può o meno eseguirla. In ogni caso la granularità con<br />

cui è possib<strong>il</strong>e andare a gestire le autorizzazioni dipende molto dalla potenza del<br />

PDP.<br />

In questo paragrafo verranno <strong>il</strong>lustrati gli approcci tipici <strong>per</strong> l’autorizzazione<br />

in ambito di rete: dalla segmentazione layer 2, al f<strong>il</strong>traggio a livello applicativo.<br />

Ness<strong>una</strong> autorizzazione (solo autenticazione). Anche se può sembrare<br />

strano <strong>il</strong> meccanismo più ut<strong>il</strong>izzato <strong>per</strong> la gestione delle autorizzazioni è proprio<br />

quello che non prevede l’uso di autorizzazioni. Dopo la fase di autenticazione, nel<br />

caso in cui essa termini positivamente (utente e/o client riconosciuti come validi),<br />

<strong>il</strong> sistema fornisce accesso indiscriminato a tutti i servizi. Questo deriva dal fatto<br />

che se l’utente o <strong>il</strong> client vengono riconosciuti dal sistema di autenticazione<br />

allora, in molti scenari, possono essere considerati “trusted” e <strong>per</strong>tanto risulta<br />

accettab<strong>il</strong>e fornirgli accesso indiscriminato. Si pensi, ad esempio, al caso di<br />

un accesso da remoto via VPN di un dipendente di <strong>una</strong> azienda. Se quanto <strong>il</strong><br />

dipendente si trova ad o<strong>per</strong>are dall’interno del <strong>per</strong>imetro della rete aziendale ha<br />

accesso a tutti i sistemi, potrebbe essere accettab<strong>il</strong>e fornirgli gli stessi <strong>per</strong>messi<br />

di accesso qualora esso si trovi ad o<strong>per</strong>are tramite la VPN. Il vantaggio di questa<br />

<strong>soluzione</strong>, se applicab<strong>il</strong>e, è ovviamente l’estrema semplicità implementativa.<br />

Segmentazione a livello 2. Al livello delle reti wireless e non, uno dei metodi<br />

più comuni <strong>per</strong> gestire le autorizzazioni consiste nell’andare a suddividere<br />

la rete fisica in un numero di reti logiche completamente separate, isolando determinate<br />

classi di client le une dalla altre. L’implementazione tipica di questo<br />

approccio prevede la definizione di Virtual LANs (VLANs) attraverso le quali<br />

è possib<strong>il</strong>e fare in modo che i client, a livello 2, possano comunicare esclusivamente<br />

con altri client nella stessa VLAN. A livello di rete, un meccanismo<br />

75


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

comune <strong>per</strong> l’implementazione delle autorizzazioni prevede proprio l’ut<strong>il</strong>izzo di<br />

VLANs insieme ad opportune regole di f<strong>il</strong>traggio a livello 3 <strong>per</strong> poter stab<strong>il</strong>ire<br />

con precisione chi può contattare chi.<br />

F<strong>il</strong>traggio a livello 3. Questo tipo di autorizzazione prevede l’implementazione<br />

di ACL su dispositivi di livello 3 OSI anche se oramai riguardano necessariamente<br />

anche <strong>il</strong> livello 4. Infatti le regole sono normalmente definite sulla<br />

base dell’indirizzo IP (livello 3) e della porta (livello 4) del mittente e del destinatario.<br />

Come introdotto precedentemente questa tecnica è la più ut<strong>il</strong>izzata,<br />

insieme alle VLANs, <strong>per</strong> definire le opportune politiche di accesso fra i client e<br />

server aziendali. Infatti host nella stessa rete sono mutuamente (e direttamente)<br />

visib<strong>il</strong>i l’uno con l’altro. Per questo motivo entrano in gioco le VLANs <strong>per</strong><br />

separare logicamente le reti (ed impedire quindi che i sistemi possano interagire<br />

direttamente) obbligando quindi <strong>il</strong> traffico ad attraversare dei router/firewall<br />

che, oltre all’instradamento, applicano le opportune politiche di f<strong>il</strong>traggio.<br />

Gateway di livello applicativo. Questa tipologia di dispositivi, senz’altro<br />

più complessa dei precedenti, va oltre <strong>il</strong> livello rete andando ad analizzare direttamente<br />

i protocolli di livello applicativo. Questo <strong>per</strong>mette di realizzare soluzioni<br />

estremamente granulari in quanto entrano nel merito del funzionamento<br />

dell’applicazione e non si limitano a trattare esclusivamente aspetti di rete.<br />

Problemi noti<br />

Data l’eterogeneità dei PEP (e dei PDP) che si possono incontrare in uno scenario<br />

reale, uno dei problemi principali che si incontrano nei sistemi <strong>per</strong> l’AAA<br />

è comunicare al PEP, in un formato a lui comprensib<strong>il</strong>e, la decisione presa dal<br />

PDP. Per questo motivo è frequente trovare dei PEP che abbiano un PDP integrato<br />

dedicato. Ovviamente <strong>il</strong> rovescio della medaglia di questa <strong>soluzione</strong> è che,<br />

in questo modo, qualora ci si trovi ad o<strong>per</strong>are in un ambiente articolato (come<br />

<strong>una</strong> realtà aziendale medio/grande) la gestione delle policy si complica notevolmente.<br />

I motivi sono sostanzialmente due: <strong>il</strong> primo riguarda <strong>il</strong> fatto che questo<br />

approccio impedisce la centralizzazione delle policy le quali si frammentano su<br />

un numero anche alto di dispositivi; <strong>il</strong> secondo è che spesso dispositivi diversi<br />

hanno modalità è funzionalità diverse complicando ulteriormente la definizione<br />

di policy consolidate a livello globale.<br />

La <strong>soluzione</strong> più naturale <strong>per</strong> la comunicazione fra PDP e PEP risulta essere<br />

ad oggi Radius poichè attualmente è <strong>il</strong> protocollo <strong>per</strong> l’AAA più ut<strong>il</strong>izzato.<br />

Ut<strong>il</strong>izzando Radius, oltre al campo “f<strong>il</strong>ter-id” che <strong>per</strong>mette al PDP di ab<strong>il</strong>itare<br />

l’accesso del client, è possib<strong>il</strong>e, attivando <strong>per</strong> <strong>il</strong> suddetto campo dei f<strong>il</strong>tri preimpostati<br />

nel PEP, definire delle estensioni del protocollo <strong>per</strong> andare a sfruttare<br />

tutte le caratteristiche, standard e non, dei vari PEP.<br />

76


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

3.2.3 Role Based Access Control<br />

Uno dei principali obiettivi di RBAC (Role Based Access Control) è quello di<br />

fac<strong>il</strong>itare la gestione della sicurezza ed è un meccanismo di controllo degli accessi<br />

concepito negli anni ’70 e riesaminato negli anni successivi [SCFY96]. Il concetto<br />

fondamentale su cui si basa è che i <strong>per</strong>messi sono associati a ruoli ed i soggetti<br />

sono assegnati ai ruoli appropriati. Pertanto viene definito un ruolo <strong>per</strong> ogni<br />

mansione lavorativa che è possib<strong>il</strong>e attribuire all’interno di un’organizzazione e i<br />

soggetti sono assegnati ai ruoli sulla base delle proprie competenze pr<strong>of</strong>essionali<br />

e degli incarichi di lavoro. Chiaramente i ruoli concessi ad un utente possono<br />

variare nel tempo e possono fornire ulteriori <strong>per</strong>messi se sono disponib<strong>il</strong>i nuove<br />

applicazioni e nuovi sistemi. Di conseguenza RBAC fornisce un modo più intuitivo<br />

e più efficace <strong>per</strong> la gestione delle autorizzazioni rispetto ad altre forme di<br />

controllo degli accessi.<br />

Le politiche di controllo degli accessi sono formulate assumendo che un ruolo<br />

lega un particolare insieme di utenti con <strong>una</strong> collezione di <strong>per</strong>messi. In altre<br />

parole un ruolo può rappresentare <strong>il</strong> potere decisionale di un soggetto su altri,<br />

la responsab<strong>il</strong>ità e la competenza necessarie <strong>per</strong> svolgere specifiche attività.<br />

Quindi i modelli e le implementazioni di RBAC devono essere in grado di poter<br />

rappresentare <strong>il</strong> concetto di ruolo in tutte le sue possib<strong>il</strong>i forme.<br />

Inoltre RBAC è <strong>una</strong> risposta alle esigenze riguardanti la sicurezza di organizzazioni<br />

o<strong>per</strong>anti nel settore commerciale e m<strong>il</strong>itare e ciò è stato dimostrato da<br />

uno studio eseguito dal NIST (National Institute <strong>of</strong> Standards and Technology)<br />

su 28 aziende ([FGL93]). Tale studio ha r<strong>il</strong>evato che molte organizzazioni assumevano<br />

decisioni, in materia di controllo degli accessi, in base ai ruoli attribuiti<br />

ai soggetti all’interno dell’organizzazione stessa. Inoltre la maggior parte delle<br />

organizzazioni preferiva mantenere un controllo centralizzato dei diritti d’accesso<br />

che veniva effettuato in accordo alle linee guida, in materia di protezione,<br />

stab<strong>il</strong>ite dalle organizzazioni stesse.<br />

Attualmente esistono un certo numero di prodotti che supportano direttamente<br />

<strong>una</strong> qualche forma di RBAC mentre altri supportano concetti strettamente<br />

correlati, come i gruppi di utenti che possono essere ut<strong>il</strong>izzati <strong>per</strong><br />

implementare i ruoli.<br />

Infatti molti sistemi di successo, <strong>per</strong> <strong>il</strong> controllo degli accessi, implementano<br />

i ruoli <strong>per</strong> amministrare la sicurezza. Ad esempio, <strong>il</strong> ruolo di o<strong>per</strong>atore consente<br />

di accedere a tutte le risorse, ma non <strong>per</strong>mette di modificare le autorizzazioni di<br />

accesso. Invece <strong>il</strong> ruolo di security-<strong>of</strong>ficer <strong>per</strong>mette di cambiare i <strong>per</strong>messi, ma<br />

non dà l’autorizzazione <strong>per</strong> l’accesso alle risorse. Questo uso amministrativo dei<br />

ruoli si trova anche nei moderni sistemi o<strong>per</strong>ativi di rete, ad esempio Novell’s<br />

NetWare e Micros<strong>of</strong>t Windows NT. Ultimamente l’interesse dei progettisti si è<br />

focalizzato su come supportare RBAC a livello applicativo. Infatti sono state<br />

sv<strong>il</strong>uppate specifiche applicazioni con l’RBAC codificato all’interno dell’applica-<br />

77


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

zione stessa. Inoltre gli attuali sistemi o<strong>per</strong>ativi forniscono un piccolo supporto<br />

all’uso dell’RBAC a livello applicativo. La sfida sarà, quindi, quella di individuare,<br />

a supporto di <strong>una</strong> vasta gamma di applicazioni, programmi che siano<br />

sufficientemente flessib<strong>il</strong>i e semplici da implementare e ut<strong>il</strong>izzare.<br />

La politica implementata da RBAC supporta direttamente i tre noti principi<br />

di sicurezza: least priv<strong>il</strong>ege, separation <strong>of</strong> duties e data abstraction. Least priv<strong>il</strong>ege<br />

è supportato poiché l’RBAC è configurato in modo tale che solo i <strong>per</strong>messi<br />

necessari <strong>per</strong> svolgere i compiti assegnati ai membri del ruolo sono attribuiti<br />

al ruolo stesso. Separation <strong>of</strong> duties è ottenuto garantendo che i ruoli mutuamente<br />

esclusivi siano invocati <strong>per</strong> completare un task “delicato” mentre la data<br />

abstraction è supportata attraverso i <strong>per</strong>messi astratti. Tuttavia l’RBAC non<br />

può forzare l’applicazione a soddisfare questi tre principi così come un addetto<br />

alla sicurezza potrebbe configurare l’RBAC a violare i suddetti principi.<br />

Il Role Based Access Control, comunque, non rappresenta la <strong>soluzione</strong> <strong>per</strong><br />

tutti i problemi di controllo degli accessi poiché forme più s<strong>of</strong>isticate sono necessarie<br />

<strong>per</strong> far fronte a situazioni in cui vi è la necessità di controllare sequenze<br />

di o<strong>per</strong>azioni. Ad esempio, un acquisto richiede diversi passaggi prima che sia<br />

possib<strong>il</strong>e emettere l’ordine di acquisto e, in questo caso, l’RBAC non consente<br />

di controllare direttamente i <strong>per</strong>messi <strong>per</strong> tale sequenza di eventi. Per tale<br />

scopo altre forme di controllo degli accessi possono essere implementate ad un<br />

livello su<strong>per</strong>iore rispetto all’RBAC che viene usato come fondamento sul quale<br />

sv<strong>il</strong>uppare queste altre tipologie di controllo degli accessi.<br />

Nel corso degli anni è stata definita <strong>una</strong> famiglia di quattro modelli concettuali<br />

<strong>per</strong> RBAC, a cui viene fatto riferimento come RBAC0, RBAC1, RBAC2<br />

e RBAC3. RBAC0 è <strong>il</strong> modello di base e rappresenta <strong>il</strong> requisito minimo <strong>per</strong><br />

ogni sistema che supporti l’RBAC. RBAC1 e RBAC2 includono RBAC0, ma<br />

aggiungono ulteriori funzioni rispetto a quello di base: RBAC1 aggiunge <strong>il</strong> concetto<br />

di gerarchie di ruoli (situazioni in cui i ruoli, organizzati gerarchicamente,<br />

ereditano i <strong>per</strong>messi dagli altri ruoli), mentre RBAC2 aggiunge i vincoli (che<br />

impongono delle restrizioni sulle configurazioni accettab<strong>il</strong>i delle diversi componenti<br />

di RBAC). Oggi <strong>il</strong> modello consolidato è RBAC3 che comprende RBAC1<br />

e RBAC2 e quindi, <strong>per</strong> transitività, RBAC0.<br />

RBAC0 (modello di base)<br />

Il modello di base RBAC0 è caratterizzato principalmente da <strong>una</strong> collezione<br />

di sessioni (S) e da tre componenti che sono utenti (U), ruoli (R) e <strong>per</strong>messi<br />

(P). Un utente è normalmente un essere umano, ma può essere generalizzato<br />

<strong>per</strong> includere entità intelligenti autonome, come i robot, i computer e/o reti di<br />

computer. Un ruolo è un incarico o titolo di lavoro all’interno di un’organizzazione<br />

e può includere <strong>il</strong> potere decisionale e la responsab<strong>il</strong>ità di un soggetto su<br />

altri. Infine un <strong>per</strong>messo è <strong>una</strong> particolare modalità di accesso ad <strong>una</strong> oppure a<br />

78


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

più risorse del sistema ed è denotato nella letteratura con i termini di autorizzazione,<br />

diritto d’accesso e priv<strong>il</strong>egio. In questo contesto i <strong>per</strong>messi sono sempre<br />

positivi dal momento che conferiscono al titolare la capacità di eseguire alcune<br />

azioni nel sistema. In generale alcune letterature sul controllo degli accessi parlano<br />

di “<strong>per</strong>messi negativi” quando vengono ut<strong>il</strong>izzati <strong>per</strong> negare esplicitamente<br />

l’accesso alle risorse. Con <strong>il</strong> termine oggetti viene fatto riferimento ai dati o ad<br />

altre risorse all’interno dei vari sistemi informativi.<br />

La natura di un <strong>per</strong>messo dipende in gran parte dal tipo di sistema e dall’implementazione<br />

dei suoi dettagli. In tale modo un sistema o<strong>per</strong>ativo può<br />

proteggere le directory, i f<strong>il</strong>e, i dispositivi e le porte con o<strong>per</strong>azioni di lettura,<br />

scrittura ed esecuzione mentre un sistema di gestione di database relazionali<br />

può proteggere le relazioni, le tuple, gli attributi e le viste rispetto ad o<strong>per</strong>azioni<br />

come SELECT, UPDATE, DELETE ed INSERT.<br />

I <strong>per</strong>messi possono essere applicati ad uno o più oggetti ed è previsto che più<br />

<strong>per</strong>messi siano raggruppab<strong>il</strong>i <strong>per</strong> poter essere manipolati come singola unità, ma<br />

questa caratteristica è altamente dipendente dall’implementazione. Ad esempio,<br />

un <strong>per</strong>messo può essere specificato al fine di consentire la lettura di un particolare<br />

f<strong>il</strong>e oppure <strong>per</strong> conferire l’accesso in lettura a tutti i f<strong>il</strong>e appartenenti ad un<br />

particolare dipartimento.<br />

Un utente può essere membro di molti ruoli e un ruolo può avere molti utenti.<br />

Allo stesso modo un ruolo può avere molti <strong>per</strong>messi e lo stesso <strong>per</strong>messo può<br />

essere assegnato a molti ruoli.<br />

Una sessione mappa un utente con tutti i suoi possib<strong>il</strong>i ruoli ed un soggetto<br />

può stab<strong>il</strong>ire <strong>una</strong> sessione attraverso la quale attiva un sottoinsieme di ruoli (di<br />

cui è membro). Da ciò deriva che è possib<strong>il</strong>e attivare simultaneamente ruoli multipli<br />

ed i <strong>per</strong>messi disponib<strong>il</strong>i <strong>per</strong> un utente sono l’unione dei <strong>per</strong>messi di tutti<br />

i ruoli attivati nella sessione. Pertanto ogni sessione è associata ad un singolo<br />

utente e questa associazione non varia durante <strong>il</strong> ciclo vita della sessione. Un<br />

utente può avere più sessioni a<strong>per</strong>te contemporaneamente, ciasc<strong>una</strong> delle quali<br />

può avere <strong>una</strong> combinazione differente di ruoli attivi. Questa caratteristica di<br />

RBAC0 supporta <strong>il</strong> principio del minimo priv<strong>il</strong>egio, ossia un utente può invocare<br />

più sottoinsiemi di ruoli, di cui è membro, necessari <strong>per</strong> eseguire i compiti<br />

assegnati in quella sessione. In tal modo un utente può normalmente mantenere<br />

un ruolo disattivandolo ed attivandolo esplicitamente a sua descrizione. In<br />

particolare <strong>per</strong> RBAC2 risulta necessario prendere in considerazione tutti i tipi<br />

di vincoli che è possib<strong>il</strong>e applicare ai componenti, tra cui quelli sull’attivazione<br />

di un ruolo. RBAC0 consente anche di attivare e disattivare dinamicamente i<br />

ruoli durante <strong>il</strong> ciclo di vita di <strong>una</strong> sessione.<br />

Chiaramente è auspicab<strong>il</strong>e che ogni ruolo sia assegnato ad almeno un <strong>per</strong>messo<br />

e che ogni utente sia associato ad almeno un ruolo, <strong>per</strong>ò questo modello<br />

di base richiede solo che i <strong>per</strong>messi siano applicati ai dati o ad altre risorse<br />

79


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

informatiche e non ai componenti di RBAC stesso.<br />

Le sessioni sono controllate dai singoli utenti e, <strong>per</strong> quanto riguarda <strong>il</strong> modello<br />

in questione, un utente può creare <strong>una</strong> sessione potendo scegliere di attivare<br />

un sottoinsieme di ruoli che possono essere cambiati a discrezione dell’utente<br />

stesso. La sessione termina su iniziativa dell’utente o <strong>per</strong> o<strong>per</strong>a di alcuni sistemi<br />

se risulta essere inattiva <strong>per</strong> troppo tempo.<br />

RBAC1<br />

Il modello RBAC1 introduce le gerarchie di ruoli (RH) che oggi sono comunemente<br />

usate nei sistemi che implementano RBAC. Tali gerarchie rappresentano<br />

un modo <strong>per</strong> strutturare i ruoli con l’obiettivo di esprimere i livelli di responsab<strong>il</strong>ità<br />

e di autorità stab<strong>il</strong>iti all’interno dell’organizzazione. Un esempio di tale<br />

struttura è mostrato nella figura 3.2 dove i ruoli “più potenti” (senior) sono mostrati<br />

nella parte alta del diagramma mentre quelli “meno potenti” (junior) sono<br />

indicati nella parte inferiore del diagramma. In tale configurazione <strong>il</strong> ruolo di<br />

su<strong>per</strong>visore di progetto eredita i <strong>per</strong>messi sia dal ruolo di tester sia da quello di<br />

programmatore.<br />

Tester<br />

Su<strong>per</strong>visore<br />

del progetto<br />

La frecce indicano la<br />

gerarchia e quindi<br />

esprimono la relazione<br />

“eredita da”<br />

Membro del<br />

progetto<br />

Programmatore<br />

Figura 3.2: Esempio di ruoli gerarchici del modello RBAC1.<br />

In questo modello un utente (U) è autorizzato a stab<strong>il</strong>ire <strong>una</strong> sessione con<br />

<strong>una</strong> qualsiasi combinazione di ruoli <strong>per</strong> i quali l’utente è un loro membro. Inoltre<br />

i <strong>per</strong>messi di <strong>una</strong> sessione sono quelli direttamente assegnati ai ruoli della<br />

sessione e quelli ereditati dai ruoli junior. A volte è ut<strong>il</strong>e <strong>per</strong> le gerarchie limitare<br />

<strong>il</strong> campo di applicazione della relazione di ereditarietà quando tali strutture non<br />

raffigurano la distribuzione dei <strong>per</strong>messi in modo accurato. In questo caso è preferib<strong>il</strong>e<br />

mantenere intatto <strong>il</strong> significato della relazione gerarchica introducendo i<br />

ruoli privati.<br />

80


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

RBAC2<br />

Il modello RBAC2 aggiunge <strong>il</strong> concetto di vincolo rispetto a RBAC1 e a<br />

RBAC0. I vincoli sono un aspetto importante di RBAC e, a volte, sono la<br />

principale motivazione <strong>per</strong> l’ut<strong>il</strong>izzo di RBAC. Infatti nella maggior parte delle<br />

organizzazioni (tranne le più piccole) ad uno stesso individuo potrebbe non essere<br />

consentito di essere un membro di due o più ruoli al fine di impedirgli, ad<br />

esempio, di commettere frodi. Tale concetto è ben noto ed è conosciuto come<br />

principio di separazione dei compiti. I vincoli possono essere considerati come un<br />

meccanismo potente <strong>per</strong> impostare politiche aziendali di alto livello. Una volta<br />

che certi ruoli sono stati dichiarati mutuamente esclusivi, non vi è la necessità<br />

di preoccuparsi sull’assegnamento dei singoli utenti a questi ruoli. Quest’ultima<br />

attività può essere delegata e, successivamente, decentrata senza compromettere<br />

la politica complessiva stab<strong>il</strong>ita dall’organizzazione. Se la gestione di RBAC è<br />

completamente centralizzata nelle mani di un singolo security-<strong>of</strong>ficer, i vincoli<br />

risultano convenienti da usare, anche se gli stessi effetti possono essere largamente<br />

raggiunti grazie alle ab<strong>il</strong>ità del security-<strong>of</strong>ficer. Tuttavia se la gestione<br />

di RBAC è decentrata, i vincoli diventano un meccanismo attraverso <strong>il</strong> quale<br />

<strong>il</strong> security-<strong>of</strong>ficer (senior) può limitare le capacità di quegli utenti che esercitano<br />

i propri priv<strong>il</strong>egi amministrativi. Ciò <strong>per</strong>mette al security-<strong>of</strong>ficer principale<br />

di impostare i confini di ciò che è accettab<strong>il</strong>e, imponendoli come un requisito<br />

obbligatorio agli altri security-<strong>of</strong>ficer ed utenti che partecipano alla gestione di<br />

RBAC.<br />

I vincoli sono predicati che, applicati a relazioni e funzioni, restituiscono<br />

un valore corrispondente ad accettab<strong>il</strong>e o non accettab<strong>il</strong>e. Pertanto RBAC2 è<br />

immutato rispetto a RBAC0 ad esclusione del set di vincoli che determinano se<br />

i valori assunti dai vari componenti sono o non sono ammissib<strong>il</strong>i.<br />

Generalmente dal punto di vista implementativo sono richiesti semplici vincoli<br />

che possono essere controllati e realizzati in modo efficiente. Il vincolo più<br />

menzionato nel contesto di RBAC è la mutua esclusione dei ruoli. Lo stesso<br />

utente può essere assegnato al massimo ad un ruolo in un set mutuamente<br />

esclusivo, ottenendo, in questo modo, la separazione dei compiti. La motivazione<br />

<strong>per</strong> l’uso di tale vincolo deriva dal fatto che un vincolo mutuamente esclusivo<br />

sull’assegnamento del <strong>per</strong>messo può <strong>of</strong>frire garanzie supplementari <strong>per</strong> la separazione<br />

dei compiti. In conclusione tale tipologia di vincoli rappresenta un mezzo<br />

ut<strong>il</strong>e <strong>per</strong> limitare la distribuzione dei <strong>per</strong>messi “più potenti” e <strong>per</strong> ritenere accettab<strong>il</strong>e<br />

o non accettab<strong>il</strong>e l’associazione tra varie combinazioni di ruoli e utenti.<br />

In questo modo può essere accettab<strong>il</strong>e che un utente sia un membro dei ruoli<br />

di programmatore e di tester in progetti diversi, ma è inaccettab<strong>il</strong>e che assuma<br />

entrambi i ruoli all’interno dello stesso progetto. Sim<strong>il</strong>mente ciò vale anche <strong>per</strong><br />

l’assegnamento dei <strong>per</strong>messi.<br />

Un altro esempio di vincolo sulla relazione di assegnamento degli utenti è<br />

81


Principi e tecnologie <strong>per</strong> la sicurezza Autorizzazione<br />

dato dal fatto che un ruolo può avere un numero massimo di utenti associati.<br />

In modo sim<strong>il</strong>e può essere limitato anche <strong>il</strong> numero di ruoli al quale un singolo<br />

utente può appartenere. Questi tipi di vincoli sono chiamati vincoli di cardinalità<br />

e possono essere applicati anche sul numero di ruoli ai quali un <strong>per</strong>messo può<br />

essere assegnato.<br />

I vincoli sull’assegnamento degli utenti sono effettivi solo se è mantenuta<br />

un’appropriata disciplina esterna sull’assegnamento di identificatori di utente<br />

agli esseri umani. Se lo stesso individuo è assegnato a due o più identificatori<br />

di utente, i controlli sulla separazione e sulla cardinalità crollano e, <strong>per</strong> evitare<br />

ciò, è necessario che ci sia <strong>una</strong> corrispondenza uno-a-uno tra identificatori di<br />

utente e esseri umani. La stesso fenomeno potrebbe accadere anche ai vincoli sui<br />

<strong>per</strong>messi, ossia, se la stessa o<strong>per</strong>azione è autorizzata da due differenti <strong>per</strong>messi, <strong>il</strong><br />

sistema di gestione di RBAC non può usare efficacemente i vincoli di cardinalità<br />

e di separazione.<br />

I vincoli possono essere applicati anche a sessioni. Ad esempio, potrebbe<br />

essere accettab<strong>il</strong>e <strong>per</strong> un utente essere membro di due differenti ruoli, ma lo<br />

stesso utente non può essere attivo allo stesso istante con entrambi i ruoli. Altre<br />

tipologie di vincoli sulle sessioni possono limitare <strong>il</strong> numero di sessioni che un<br />

utente può attivare nello stesso momento oppure possono limitare <strong>il</strong> numero di<br />

sessioni al quale un <strong>per</strong>messo è assegnato. Infine <strong>una</strong> gerarchia di ruoli può essere<br />

considerata un vincolo poiché un <strong>per</strong>messo, associato ad un ruolo subordinato<br />

(junior), deve essere assegnato anche a tutti i ruoli su<strong>per</strong>iori (senior) ed un<br />

utente, assegnato ad un ruolo senior, deve appartenere anche a tutti i ruoli<br />

subalterni.<br />

RBAC3<br />

Il modello RBAC3 combina RBAC1 e RBAC2 al fine di <strong>of</strong>frire sia le gerarchie<br />

di ruoli sia i vincoli, ma usare entrambi i concetti può comportare notevoli<br />

problemi in quanto sott<strong>il</strong>i interazioni possono sorgere tra vincoli e gerarchie.<br />

I vincoli possono riferirsi ad <strong>una</strong> gerarchia di ruoli, che è <strong>una</strong> relazione d’ordine<br />

parziale dal punto di vista matematico. Vincoli supplementari possono<br />

limitare <strong>il</strong> numero di ruoli senior (o junior) che un dato ruolo può avere e possono<br />

costringere due o più ruoli a non avere un ruolo senior (o junior) comune.<br />

Tali tipologie di vincoli sono ut<strong>il</strong>i in situazioni dove l’autorità <strong>per</strong> cambiare le<br />

gerarchie di ruoli è stata decentrata anche se <strong>il</strong> security <strong>of</strong>ficer principale può<br />

desiderare di limitare le modalità con le quali possono essere fatte tali modifiche.<br />

Nel modello RBAC3 i vincoli possono essere applicati sia ai <strong>per</strong>messi diretti sia<br />

a quelli ereditati ed è prevista <strong>una</strong> relazione di mutua esclusione tra i ruoli e<br />

i ruoli amministrativi, ossia sono tra loro esclusivi. In conclusione gli obiettivi<br />

del modello RBAC3 sono i seguenti:<br />

• metodologia sistematica di analisi;<br />

82


Principi e tecnologie <strong>per</strong> la sicurezza Accounting<br />

• progettazione e gestione della gerarchia di ruoli e dei vincoli;<br />

• visione integrata del sistema.<br />

3.3 Accounting<br />

L’accounting ha un ruolo molto importante nelle infrastrutture <strong>per</strong> l’AAA.<br />

Entra in gioco solo al termine del processo di autenticazione autorizzazione ed<br />

eventualmente accesso e traccia, a posteriori, tutti gli eventi che si sono succeduti.<br />

Normalmente memorizza, in opportuni log, quando gli utenti si connettono<br />

ai vari sistemi, cosa sono stati autorizzati (e non autorizzati) a fare (e/o cosa<br />

hanno fatto 3 ) ed infine quando si disconnettono.<br />

L’accounting è ampliamente ut<strong>il</strong>izzato dagli Internet Service Provider (ISP)<br />

<strong>per</strong>ché è sulla base delle informazioni memorizzate che, normalmente, calcolano i<br />

costi di connessione da addebitare ai clienti. Inoltre tali informazioni risultano di<br />

vitale importanza nel caso in cui venga fatto un uso fraudolento delle tecnologie<br />

ICT. Tale uso fraudolento può essere classificato sia in attacchi informatici (in<br />

tal caso è fondamentale poter tracciare quante più informazioni possib<strong>il</strong>i sia <strong>per</strong><br />

risalire ai potenziali attaccanti che, più che altro, <strong>per</strong> poter stimare in tempi<br />

rapidi l’entità del danno subito) che in ut<strong>il</strong>izzo delle tecnologie telematiche <strong>per</strong><br />

scopi <strong>il</strong>leciti (ped<strong>of</strong><strong>il</strong>ia, terrorismo e quant’altro e in questo caso l’accounting è<br />

determinante <strong>per</strong> rintracciare i responsab<strong>il</strong>i).<br />

Come descritto nella RFC 2924 [BB00] un sistema <strong>per</strong> l’accounting è costituito<br />

da varie entità:<br />

• <strong>il</strong> servizio di rete che <strong>of</strong>fre delle funzionalità ai client;<br />

• i client che richiedono al servizio l’esecuzione di <strong>una</strong> o più o<strong>per</strong>azioni;<br />

• l’accounting server che riceve le segnalazioni di ut<strong>il</strong>izzo e provvede a<br />

trattarle;<br />

• le segnalazioni di ut<strong>il</strong>izzo (costituite da un insieme di coppie“nome-valore”)<br />

che vengono generate dai servizi di rete in concomitanza dell’esecuzione di<br />

o<strong>per</strong>azioni di vario tipo su richiesta dei client.<br />

La figura 3.3 mostra uno scenario tipico in cui uno o più client richiedono<br />

l’esecuzione di o<strong>per</strong>azioni al servizio <strong>il</strong> quale notificherà, tramite opportune<br />

segnalazioni, l’esecuzione delle stesse all’accounting server.<br />

L’accounting server può trattare la segnalazione in autonomia oppure inoltrarla,<br />

eventualmente a seguito di <strong>una</strong> elaborazione locale, ad altri accounting<br />

server.<br />

3 In realtà si tratta di due facce della stessa medaglia, <strong>una</strong> vista dal lato del sistema di<br />

autorizzazione l’altra dal punto di vista del servizio richiesto dall’utente.<br />

83


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Client<br />

Client<br />

Servizio<br />

Segnalazioni<br />

di Ut<strong>il</strong>izzo<br />

Accounting<br />

Server<br />

Figura 3.3: Architettura di un sistema di accounting.<br />

3.4 Tecnologie <strong>per</strong> l’AAA<br />

3.4.1 Public Key Infrastructure<br />

La crittografia asimmetrica <strong>of</strong>fre <strong>una</strong> serie di opportunità che riguardano la<br />

confidenzialità e l’integrità dei dati, l’identificab<strong>il</strong>ità certa dei messaggi e delle<br />

entità in gioco (autenticazione) e la non ripudiab<strong>il</strong>ità ([Tan03]). Ovviamente<br />

non è la tecnologia di <strong>per</strong> se a garantire che queste opportunità si trasformino in<br />

vantaggi concreti, ma l’uso che ne viene fatto. A esempio, <strong>il</strong> fornire ad un utente<br />

<strong>una</strong> coppia di chiavi asimmetriche non garantisce che, tramite le stesse, sia<br />

possib<strong>il</strong>e identificare i messaggi di posta elettronica da esso inviati: banalmente<br />

l’utente potrebbe non ut<strong>il</strong>izzare le chiavi <strong>per</strong> firmare le e-ma<strong>il</strong>, <strong>per</strong> non parlare<br />

del più insidioso problema che nasce se esso non riesce a mantenere segreta la<br />

propria chiave privata. In quest’ultimo caso infatti, potrebbe essere possib<strong>il</strong>e<br />

imbattersi in un caso di sicurezza apparente: confidando sulle potenzialità della<br />

crittografia si potrebbe pensare che un certo messaggio di posta sia riconducib<strong>il</strong>e<br />

ad un determinato utente quando in realtà, non essendo esso riuscito a<br />

mantenere segreta la chiave privata, chiunque (ovviamente in grado di accedere<br />

alla stessa) avrebbe potuto firmare l’e-ma<strong>il</strong> al posto dell’utente, eventualmente<br />

ignaro della situazione, spacciandosi <strong>per</strong> esso.<br />

È chiaro quindi che la sicurezza non è un traguardo che si raggiunge esclusivamente<br />

con mezzi tecnici, ma riguarda moltissimo i processi e tutte le entità,<br />

individui compresi, che vi ruotano attorno.<br />

Per questo motivo, come sarà <strong>il</strong>lustrato nel presente paragrafo, è necessario<br />

fissare tutta <strong>una</strong> serie di vincoli e procedure o<strong>per</strong>ative, oltre alle soluzioni prettamente<br />

tecniche, <strong>per</strong> raggiungere dei risultati in questo contesto che abbiano <strong>una</strong><br />

qualità accettab<strong>il</strong>e. Le infrastrutture a chiave pubblica (PKI, Public Key Infrastructure)<br />

sono quindi delle soluzioni tecniche, organizzative e politiche <strong>il</strong> cui<br />

obiettivo è quello di esprimere nel mondo reale le potenzialità della crittografia<br />

asimmetrica.<br />

84


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Appare chiaro che <strong>una</strong> PKI non è un metodo di autenticazione [Shi04], ma<br />

un’infrastruttura che, pur ut<strong>il</strong>izzando i certificati digitali come metodo di autenticazione,<br />

ha lo scopo di stab<strong>il</strong>ire le modalità tecniche ed i processi organizzativi<br />

necessari <strong>per</strong> <strong>il</strong> r<strong>il</strong>ascio e la gestione dei certificati (con le relative chiavi) in modo<br />

efficace, sicuro ed efficiente.<br />

Elementi di <strong>una</strong> PKI<br />

Le PKI possono essere realizzate in contesti diversificati. Ad esempio le<br />

aziende possono realizzarsi delle PKI private <strong>per</strong> l’assegnazione dei certificati<br />

validi esclusivamente all’interno dell’azienda stessa, come trovare realtà affermate<br />

che r<strong>il</strong>asciano certificati <strong>per</strong> l’utenza Internet. Indipendentemente dal<br />

contesto, parlare di PKI significa andare a chiamare in causa <strong>una</strong> serie di entità,<br />

ogn<strong>una</strong> delle quali ha uno scopo ben preciso:<br />

• almeno <strong>una</strong> certification authority (CA) <strong>per</strong> l’emissione dei certificati;<br />

• un insieme di politiche prestab<strong>il</strong>ite <strong>per</strong> la gestione di ogn<strong>una</strong> delle possib<strong>il</strong>i<br />

o<strong>per</strong>azioni effettuab<strong>il</strong>i dalla PKI;<br />

• un insieme di certificati digitali;<br />

• un insieme di applicazioni in grado di usufruire dei servizi forniti dalla<br />

PKI.<br />

Le Certification Authority<br />

Le CA sono ovviamente <strong>il</strong> cuore di ogni PKI ed ogni PKI ne ha almeno<br />

<strong>una</strong>. Sono costituite da un s<strong>of</strong>tware <strong>per</strong> la gestione di certificati (detto CPS,<br />

Cryptographic Service Provider) e da <strong>una</strong> coppia di chiavi asimmetriche di cui<br />

quella pubblica firmata digitalmente (è un certificato a tutti gli effetti).<br />

Solitamente si realizzano soluzioni con più CA organizzate gerarchicamente.<br />

In questo caso si ha almeno <strong>una</strong> root CA al livello più alto della gerarchia che<br />

viene ut<strong>il</strong>izzata esclusivamente <strong>per</strong> creare e firmare i certificati propri delle CA<br />

di livello inferiore. La root CA ut<strong>il</strong>izza un certificato digitale self-signed (aut<strong>of</strong>irmato)<br />

in quanto è l’elemento di partenza della catena di trust al quale viene<br />

fornita fiducia <strong>per</strong> definizione. Questo fa capire <strong>il</strong> motivo <strong>per</strong> <strong>il</strong> quale le root<br />

CA non dovrebbero essere ut<strong>il</strong>izzate <strong>per</strong> emettere i certificati ad eccezione di<br />

quelli <strong>per</strong> le CA di livello inferiore: è assolutamente prioritario mantenere tale<br />

categoria di CA al sicuro, in quanto la compromissione delle stesse equivale alla<br />

compromissione dell’intera catena di trust ovvero di tutta la PKI. Normalmente<br />

quindi le root CA vengono mantenute al sicuro, disconnesse dalla rete e non<br />

accessib<strong>il</strong>i fisicamente.<br />

85


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

L’architettura più generale (aggiungere ulteriori livelli, seppur fattib<strong>il</strong>e da<br />

un punto di vista pratico, non apporta ulteriori vantaggi) prevede <strong>una</strong> gerarchia<br />

a tre livelli in cui:<br />

• al livello più alto si collocano le root CA;<br />

• al livello intermedio le Certification Policy Certification Authority (o più<br />

brevemente Policy CA);<br />

• infine al livello più basso le Issuing Certification Authority (o più brevemente<br />

Issuing CA).<br />

Legenda<br />

R<strong>il</strong>ascio Certificato<br />

Revoca Certificato<br />

X X<br />

X X<br />

X X<br />

Root-0 CA<br />

X X<br />

Policy-0 CA Policy-1 CA<br />

... ...<br />

X X<br />

X X<br />

User Server<br />

X X Issuing-n CA<br />

X X<br />

Anni<br />

Mesi<br />

Giorni/Ore<br />

Figura 3.4: Struttura gerarchica delle CA di <strong>una</strong> PKI.<br />

Frequenza R<strong>il</strong>asci/Revoche<br />

(ordini di grandezza a titolo esemplificativo)<br />

In questo scenario, figura 3.4, l’unico scopo delle root CA è quello di emettere<br />

(e, qualora necessario, revocare) i certificati ed eventualmente di generare le<br />

chiavi <strong>per</strong> le Policy CA; quest’ultime sono destinate a firmare (e, se necessario,<br />

revocare) i certificati ed eventualmente a generare le chiavi <strong>per</strong> le Issuing CA.<br />

Sono infine quest’ultime destinate a generare le chiavi (se necessario) ed emettere<br />

(ed eventualmente revocare) i certificati degli utenti (e delle applicazioni) della<br />

PKI.<br />

86


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Questo approccio <strong>per</strong>mette di mantenere le root CA al sicuro anche in contesti<br />

fortemente distribuiti (ad esempio multinazionali con sedi dislocate in tutto<br />

<strong>il</strong> mondo) nei quali si riesce ad ottenere la sufficiente flessib<strong>il</strong>ità nel r<strong>il</strong>ascio e<br />

nella revoca delle Issuing CA attraverso le Policy CA. Questo <strong>per</strong>ché le Issuing<br />

CA, dovendo o<strong>per</strong>are quotidianamente <strong>per</strong> <strong>il</strong> r<strong>il</strong>ascio e la revoca dei certificati,<br />

sono esposte a compromissioni ed in tal caso è necessario revocarle (la revoca<br />

dei certificati, e conseguentemente l’invalidazione di tutto ciò che è stato firmato<br />

con gli stessi, è un argomento trattato successivamente). Viceversa le Policy CA<br />

e, a maggior ragione, le root CA entrano in gioco solo raramente e ciò consente<br />

di garantirne l’integrità mantenendole in luogo sicuro disconnesse dalla rete.<br />

In ogni caso è frequente l’implementazione di PKI a due soli livelli in cui le<br />

root CA emettono direttamente i certificati <strong>per</strong> le Issuing CA.<br />

Le Policy delle PKI<br />

Le policy relative ad <strong>una</strong> PKI servono <strong>per</strong> definire le regole necessarie a<br />

garantire la sicurezza delle chiavi, i processi di emissione, rinnovo e revoca dei<br />

certificati, le classi dei certificati (destinati ad utenti <strong>per</strong> la firma elettronica,<br />

destinati ad utenti <strong>per</strong> l’accesso a servizi telematici, destinati a web server,<br />

destinati a server di posta, etc.) ed i relativi dettagli (come la durata temporale<br />

predefinita) e quant’altro.<br />

Per quanto riguarda la realizzazione di PKI pubbliche (ad esempio come<br />

quelle create da organizzazioni a fini commerciali come VeriSign) è necessario<br />

che venga redatto uno specifico documento detto Certificate Practice Statement<br />

(CPS). Il CPS dichiara le modalità con cui le chiavi vengono generate ed archiviate,<br />

le procedure di r<strong>il</strong>ascio e revoca dei certificati, eccetera. Se la PKI è di<br />

tipo privato, non è richiesto che venga pubblicato <strong>il</strong> CPS, anche se è fortemente<br />

consigliato produrre <strong>una</strong> chiara documentazione relativamente alle metodologie<br />

ut<strong>il</strong>izzate <strong>per</strong> validare l’identità di coloro ai quali vengono r<strong>il</strong>asciati i certificati,<br />

nella quale si vadano ad indicare chi può revocare i certificati e come viene<br />

distribuita la lista contenente i certificati revocati, con quale frequenza e con<br />

quali modalità si procede <strong>per</strong> l’archiviazione dei certificati ed infine quali sono<br />

le applicazioni autorizzazione e non autorizzate all’uso dei certificati.<br />

R<strong>il</strong>ascio, gestione e revoca dei certificati<br />

I processi inerenti al r<strong>il</strong>ascio ed alla gestione dei certificati sono abbastanza<br />

complessi. In ogni caso è possib<strong>il</strong>e descrivere <strong>una</strong> sequenza di o<strong>per</strong>azioni che<br />

possono essere prese a riferimento <strong>per</strong> la descrizione del ciclo di vita di un<br />

certificato. Ciò non toglie che alcuni dei passi successivamente descritti possano<br />

non essere svolti oppure essere svolti in ordine diverso; resta comunque inteso<br />

che sono presenti alcuni vincoli che non possono essere violati.<br />

Si consideri quindi la seguente sequenza temporale di azioni:<br />

87


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

1. l’utente intende dotarsi di un certificato digitale <strong>per</strong> un motivo qualunque;<br />

2. la CA genera <strong>una</strong> coppia di chiavi asimmetriche da assegnargli. Si noti che<br />

normalmente sarà la CA a fornirgli tutto quello che serve, chiavi comprese,<br />

ma questo non è necessario: la generazione delle chiavi è un’o<strong>per</strong>azione<br />

da effettuare a monte, del tutto scorrelata dal resto. Inoltre è frequente<br />

l’ut<strong>il</strong>izzo della stessa coppia di chiavi <strong>per</strong> la generazione di più certificati;<br />

3. l’utente crea <strong>il</strong> Certificate Signing Request (CSR). Il CSR è <strong>il</strong> documento<br />

che viene inviato alla CA <strong>per</strong> l’emissione del certificato. Come minimo<br />

contiene la chiave pubblica dell’utente e tutte le informazioni necessarie <strong>per</strong><br />

identificarlo univocamente (nel caso dei certificati X.509 <strong>il</strong> distinguished<br />

name), ma può contenere ulteriori informazioni come l’indirizzo e-ma<strong>il</strong>, la<br />

nazionalità, <strong>il</strong> paese, eccetera. Il CSR viene creato dall’utente firmando<br />

questo insieme di informazioni con la propria chiave privata;<br />

4. la CA valida <strong>il</strong> CSR alla luce delle proprie policy;<br />

5. in caso di esito positivo del passo precedente, la CA firma la chiave pubblica<br />

dell’utente con la propria chiave privata creando di fatto <strong>il</strong> certificato;<br />

6. <strong>il</strong> certificato viene fornito all’utente <strong>il</strong> quale, in abbinamento alla propria<br />

chiave privata, può essere ut<strong>il</strong>izzato <strong>per</strong> gli scopi del passo 1.<br />

Considerazioni sulle PKI. In tutta la procedura, grazie alle caratteristiche<br />

della crittografia asimmetrica, le uniche entità da mantenere segrete sono solo<br />

le chiavi private. Tutto <strong>il</strong> resto può essere considerato pubblico, certificato<br />

compreso. Questo spiega <strong>il</strong> motivo <strong>per</strong> <strong>il</strong> quale spesso la stessa coppia di chiavi<br />

viene ut<strong>il</strong>izzata <strong>per</strong> più certificati: <strong>una</strong> delle fasi più critiche di tutto <strong>il</strong> processo,<br />

se non la più critica in assoluto, è quella di fornire la coppia di chiavi all’utente.<br />

In questa fase si evidenziano infatti due importanti criticità:<br />

• la prima riguarda l’identificazione certa del richiedente (secondo le modalità<br />

descritte nel CPS o nella documentazione equivalente), in quanto è<br />

assolutamente necessario che le chiavi vengano davvero fornite al legittimo<br />

proprietario (si pensi al fatto che la firma digitale, intesa nell’accezione del<br />

Codice dell’Amministrazione Digitale, è stata equiparata a tutti gli effetti<br />

alla firma autografa). Si noti che essendo <strong>il</strong> CSR emesso dal richiedente e<br />

firmato con la propria chiave privata, la CA, nell’ipotesi in cui tali chiavi<br />

siano state fornite all’utente secondo le opportune modalità, ha tutti<br />

gli strumenti <strong>per</strong> verificarne l’attendib<strong>il</strong>ità (andando a verificare la firma<br />

ut<strong>il</strong>izzando la chiave pubblica dell’utente);<br />

• la seconda riguarda la confidenzialità della trasmissione delle chiavi: è<br />

assolutamente necessario che, anche se l’utente è davvero <strong>il</strong> legittimo pro-<br />

88


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

prietario delle stesse, esse vengano fornite tramite un canale sicuro. Ovviamente<br />

se le chiavi finiscono nelle mani sbagliate, lo sono a prescindere<br />

dal fatto che siano state fornite alla <strong>per</strong>sona sbagliata oppure che siano<br />

state intercettate da un soggetto terzo durante la trasmissione alla <strong>per</strong>sona<br />

corretta.<br />

L’emissione del certificato può avvenire, ovviamente, <strong>per</strong> scopi diversi. Fermo<br />

restando la validità delle chiavi e la corretta associazione con l’utente, la<br />

validità del CSR eccetera, la CA, quando emette <strong>il</strong> certificato, va a specificare<br />

nello stesso <strong>per</strong> quali applicazioni può essere ut<strong>il</strong>izzato oltre ad altre informazioni<br />

quali l’intervallo temporale di validità. A titolo esemplificativo possono<br />

essere citati certificati validi solo <strong>per</strong> la firma di e-ma<strong>il</strong>, <strong>per</strong> l’ut<strong>il</strong>izzo con applicazioni<br />

lato client (ad esempio <strong>per</strong> l’autenticazione a reti private virtuali), <strong>per</strong><br />

l’autenticazione via web, <strong>per</strong> l’erogazione di servizi in rete, eccetera.<br />

Infine, ma certamente non a causa del fatto che questo aspetto assume <strong>una</strong><br />

minore importanza nell’ambito di <strong>una</strong> PKI, resta da analizzare <strong>il</strong> processo di<br />

revoca dei certificati. La revoca di un certificato può essere effettuata <strong>per</strong> vari<br />

motivi. Il primo motivo riguarda la compromissione delle chiavi: è assolutamente<br />

necessario rendere inut<strong>il</strong>izzab<strong>il</strong>e <strong>il</strong> certificato qualora la chiave privata<br />

dell’utente venga violata. In questo modo, anche se le chiavi cadono nelle mani<br />

sbagliate, nel momento in cui <strong>il</strong> certificato non è più valido esse diventano<br />

inut<strong>il</strong>izzab<strong>il</strong>i. Un’altra causa che porta alla revoca di un certificato è legata<br />

a variazioni di stato dell’utente. Ad esempio se un’azienda fornisce tramite<br />

la propria PKI un certificato agli utenti <strong>per</strong> l’accesso ai servizi interni, risulta<br />

ovviamente necessario attuare <strong>una</strong> revoca dei certificati <strong>per</strong> quegli utenti che<br />

lasciano l’azienda prima della scadenza dei certificati stessi.<br />

Il processo di revoca avviene indirettamente e segue <strong>il</strong> principio delle blacklist:<br />

la CA genera e pubblica/distribuisce un documento, detto Certificate Revocation<br />

List (CRL), contenente la lista dei certificati revocati. Resta inteso<br />

che ogni CA può revocare solo i certificati a lei riconducib<strong>il</strong>i e la garanzia di<br />

genuinità della lista è ovviamente fornita tramite un meccanismo di firma (<strong>il</strong><br />

documento è emesso e firmato dalla CA stessa). Una difficoltà che spesso viene<br />

incontrata riguarda la difficoltà nel distribuire tempestivamente la CRL a tutte<br />

le applicazioni, in modo da inibire l’uso dei certificati revocati. Si pensi ad<br />

esempio ai certificati ut<strong>il</strong>izzati <strong>per</strong> l’autenticazione: se <strong>il</strong> server non ha ricevuto<br />

la CRL aggiornata, ignorando quindi la revoca di alcuni certificati, continuerebbe<br />

a fornire servizi anche ad utenti che non ne avrebbero più diritto (se non<br />

addirittura in mala fede).<br />

Infine la revoca di un certificato relativo ad <strong>una</strong> CA, non solo impedisce alla<br />

CA di emettere nuovi certificati, ma invalida tutti i certificati emessi dalla CA<br />

stessa. Questo aspetto è di particolare importanza <strong>per</strong> la garantire l’affidab<strong>il</strong>ità<br />

dell’intera PKI: se <strong>una</strong> CA viene compromessa al tempo t1 e la sco<strong>per</strong>ta della<br />

89


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

compromissione avviene al tempo t1 +δ (ovviamente con δ > 0) è assolutamente<br />

necessario poter invalidare tutti i certificati emessi fra t1 e t1 + δ, certificati<br />

che potrebbero essere stati emessi dall’attaccante <strong>per</strong> scopi <strong>il</strong>leciti. Anche se<br />

meno evidente è altrettanto importante l’invalidazione dei certificati emessi al<br />

tempo t0 < t1 (quindi di tutti i certificati). Infatti, dopo la compromissione<br />

della CA, l’attaccante potrebbe retrodatare l’emissione di un CSR (all’istante<br />

t ′ 0), emettere un certificato a t ′′<br />

0 ed infine firmare un documento all’istante t ′′′<br />

0<br />

(con t ′ 0 < t ′′<br />

0 < t ′′′<br />

0 < t1). Tale documento, se non venissero invalidati tutti i<br />

certificati emessi dalla CA, avrebbe piena validità <strong>per</strong> la PKI in quanto non<br />

sarebbe possib<strong>il</strong>e distinguere <strong>il</strong> certificato creato al tempo t ′′<br />

0 (compromesso) da<br />

un qualunque altro certificato valido. Ovviamente questo tipo di attacco non è<br />

attuab<strong>il</strong>e <strong>per</strong> servizi come l’autenticazione, nei quali è immediata (e condivisa<br />

fra le parti) la validazione dell’istante temporale in cui avviene l’azione.<br />

3.4.2 OpenID<br />

OpenID è uno standard tecnologico a<strong>per</strong>to, non proprietario e <strong>il</strong> cui obiettivo<br />

è quello di creare un livello di autenticazione <strong>Web</strong> assegnando all’utente <strong>una</strong><br />

singola identità digitale. Si tratta di un’architettura (basata sull’infrastruttura<br />

Internet già esistente) che semplifica le o<strong>per</strong>azioni di login all’utente, in quanto<br />

elimina la necessità di creare username multipli <strong>per</strong> accedere a diversi siti <strong>Web</strong>.<br />

Un utente che accede ad un sito che adotta OpenID, non ha bisogno di creare<br />

username e password specifici <strong>per</strong> quel sito (e quindi detenuti da esso), ma<br />

ha solo bisogno di essere registrato con un qualsiasi OpenID Identity Provider<br />

(IdP). Poiché OpenID è decentralizzato, non c’è bisogno di ness<strong>una</strong> autorità<br />

centrale che approvi o registri gli IdP ed i siti <strong>Web</strong> che adottano lo standard.<br />

Un utente può scegliere liberamente quale IdP ut<strong>il</strong>izzare e qualora decidesse di<br />

cambiarlo può mantenere <strong>il</strong> suo identificatore. Ad oggi sempre più siti <strong>Web</strong> stanno<br />

adottando questo standard, infatti organizzazioni come AOL, BBC, Google,<br />

IBM, Micros<strong>of</strong>t, MySpace, Orange, VerySign, Yandex, Yahoo! sono già degli<br />

IdP e qualche migliaio di siti <strong>Web</strong> ne supportano <strong>il</strong> login. La OpenID Foundation<br />

(OIF), un’organizzazione senza scopo di lucro, è stata realizzata al fine di<br />

aiutare la gestione di copyright, marchi, marketing ed altre attività inerenti la<br />

comunità OpenID, ed <strong>il</strong> suo obiettivo è tutelare OpenID.<br />

Il processo di autenticazione OpenID<br />

Prima di descrivere in dettaglio <strong>il</strong> processo di autenticazione tramite OpenID,<br />

è opportuno definire <strong>il</strong> glossario di base dei termini ut<strong>il</strong>izzati nella specifica:<br />

• End-user: l’utente che vuole autenticare la sua identità su un sito.<br />

• Identificatore: la URL o l’XRI scelto dall’end-user come suo identificatore<br />

OpenID.<br />

90


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• OpenID Identity Provider (OP) o Identity Provider (IdP): un service provider<br />

che <strong>of</strong>fre <strong>il</strong> servizio di registrazione di URL o di XRI OpenID e<br />

effettua l’o<strong>per</strong>azione di autenticazione OpenID.<br />

• Relying Party (RP): un’applicazione <strong>Web</strong> che vuole verificare l’identificatore<br />

dell’end-user.<br />

• OP Endpoint URL: è la URL ricavata dal RP con un o<strong>per</strong>azione di<br />

“discovery” sull’identificatore fornito dall’utente.<br />

• User-agent: <strong>il</strong> programma (<strong>per</strong> esempio un browser) che l’end-user ut<strong>il</strong>izza<br />

<strong>per</strong> accedere all’OP e al RP.<br />

Con queste keyword, è ora possib<strong>il</strong>e descrivere in dettaglio <strong>il</strong> processo di<br />

autenticazione. Un sito <strong>Web</strong> RP (es. www.wishlistr.com) mostra un form<br />

OpenID login da qualche parte nella pagina. Diversamente da un tipico form<br />

di login con i campi di username e password, un form OpenID ha soltanto<br />

un campo <strong>per</strong> l’inserimento dell’identificatore OpenID (o del nome del provider)<br />

dell’end-user. Va evidenziato come questo standard, in quanto a<strong>per</strong>to<br />

e non proprietario, <strong>per</strong>mette ad un qualunque utente che sia proprietario di<br />

un dominio (come ad esempio un blog <strong>per</strong>sonale o <strong>una</strong> homepage) di usare<br />

la propria URL come identificatore OpenID inserendo in HTML un tag OpenID<br />

che segue le specifiche [Fit07]; oppure più semplicemente può registrare<br />

un identificatore OpenID tramite un OP, quest’ultimo <strong>of</strong>fre infatti la possib<strong>il</strong>ità<br />

di creare un XRI o un URL (tipicamente di terzo livello) <strong>per</strong> l’end-user<br />

che sarà automaticamente configurato <strong>per</strong> <strong>il</strong> servizio di autenticazione OpenID.<br />

Un end-user, che avrà quindi precedentemente registrato un identificatore OpenID<br />

(es. me.yahoo.com/a/OIzLz9V.0cnD51hKEuSK.kFM<strong>of</strong>iyuNZZlQ-- nel caso<br />

in cui l’identificatore sia <strong>una</strong> URL) con un OP (es. yahoo.com), nel momento<br />

in cui visita <strong>il</strong> sito <strong>Web</strong> RP (es. www.wishlistr.com) digita <strong>il</strong> suo identificatore<br />

nel form OpenID login. Il sito <strong>Web</strong> RP a questo punto esegue <strong>il</strong> processo di<br />

discovery sull’identificatore OpenID dell’utente e quindi ottiene l’OP Endpoint<br />

URL di cui l’end-user si serve <strong>per</strong> l’autenticazione. La discovery è infatti <strong>il</strong> processo<br />

in cui <strong>il</strong> RP usa l’identificatore inserito dall’utente <strong>per</strong> scoprire (discover)<br />

le informazioni necessarie <strong>per</strong> poter effettuare l’autenticazione. Con OpenID 2.0<br />

[Fit07] ci sono tre modi <strong>per</strong> effettuare la discovery:<br />

1. se l’identificatore è un XRI sarà ottenuto un documento XRDS (eXtensible<br />

Resource Descriptor Sequence) [WRM + 08] contenente le informazioni<br />

necessarie;<br />

2. se invece l’identificatore è un URL (come nell’esempio visto sopra) si ut<strong>il</strong>izzerà<br />

lo Yadis protocol [M<strong>il</strong>06], <strong>per</strong> mezzo del quale si otterrà ancora un<br />

XRDS document;<br />

91


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

3. infine se lo Yadis protocol non è in grado di restituire un documento XRDS<br />

valido, allora le informazioni necessarie saranno ottenute grazie ad <strong>una</strong><br />

discovery basata su HTML.<br />

L'end-user vuole autenticarsi<br />

3<br />

su www.whishlistr.com<br />

L'end-user è già<br />

autenticato<br />

dal provider?<br />

SI<br />

Modalità<br />

checkid_immediate<br />

CONFERMA<br />

L'end-user è autenticato<br />

me.yahoo.com/a/OIzLz9V.0cnD51hKEuSK.kFM<strong>of</strong>iyuNQ<br />

oppure yahoo.com<br />

su www.wishlistr.com<br />

NO<br />

1<br />

4<br />

Modalità<br />

checkid_setup<br />

Figura 3.5: Flowchart di autenticazione OpenID.<br />

A questo punto <strong>il</strong> RP può effettuare la procedura di autenticazione vera e<br />

propria, e ciò può essere fatto in due modi (vedi <strong>il</strong> flow chart di figura 3.5 con<br />

le schermate relative ad ogni passo <strong>il</strong>lustrate in figura 3.6 e lo state diagram di<br />

figura 3.7):<br />

1. checkid-immediate. Viene eseguita se l’end-user è già loggato sull’OP;<br />

viene chiesta all’end-user <strong>una</strong> semplice conferma <strong>per</strong> poter accedere al<br />

RP.<br />

2<br />

92


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Figura 3.6: Schermate di esempio relative ad <strong>una</strong> autenticazione OpenID.<br />

1<br />

2<br />

3<br />

4<br />

93


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

2. checkid-setup. Viene eseguita se l’end-user non è ancora loggato sull’OP<br />

oppure nel caso in cui l’autenticazione con <strong>il</strong> checkid-immediate<br />

non va a buon fine. Con questa seconda modalità, l’end-user comunica<br />

con l’OP direttamente, usando lo stesso browser ut<strong>il</strong>izzato <strong>per</strong> accedere<br />

al sito del RP. Verranno quindi richieste all’end-user le credenziali registrate<br />

sull’OP (username e password) <strong>per</strong> verificare la reale appartenenza<br />

dell’identificatore all’utente che si sta collegando al RP.<br />

enduser<br />

non autenticato<br />

su RP<br />

enduser non<br />

ancora<br />

autenticato<br />

su OP<br />

checkid_setup<br />

inserimento URL<br />

o indirizzo OP<br />

enduser già autenticato su OP<br />

inserimento URL o indirizzo OP<br />

username e password corrette<br />

errore nell' inserimento di<br />

username e/o password<br />

checkid_immediate<br />

conferma<br />

enduser<br />

autenticato<br />

Su RP<br />

Figura 3.7: State diagram della procedura di autenticazione OpenID.<br />

Opzionalmente <strong>il</strong> RP e l’OP si scambiano <strong>una</strong> chiave segreta che è usata dal<br />

OP <strong>per</strong> firmare i successivi messaggi verso <strong>il</strong> RP in modo tale che quest’ultimo<br />

potrà verificarne l’autenticità. Per questo processo viene usato <strong>il</strong> Diffie-Hellman<br />

Key Exchange [Res99]. Dopo che l’identificatore OpenID è stato identificato,<br />

l’autenticazione OpenID è riuscita e l’end-user è loggato sul sito <strong>Web</strong> RP con<br />

l’identificatore dato. È importante notare che OpenID non dispone di un proprio<br />

sistema di autenticazione, <strong>per</strong>tanto la sicurezza dell’intera o<strong>per</strong>azione è<br />

strettamente legata a quella dell’OP.<br />

Per comprendere al meglio <strong>il</strong> processo di autenticazione, può essere ut<strong>il</strong>e<br />

consultare i sequence diagram in figura 3.8 e 3.9, rispettivamente <strong>per</strong> le modalità<br />

checkid-immediate e checkid-setup.<br />

94


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Moz<strong>il</strong>la Firefox www.wishlistr.com yahoo.com<br />

User-agent Relying Party OpenID Provider<br />

1 – get<br />

2 – sign in<br />

homepage<br />

3 – richiesta di accesso<br />

5 – connessione a OP<br />

cookie 6 – continua<br />

logged-in<br />

7<br />

form<br />

redirect<br />

ack<br />

4 – scambio di chiave<br />

utente già autenticato:<br />

richiesta a procedere<br />

utente<br />

autenticato<br />

redirect<br />

Figura 3.8: Sequence diagram <strong>per</strong> l’autenticazione checkid-immediate.<br />

95


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Moz<strong>il</strong>la Firefox www.wishlistr.com yahoo.com<br />

User-agent Relying Party OpenID Provider<br />

1 – get<br />

2 – sign in<br />

cookie 6 – submit<br />

logged-in<br />

homepage<br />

3 – richiesta di accesso<br />

5 – connessione a OP<br />

7 – continua<br />

8<br />

form<br />

redirect<br />

ack<br />

4 – scambio di chiave<br />

form di login<br />

autenticazione utente<br />

utente autenticato<br />

redirect<br />

Figura 3.9: Sequence diagram <strong>per</strong> l’autenticazione checkid-setup.<br />

96


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Nella figura 3.8 è possib<strong>il</strong>e vedere i vari“passi”con cui viene effettuata la procedura<br />

di autenticazione con la modalità checkid-immediate (cioè supponendo<br />

che la fase di login con <strong>il</strong> service provider sia già stata effettuata). Le varie fasi<br />

della procedura di autenticazione si basano su messaggi HTTP, e come tali prevedono<br />

un meccanismo richiesta/risposta (client/server): la parte client esegue<br />

<strong>una</strong> richiesta e la parte server restituisce la risposta. Pertanto ogni passo consisterà<br />

in uno scambio di messaggi di questo tipo (richiesta con linea continua,<br />

risposta con linea tratteggiata).<br />

1. L’user-agent fa <strong>una</strong> richiesta GET al RP, e quest’ultimo gli restituisce la<br />

pagina richiesta. L’end-user si connette <strong>per</strong>ciò alla homepage del RP.<br />

2. L’end-user che vuole autenticarsi sul RP accede all’area Sign In sulla<br />

homepage, e <strong>il</strong> RP gli presenta <strong>il</strong> form OpenID in cui inserire i dati.<br />

3. L’end-user immette l’identificatore OpenID (URL o XRI precedentemente<br />

creato sull’OP) oppure <strong>il</strong> nome dell’OP nell’apposito form presentato dal<br />

RP. Il RP reindirizza l’user-agent all’OP.<br />

4. (Opzionale) RP e OP si scambiano <strong>una</strong> chiave segreta che è usata dal OP<br />

<strong>per</strong> firmare i successivi messaggi verso <strong>il</strong> RP in modo tale che quest’ultimo<br />

potrà verificarne l’autenticità.<br />

5. Procedura di checkid-immediate. L’user-agent si collega all’OP, e viene<br />

riconosciuto da quest’ultimo (come già detto, si è assunto che la procedura<br />

di login verso l’OP sia stata già effettuata). A questo punto viene creato un<br />

cookie [KM00], cioè un f<strong>il</strong>e che viene salvato sul disco rigido della macchina<br />

in uso <strong>per</strong> tenere traccia del login effettuato dall’end-user sull’OP. L’OP<br />

invia all’user-agent la conferma <strong>per</strong> accedere al RP. È importante notare<br />

che se l’utente decidesse in questo momento di cancellare la lista dei cookie<br />

dal proprio PC, la procedura di autenticazione OpenID non potrebbe più<br />

andare a buon fine, <strong>per</strong>ché l’end-user non risulterebbe più loggato sull’OP<br />

e quindi si renderebbe necessaria l’o<strong>per</strong>azione di checkid-setup.<br />

6. L’end-user conferma di voler accedere al RP. L’OP comunica <strong>per</strong>ciò al RP<br />

che l’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere (questo chiaramente<br />

risulta trasparente all’utente); <strong>il</strong> RP risponde con un messaggio<br />

di conferma all’OP, e a questo punto l’OP reindirizza l’user-agent al sito<br />

RP, che ora gli consentirà l’accesso.<br />

7. L’end-user è ora loggato sul RP, e può interagire con esso. Da questo<br />

momento in poi tutta la comunicazione avverrà tra l’end-user (autenticato)<br />

ed <strong>il</strong> RP.<br />

Finora è stato ipotizzato che l’end-user fosse a priori loggato sull’OP o che<br />

non ci fossero errori durante la procedura, <strong>per</strong> esempio cancellazioni di cookie.<br />

97


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Se invece l’utente non è ancora loggato sull’OP o si verifica l’errore sopra descritto,<br />

allora si renderà necessaria la modalità di checkid-setup. La procedura<br />

di autenticazione con questa modalità è mostrata in figura 3.9.<br />

Dall’analisi effettuata si può notare che fino al passo 4 la procedura è praticamente<br />

identica a quella appena considerata, <strong>per</strong>tanto saranno descritte solamente<br />

le fasi successive a partire dalla 5.<br />

1. Procedura di checkid-setup. L’user-agent si collega all’OP, e quest’ultimo<br />

gli presenta <strong>il</strong> form in cui l’end-user dovrà inserire username e password<br />

di accesso.<br />

2. L’end-user immette nell’apposito form le proprie credenziali, ed effettua<br />

<strong>per</strong>ciò <strong>il</strong> login sull’OP. Anche in questo caso viene creato <strong>il</strong> cookie<br />

<strong>per</strong> tenere traccia delle informazioni relative all’utente. L’OP presenta<br />

all’user-agent <strong>una</strong> richiesta di conferma <strong>per</strong> accedere al RP.<br />

3. L’end-user conferma di voler accedere al RP. L’OP comunica <strong>per</strong>ciò al<br />

RP che l’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere; <strong>il</strong> RP<br />

risponde con un messaggio di conferma all’OP, e a questo punto l’OP<br />

reindirizza l’user-agent al sito RP, che ora gli consentirà l’accesso.<br />

4. L’end-user è ora loggato sul RP, e può interagire con esso.<br />

È importante notare che la procedura di autenticazione appena mostrata<br />

nei sequence diagram, è <strong>una</strong> sorta di “linea guida” alla quale si devono attenere<br />

le tre parti; vale a dire che da un punto di vista logico devono essere sempre<br />

seguiti i passi sopra descritti <strong>per</strong> <strong>per</strong>mettere l’autenticazione dell’end-user sul<br />

RP, ma nell’implementazione pratica le parti potrebbero agire in modo diverso.<br />

Per esempio dopo la conferma d’accesso (vedi passo 7), l’OP comunica al RP che<br />

l’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere; <strong>per</strong>ò se a questo punto<br />

l’OP comunicasse direttamente con l’end-user fornendogli l’autorizzazione <strong>per</strong><br />

l’accesso al RP, si potrebbe arrivare direttamente al passo 8, senza <strong>il</strong> bisogno<br />

dei messaggi “utente autenticato” e “ack” visib<strong>il</strong>i in figura 3.9. Tecnicamente<br />

l’implementazione della procedura è fatta in modo diverso, ma da un punto di<br />

vista prettamente logico non cambia nulla. I vari RP e OP sono <strong>per</strong>tanto liberi<br />

riguardo all’implementazione del sistema di autenticazione OpenID, purché non<br />

ne vadano a cambiare la logica.<br />

Punti critici di OpenID<br />

Analizzando <strong>il</strong> funzionamento dell’autenticazione OpenID si possono r<strong>il</strong>evare<br />

alcune debolezze e vulnerab<strong>il</strong>ità <strong>per</strong> quanto riguarda la sicurezza, quindi<br />

potrebbe essere soggetto a vari tipi di attacchi.<br />

98


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• Attacco Eavesdropping: consiste nell’intercettazione fraudolenta di dati<br />

che transitano in <strong>una</strong> rete telematica. Esistono dei s<strong>of</strong>tware che sono in<br />

grado di intercettare la procedura di autenticazione a livello di trasporto<br />

ed effettuare uno sniffing delle informazioni necessarie al login. Queste<br />

informazioni possono essere ut<strong>il</strong>izzate in seguito dall’attaccante <strong>per</strong> effettuare<br />

<strong>una</strong> non lecita autenticazione. Questo tipo di attacco può essere<br />

prevenuto effettuando un trasporto criptato.<br />

• Attacco Man-in-the-Middle: è un attacco nel quale l’attaccante è in<br />

grado di leggere o modificare messaggi tra due parti senza che ness<strong>una</strong><br />

delle due si renda conto del fatto che <strong>il</strong> collegamento è stato compromesso.<br />

Un attaccante può fingersi l’OP dell’utente e quindi entrare in possesso<br />

delle sue credenziali senza che quest’ultimo se ne accorga. Un metodo <strong>per</strong><br />

prevenire questo tipo di attacco è usare la firma digitale e protocolli di<br />

crittografia <strong>per</strong> creare un canale sicuro <strong>per</strong> i messaggi scambiati.<br />

• Attacco Denial <strong>of</strong> Service: In questo tipo di attacco si cerca di portare<br />

<strong>il</strong> funzionamento di un sistema informatico che fornisce un servizio al limite<br />

delle prestazioni, fino a renderlo non più in grado di erogare <strong>il</strong> servizio<br />

stesso. Nel protocollo OpenID non c’è ness<strong>una</strong> misura di sicurezza che<br />

<strong>per</strong>metta di capire se <strong>una</strong> richiesta di autenticazione è finalizzata a questo<br />

tipo di attacco, quindi un attaccante che si finge un RP potrebbe inviare<br />

molte richieste ad un OP, così da saturarne le risorse. Un metodo efficace<br />

che <strong>per</strong>mette ad un OP di difendersi è usare tecniche di rate-limiting a<br />

livello trasporto.<br />

• Phishing: è un’attività <strong>il</strong>legale ut<strong>il</strong>izzata da un’attaccante <strong>per</strong> ottenere<br />

l’accesso ad informazioni <strong>per</strong>sonali soprattutto tramite messaggi fasulli di<br />

posta elettronica (che imitano ed esempio loghi ufficiali) o contatti telefonici.<br />

L’utente viene così ingannato e portato a rivelare dati <strong>per</strong>sonali,<br />

codici di identificazione, eccetera. Gli OP dovrebbero <strong>per</strong>ciò educare i<br />

loro utenti in modo da difendersi da questo tipo di attacchi; inoltre potrebbero<br />

fornire agli utenti un plug-in <strong>per</strong> aggiungere un <strong>per</strong>sonale sig<strong>il</strong>lo<br />

di sicurezza che appaia tutte le volte che si tenti di accedere al provider.<br />

Come detto precedentemente, OpenID è decentralizzato. Se da <strong>una</strong> parte<br />

questo rende libero l’utente circa la scelta dell’OP a cui affidare i suoi dati,<br />

dall’altra aumenta la complessità e la vulnerab<strong>il</strong>ità del sistema, infatti la responsab<strong>il</strong>ità<br />

di “qualità” dell’autenticazione è spostata verso l’end-user (nella<br />

scelta dell’OP).<br />

99


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

3.4.3 Kerberos<br />

Kerberos [Zap06, Gar03, NYHR05] è un servizio di autenticazione sv<strong>il</strong>uppato<br />

a partire dalla metà degli anni ’80 al Massachusetts Institute <strong>of</strong> Technology<br />

(MIT) come parte di un progetto più ampio denominato Project Athena<br />

[MIT06]. Il suo scopo era quello di <strong>per</strong>mettere ad utenti e servizi di effettuare<br />

<strong>una</strong> mutua autenticazione di tipo single sign-on in maniera rapida e sicura.<br />

Terminologia e concetti<br />

Kerberos è un sistema complesso e, in quanto tale, sono molti gli elementi<br />

che lo costituiscono ed i concetti su cui è costruito. In questo paragrafo viene<br />

descritto tutto ciò che concorre al suo funzionamento in modo da semplificarne<br />

la trattazione in quello seguente.<br />

Reami, nomi principali e istanze. Ogni installazione di Kerberos definisce<br />

un ambito amministrativo, distinto da ogni altra installazione. Questo ambito<br />

è chiamato reame.<br />

Ogni entità in <strong>una</strong> rete Kerberos sia essa un client, un utente, un servizio o la<br />

macchina che lo ospita deve avere <strong>una</strong> identità all’interno del reame che, secondo<br />

la nomenclatura del protocollo, viene definita principal o nome principale. Ad<br />

ogni identità è inoltre associata <strong>una</strong> chiave a lungo termine. Ciò <strong>per</strong> <strong>per</strong>mettere<br />

<strong>una</strong> mutua autenticazione in ogni connessione. Ogni nome principale è unico<br />

globalmente e, <strong>per</strong> fac<strong>il</strong>itarne la gestione, è costituito da più parti secondo <strong>una</strong><br />

struttura gerarchica molto sim<strong>il</strong>e a quella dei domini. Inizia con <strong>il</strong> nome utente<br />

o <strong>il</strong> nome del servizio e termina con <strong>il</strong> nome del reame a cui appartiene. Il nome<br />

del reame è introdotto dal simbolo “@”. Fra i due è presente un campo opzionale<br />

detto istanza che può essere usato in due situazioni: <strong>per</strong> creare principal speciali<br />

ad uso amministrativo o, come si vedrà più avanti, <strong>per</strong> <strong>il</strong> principal di un servizio.<br />

Questi due elementi, considerati insieme, devono essere unici all’interno di un<br />

reame.<br />

Nel caso di un host <strong>il</strong> campo username viene impostato ad “host”.<br />

Per distinguere i principal di servizi uguali, ma su macchine differenti, viene<br />

riempito <strong>il</strong> campo istanza con l’hostname della macchina che lo ospita.<br />

È bene tenere presente che lo stesso sistema Kerberos, <strong>per</strong> <strong>per</strong>mettere lo<br />

svolgimento della procedura di autenticazione, deve fornire dei servizi, ognuno<br />

provvisto del proprio principal.<br />

La sintassi completa <strong>per</strong> i nomi principali è la seguente:<br />

component[/component][/component]...@REALM<br />

che all’atto pratico può risultare:<br />

username[/istance]...@REALM<br />

100


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

service/fully-qualified-domain-name...@REALM<br />

Le chiavi. Tutte le chiavi segrete sono condivise da almeno due entità: l’utente<br />

o <strong>il</strong> servizio e <strong>il</strong> Key Distribution Center che sarà descritto in seguito. Le<br />

chiavi segrete sono <strong>per</strong>ò, in generale, delle stringhe alfanumeriche che devono<br />

essere trasformate <strong>per</strong> poter essere usate come chiavi crittografiche. Si ut<strong>il</strong>izza<br />

quindi la funzione string2key che applica alla chiave segreta delle trasformazioni<br />

al fine di ottenere <strong>una</strong> serie di cifre. Trattandosi, nell’insieme, di <strong>una</strong> trasformazione<br />

non invertib<strong>il</strong>e è matematicamente impossib<strong>il</strong>e risalire alla password che<br />

ha generato la chiave crittografica. La parte più importante di questa trasformazione<br />

è l’aggiunta del “key salt”. Con questo termine si intende <strong>una</strong> sequenza<br />

di caratteri che viene concatenata alla parola chiave prima di applicare la funzione<br />

hash <strong>per</strong> rendere più particolare la stessa. In Kerberos 5 <strong>il</strong> key salt di<br />

default è rappresentato dal nome del reame. In questo modo se un utente ut<strong>il</strong>izza<br />

la stessa password in due reami diversi, avrà comunque generato due chiavi<br />

crittografiche diverse. La compromissione di <strong>una</strong> delle due chiavi non porterà<br />

automaticamente alla compromissione dell’altra.<br />

Dato che le entità sulla rete possono cambiare la propria password deve<br />

esistere un modo <strong>per</strong> determinare quale di queste deve essere considerata <strong>per</strong><br />

accordare l’accesso ai servizi. È stato quindi definito <strong>il</strong> Key Version Number<br />

(kvno). Quando un utente cambia la propria password <strong>il</strong> kvno viene incrementato<br />

di <strong>una</strong> unità. La stessa cosa accade, ovviamente, se è un servizio a farlo;<br />

in questo caso <strong>il</strong> kvno acquista maggiore importanza in quanto, <strong>per</strong>ché i servizi<br />

riescano a interpretare i messaggi degli utenti, sia la chiave crittografica sia <strong>il</strong><br />

kvno devono corrispondere ai valori memorizzati nel database di Kerberos.<br />

Key Distribution Center. Il Key Distribution Center (KDC) consiste di tre<br />

parti logicamente distinte: un database dei principal e delle relative chiavi, l’Authentication<br />

Server (AS) e <strong>il</strong> Ticket Granting Server. Questi tre elementi, pur<br />

essendo logicamente distinti sono di solito implementati nello stesso programma.<br />

Ogni reame deve avere almeno un KDC e, vista la notevole importanza<br />

che ricoprono le informazioni che conserva, è buona norma che esista nella rete<br />

<strong>una</strong> macchina esclusivamente adibita ad ospitarlo. Il KDC contiene, infatti, al<br />

suo interno un database dei principal e dei segreti delle entità del reame e, a<br />

seconda della implementazione esaminata, anche altre informazioni relative agli<br />

utenti. Queste possono venir memorizzate su un database locale nel f<strong>il</strong>esystem<br />

del KDC stesso, come l’implementazione del MIT ha scelto, o anche con servizi<br />

di directory.<br />

Kerberos <strong>per</strong>mette di impostare dei KDC di tipo slave che replicano in tutto<br />

e <strong>per</strong> tutto <strong>il</strong> funzionamento del servizio master. Ciò che li differenzia sono le<br />

o<strong>per</strong>azioni che possono essere effettuate sui database degli accessi: è possib<strong>il</strong>e<br />

accedere ai database dei server slave esclusivamente in sola lettura. Tutte le<br />

101


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

o<strong>per</strong>azioni di modifica devono necessariamente essere svolte sul database master<br />

e, solo in un secondo momento, sarà possib<strong>il</strong>e effettuarne la propagazione<br />

ai database slave. In questo modo qualora <strong>il</strong> KDC master fosse inaccessib<strong>il</strong>e<br />

sarebbe sempre possib<strong>il</strong>e ottenere nuovi ticket attraverso i KDC slave. Il protocollo<br />

non definisce <strong>il</strong> meccanismo di propagazione delle modifiche quindi in ogni<br />

realizzazione sono state sv<strong>il</strong>uppate soluzioni ad-hoc.<br />

L’Autentication Server r<strong>il</strong>ascia un Ticket Granting Ticket (TGT) crittografato<br />

ai client che vogliono autenticarsi verso <strong>il</strong> reame Kerberos. Non è necessario<br />

che <strong>il</strong> client dimostri la sua identità all’AS in quanto <strong>il</strong> TGT, essendo crittografato<br />

con la chiave segreta dell’utente, risulterebbe inut<strong>il</strong>izzab<strong>il</strong>e da chiunque<br />

altro. Una volta decrittato, <strong>il</strong> TGT rappresenta l’elemento fondamentale <strong>per</strong><br />

<strong>per</strong>mettere un’autenticazione di tipo single sign-on: non sarà infatti più necessario<br />

inserire la propria password a lungo termine fino alla scadenza del TGT<br />

in uso.<br />

Il Ticket Granting Server (TGS), invece, è un servizio che r<strong>il</strong>ascia ai client<br />

dei ticket specifici <strong>per</strong> un servizio della rete, i service-ticket. Il client, quando<br />

effettua la richiesta di un servizio, deve fornire due oggetti al TGS: <strong>il</strong> principal<br />

del servizio che vuole contattare e <strong>il</strong> TGT che gli è stato fornito dall’AS al<br />

momento dell’autenticazione. Il TGS, <strong>una</strong> volta verificata la validità del TGT,<br />

<strong>per</strong> fare ciò è sufficiente che controlli che sia stata criptata con la chiave dell’AS,<br />

risponde con <strong>il</strong> service-ticket richiesto.<br />

I Ticket. Come appena visto, Kerberos introduce <strong>il</strong> concetto di ticket. Concettualmente<br />

si tratta di un dato strutturato crittografato che contiene al suo<br />

interno <strong>una</strong> chiave crittografica diversa <strong>per</strong> ogni sessione, la chiave di sessione<br />

e altri campi tra cui alcuni flag <strong>per</strong> definire la modalità di funzionamento del<br />

ticket stesso. I ticket hanno due finalità: confermare l’identità degli end-point<br />

della comunicazione e fornire loro la chiave di sessione. Questa chiave ha <strong>una</strong><br />

validità relativamente breve che viene calcolata in base al trade-<strong>of</strong>f tra <strong>il</strong> danno<br />

causato da un possib<strong>il</strong>e furto delle credenziali e la convenienza portata dal single<br />

sign-on. Tipicamente è impostata tra le 10 e le 24 ore.<br />

I campi più importanti che Kerberos include in un ticket sono:<br />

• <strong>il</strong> principal del richiedente;<br />

• <strong>il</strong> principal del servizio richiesto;<br />

• la finestra temporale di validità del ticket stesso;<br />

• <strong>una</strong> lista degli indirizzi IP da cui <strong>il</strong> ticket può essere ut<strong>il</strong>izzato;<br />

• la chiave crittografica condivisa tra utente e servizio <strong>per</strong> renderne possib<strong>il</strong>e<br />

la comunicazione (la chiave di sessione).<br />

102


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Alcuni campi, come la finestra temporale o la chiave di sessione, sono riempiti<br />

dal KDC <strong>per</strong> ovvi motivi di sicurezza; altri vengono impostati dal client <strong>per</strong><br />

esempio in relazione al servizio contattato o alle modalità con cui vuole ottenere<br />

l’accesso.<br />

Ogni ticket che <strong>il</strong> KDC genera deve essere crittografato <strong>per</strong> impedire che un<br />

attaccante possa modificarlo, <strong>per</strong> esempio, <strong>per</strong> allargare la finestra di validità di<br />

un ticket rubato.<br />

Le credenziali ottenute devono ovviamente essere mantenute in <strong>una</strong> cache,<br />

chiamata indifferentemente ticket cache che credentials cache, che può essere<br />

implementata in più modi. Nella versione sv<strong>il</strong>uppata dal MIT è stato scelto,<br />

<strong>per</strong> fac<strong>il</strong>itare la portab<strong>il</strong>ità, di salvare <strong>il</strong> contenuto dei ticket in un f<strong>il</strong>e sul disco<br />

fisso. Questo metodo è <strong>per</strong>ò poco flessib<strong>il</strong>e e porta a problemi di sicurezza. Una<br />

<strong>soluzione</strong> migliore è quella di salvare le credenziali in memoria <strong>per</strong> garantire la<br />

loro distruzione al termine della sessione Kerberos.<br />

Il funzionamento di Kerberos<br />

Fin ora sono stati presentati tutti i concetti che <strong>per</strong>mettono di descrivere <strong>il</strong><br />

funzionamento di Kerberos. Varrà ora descritto nel dettaglio <strong>il</strong> funzionamento<br />

del protocollo di autenticazione.<br />

L’autenticazione Intra-Realm. L’idea alla base di Kerberos è quella di<br />

creare un’infrastruttura <strong>il</strong> cui unico scopo sia l’autenticazione. In questo modo<br />

i servizi non devono preoccuparsi di mantenere informazioni riguardo gli utenti<br />

e i <strong>per</strong>messi ad essi associati; sia l’utente che i servizi, <strong>per</strong>ò, devono necessariamente<br />

fidarsi dell’Authentication Server che ha <strong>il</strong> compito di “presentare” gli<br />

agenti l’un l’altro; <strong>per</strong> fare ciò sia l’utente che i servizi devono condividere <strong>una</strong><br />

chiave segreta con l’AS; queste sono chiamate chiavi a lungo termine dato che<br />

hanno <strong>una</strong> validità che può arrivare a settimane o addirittura mesi.<br />

Si consideri ora la situazione in cui un client C voglia accedere ad un servizio<br />

remoto S; <strong>il</strong> processo di autenticazione può essere suddiviso in tre fasi distinte<br />

[CJ05] ed <strong>il</strong>lustrate in figura 3.10.<br />

• Authentication Service Exchange (C ⇐⇒ AS). Questo scambio<br />

di messaggi avviene quando l’utente accede <strong>per</strong> la prima volta alla rete<br />

Kerberos.<br />

Il processo client C genera un nonce 4 n1 e lo invia all’AS insieme al proprio<br />

nome e al nome del TGS. Una volta riconosciuto <strong>il</strong> client e quindi, anche se<br />

indirettamente, l’utente, l’AS risponde con un messaggio crittografato in<br />

due parti: <strong>il</strong> TGT, che viene memorizzato da C <strong>per</strong> essere usato durante<br />

4 In questo contesto <strong>il</strong> termine nonce sta <strong>per</strong> “number used once”. Si tratta, di solito, di un<br />

numero casuale o pseudo-casuale ut<strong>il</strong>izzato nei protocolli di autenticazione <strong>per</strong> assicurare che<br />

vecchi messaggi non siano riut<strong>il</strong>izzati da un utente malintenzionato.<br />

103


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

tutta la sessione Kerberos <strong>per</strong> ottenere i service-ticket, e <strong>una</strong> seconda parte<br />

con cui l’AS passa a C alcuni parametri riguardanti <strong>il</strong> ticket.<br />

Il TGT, crittografato con la chiave a lungo termine del TGS, contiene al<br />

suo interno <strong>una</strong> chiave di autenticazione AK e un timestamp tk oltre al<br />

nome di C e ad altri dati in questo momento meno importatanti.<br />

La seconda parte, crittografata stavolta con la chiave a lungo termine<br />

del client, contiene la stessa chiave di autenticazione AK che, da questo<br />

momento, verrà usata in tutte le seguenti comunicazioni con <strong>il</strong> TGS in<br />

modo da non esporre la ben più preziosa chiave a lungo termine.<br />

Il timestamp presente in entrambe le parti del messaggio assicura che <strong>il</strong><br />

ticket sia stato generato recentemente dato che tutte le macchine della rete<br />

sono sincronizzate su un time server comune. Il nonce n1 serve a legare la<br />

risposta dell’AS con la richiesta del client.<br />

• Ticket Granting Exchange (C ⇐⇒ TGS). Questo scambio di messaggi<br />

avviene quando un utente accede <strong>per</strong> la prima volta ad un servizio.<br />

C trasmette al TGS un messaggio in due parti: la prima parte contiene <strong>il</strong><br />

TGT precedentemente memorizzato, <strong>il</strong> nome del servizio cui l’utente vuole<br />

accedere e un nonce n2; la seconda parte, detta authenticator, contiene <strong>il</strong><br />

nome del client e un timestamp tc ed è crittografato con la chiave AK.<br />

L’authenticator serve <strong>per</strong> provare al TGS che <strong>il</strong> client conosce la chiave di<br />

autenticazione AK.<br />

Una volta autenticato C e verificato <strong>il</strong> suo livello di accesso, <strong>il</strong> TGS risponde<br />

con un nuovo messaggio, sempre suddiviso in due parti: entrambe<br />

contengono <strong>il</strong> nome del client, un timestamp tT GS e <strong>una</strong> nuova chiave,<br />

creata <strong>per</strong> l’imminente comunicazione tra client e server, chiamata chiave<br />

di sessione. Ciò che differenzia le due parti è la chiave crittografica usata<br />

<strong>per</strong> “sig<strong>il</strong>lare” <strong>il</strong> messaggio: la prima parte viene criptata con la chiave a<br />

lungo termine del servizio e prende <strong>il</strong> nome di service-ticket; la seconda<br />

con la chiave di autenticazione AK.<br />

Il client memorizza <strong>il</strong> service-ticket.<br />

• Client-Server Exchange (C ⇐⇒ S). Questo scambio di messaggi<br />

avviene quando <strong>il</strong> client inizia <strong>una</strong> nuova sessione con <strong>il</strong> server.<br />

A questo punto C possiede <strong>il</strong> service-ticket e può contattare S inviando<br />

tale ticket al suo interlocutore, insieme ad un authenticator costruito come<br />

quello precedentemente descritto. Entrambi sono i soli in grado di estrarre<br />

dai messaggi la chiave di sessione necessaria <strong>per</strong> comunicare in sicurezza<br />

e hanno <strong>una</strong> conferma dell’identità dell’interlocutore.<br />

104


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Il server può, in base alle preferenze dell’amministratore del sistema, rispondere<br />

o meno al client <strong>per</strong> esempio inviando <strong>il</strong> timestamp t ′<br />

C che C<br />

aveva inviato nella sua richiesta, crittografandolo con la chiave di sessione.<br />

1<br />

2<br />

3<br />

4<br />

5<br />

6<br />

C<br />

1<br />

{ n 1 , I D C , I D T G S }<br />

TGT = { I D C , t k , AK , ... } KT G S ; { AK , … } KC<br />

{ TGT, n 2 , I D S } ; authenticator = { I D C , t C } A K<br />

service ticket = { I D C , t T G S , SK } KS ; { I D C , t T G S , SK } A K<br />

service ticket ; authenticator = { I D C , t ' C } A K<br />

{ t ' C } S K<br />

2<br />

AS TGS<br />

3<br />

5<br />

Figura 3.10: Autenticazione intra-realm in Kerberos.<br />

Ora può aver inizio la comunicazione con <strong>il</strong> servizio <strong>per</strong> <strong>il</strong> quale è stato<br />

contattato <strong>il</strong> server.<br />

Come descritto poco sopra, nella prima fase del processo di autenticazione,<br />

l’AS riconosce <strong>il</strong> client C esclusivamente dal nome inserito nel primo messaggio<br />

generato. Per ragioni di sicurezza che verranno analizzate in seguito è stato<br />

introdotto con Kerberos 5 un meccanismo chiamato pre-autenticazione: l’utente<br />

deve in qualche modo provare la propria identità <strong>per</strong>ché <strong>il</strong> KDC generi <strong>il</strong> ticket<br />

<strong>per</strong> quel particolare principal. Esistono vari tipi di pre-autenticazione ma solo<br />

<strong>il</strong> metodo denominato encrypted timestamp è implementato comunemente.<br />

La pre-autenticazione è controllata dal KDC. Se un utente cerca di ottenere<br />

un TGT, come descritto precedentemente nella fase denominata“Authentication<br />

Service Exchange”, e <strong>il</strong> KDC è impostato <strong>per</strong> richiedere la pre-autenticazione,<br />

quest’ultimo risponderà con un messaggio di errore. Questo messaggio comunica<br />

al client che è necessario pre-autenticarsi <strong>per</strong> ottenere un ticket. Quindi la<br />

6<br />

4<br />

S<br />

105


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

richiesta verrà ripetuta ma aggiungendo al messaggio i dati di pre-autenticazione<br />

richiesti. Nel caso menzionato (encrypted timestamp), questi consistono di un<br />

timestamp firmato con la chiave privata dell’utente. Se <strong>il</strong> KDC è in grado<br />

di decifrarlo, ut<strong>il</strong>izzando la chiave pubblica dell’utente a lui nota, risponde al<br />

client inviandogli <strong>il</strong> TGT altrimenti invierà un nuovo messaggio di errore <strong>per</strong><br />

comunicare all’interlocutore <strong>il</strong> fallimento della pre-autenticazione.<br />

L’autenticazione Cross-Realm. Fino qui è stato esaminato uno scenario<br />

in cui sia presente un solo AS ed un solo TGS, che possono o meno risiedere<br />

sulla stessa macchina. Finchè <strong>il</strong> numero delle richieste si mantiene basso non<br />

c’è nessun problema ma col crescere della rete, e quindi anche del numero delle<br />

richieste, <strong>il</strong> AS e <strong>il</strong> TGS diventano <strong>il</strong> collo di bottiglia nel processo di autenticazione.<br />

In breve <strong>il</strong> sistema, così come è stato descritto fin ora, non è scalab<strong>il</strong>e. Per<br />

questa ragione può essere sensato suddividere la rete in aree. D’altra parte <strong>una</strong><br />

struttura sim<strong>il</strong>e può essere <strong>il</strong> risultato di <strong>una</strong> integrazione di reti già esistenti<br />

e separate su base organizzativa. Nella terminologia di Kerberos queste aree<br />

prendono <strong>il</strong> nome di reame. Ogni reame consiste di client, servizi e di un KDC<br />

proprio.<br />

Per <strong>per</strong>mettere un’autenticazione cross-realm, cioè <strong>per</strong> <strong>per</strong>mettere che utenti<br />

in un certo reame possano usufruire di servizi presenti in altri reami, è necessario<br />

registrare <strong>il</strong> KDC afferente al reame del servizio come un server speciale nel<br />

reame dell’utente ed usare <strong>una</strong> variante del protocollo intra-realm. In questo<br />

modo viene aggiunto un ulteriore livello che rende più indiretta la procedura di<br />

autenticazione.<br />

Il caso più semplice che è possib<strong>il</strong>e prendere in esame coinvolge un client C<br />

nel reame R1 e un server S nel reame Rn. Il KDC di Rn deve essere registrato<br />

come un server speciale in R1. Il client ottiene un TGT in R1, come visto<br />

precedentemente, e un service-ticket <strong>per</strong> <strong>il</strong> KDC di Rn che viene visto come un<br />

servizio locale in R1. Il service-ticket ha lo stesso formato di un TGT <strong>per</strong> i client<br />

di Rn e come tale viene gestito dal KDC di Rn <strong>per</strong> fornire a C un service-ticket<br />

<strong>per</strong> <strong>il</strong> servizio S. In pratica <strong>il</strong> KDC di R1 agisce come client nei confronti del<br />

KDC del reame remoto. Questo è <strong>il</strong> massimo che può essere ottenuto con la<br />

versione 4 di Kerberos. Con la versione 5 è stata aggiunta la possib<strong>il</strong>ità di organizzare<br />

i reami in <strong>una</strong> vera e propria struttura gerarchica. Sarà possib<strong>il</strong>e quindi<br />

che un client C nel reame R1 voglia accedere ad un servizio S nel reame Rn ma<br />

che stavolta non sia direttamente disponib<strong>il</strong>e in R1 <strong>il</strong> server “di collegamento”<br />

<strong>per</strong> Rn descritto poco sopra. Sarà necessario quindi attraversare in successione<br />

dei reami intermedi R2,...,Rn−1 a patto <strong>per</strong>ò che sia stata precedentemente<br />

definita <strong>una</strong> aff<strong>il</strong>iazione tra R2 ed R3, tra R3 ed R4 e così via fino ad Rn.<br />

La lista dei KDC attraversati è chiamata authentication path di C <strong>per</strong> S. I<br />

reami attraversati vengono definiti transited realms e i loro nomi sono registrati<br />

106


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

nel ticket in modo da informare <strong>il</strong> servizio dei passi effettuati nella catena di<br />

autenticazione. Ciò da la possib<strong>il</strong>ità al servizio di esaudire o meno le richieste in<br />

base ad <strong>una</strong> <strong>per</strong>sonale valutazione del grado di affidab<strong>il</strong>ità dei nodi attraversati.<br />

Resta da chiarire in che modo vengano determinati gli authentication path<br />

verso i servizi remoti. Esistono due modalità: <strong>una</strong> basata sulla gerarchia dei<br />

reami e <strong>una</strong> sulla sezione capaths del f<strong>il</strong>e di configurazione di Kerberos.<br />

La prima modalità è abbastanza semplice da realizzare: <strong>una</strong> volta organizzati<br />

i reami secondo <strong>una</strong> struttura gerarchica, del tutto sim<strong>il</strong>e a quella dei domini<br />

DNS, i client sanno implicitamente quali nodi di rete attraversare <strong>per</strong> raggiungere<br />

un determinato servizio. In questo modo <strong>per</strong>ò non si ha nessuno strumento<br />

<strong>per</strong> verificare <strong>il</strong> grado di fiducia degli host attraversati.<br />

La seconda modalità si basa sulla configurazione della sezione capaths del<br />

f<strong>il</strong>e krb5.conf presente su ogni macchina della rete Kerberos. Qui vengono definiti,<br />

<strong>per</strong> ogni servizio remoto, gli authentication path validi. Questi verranno<br />

ut<strong>il</strong>izzati dai client <strong>per</strong> determinare <strong>il</strong> corretto <strong>per</strong>corso fino ad un certo servizio<br />

remoto e dagli application server <strong>per</strong> determinare se un dato authentication path<br />

è da considerarsi valido o meno. Dato che ogni application server verifica gli<br />

authentication path usando questa sezione del f<strong>il</strong>e di configurazione la semplice<br />

aggiunta di un nuovo <strong>per</strong>corso verso un reame non sottintende ness<strong>una</strong> informazione<br />

di fiducia nei confronti degli altri. Di contro <strong>il</strong> f<strong>il</strong>e krb5.conf deve essere<br />

aggiornato manualmente su ogni host coinvolto.<br />

La figura 3.11 <strong>il</strong>lustra <strong>una</strong> sequenza di passi esemplificativa in cui un client<br />

effettua l’accesso ad un servizio in un reame diverso ut<strong>il</strong>izzando l’autenticazione<br />

cross-realm di Kerberos.<br />

Analisi della sicurezza e sv<strong>il</strong>uppi di Kerberos<br />

Non è diffic<strong>il</strong>e capire che trattare la sicurezza di un sistema complesso come<br />

Kerberos non può ridursi al semplice fatto di “proteggere <strong>il</strong> KDC”. Basti pensare<br />

che se gli utenti non pongono la dovuta cura nella scelta e nella custodia<br />

delle password tutti gli sforzi finalizzati a mantenere elevata la “sicurezza” da<br />

un punto di vista tecnico risultano assolutamente vani. In ogni caso Kerberos,<br />

essendo un sistema molto complesso, è soggetto a falle e vulnerab<strong>il</strong>ità che possono<br />

ridurne l’efficacia. Per non esulare dai fini della presente dissertazione si<br />

rimanda a [Zap06, BM90, CJ05, Gar03] <strong>per</strong> <strong>una</strong> discussione appr<strong>of</strong>ondita delle<br />

problematiche di sicurezza note di Kerberos e, eventualmente, delle possib<strong>il</strong>i<br />

strategie e/o soluzioni con <strong>il</strong> tempo proposte <strong>per</strong> ridurne o annullarne gli effetti.<br />

Inoltre in [Zap06] vengono introdotti potenziali evoluzioni del sistema come<br />

l’integrazione della tecnologia crittografica a chiave asimmetrica e l’ut<strong>il</strong>izzo delle<br />

smartcard come mezzo <strong>per</strong> evitare all’utente di dover ricordare password robuste<br />

([Gar03]).<br />

107


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

1<br />

2<br />

3<br />

4<br />

AS 1<br />

1 2<br />

4<br />

TGS 1<br />

3<br />

S 1<br />

R 1<br />

AS n<br />

S n<br />

R n<br />

TGS n<br />

A seguito della richiesta presentata all' AS 1 , <strong>il</strong> client ottiene<br />

un TGT valido<br />

Il client mostra <strong>il</strong> TGT al TGS locale, TGS 1 , <strong>il</strong> quale risponde<br />

con un service ticket <strong>per</strong> S 1 , che è in realtà costruito come<br />

un TGT valido in R n<br />

Il client mostra <strong>il</strong> TGT appena ottenuto ad S 1 , che è in realtà<br />

<strong>il</strong> TGS remoto TGS n , <strong>il</strong> quale risponde con un service ticket<br />

<strong>per</strong> S n<br />

A questo punto <strong>il</strong> client è in grado di contattare <strong>il</strong> servizio<br />

remoto S n<br />

Figura 3.11: Autenticazione cross-realm in Kerberos.<br />

3.4.4 Extensible Authentication Protocol<br />

EAP è un framework <strong>per</strong> l’autenticazione proposto da IETF definito nella<br />

RFC 5247 [ASE08] (che aggiorna la RFC 3748 [ABV + 04]). Viene principalmente<br />

ut<strong>il</strong>izzato <strong>per</strong> l’accesso a reti wireless e nella fase di handshake in connessioni<br />

punto-punto anche se <strong>il</strong> suo campo di applicazione non si limita solamente a<br />

queste casistiche.<br />

EAP non è uno specifico protocollo <strong>per</strong> l’autenticazione, bensì un framework<br />

in quanto definisce solamente <strong>il</strong> formato dei messaggi e non <strong>il</strong> loro contenuto.<br />

108


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Questo significa che <strong>of</strong>fre un set predefinito di funzionalità di base nel contesto<br />

dell’autenticazione e dei metodi <strong>per</strong> negoziare <strong>il</strong> meccanismo più adatto al contesto<br />

in essere. Tali meccanismi sono detti EAP methods ed ad oggi ne esistono<br />

oltre 40. Oltre a un elevato numero di meccanismi proprietari, oltre a quelli in<br />

fase di approvazione, IETF ne ha standardizzato un discreto numero in varie<br />

RFC. Fra questi è possib<strong>il</strong>e citare EAP-MD5, EAP-PSK, EAP-TLS, EAP-OTP,<br />

EAP-IKEv2, EAP-SIM e EAP-AKA.<br />

I meccanismi più recenti, in uso nei dispositivi NAS (Network Access Server)<br />

802.1X-compliant come gli Access Point Wireless 802.11 a/b/g, <strong>of</strong>frono, oltre<br />

all’autenticazione sicura, la negoziazione di chiavi simmetriche (PMK, Pair-wise<br />

Master Key) da ut<strong>il</strong>izzare <strong>per</strong> criptare <strong>il</strong> canale fra <strong>il</strong> NAS e <strong>il</strong> client, dopo aver<br />

instaurato la sessione a seguito dell’avvenuta autenticazione.<br />

EAP-MD5. Questo metodo, definito direttamente nella RFC 3748 [ABV + 04],<br />

<strong>of</strong>fre un livello di sicurezza minimo in quanto la funziona hash MD5 è vulnerab<strong>il</strong>e<br />

ad attacchi a dizionario, non supporta la generazione di chiavi e questo lo rende<br />

inut<strong>il</strong>izzab<strong>il</strong>e in ambienti enterprise in cui è richiesta <strong>una</strong> certa dinamicità delle<br />

configurazioni. Rispetto ad altri metodi EAP non <strong>of</strong>fre la mutua autenticazione,<br />

<strong>per</strong>mettendo di autenticare <strong>il</strong> client al server, ma non <strong>of</strong>frendo la possib<strong>il</strong>ità al<br />

client di verificare l’identità del server, esponendo i sistemi che lo ut<strong>il</strong>izzano ad<br />

attacchi di tipo man-in-the-middle.<br />

EAP-PSK. Questo metodo, definito nella RFC 4764 [BT07], <strong>of</strong>fre la mutua<br />

autenticazione fra client e server ed o<strong>per</strong>a grazie ad <strong>una</strong> chiave di sessione generata<br />

a partire da <strong>una</strong> Pre-Shared Key (PSK, chiave condivisa). Dopo l’autenticazione<br />

<strong>of</strong>fre quindi un canale sicuro su cui comunicare tanto è vero che questo<br />

metodo è stato esplicitamente progettato <strong>per</strong> l’uso su reti non sicure come le<br />

IEEE 802.11.<br />

EAP-TLS (e EAP-TTLS). EAP-Transport Layer Security, definito nella<br />

RFC 5216 [SAH08], è uno standard a<strong>per</strong>to IETF supportato dalla maggioranza<br />

dei dispositivi in commercio (almeno del settore enterprise). Questo metodo<br />

basa <strong>il</strong> proprio principio di funzionamento su <strong>una</strong> PKI (paragrafo 3.4.1) <strong>per</strong>tanto,<br />

pur <strong>of</strong>frendo un livello di sicurezza elevatissimo, paga, rispetto ad altri<br />

metodi più semplici, <strong>il</strong> maggior livello di complessità a livello <strong>infrastrutturale</strong> e<br />

l’overhead della crittografia a chiave asimmetrica.<br />

Sebbene non sia frequentemente ut<strong>il</strong>izzato è universalmente riconosciuto come<br />

uno dei metodi EAP più sicuri e supportati dai vari produttori. Il fatto che<br />

richieda un certificato digitale installato su ogni dispositivo client ne limita la<br />

diffusione <strong>per</strong> la complicazione a livello <strong>infrastrutturale</strong> che comporta ed è un<br />

chiaro esempio che spesso, parlando di sicurezza, non si cerca <strong>il</strong> meglio che lo<br />

stato dell’arte <strong>of</strong>fre, ma si opta <strong>per</strong> un certo trade-<strong>of</strong>f fra sicurezza e convenienza.<br />

109


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Per ovviare a questo inconveniente con la RFC 5281 [FBW08] come estensione<br />

di EAP-TSL è stato definito un altro protocollo detto EAP-TTSL (EAP-<br />

Tunneled Transport Layer Security). Offre un livello di sicurezza inferiore al<br />

protocollo da cui deriva, ma non richiede l’uso di un certificato in ogni client,<br />

ma solamente nel server.<br />

In <strong>una</strong> prima fase <strong>il</strong> server viene autenticato in modo sicuro dal client (grazie<br />

al certificato di cui dispone) e viene instaurato un canale sicuro. Ut<strong>il</strong>izzato<br />

quindi tale canale in client si autentica verso <strong>il</strong> server con un metodo più semplice<br />

(ad esempio <strong>una</strong> password), ma grazie al canale sicuro vengono scongiurati rischi<br />

di attacco man-in-the-middle e di sniffing della password.<br />

EAP-OTP. Questo metodo <strong>per</strong> autenticare l’utente o <strong>il</strong> dispositivo ut<strong>il</strong>izza<br />

One-Time Password (RFC 2289 [HMNS98]). Dato che <strong>of</strong>fre un livello di sicurezza<br />

poco su<strong>per</strong>iore a EAP-MD5, con <strong>il</strong> quale condivide l’impossib<strong>il</strong>ità della<br />

mutua autenticazione; è da ut<strong>il</strong>izzarsi solamente in corrispondenza di canali di<br />

comunicazione sicuri.<br />

EAP-IKEv2. EAP-IKEv2 (Internet Key Exchange Protocol version 2) è descritto<br />

nella RFC 5106 [TKP + 08] ed <strong>of</strong>fre mutua autenticazione fra EAP peer<br />

ed EAP server. Supporta varie tecniche di autenticazione basate sulle seguenti<br />

tipologie di credenziali:<br />

• chiavi asimmetriche (infrastruttura PKI);<br />

• chiavi simmetriche (stringhe di bit ad elevata entropia condivise fra server<br />

e peer);<br />

• password (stringhe di bit a bassa entropia condivise fra server e peer).<br />

È possib<strong>il</strong>e ut<strong>il</strong>izzare tipologie diverse di credenziali nelle due direzioni, ad<br />

esempio potrebbe succedere che <strong>il</strong> server si autentica con chiavi asimmetriche<br />

mentre <strong>il</strong> peer che chiavi simmetriche. Nella pratica di trovano usualmente le<br />

seguenti configurazioni:<br />

• server chiavi asimmetriche - peer chiavi asimmetriche;<br />

• server chiavi asimmetriche - peer chiavi simmetriche;<br />

• server chiavi asimmetriche - peer password;<br />

• server chiavi simmetriche - peer chiavi simmetriche.<br />

EAP-SIM e EAP-AKA. EAP for GSM Subscriber Identity (EAP-SIM)<br />

ed EAP for UMTS Authentication and Key Agreement (EAP-AKA) (descritti<br />

rispettivamente nelle RFC 4186 [HS06] e RFC 4187 [AH06]) vengono ut<strong>il</strong>izzati<br />

come metodi di autenticazione nelle reti mob<strong>il</strong>i GSM ed UMTS.<br />

110


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

3.4.5 Radius<br />

Radius (Remote Authentication Dial In User Service) [RWRS00, Rig00] è un<br />

protocollo di rete appartenente alla famiglia dei protocolli AAA. Il suo ut<strong>il</strong>izzo<br />

principale è in applicazioni di accesso alle rete o di mob<strong>il</strong>ità IP. Sv<strong>il</strong>uppato<br />

nel 1991 dalla Livingston Enterprises, è più tardi diventato uno standard di<br />

IETF. Radius è un protocollo ampiamente ut<strong>il</strong>izzato da ISP e aziende <strong>per</strong> gestire<br />

l’accesso alla rete e <strong>per</strong>ciò integrato in dispositivi di rete come router, modem,<br />

switch, eccetera. Esso definisce un’architettura client/server e ut<strong>il</strong>izza l’UDP<br />

come protocollo di trasporto. Originariamente le porte UDP assegnate a Radius<br />

erano la 1645 e la 1646, accounting ed autenticazione rispettivamente. Ad oggi<br />

la IANA (Internet Assigned Number Authority) ha ufficialmente assegnato al<br />

protocollo le porte UDP 1812 <strong>per</strong> l’autenticazione e 1813 <strong>per</strong> l’accounting. Le<br />

funzionalità <strong>of</strong>ferte sono tre:<br />

• autenticare gli utenti ed i dispositivi prima di garantirne l’accesso al servizio<br />

richiesto;<br />

• autorizzare gli utenti ed i dispositivi ad accedere al servizio richiesto, se<br />

possessori dei priv<strong>il</strong>egi necessari;<br />

• memorizzare (accounting) tutte le informazioni necessarie <strong>per</strong> tracciare<br />

l’uso dei vari servizi da parte degli utenti e dei dispositivi.<br />

Autenticazione e autorizzazione<br />

Le funzionalità di autenticazione e autorizzazione di Radius sono descritte<br />

nella RFC 2865 [RWRS00]. In figura 3.12 è mostrato un tipico scenario di<br />

gestione dell’accesso in un’azienda.<br />

L’interazione inizia quando un utente (o un dispositivo) ha la necessità di<br />

accedere ad un servizio di rete. L’utente invia <strong>una</strong> richiesta di accesso al Network<br />

Access Server (NAS) <strong>per</strong> accedere ad un determinato servizio usando le proprie<br />

credenziali. Le modalità di interazione fra client e NAS dipendono dalla specifica<br />

applicazione: ad esempio potrebbe trattarsi di <strong>una</strong> richiesta di creazione di un<br />

link punto-punto (in tal caso tutta l’interazione avviene grazie al protocollo<br />

PPP) oppure di <strong>una</strong> richiesta di accesso ad <strong>una</strong> pagina web (ut<strong>il</strong>izzando quindi<br />

HTTP).<br />

Il NAS invia un messaggio Radius di tipo Access-Request al server, ut<strong>il</strong>izzando<br />

tale protocollo <strong>per</strong> la garantire l’autorizzazione all’accesso dell’utente;<br />

tale richiesta include le credenziali di accesso, di solito username e password.<br />

Il server Radius controlla la correttezza delle informazioni immesse, verificando<br />

l’identità dell’utente. Quindi <strong>il</strong> server invia al NAS <strong>una</strong> fra le seguenti<br />

possib<strong>il</strong>i risposte:<br />

111


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• Access-Reject: all’utente è stato negato qualsiasi tipo di accesso alla rete<br />

a causa del fallimento della verifica dell’autenticazione;<br />

• Access-Challenge: vengono richieste all’utente ulteriori credenziali come<br />

<strong>una</strong> password secondaria, un PIN, eccetera;<br />

• Access-Accept: all’utente viene accordato <strong>il</strong> <strong>per</strong>messo ad accedere.<br />

In ogni caso, <strong>una</strong> volta autenticato, l’utente viene nuovamente sottoposto<br />

a controllo da parte del server Radius <strong>per</strong> accertarsi che l’utente sia<br />

autorizzato ad usare <strong>il</strong> servizio richiesto.<br />

modem<br />

Internet<br />

Access<br />

Point<br />

RAS Server<br />

VPN Server<br />

Switch con port-based<br />

Authentication<br />

Captive Portal<br />

e NAS<br />

RADIUS<br />

Server<br />

SERVIZI<br />

Figura 3.12: Scenario di accesso ad <strong>una</strong> rete tramite Radius.<br />

Per analizzare più nel dettaglio come avviene l’interazione è necessario introdurre<br />

la struttura di un generico pacchetto Radius [RWRS00] mostrata in<br />

figura 3.13.<br />

I campi che costituiscono <strong>il</strong> pacchetto vengono trasmessi da sinistra a destra.<br />

Il campo Code stab<strong>il</strong>isce la tipologia del pacchetto. I principali codici previsti<br />

sono i seguenti:<br />

• 1 = Access-Request<br />

112


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• 2 = Access-Accept<br />

• 3 = Access-Reject<br />

• 4 = Accounting-Request<br />

• 5 = Accounting-Response<br />

• 11 = Access-Challenge<br />

• 255 = riservato<br />

0 1 2 3<br />

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Code | Identifier | Length |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| |<br />

| Authenticator |<br />

| |<br />

| |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Attributes...<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-<br />

Figura 3.13: Pacchetto Radius.<br />

L’Identifier è un ottetto che <strong>per</strong>mette al client Radius di associare le risposte<br />

alle relative richieste; si noti che <strong>il</strong> protocollo non prevede un algoritmo<br />

di generazione dell’identificatore e <strong>per</strong>tanto i client normalmente usano <strong>una</strong> politica<br />

sequenziale. Il campo Length specifica la dimensione dell’intero pacchetto<br />

Radius che comprende <strong>il</strong> codice, l’identificatore, la lunghezza, l’authenticator e<br />

gli attributi opzionali. L’Authenticator, come spiegato più nel dettaglio successivamente,<br />

<strong>per</strong>mette di garantire la riservatezza della password. Infine vi è <strong>il</strong><br />

campo degli attributi, indicato con AVPs (Attribute Value Pairs), che è formato<br />

come rappresentato in figura 3.14.<br />

0 1<br />

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Type | Length | Value...<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

Esempi di attributi sono i seguenti:<br />

• 1 = User-Name;<br />

• 2 = User-Password;<br />

Figura 3.14: AVP Radius.<br />

113


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• 4 = NAS-IP-Address;<br />

• 5 = NAS-Port;<br />

• 6 = Service-Type;<br />

• 18 = Reply-Message;<br />

• 32 = NAS-Identifier;<br />

• 26 = Vendor-Specific.<br />

Detto ciò, <strong>il</strong> Radius Access-Request è quindi un pacchetto costituito da:<br />

• <strong>il</strong> campo codice (Code) pari a “1”;<br />

• l’identificatore (Identifier) generato dal client in maniera sequenziale;<br />

• <strong>il</strong> campo Length contenente la dimensione dell’intero pacchetto;<br />

• <strong>il</strong> campo Authenticator contenente <strong>una</strong> stringa di 128 bit generata in<br />

modo casuale nella quale sono (almeno) presenti gli attributi User-Name<br />

e User-Password.<br />

L’intero pacchetto viene trasmesso in chiaro eccetto <strong>il</strong> campo User-Password<br />

che viene criptato nel modo seguente: client e server condividono <strong>una</strong> chiave segreta<br />

che viene concatenata con <strong>il</strong> contenuto del campo Authenticator ed <strong>il</strong><br />

risultato viene sottoposto ad <strong>una</strong> funzione hash, <strong>il</strong> risultato dell’hash è a sua<br />

volta calcolato in XOR con la password immessa. Il server Radius riceve <strong>il</strong> pacchetto<br />

Access-Request e verifica di disporre della chiave condivisa relativa al<br />

client dal quale proviene la richiesta. In caso affermativo applica l’algoritmo<br />

inverso sul campo User-Password <strong>per</strong> recu<strong>per</strong>are la password in chiaro, altrimenti<br />

la richiesta viene s<strong>il</strong>enziosamente ignorata. Ricostruita la password ne<br />

verifica l’esattezza sul database delle password: se la password è valida, <strong>il</strong> server<br />

crea un pacchetto Access-Accept da inviare al client, in caso contrario, ne crea<br />

uno di tipo Access-Reject.<br />

Il database delle password nelle prime implementazioni era normalmente<br />

un f<strong>il</strong>e di testo non strutturato; nelle versioni più recenti di Radius invece <strong>il</strong><br />

server fa riferimento a risorse esterne come server SQL, Kerberos, LDAP, Active<br />

Directory e quant’altro.<br />

Entrambi i pacchetti Access-Accept e Access-Reject ut<strong>il</strong>izzano lo stesso<br />

valore identificatore del pacchetto Access-Request generato dal client, <strong>per</strong><br />

<strong>per</strong>mettere al client stesso di associare tale risposta alla richiesta corretta; <strong>il</strong> valore<br />

di Authenticator viene calcolato applicando <strong>una</strong> funzione hash al risultato<br />

della concatenazione fra l’originario pacchetto di Radius Access-Request ed <strong>il</strong><br />

segreto condiviso.<br />

114


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

A questo punto <strong>il</strong> client verifica di essere in attesa di <strong>una</strong> risposta relativa<br />

ad <strong>una</strong> richiesta con l’Identifier specificato (in caso contrario ignora s<strong>il</strong>enziosamente<br />

<strong>il</strong> pacchetto ricevuto); quindi ricostruisce l’Authenticator originario<br />

applicando l’algoritmo inverso sull’Authenticator presente nel pacchetto<br />

di risposta (se non vi è corrispondenza ignora s<strong>il</strong>enziosamente <strong>il</strong> pacchetto) ed<br />

infine considera l’utente correttamente autenticato o meno in base al tipo di<br />

pacchetto ricevuto: Access-Accept o Access-Reject rispettivamente. La generazione<br />

della risposta Radius Access-Accept (e quindi della complementare<br />

Radius Access-Reject) è solitamente subordinata alla verifica, oltre che della<br />

password, dei diritti dell’utente, <strong>il</strong> quale, pur essendo autenticato, potrebbe non<br />

essere autorizzato ad accedere a quel particolare servizio. Anche <strong>per</strong> questa fase<br />

<strong>il</strong> server Radius può sfruttare dei backend tipo SQL, LDAP/Active-Directory,<br />

o altro, <strong>per</strong> la verifica dei diritti di accesso dell’utente.<br />

Oltre a Radius Access-Accept e Radius Access-Reject, come precedentemente<br />

citato, esiste un terzo tipo di risposta, la Radius Access-Challenge.<br />

Con questo tipo di risposta <strong>il</strong> server Radius intende richiedere ulteriori informazioni<br />

di autenticazione come <strong>una</strong> password secondaria, un PIN, eccetera. Inoltre<br />

essa può essere ut<strong>il</strong>izzata in schemi di autenticazione più articolati in cui, dopo<br />

la prima fase di interazione convenzionale, <strong>il</strong> dispositivo dell’utente instaura<br />

<strong>una</strong> connessione sicura direttamente con <strong>il</strong> server Radius <strong>per</strong>mettendo quindi<br />

di escludere, in questa seconda fase, <strong>il</strong> NAS dal processo di autenticazione,<br />

garantendo <strong>una</strong> maggior confidenzialità delle credenziali dell’utente.<br />

Gli attributi vengono ut<strong>il</strong>izzati <strong>per</strong> veicolare ulteriori informazioni. Oltre<br />

agli attributi Vendor-Specific che possono essere definiti in autonomia dai vari<br />

produttori <strong>il</strong> protocollo ne prevede già un quantitativo standardizzato e pronto<br />

all’uso. Tali attributi vengono ut<strong>il</strong>izzati nelle Radius Access-Accept <strong>per</strong> porre<br />

dei vincoli relativi all’autorizzazione concessa oppure <strong>per</strong> specificare parametri di<br />

configurazione. Ad esempio, se la richiesta di autorizzazione riguarda un accesso<br />

di livello rete (come l’associazione ad un access-point wireless), gli attributi<br />

inclusi in un’Access-Accept potrebbero essere:<br />

• lo specifico indirizzo IP da assegnare all’utente;<br />

• <strong>il</strong> tempo massimo durante <strong>il</strong> quale l’utente può restare connesso;<br />

• parametri di vario tipo sulla Qualità del Servizio;<br />

• altri tipi di restrizioni.<br />

Accounting<br />

La funzionalità di accounting viene descritta nella RFC 2866 [Rig00]. Dopo<br />

che <strong>il</strong> NAS ha fornito l’accesso alla risorsa a seguito del Radius Access-Accept,<br />

ha inizio la procedura di accounting (figura 3.15).<br />

115


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

C<br />

L<br />

I<br />

E<br />

N<br />

T<br />

R<br />

A<br />

D<br />

I<br />

U<br />

S<br />

RADIUS : Accounting-Request<br />

[acct_status_type=start]<br />

RADIUS : Accounting-Response<br />

RADIUS : Accounting-Request<br />

[acct_status_type=interim:update]<br />

RADIUS : Accounting-Response<br />

RADIUS : Accounting-Request<br />

[acct_status_type=stop]<br />

RADIUS : Accounting-Response<br />

Figura 3.15: Flusso di accounting.<br />

Il NAS invia al server Radius un pacchetto di Accounting-Request con l’attributo<br />

Acct-Status-Type di valore start. I pacchetti di questo tipo contengono<br />

solitamente anche informazioni quali l’identificativo utente, l’indirizzo di rete<br />

dal quale sta o<strong>per</strong>ando ed un identificativo univoco di sessione. Periodicamente<br />

<strong>il</strong> NAS può inviare dei pacchetti Accounting-Request con Acct-Status-Type<br />

di valore Interim-Update con la finalità di aggiornare lo stato delle sessioni<br />

attive. Al termine della sessione, <strong>il</strong> NAS invia al server Radius un pacchetto<br />

Accounting-Request con l’attributo Acct-Status-Type di valore stop. Opzionalmente<br />

può inviare ulteriori informazioni relative alla sessione in fase di<br />

conclusione come la durata della stessa, i pacchetti/dati trasferiti, <strong>il</strong> motivo<br />

della disconnessione, eccetera.<br />

Roaming<br />

Radius può essere ut<strong>il</strong>izzato, come <strong>il</strong>lustrato in figura 3.16, <strong>per</strong> autenticare<br />

utenti in scenari cross-organizzazione.<br />

Questo obiettivo viene raggiunto grazie ai reami [RWRS00], i quali <strong>per</strong>mettono<br />

di individuare dove <strong>il</strong> server Radius debba inoltrare le richieste. I reami<br />

vengono rappresentati con opportune stringhe di testo da concatenare all’identificativo<br />

utente come suffisso (nel qual caso le due informazioni sono delimitate<br />

S<br />

E<br />

R<br />

V<br />

E<br />

R<br />

R<br />

A<br />

D<br />

I<br />

U<br />

S<br />

116


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

RADIUS<br />

Server<br />

Internet<br />

Access<br />

Point<br />

RADIUS<br />

Server<br />

(proxy)<br />

Captive Portal<br />

e NAS<br />

Figura 3.16: Scenario di roaming tramite Radius.<br />

SERVIZI<br />

dal carattere “@”) o come prefisso (in questo caso le informazioni sono invece<br />

separate dal carattere “\”). In questo modo, quando un server Radius riceve<br />

<strong>una</strong> richiesta con un identificativo utente con allegato un reame, può estrarre <strong>il</strong><br />

nome del reame e verificare in <strong>una</strong> tabella interna quale sia <strong>il</strong> server Radius al<br />

quale inoltrare le richiesta. In questo caso <strong>il</strong> primo server chiamato in causa agisce<br />

da proxy e può manipolare la richiesta (ad esempio rimuovendo <strong>il</strong> nome del<br />

reame) sulla base della propria configurazione. In aggiunta, <strong>il</strong> server proxy può<br />

ammettere nella propria configurazione la possib<strong>il</strong>ità di aggiungere, rimuovere<br />

o rinviare <strong>una</strong> richiesta.<br />

Considerazioni<br />

Come precedentemente affermato, Radius è un protocollo ampiamente usato<br />

in diversi dispositivi di rete. Il suo esteso ut<strong>il</strong>izzo è da attribuirsi a diversi fattori:<br />

• <strong>per</strong>mette di gestire un numero arbitrario di autenticazioni differenti su<strong>per</strong>ando<br />

i limiti dei singoli dispositivi di rete; i sistemi integrati infatti<br />

generalmente non riescono a gestire un gran numero di utenti con informazioni<br />

di autenticazione distinte, in quanto ciò richiederebbe molta più<br />

memoria di quanta ne posseggano;<br />

• fac<strong>il</strong>ita la gestione centralizzata degli account, requisito fondamentale in<br />

diverse applicazioni; basti pensare agli ISP che possono trovarsi nella si-<br />

117


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

tuazione di dover gestire m<strong>il</strong>ioni di account con un tasso di variab<strong>il</strong>ità<br />

giornaliero non trascurab<strong>il</strong>e;<br />

• fornisce alcuni livelli di protezione contro attacchi attivi e di sniffing; altri<br />

protocolli di autenticazione remota <strong>of</strong>frono <strong>una</strong> protezione intermittente,<br />

inadeguata o inesistente;<br />

• è supportato dalla maggioranza dei dispositivi; altri protocolli di autenticazione<br />

remota non hanno un così consistente supporto da parte dei<br />

fornitori di hardware.<br />

Nonostante i molteplici pregi di cui vanta Radius, esso ha un limite consistente<br />

nell’autenticazione basata esclusivamente su password trasmessa in forma hash,<br />

algoritmo non del tutto sicuro.<br />

3.4.6 Diameter<br />

Diameter [CLG + 03] nasce nel Settembre del 2003 come protocollo di rete<br />

della famiglia dei protocolli AAA (Autenticazione, Autorizzazione ed Accounting).<br />

Nonostante non sia direttamente retrocompatib<strong>il</strong>e, Diameter rappresenta<br />

<strong>il</strong> successore del protocollo Radius discusso nel paragrafo 3.4.5.<br />

Diameter è costituito da un protocollo base [CLG + 03] che specifica i requisiti<br />

di base <strong>per</strong> l’implementazione delle funzionalità di AAA. In riferimento a tale<br />

protocollo si introduce <strong>il</strong> concetto di applicazione: <strong>il</strong> protocollo base infatti<br />

può essere ut<strong>il</strong>izzato da solo <strong>per</strong> la funzione di accounting, mentre deve essere<br />

necessariamente associato ad altre applicazioni <strong>per</strong> le funzioni di autenticazione<br />

e autorizzazione. Le applicazioni, che possono essere di tipi differenti a seconda<br />

delle funzionalità <strong>of</strong>ferte, devono obbligatoriamente far capo al protocollo base<br />

<strong>per</strong> <strong>il</strong> loro funzionamento, nel senso che devono implementare le specifiche in<br />

esso definite: da ciò si deduce che tutte le applicazione debbano supportare la<br />

funzione di accounting. Tale caratteristica <strong>per</strong>mette a Diameter di estendere i<br />

propri servizi.<br />

Diameter è basato su un’architettura peer-to-peer composta di nodi Diameter,<br />

cioè nodi che implementano <strong>il</strong> protocollo. Mentre Radius prevede un’architettura<br />

client-server tra dei NAS e un server Radius centralizzato, in Diameter<br />

ogni nodo può agire indistintamente sia da client che da server: <strong>il</strong> nodo che<br />

effettua <strong>una</strong> richiesta di accesso, solitamente un NAS, rappresenta <strong>il</strong> client.<br />

Tale client genera dei messaggi Diameter <strong>per</strong> richiedere le funzioni di autenticazione,<br />

autorizzazione e accounting <strong>per</strong> un determinato utente. Il server è<br />

invece colui <strong>il</strong> quale risponde alle richieste del client ed in particolare provvede<br />

all’autenticazione ed all’autorizzazione dell’utente.<br />

118


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Connessione e sessione<br />

In Diameter esistono due concetti diversi <strong>per</strong> identificare la comunicazione<br />

fra due nodi: connessione e sessione [CLG + 03]. Una connessione è un collegamento<br />

a livello di trasporto fra due nodi Diameter, mentre <strong>una</strong> sessione<br />

è un collegamento a livello applicativo e viene tipicamente instaurata fra un<br />

dispositivo di accesso e un server.<br />

Sessione Utente X<br />

Sicurezza End - To - End<br />

Client Agent Server<br />

Sicurezza Hop - To - Hop Sicurezza Hop - To - Hop<br />

Connessione A Connessione B<br />

Figura 3.17: Sessione e connessione in Diameter.<br />

La figura 3.17 mostra <strong>una</strong> connessione (A) fra un client ed un agent e <strong>una</strong><br />

connessione (B) fra un agent e un server. Nello stesso tempo <strong>una</strong> sessione (X)<br />

è instaurata fra <strong>il</strong> client e <strong>il</strong> server. Perciò ogni messaggio inviato fra due nodi<br />

fra i quali è instaurata <strong>una</strong> sessione attraversa le connessioni fra nodi intermedi<br />

interposti fra client e server. Nello spiegare <strong>il</strong> concetto di connessione si è fatto<br />

riferimento agli agent: infatti in Diameter, oltre ai nodi tradizionali, sono presenti<br />

dei nodi cosiddetti agenti con compiti specifici all’interno delle connessioni<br />

Diameter. Questi agenti [JL06] sono principalmente di quattro tipi:<br />

• Relay Agent. Si occupa del routing dei messaggi Diameter, basandosi<br />

sulle informazioni contenute nel messaggio. In particolare esso associa le<br />

richieste provenienti da differenti reami e destinate ad uno specifico reame.<br />

Può modificare i messaggi solo inserendo o cancellando informazioni di<br />

routing, ma non può modificare altre porzioni del messaggio.<br />

• Proxy Agent. Si occupa anch’esso del routing, ma, a differenza del precedente,<br />

può modificare i messaggi <strong>per</strong> implementare decisioni e/o policy:<br />

ha infatti la facoltà di monitorare gli stati del NAS (o comunque del dispositivo<br />

di accesso) allo scopo di controllarne l’ut<strong>il</strong>izzo delle risorse o di<br />

gestirne i servizi a valore aggiunto. Se <strong>il</strong> proxy agent non modifica <strong>il</strong> contenuto<br />

del messaggio di richiesta originario, allora al suo posto può essere<br />

usato un relay agent.<br />

• Redirect Agent. Si occupa ancora del routing, generalmente agendo come<br />

sorgente centralizzata di mappe di indirizzi di dominio <strong>per</strong> i membri dello<br />

119


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

stesso. Diversamente dagli altri tipi di agent, un redirect agent restituisce<br />

uno speciale tipo di messaggio di risposta al peer che ha inviato la<br />

richiesta; questo messaggio di risposta contiene informazioni di routing<br />

che consentono al peer di rinviare la richiesta, direttamente alla corretta<br />

destinazione.<br />

• Translation Agent. Effettua traduzioni tra protocolli diversi, <strong>per</strong> esempio<br />

da Radius a Diameter (e viceversa). Il translation agent supporta quindi<br />

la migrazione da un protocollo all’altro, rendendo quindi intero<strong>per</strong>ab<strong>il</strong>i<br />

client e server che non ut<strong>il</strong>izzano lo stesso protocollo.<br />

example.net<br />

Client<br />

Radius<br />

Richiesta Radius Richiesta Diameter<br />

Translation<br />

Agent<br />

Diameter<br />

Risposta Radius Risposta Diameter<br />

Server<br />

Diameter<br />

Figura 3.18: Translation Agent Diameter.<br />

La figura 3.18 <strong>il</strong>lustra un esempio in cui un client nel dominio example.net ut<strong>il</strong>izza<br />

<strong>il</strong> protocollo Radius <strong>per</strong> l’accesso a servizi nel dominio example.com in cui è in<br />

uso <strong>il</strong> protocollo Diameter.<br />

Le connessioni Diameter. Una connessione [CLG + 03] è un collegamento<br />

che avviene a livello di trasporto fra due nodi Diameter. Diameter, a differenza<br />

di Radius che si avvale del protocollo UDP, fa uso del protocollo di trasporto<br />

affidab<strong>il</strong>e TCP. Oltre a TCP, di cui sono ben note, ad esempio, le caratteristiche<br />

di controllo del flusso e controllo della congestione, può essere ut<strong>il</strong>izzato anche<br />

un protocollo di più recente ideazione, l’SCTP (Stream Control Transmission<br />

Protocol), anch’esso basato su IP e specificato nella RFC 4960 [Ste07]. La porta<br />

ut<strong>il</strong>izzata <strong>per</strong> le connessioni Diameter, assegnata dallo IANA, è la 3868 (sia <strong>per</strong><br />

TCP che <strong>per</strong> SCTP).<br />

Come precedentemente affermato <strong>una</strong> connessione Diameter avviene fra due<br />

nodi. Sebbene un nodo abbia a disposizione molteplici peer con cui comunicare,<br />

spesso non è conveniente instaurare <strong>una</strong> connessione con ognuno di essi. Ciò che<br />

invece si rende obbligatorio è che un nodo instauri <strong>una</strong> connessione con almeno<br />

due nodi dello stesso reame, dei quali uno funge da nodo primario e l’altro<br />

da nodo secondario. Questa regola vale in quanto tutti i messaggi indirizzati<br />

example.com<br />

120


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

ad un determinato reame vengono spediti al peer primario, mentre in eventi<br />

di Fa<strong>il</strong>Over le richieste pendenti sono inviate al peer secondario. Infatti, nel<br />

momento in cui un nodo sembra sospetto <strong>per</strong> diverse ragioni, non gli vengono<br />

inviate nuove richieste, ma viene invocata <strong>una</strong> procedura di Fa<strong>il</strong>Over: quando<br />

ciò accade devono essere instaurate nuove connessioni <strong>per</strong> garantire <strong>il</strong> numero<br />

minimo di connessioni. Naturalmente un nodo che agisce da primario in un<br />

reame, può agire da secondario in un reame diverso.<br />

La ricerca del peer con cui un nodo intende comunicare può essere effettuata<br />

sia in modo dinamico che in modo statico. Un nodo Diameter ha associate due<br />

tabelle [JL06]:<br />

• la Peer Table contiene gli indirizzi dei nodi conosciuti e può includere<br />

informazioni quali lo stato, <strong>il</strong> livello di sicurezza, <strong>il</strong> fatto che sia stato<br />

individuato dinamicamente o meno;<br />

• la Realm-based Routing Table contiene le informazioni necessarie <strong>per</strong> <strong>il</strong><br />

routing fra reami.<br />

Quindi, a meno che un nodo non sia <strong>il</strong> destinatario di un messaggio, avrà bisogno<br />

di consultare queste tabelle <strong>per</strong> trovare <strong>il</strong> prossimo nodo a cui affidare un<br />

messaggio. Nel caso di discovery dinamico, <strong>il</strong> peer trovato provocherà l’aggiunta<br />

di <strong>una</strong> nuova voce nella tabella dei peer.<br />

Trovati i peer con cui comunicare, si consideri ora come avvengano tali<br />

connessioni attraverso lo schema di funzionamento riportato in figura 3.19.<br />

La prima fase della comunicazione riguarda la cosiddetta capacità di negoziazione<br />

in cui i due nodi effettuano <strong>una</strong> procedura di negoziazione della connessione.<br />

Infatti, quando due nodi Diameter stab<strong>il</strong>iscono <strong>una</strong> connessione, devono<br />

scambiarsi dei messaggi di tipo Capab<strong>il</strong>ities Exchange. Questi messaggi<br />

<strong>per</strong>mettono di venire a conoscenza dell’identità e delle capacità supportate da<br />

un peer. Il nodo ricevente <strong>il</strong> messaggio di Capab<strong>il</strong>ities-Exchange-Request<br />

(CER), che non abbia applicazioni in comune con <strong>il</strong> mittente, ritornerà un messaggio<br />

di Capab<strong>il</strong>ities-Exchange-Answer (CEA) con l’attributo Result-Code<br />

con <strong>il</strong> valore Diameter_NO_COMMON_APPLICATION e quindi la connessione verrà<br />

chiusa. Allo stesso modo un messaggio di tipo CER ricevuto da un peer senza<br />

meccanismi di sicurezza in comune con <strong>il</strong> mittente, darà vita ad <strong>una</strong> risposta<br />

CEA con l’attributo Result-Code con <strong>il</strong> valore Diameter_NO_COMMON_SECURITY<br />

e provocherà la chiusura della connessione. Infine, messaggi di tipo CER ricevuti<br />

da peer sconosciuti possono essere scartati o possono scatenare <strong>una</strong> risposta<br />

con <strong>il</strong> Result-Code di valore Diameter_UNKNOWN_PEER e la conseguente chiusura<br />

della connessione. I messaggi CER e CEA non possono essere sottoposti a<br />

relaying, proxing e redirecting.<br />

Per quanto riguarda la sicurezza o<strong>per</strong>ativa Diameter impone <strong>una</strong> serie di<br />

meccanismi e di strategie [CLG + 03] <strong>per</strong> le connessioni. In particolare <strong>il</strong> proto-<br />

121


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Transport connection establishment<br />

CER<br />

DWR<br />

DPR<br />

messages<br />

CEA<br />

DWA<br />

DPA<br />

Transport connection disconnected<br />

Figura 3.19: Una tipica connessione Diameter.<br />

collo base suggerisce che ogni connessione Diameter debba essere protetta da<br />

IPSec, o alternativamente da TLS; nel momento in cui IPSec non è implementato,<br />

messaggi CER e CEA contengono un attributo Inband-Security-ID che<br />

specifica l’ut<strong>il</strong>izzo di TLS. Il TLS include <strong>una</strong> fase di handshake successiva allo<br />

scambio dei messaggi CER/CEA, <strong>per</strong> far sì che vada a buon fine la connessione.<br />

La modalità di trasporto tramite IPSec garantisce la sicurezza attraverso la<br />

cifratura e l’autenticazione dei pacchetti IP e lo scambio delle chiavi <strong>per</strong> realizzare<br />

<strong>il</strong> flusso crittografico. La prima caratteristica è ottenuta tramite i seguenti<br />

protocolli: Authentication Header (AH), <strong>il</strong> quale garantisce l’autenticazione e<br />

l’integrità dei messaggi, ma non <strong>of</strong>fre la confidenzialità, ed Encapsulating Security<br />

Payload (ESP), <strong>il</strong> quale fornisce autenticazione, confidenzialità e controllo<br />

di integrità dei messaggi. Invece <strong>per</strong> lo scambio delle chiavi, <strong>il</strong> solo protocollo<br />

esistente è <strong>il</strong> protocollo Internet Key Exchange (IKE). Quest’ultimo ut<strong>il</strong>izza <strong>una</strong><br />

chiave condivisa corrispondente alla sessione da instaurare e, al fine di autenticare<br />

le entità coinvolte, possono essere usate tecniche a chiave simmetrica o<br />

asimmetrica (in quest’ultimo caso si fa ricorso a infrastrutture a chiave pubblica,<br />

le PKI descritte nel paragrafo 3.4.1).<br />

Se invece viene garantita <strong>una</strong> connessione sicura basata su TLS, <strong>il</strong> nodo che<br />

dà inizio alla connessione rappresenta <strong>il</strong> TLS client, mentre quello che accetta<br />

la connessione è <strong>il</strong> TLS server. In questo caso, l’autenticazione avviene in modo<br />

122


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

manuale: <strong>il</strong> server deve richiedere <strong>il</strong> certificato al client, che deve essere in grado<br />

di fornirglielo.<br />

Terminata la fase di negoziazione può avvenire lo scambio dei messaggi vero<br />

e proprio. Se non vengono scambiati messaggi <strong>per</strong> un certo lasso di tempo, viene<br />

inviato un messaggio di Device-Watchdog-Request (DWR) dal nodo in attesa,<br />

a cui l’altro nodo dovrà rispondere con un Device-Watchdog-Answer (DWA).<br />

Infine la comunicazione può essere terminata da uno dei due nodi tramite l’invio<br />

di un messaggio di Disconnect-Peer-Request (DPR) al quale dovrà seguire <strong>il</strong><br />

messaggio di Disconnect-Peer-Answer (DPA). Quest’ultimo scambio causa la<br />

terminazione della connessione.<br />

Accounting. Un tipico esempio di funzionamento di <strong>una</strong> connessione è rappresentato<br />

dalla funzionalità di accounting [CLG + 03]. Come detto in prece-<br />

Dispositivo<br />

di<br />

accesso<br />

Capab<strong>il</strong>ity Exchange Request<br />

Capab<strong>il</strong>ity Exchange Response<br />

Accounting Request ( start )<br />

Accounting Request (interim)<br />

Accounting Request (stop)<br />

Disconnect Peer Request<br />

Accounting Answer ( start )<br />

Accounting Answer (interim)<br />

Accounting Answer (stop)<br />

Disconnect Peer Answer<br />

Figura 3.20: Funzione di accounting in Diameter.<br />

Server<br />

Diameter<br />

denza, questa funzione può essere svolta autonomamente dal protocollo base<br />

di Diameter. In figura 3.20 è mostrato lo scambio di messaggi di <strong>una</strong> fase di<br />

accounting: in essa si possono trovare le fasi di negoziazione delle capacità, con<br />

lo scambio dei pacchetti Capab<strong>il</strong>ities-Exchange, e di terminazione della connessione,<br />

con lo scambio dei pacchetti di disconnessione. Oltre a queste fasi<br />

in comune con gli altri tipi di connessione, è presente la fase di scambio delle<br />

informazioni vere e proprie, la quale coinvolge due tipi di messaggi: un messaggio<br />

di richiesta di accounting, Accounting-Request (ACR) ed uno in risposta,<br />

Accounting-Answer (ACA).<br />

123


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

I messaggi Diameter. Per capire nel dettaglio come avviene la scambio<br />

di messaggi fra nodi, è necessario introdurre la struttura dei messaggi Diameter<br />

[CLG + 03]. I messaggi <strong>per</strong>mettono lo scambio di informazioni fra nodi<br />

Diameter. La struttura di un messaggio Diameter è quella di figura 3.21.<br />

0 1 2 3<br />

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Version | Message Length |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Command Flags | Command Code |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Application-ID |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Hop-by-hop Identifier |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| End-to-end Identifier |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| AVPs...<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-<br />

Figura 3.21: Pacchetto Diameter.<br />

I campi che costituiscono la struttura del pacchetto vengono trasmessi da sinistra<br />

verso destra. Il primo campo è Version, che indica la versione di Diameter<br />

e, attualmente, deve valere“1”. Il campo Message Length è un triplo ottetto che<br />

indica la dimensione dell’intero pacchetto Diameter, mentre <strong>il</strong> Command Flags<br />

è un ottetto così formato, andando da sinistra verso destra (dal bit 0 al bit 7):<br />

0. R (request). Se 1 indica che <strong>il</strong> messaggio è <strong>una</strong> richiesta, altrimenti è <strong>una</strong><br />

risposta;<br />

1. P (proxiable). Se 1 indica che <strong>il</strong> messaggio può usufruire delle funzioni<br />

di uno degli agenti Diameter (Relay, Proxy o Redirect Agent), altrimenti<br />

esso viene processato localmente;<br />

2. E (error). Se 1 indica che <strong>il</strong> messaggio contiene un errore di protocollo e<br />

<strong>il</strong> messaggio non rispetta la sintassi del pacchetto; questo bit deve essere<br />

0 nei messaggi di richiesta;<br />

3. T (Potentially re-trasmitted message). Viene impostato a 1 dopo <strong>una</strong><br />

procedura di Fa<strong>il</strong>Over, <strong>per</strong> aiutare nella rimozione dei duplicati delle richieste.<br />

Viene impostato a 1 quando vengono rinviate richieste non ancora<br />

riscontrate, come indicazione di un possib<strong>il</strong>e duplicato;<br />

4. r (reserved). Sono gli ultimi 4 bit, sono riservati <strong>per</strong> usi futuri e quindi<br />

devono essere obbligatoriamente 0.<br />

Un campo relativamente importante è Command-Code, esso infatti identifica<br />

i diversi tipi di messaggio. Ad esempio, come introdotto con la descrizione<br />

della negoziazione della connessione fra due nodi, un messaggio di tipo<br />

124


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Capab<strong>il</strong>ities-Exchange-Request (CER), con Command-Code 257, fornirà informazioni<br />

sulle capacità di un nodo. Siccome lo scambio di messaggi avviene<br />

in modalità sincrona, ogni messaggio avrà la sua controparte con la quale<br />

condivide lo stesso Command-Code: ad esempio, ad un messaggio CER farà seguito<br />

un messaggio di Capab<strong>il</strong>ities-Exchange-Answer (CEA) con lo stesso<br />

Command-Code. Naturalmente sono definiti molteplici tipi di messaggi, e quindi<br />

diversi Command-Code a seconda del contesto e dello scopo, fra questi vi sono:<br />

• 271 = Accounting-Request/Accounting Answer<br />

• 258 = Re-Auth-Request/Re-Auth-Answer<br />

• 282 = Disconnect-Peer-Request/Disconnect-Peer-Answer<br />

• 280 = Device-Watchdog-Request/Device-Watchdog-Answer<br />

• 265 = AA-Request/AA-Answer<br />

Un ulteriore campo è Application-ID, <strong>il</strong> quale viene usato <strong>per</strong> identificare<br />

a quale applicazione è riferito <strong>il</strong> messaggio. I due campi successivi, entrambi<br />

a 32 bit, sono quelli riguardanti la sicurezza: <strong>il</strong> Hop-by-hop Identifier e <strong>il</strong><br />

End-to-end Identifier. Il primo aiuta nella corrispondenza fra richieste e<br />

risposte e nelle richieste viene sostituito ad ogni hop, fin quando <strong>il</strong> messaggio<br />

non viene inoltrato alla destinazione finale; <strong>il</strong> mittente del messaggio di risposta<br />

restituisce lo stesso valore che ha trovato nella corrispondente richiesta. Il<br />

secondo identificatore, insieme all’identità dell’host di origine, è ut<strong>il</strong>izzato <strong>per</strong><br />

riconoscere messaggi di richiesta duplicati e non viene modificato mai fino all’arrivo<br />

a destinazione della richiesta; <strong>il</strong> mittente della risposta restituisce lo stesso<br />

valore che ha trovato nella richiesta corrispondente.<br />

A differenza di Radius, <strong>il</strong> quale assicura solo <strong>una</strong> sicurezza di tipo hop-tohop<br />

<strong>per</strong> le sue connessioni, Diameter garantisce anche <strong>una</strong> sicurezza end-toend<br />

tramite l’ut<strong>il</strong>izzo di specifiche estensioni del modulo CMS (Cryptographic<br />

Message Syntax). Quest’ultimo modulo, implementato nelle più recenti versioni<br />

del protocollo, garantisce la sicurezza end-to-end tramite meccanismi di firma<br />

digitale e attraverso la cifratura previene la fruizione non autorizzata dei dati.<br />

L’ultimo campo è quello degli AVP [CLG + 03] (Attribute-Value-Pairs). Le<br />

informazioni vere e proprie, che vengono scambiate tramite <strong>il</strong> protocollo Diameter,<br />

sono definite da questi attributi. Diameter ha un insieme di attribuiti<br />

predefiniti con ognuno uno specifico significato: essi possono fornire ad esempio<br />

dettagli riguardanti l’instradamento dei messaggi, la sicurezza, la capacità di<br />

scambio di informazioni fra due nodi, eccetera. Inoltre è comunque possib<strong>il</strong>e definire<br />

degli attributi specifici <strong>per</strong> determinate applicazioni. Esempi di attributi<br />

sono i seguenti:<br />

• 276 = Auth-Grace-Period<br />

125


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• 299 = Inband-Security-Id<br />

• 268 = Result-Code<br />

Ogni AVP ha <strong>il</strong> seguente formato riportato in figura 3.22.<br />

0 1 2 3<br />

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| AVP Code |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

|V M P r r r r r| AVP Length |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Vendor-ID (optional) |<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />

| Data...<br />

+-+-+-+-+-+-+-+-+-+-+-+-+-<br />

Figura 3.22: AVP Diameter.<br />

Il campo AVP Code, insieme al campo Vendor-ID, identifica univocamente<br />

l’attributo. I primi 256 numeri, insieme al Vendor-ID impostato a 0, sono riservati<br />

<strong>per</strong> la retro-compatib<strong>il</strong>ità con Radius. Il campo AVP Data è formato da zero<br />

o più ottetti e contiene informazioni specifiche dell’attributo. I campi AVP Code<br />

e AVP Length determinano <strong>il</strong> formato e la lunghezza del campo Data. Infine<br />

<strong>il</strong> campo Flags è del tutto sim<strong>il</strong>e all’analogo campo nel pacchetto Diameter; è<br />

formato da 8 bit con i seguenti valori: “V”, Vendor Specific (se 1 allora è presente<br />

<strong>il</strong> campo Vendor-ID); “M”, Mandatory (se 1 lo specifico AVP è obbligatorio);<br />

“P”, Protected (se 1 è richiesta l’ab<strong>il</strong>itazione della crittografia end-to-end). Per<br />

fare un esempio di attributo, basta tornare alla negoziazione della connessione,<br />

in cui, in risposta ad un messaggio di Capab<strong>il</strong>ities-Exchange-Request,<br />

viene generato un messaggio Capab<strong>il</strong>ities-Exchange-Answer con l’attributo<br />

Result-Code impostato a Diameter_NO_COMMON_APPLICATION (nel caso di supporto<br />

di applicazioni diverse da parte dei due nodi). Perciò l’informazione vera<br />

e propria sulle caratteristiche dei nodi, in questo caso in termini di applicazioni<br />

supportate, sono trasportate negli AVP dei messaggi.<br />

Le sessioni Diameter: autenticazione, autorizzazione e accounting.<br />

Una sessione è un collegamento a livello applicativo tra un client Diameter, che<br />

tipicamente è rappresentato da un NAS (Network Access Server), e un server<br />

Diameter. Per spiegare nel dettaglio come avviene <strong>una</strong> sessione, si farà riferimento<br />

ad <strong>una</strong> tipica applicazione Diameter: NASREQ [CZSM05]. Diameter è<br />

in grado di <strong>of</strong>frire alle sue applicazioni due differenti tipi di servizi: <strong>il</strong> primo tipo<br />

riguarda i servizi di autenticazione ed autorizzazione, <strong>il</strong> secondo riguarda l’accounting.<br />

Mentre quest’ultimo viene svolto dal solo protocollo base, le funzioni<br />

di autenticazione e autorizzazione hanno bisogno del supporto delle applicazioni<br />

Diameter.<br />

126


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

L’applicazione NASREQ fornisce servizi di AAA <strong>per</strong> l’accesso alla rete in<br />

scenari in cui sia presente un NAS che interagisce con un server Diameter.<br />

Fondamentalmente essa si occupa delle fasi di autenticazione e autorizzazione,<br />

demandando la fase di accounting al protocollo base di Diameter.<br />

Per <strong>il</strong>lustrare meglio come avviene lo scambio di informazioni in <strong>una</strong> tipica<br />

sessione NASREQ [MN05] si farà riferimento alla figura 3.23.<br />

Utente NAS<br />

Auth Request<br />

Auth Answer<br />

Re-Auth Request<br />

Re-Auth Request<br />

Termination Indication<br />

AA Request<br />

Re-Authentication Answer<br />

AA Answer<br />

Re-Authentication Request<br />

Session Termination Request (STR)<br />

Session Termination Answer (STA)<br />

Server<br />

Diameter<br />

Figura 3.23: Funzioni di autenticazione e autorizzazione in NASREQ.<br />

Nel momento in cui un utente fa <strong>una</strong> richiesta di accesso alla rete, <strong>il</strong> client<br />

Diameter emette <strong>una</strong> richiesta di autenticazione ed autorizzazione indirizzata al<br />

server tramite <strong>il</strong> messaggio AA-Request: tutte le richieste di questo tipo devono<br />

contenere informazioni <strong>per</strong> l’identificazione del chiamante come username, porta<br />

del NAS, eccetera. Ad ogni sessione è collegato un identificativo <strong>per</strong> <strong>per</strong>mettere<br />

a client e server di legare un determinato messaggio ad <strong>una</strong> certa sessione. Per<br />

questo motivo, <strong>il</strong> messaggio di richiesta AA-Request conterrà anche un AVP<br />

univoco chiamato Session-Id. A questo punto <strong>il</strong> server elabora la richiesta ed<br />

invia un messaggio di AA-Answer, includendo le informazioni di autorizzazione<br />

dell’utente. Può accadere che <strong>il</strong> server intenda autorizzare l’uso delle risorse da<br />

parte dell’utente solo <strong>per</strong> un certo <strong>per</strong>iodo temporale: nel qual caso esso include<br />

un attributo di Authorization-Lifetime nel messaggio di risposta che definisce<br />

<strong>il</strong> <strong>per</strong>iodo di tempo, espresso in secondi, trascorso <strong>il</strong> quale <strong>il</strong> client ha bisogno<br />

di essere autorizzato nuovamente. Inoltre si aggiunge un ulteriore attributo,<br />

127


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

Auth-Grace-Period, che contiene <strong>il</strong> numero di secondi successivi alla scadenza<br />

dell’Authorization-Lifetime, dopo i quali <strong>il</strong> server rimuove la sessione corrente<br />

dalla sua lista e r<strong>il</strong>ascia le risorse allocate.<br />

Durante la sessione, <strong>il</strong> server può dare inizio ad <strong>una</strong> nuova richiesta di autenticazione<br />

o di autorizzazione. Ad esempio, nei servizi prepagati, questo tipo di<br />

richiesta viene usata <strong>per</strong> controllare se l’utente sia ancora interessato al servizio,<br />

e nel caso non lo sia, <strong>il</strong> server cessa la sessione <strong>per</strong> evitare addebiti aggiuntivi.<br />

In questa fase, <strong>il</strong> server invia un messaggio di Re-Auth-Request a cui farà seguito<br />

un messaggio di Re-Auth-Answer. È importante notare che Diameter dà<br />

la possib<strong>il</strong>ità di effettuare <strong>il</strong> solo processo di autenticazione, escludendo quello<br />

di autorizzazione; naturalmente tale prassi è soggetta a rischi nella sicurezza.<br />

Terminata la procedura di autenticazione e/o autorizzazione dell’utente, quest’ultimo<br />

può decidere di terminare la sessione; a tal fine <strong>il</strong> NAS invia un messaggio<br />

di richiesta di terminazione Session-Termination-Request (STR) al server<br />

Diameter. In questo messaggio viene incluso l’attributo Termination-Cause che<br />

spiega i motivi <strong>per</strong> cui la sessione è stata terminata. Alternativamente, se, <strong>per</strong><br />

un qualche motivo, <strong>il</strong> server r<strong>il</strong>eva che la sessione debba essere chiusa, invia<br />

un messaggio Abort-Session-Request al client. In ogni caso, <strong>il</strong> client potrebbe<br />

decidere di non chiudere la sessione, pur avendo ricevuto un messaggio di<br />

terminazione dal server, e quindi lasciare che l’utente continui ad usufruire del<br />

servizio, oppure rispondere al messaggio di richiesta di terminazione con <strong>una</strong><br />

Session-Termination-Answer (STA).<br />

Gestione degli errori<br />

In Diameter gli errori [CLG + 03] possono essere di due tipi: errori del protocollo<br />

ed errori delle applicazioni. I primi si riferiscono ad errori nel trasporto<br />

dei messaggi, come ad esempio informazioni di routing sbagliate o falle nelle<br />

rete. Gli errori delle applicazioni, invece, derivano da fallimenti del protocollo<br />

base e possono essere scatenati da molteplici fattori. Occorre precisare che ogni<br />

messaggio di risposta contiene un attributo Result-Code, in modo che <strong>il</strong> ricevente<br />

possa controllare tale attributo <strong>per</strong> capire se <strong>il</strong> precedente messaggio sia<br />

stato processato con successo. Il tipo di errore viene identificato controllando <strong>il</strong><br />

primo numero del codice inserito nel Result-Code:<br />

• 1xxx: la richiesta non può essere soddisfatta e servono ulteriori informazioni<br />

<strong>per</strong> garantire <strong>il</strong> servizio;<br />

• 2xxx: la richiesta è stata processata con successo;<br />

• 3xxx: è accaduto un errore del protocollo durante la trasmissione del messaggio.<br />

Generalmente, vi è un proxy Diameter che tenta di porre rimedio<br />

all’errore o inoltrando <strong>il</strong> messaggio ad un altro server oppure conservando<br />

<strong>il</strong> messaggio nella cache <strong>per</strong> poi re-inviarlo in un secondo momento;<br />

128


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

• 4xxx: <strong>il</strong> messaggio richiesto al momento non può essere soddisfatto, ma<br />

potrà essere elaborato in futuro. Un esempio si ha quando un server non<br />

ha temporaneamente spazio <strong>per</strong> memorizzare un’ulteriore richiesta;<br />

• 5xxx: è accaduto un errore applicativo mentre <strong>il</strong> server stava processando<br />

<strong>il</strong> messaggio di richiesta. Il mittente non deve re-inviare <strong>il</strong> messaggio,<br />

ma può determinare la causa dell’errore controllando l’error code e quindi<br />

tentare di riparare.<br />

Per fare un esempio, se in un messaggio manca un attributo obbligatorio, allora<br />

viene restituito l’errore Diameter_MISSING_AVP con un Result-Code con codice<br />

5005.<br />

Per la r<strong>il</strong>evazione degli errori, <strong>il</strong> protocollo definisce un messaggio di tipo<br />

Device-Watchdog-Request, che era stato già introdotto nella fase di negoziazione<br />

della connessione. Quando due nodi Diameter connessi tra loro non si<br />

scambiano messaggi <strong>per</strong> un certo <strong>per</strong>iodo temporale, uno dei due nodi invia un<br />

messaggio di questo tipo <strong>per</strong> capire se ci siano problemi nella rete.<br />

Oltre all’attributo Result-Code, vi sono altri AVPs <strong>per</strong> la gestione degli<br />

errori. Tra cui Error-Message riporta un messaggio d’errore leggib<strong>il</strong>e <strong>per</strong> determinare<br />

l’effettiva causa; Error-Reporting-Message contiene l’identità del<br />

terminale che ha generato <strong>il</strong> Result-Code.<br />

Una volta che l’errore è stato r<strong>il</strong>evato, <strong>il</strong> nodo mittente invia tutti i messaggi<br />

pendenti ad un nodo alternativo: si attua un processo di Fa<strong>il</strong>Over. Un<br />

messaggio pendente è un messaggio inviato, ma che non ha ancora ricevuto<br />

un riscontro. Ad ogni nodo Diameter viene richiesto di mantenere <strong>una</strong> copia<br />

locale dei messaggi in uscita. Il campo Hop-by-hop Identifier, contenuto<br />

in ogni messaggio, viene salvato al momento dell’inoltro di <strong>una</strong> richiesta, esso<br />

viene poi sostituito da un identificativo locale e riportato infine al suo valore<br />

originario al momento della ricezione della corrispondente risposta. Tuttavia,<br />

questo processo può causare la ricezione di uno stesso messaggio più volte da<br />

parte di un nodo. Per rimediare a ciò, <strong>il</strong> nodo ut<strong>il</strong>izza <strong>una</strong> combinazione del<br />

campo End-to-end Identifier e dell’attributo Origin-Host <strong>per</strong> identificare<br />

univocamente un messaggio proveniente da un determinato nodo Diameter.<br />

Radius e Diameter a confronto<br />

Dalla trattazione proposta nei paragrafi precedenti si possono evincere le<br />

principali differenze fra Radius e Diameter:<br />

• Meccanismo di fa<strong>il</strong>over: come discusso parlando delle connessioni, può<br />

accadere che, <strong>per</strong> <strong>una</strong> qualche ragione, ad un certo punto un nodo possa<br />

risultare sospetto e che quindi ad esso non vengano più inviati messaggi.<br />

In Diameter <strong>il</strong> meccanismo di fa<strong>il</strong>over prevede che tutte le richieste pendenti<br />

vengano indirizzate verso un nuovo nodo. Questo meccanismo deve<br />

129


Principi e tecnologie <strong>per</strong> la sicurezza Tecnologie <strong>per</strong> l’AAA<br />

essere supportato da informazioni specifiche che avvisino i nodi coinvolti<br />

dell’accadimento. Mentre Diameter prevede i messaggi di Watchdog <strong>per</strong><br />

r<strong>il</strong>evare momenti di inattività, Radius non supporta tale meccanismo: i<br />

nodi coinvolti non vengono a conoscenza di eventuali <strong>per</strong>iodi inattivi e<br />

ciò comporta <strong>per</strong>iodi di attesa molto lunghi <strong>per</strong> trovare un nodo ut<strong>il</strong>e<br />

alternativo.<br />

• Invio messaggi volontari da parte del server: Diameter prevede la possib<strong>il</strong>ità<br />

da parte del server di inviare messaggi volontari e non solo in risposta<br />

alle richieste del client. Tali messaggi sono ad esempio quelli relativi alla<br />

terminazione di <strong>una</strong> sessione o relativi alla rinnovata autenticazione e/o<br />

autorizzazione di un utente. In Radius questi messaggi non sono previsti,<br />

rendendo diffic<strong>il</strong>i tali o<strong>per</strong>azioni.<br />

• Trasporto affidab<strong>il</strong>e: Diameter lavora con i protocolli di trasporto affidab<strong>il</strong>i<br />

TCP e SCTP che sono orientati alla connessione ed effettuano controllo<br />

di flusso e di congestione. Radius, viceversa, lavora con UDP che non supporta<br />

alcun meccanismo di ritrasmissione dei dati e quindi la probab<strong>il</strong>ità<br />

di <strong>per</strong>dita di pacchetti è non trascurab<strong>il</strong>e.<br />

• Negoziazione delle capacità: in Diameter le connessioni prevedono degli<br />

scambi di messaggi contenenti informazioni sulle caratteristiche dei nodi<br />

coinvolti: <strong>una</strong> connessione fra nodi è possib<strong>il</strong>e solo se questi condividono le<br />

stesse caratteristiche in termini di applicazioni supportate o meccanismi di<br />

sicurezza. In Radius non esiste tale meccanismo rendendo possib<strong>il</strong>i errori<br />

nella gestione dei messaggi.<br />

• Gestione degli errori: in Diameter esiste un meccanismo di gestione degli<br />

errori che informa sull’occorrenza e sul tipo di eventuali errori. In caso di<br />

errore viene attivato <strong>il</strong> meccanismo di fa<strong>il</strong>over. Radius invece prevede che<br />

in caso di errore i messaggi vengano s<strong>il</strong>enziosamente respinti; in questo caso<br />

<strong>il</strong> NAS assumerà che <strong>il</strong> server non abbia ricevuto <strong>il</strong> messaggio e proverà a<br />

ritrasmetterlo diverse volte prima dell’abbandono della comunicazione.<br />

• Sicurezza end-to-end: Diameter, oltre a garantire la sicurezza hop-to-hop<br />

tramite i protocollo IPSec e TLS, garantisce anche <strong>una</strong> sicurezza endto-end<br />

tramite l’ut<strong>il</strong>izzo del modulo CMS, che rende sicuro <strong>il</strong> canale con<br />

meccanismi di firma digitale e crittografia. Radius invece garantisce solo<br />

la sicurezza hop-to-hop e <strong>per</strong>mette ai nodi intermedi di memorizzare<br />

informazioni confidenziali a discapito degli endpoint.<br />

130


Parte II<br />

<strong>InterDataNet</strong>: basi teoriche


Capitolo<br />

4<br />

<strong>InterDataNet</strong> Information<br />

Model<br />

L’entità gestita nell’ambiente <strong>InterDataNet</strong> è un generico (nel senso di non<br />

specializzato) documento multimediale che è stato definito e progettato a partire<br />

dai i principi fondanti dell’architettura IDN stessa che sono i seguenti:<br />

• Principio 1: Contenitore-Contenuto. I documenti sono contenitori mentre<br />

i dati ed i metadati costituiscono <strong>il</strong> loro contenuto. I dati ed i metadati<br />

sono importanti al pari della struttura che li contiene.<br />

• Principio 2: Identificatori Globali. Ad ogni dato sono assegnati degli<br />

identificatori gestiti da un sistema globale <strong>per</strong> l’identificazione attraverso<br />

<strong>il</strong> quale sia possib<strong>il</strong>e effettuare <strong>il</strong> recu<strong>per</strong>o delle informazioni. Sia i contenitori<br />

che i contenuti (ovvero documenti e dati/metadati) possono avere<br />

uno o più nomi con validità locale o globale. Al momento della creazione<br />

un documento o un dato ha un nome locale, che diventa globale <strong>una</strong> volta<br />

che l’autore decide di assegnarne la visib<strong>il</strong>ità ad un certo insieme di utenti<br />

(ovvero singolo utente, gruppi specifici, etc.).<br />

• Principio 3: Coo<strong>per</strong>azione. Sia i documenti che i dati sono arricchiti di<br />

un insieme di metadati/attributi che ab<strong>il</strong>itano la coo<strong>per</strong>azione. In sintesi<br />

si asserisce che <strong>il</strong> modello dell’informazione costituito dall’insieme “datimetadati-struttura”<br />

deve essere ab<strong>il</strong>itante alla coo<strong>per</strong>azione.


<strong>InterDataNet</strong> Information Model<br />

In IDN <strong>il</strong> documento viene modellato come un aggregato di informazioni elementari;<br />

la struttura e <strong>il</strong> contenuto sono completamente separati dalla presentazione.<br />

Ciascun elemento informativo viene mantenuto isolato rispetto agli altri<br />

secondo un principio gerarchico che si basa sull’associazione ad un responsab<strong>il</strong>e.<br />

Si consideri l’esempio semplificato di un documento che rappresenta <strong>una</strong><br />

patente di guida. Per ogni contenuto informativo è possib<strong>il</strong>e determinare un’organizzazione<br />

che detiene l’informazione: <strong>per</strong> i dati anagrafici del titolare si risale<br />

al Comune di nascita, <strong>per</strong> i dati della residenza si risale al Comune di residenza,<br />

<strong>per</strong> la categoria di guida al Ministero dei Trasporti, <strong>per</strong> i punti al Ministero degli<br />

Interni, <strong>per</strong> i dati relativi alla scadenza si risale alla Motorizzazione, e così via.<br />

Il procedimento tende quindi a strutturare rigidamente <strong>il</strong> documento, seguendo<br />

le regole organizzative e procedurali che hanno contribuito alla sua creazione o<br />

r<strong>il</strong>ascio.<br />

Più un documento è finemente suddiviso nei suoi elementi, più ogni sua<br />

parte, se opport<strong>una</strong>mente indicizzata e classificata, risulta riut<strong>il</strong>izzab<strong>il</strong>e <strong>per</strong> la<br />

costruzione e la produzione di nuova informazione. Per agevolare <strong>il</strong> riuso è quindi<br />

opportuno che l’informazione possa essere trattata con un livello di granularità<br />

arbitrario.<br />

Non è necessario che la sorgente di informazione sia unica 1 e unitaria 2 ; anzi,<br />

<strong>il</strong> poter disporre della possib<strong>il</strong>ità di modellare le informazioni con un livello di<br />

granularità arbitrario è tanto più vantaggioso quanto più è possib<strong>il</strong>e distinguere<br />

le organizzazioni (e sotto-organizzazioni) che trattano le singole informazioni,<br />

costituendo in modo naturale un sistema distribuito dal punto di vista dello<br />

stesso documento.<br />

La dinamicità e la flessib<strong>il</strong>ità sono ottenute grazie all’elevato grado di autonomia<br />

delle singole sorgenti che, in modo collaborativo, partecipano alla determinazione<br />

di documenti capaci di evolvere nel tempo, lasciando che ogni parte<br />

degli stessi sia soggetta a modifiche indipendenti. In realtà <strong>il</strong> fruitore dell’informazione<br />

può trovarsi di fronte a documenti che <strong>per</strong>cepisce come immutab<strong>il</strong>i (un<br />

atto di nascita, ma anche un articolo di giornale ormai pubblicato) così come<br />

ad entità intrinsecamente dinamiche (come lo stato del conto corrente bancario<br />

o lo stato di famiglia) che spesso vengono quantizzate con opportune tecniche<br />

di campionamento (nel tempo) al fine di renderle immutab<strong>il</strong>i e quindi più fac<strong>il</strong>mente<br />

trattab<strong>il</strong>i (l’estratto conto, lo stato di famiglia ad <strong>una</strong> certa data). In<br />

ogni caso è esistito un processo, eventualmente distribuito, attivo nell’intervallo<br />

[t1, t2] (con t1 ≤ t2) che ha portato alla generazione dell’informazione al tempo<br />

tx (immutab<strong>il</strong>e o meno) con tx ∈ [t1, t2]. Applicando quindi queste considerazioni<br />

all’esempio del documento patente, se i punti vengono azzerati come effetto<br />

di <strong>una</strong> serie di contravvenzioni, <strong>il</strong> documento <strong>per</strong>de di validità e possono venire<br />

automaticamente notificati degli avvisi ad <strong>una</strong> serie di soggetti. Da un punto di<br />

1 A livello logico: enti/organizzazioni diversi/e.<br />

2 A livello fisico: sistemi diversi (eventualmente appartenenti al medesimo ente).<br />

133


<strong>InterDataNet</strong> Information Model<br />

vista tecnico e formale (non giuridico) si determina la creazione automatica di<br />

<strong>una</strong> nuova patente: “se cambia <strong>una</strong> parte cambia l’intero aggregato delle parti”.<br />

Il documento IDN è quindi <strong>una</strong> entità attiva, in quanto può evolvere e cambiare<br />

comportamento sulla base dello stato assunto e dalle relazioni espresse<br />

all’interno <strong>per</strong> effetto del versionamento.<br />

Nell’<strong>InterDataNet</strong> Information Model (IDN-IM) le informazioni ottenute dal<br />

procedimento di suddivisione dei contenuti informativi sono chiamate informazioni<br />

atomiche (definizione in 4.2.1) la suddivisione termina nel momento in cui<br />

si incorre in un’informazione non ulteriormente (e ragionevolmente) frazionab<strong>il</strong>e,<br />

come ad esempio <strong>il</strong> nome o <strong>il</strong> cognome di <strong>una</strong> <strong>per</strong>sona.<br />

Ovviamente, questo procedimento necessita di raggiungere un compromesso<br />

tra la complessità, l’effettiva necessità di riuso dei contenuti informativi e<br />

l’adeguatezza della granularità della rappresentazione. Per tale motivo viene<br />

introdotto <strong>il</strong> concetto di informazione primitiva (definizione in 4.2.2).<br />

Nella presente trattazione si propone un approccio <strong>per</strong> la creazione di informazioni<br />

sufficientemente granulari da possedere le seguenti caratteristiche:<br />

• modularità, aggregab<strong>il</strong>i in maniera versat<strong>il</strong>e con altre;<br />

• indirizzab<strong>il</strong>ità, identificab<strong>il</strong>i sia logicamente che <strong>per</strong> indice;<br />

• riusab<strong>il</strong>ità, <strong>per</strong> la loro autonomia in diverse situazioni;<br />

• intero<strong>per</strong>ab<strong>il</strong>ità, indipendenti dal contesto.<br />

Tenendo presente le esigenze della collaborazione, in pratica si propone di applicare<br />

come regola strutturante <strong>il</strong> principio di responsab<strong>il</strong>ità sulle parti informative<br />

che costituiscono l’informazione. Principio che apre la strada alla possib<strong>il</strong>ità<br />

di elaborare in autonomia le singole parti di cui è costituito <strong>il</strong> documento.<br />

In questo scenario <strong>il</strong> responsab<strong>il</strong>e è colui <strong>il</strong> quale ha la consapevolezza di<br />

dover rispondere degli effetti che possono scaturire a seguito della divulgazione<br />

dell’informazione ([Inn04, Pao06, Inn08]). Il responsab<strong>il</strong>e può essere <strong>una</strong> <strong>per</strong>sona<br />

fisica oppure giuridica che crea o modifica l’informazione. Osserviamo che<br />

questa metodologia assume un valore estremamente determinante quando viene<br />

coinvolto <strong>il</strong> trattamento di informazioni sensib<strong>il</strong>i ed in generale da un punto di<br />

vista giuridico.<br />

Strutturare con questa tecnica significa agire su un piano trasversale ai contenuti<br />

semantici del documento, che possono essere ignorati a livello <strong>infrastrutturale</strong>.<br />

Su larga scala consente di realizzare in maniera automatizzata un insieme<br />

di mattoni informativi elementari che possono essere riut<strong>il</strong>izzati dalla comunità<br />

<strong>per</strong> costruire nuova informazione.<br />

Il principio di responsab<strong>il</strong>ità può anche essere inteso come conseguenza naturale<br />

dei processi organizzativi e metodologici individuati all’interno delle organizzazioni,<br />

ma sopratutto un modo relativamente più fac<strong>il</strong>e da automatizzare<br />

ed informatizzare che accompagna l’informazione durante <strong>il</strong> suo ciclo di vita.<br />

134


<strong>InterDataNet</strong> Information Model Nella direzione dell’Information Model<br />

Un’importante osservazione è legata alla assegnazione selettiva dei diritti di<br />

accesso <strong>per</strong> le singole informazioni quale condizione necessaria <strong>per</strong> poter parlare<br />

di responsab<strong>il</strong>e. Al responsab<strong>il</strong>e <strong>per</strong> esercitare <strong>il</strong> suo ruolo devono essere fornite<br />

le garanzie sulle modalità di gestione ed accesso all’informazione.<br />

All’interno dei documenti con i quali si interagisce possono essere individuate<br />

alcune categorie di informazioni che risultano le seguenti:<br />

• contenuti: elementi esplicitamente fruib<strong>il</strong>i dall’uomo e che sono direttamente<br />

individuab<strong>il</strong>i all’interno del documento. Rientrano in questa categoria<br />

i testi, le immagini, le date, i nomi, i contenuti multimediali,<br />

eccetera;<br />

• relazioni: legami fra contenuti che possono essere di tipo esplicito o implicito.<br />

Un esempio di legame esplicito può essere <strong>il</strong> riferimento ad <strong>una</strong><br />

pagina o paragrafo di un libro, ad un articolo presente in <strong>una</strong> legge, eccetera.<br />

In modo duale un legame implicito può essere quello esistente fra <strong>il</strong><br />

titolo di un capitolo di un libro e <strong>il</strong> contenuto del capitolo stesso;<br />

• presentazione: informazioni necessarie <strong>per</strong> mostrare correttamente <strong>il</strong> documento<br />

all’utente. Rientra a pieno titolo in questa categoria l’aspetto grafico,<br />

ovvero la scelta dei caratteri, dei colori, dell’impaginazione, eccetera.<br />

Questa categoria di informazioni fornisce un valore aggiunto che in particolari<br />

casi è determinante <strong>per</strong> <strong>per</strong>mettere la fruib<strong>il</strong>ità delle informazioni<br />

contenute nel documento;<br />

• informazioni aggiuntive: ulteriori informazioni associate al documento e/o<br />

che possono essere date <strong>per</strong> scontate. Ad esempio l’autore di un brano<br />

musicale oppure <strong>il</strong> fatto che i contenuti presenti nella prima pagina di<br />

un quotidiano rappresentano un sunto delle notizie più importanti del<br />

giornale.<br />

Queste categorie di informazioni sono state introdotte parlando di documento<br />

in senso astratto e/o nel senso convenzionale del termine. Nel momento in cui<br />

si intende codificare un documento <strong>per</strong> renderlo trattab<strong>il</strong>e dalle macchine occorre<br />

formalizzare al meglio questi concetti al fine di poterli gestire efficacemente<br />

ed efficientemente da un punto di vista informatico.<br />

4.1 Nella direzione dell’Information Model<br />

Si definisce Information Model <strong>una</strong> rappresentazione universale delle entità<br />

e delle loro proprietà, o<strong>per</strong>azioni e relazioni, <strong>il</strong> cui scopo principale è quello di<br />

modellare gli oggetti ad un livello concettuale, indipendentemente da qualsiasi<br />

specifico repository, applicazione, protocollo o piattaforma. Esso non riguarda i<br />

135


<strong>InterDataNet</strong> Information Model Nella direzione dell’Information Model<br />

dettagli, ma mira a catturare le astrazioni e i requisiti fondamentali delle entità<br />

da modellare.<br />

Un Data Model, invece, si occupa di gestire gli oggetti ad un livello di astrazione<br />

più basso, e comprende dettagli specifici dell’implementazione e del protocollo,<br />

ad esempio regole che spieghino come mappare gli oggetti gestiti su<br />

costrutti protocollari di livello più basso [PS03].<br />

Il principale vantaggio nell’uso di un Information Model è la possib<strong>il</strong>ità di<br />

generare, a partire da esso, più Data Model, intesi come i modelli concretamente<br />

realizzati. Questa capacità <strong>per</strong>mette la scalab<strong>il</strong>ità e l’adattab<strong>il</strong>ità del modello<br />

in contesti diversi e con tecnologie diverse.<br />

Un’ulteriore conseguenza è la possib<strong>il</strong>ità di scegliere, <strong>per</strong> la realizzazione, tra<br />

<strong>una</strong> vasta gamma di standard e tecnologie esistenti, se rispondenti alle esigenze.<br />

D’altra parte, questa prospettiva rappresenta anche <strong>una</strong> forte restrizione, in<br />

quanto la sott<strong>il</strong>e linea che divide <strong>il</strong> modello astratto dai relativi modelli concreti<br />

non è sempre di fac<strong>il</strong>e identificazione.<br />

IDN-IM è dunque <strong>una</strong> rappresentazione omogenea (uniforme, riconducib<strong>il</strong>e<br />

ai medesimi principi indipendentemente dal contenuto informativo che esprime),<br />

astratta (del tutto svincolata da specifiche implementazioni) e consistente (applicando<br />

i principi e le o<strong>per</strong>azioni previste dal modello IDN-IM su informazioni<br />

modellate con IDN-IM, <strong>il</strong> risultato è sempre prevedib<strong>il</strong>e e coerente con <strong>il</strong> modello<br />

stesso) dell’informazione, che ne cattura i requisiti, i principi e le proprietà<br />

desiderab<strong>il</strong>i in termini assoluti, oltre a rappresentare un modello di documento<br />

universale, indipendente dal particolare contesto e da tecnologie specifiche.<br />

Il paragrafo successivo <strong>il</strong>lustrerà quindi le principali motivazioni che hanno<br />

portato alla definizione dell’Information Model come descritto nel presente<br />

capitolo.<br />

4.1.1 Osservazioni sul modello<br />

Sulla base dell’analisi estesa dei requisiti discussa in [Inn08] e delle considerazioni<br />

riportate nell’introduzione del presente capitolo è possib<strong>il</strong>e elencare le<br />

caratteristiche che <strong>il</strong> documento definito da IDN-IM deve soddisfare.<br />

Alcune di esse risultano vincolanti <strong>per</strong> gli obiettivi del sistema, mentre altre<br />

sono desiderab<strong>il</strong>i al fine di garantire la massima applicab<strong>il</strong>ità ed estensib<strong>il</strong>ità del<br />

modello.<br />

Una prima caratteristica prevede che l’informazione sia strutturata, <strong>il</strong> che<br />

sottintende la necessità di poter riusare ed elaborare l’informazione con <strong>il</strong> minimo<br />

dispendio di risorse <strong>per</strong> la sua interpretazione.<br />

Ogni informazione deve essere strutturab<strong>il</strong>e, indipendentemente dalla sua<br />

forma fisica, anche se non si è certi che la struttura sia univocamente determinab<strong>il</strong>e<br />

a fronte di scelte interpretative diverse.<br />

136


<strong>InterDataNet</strong> Information Model Nella direzione dell’Information Model<br />

Inoltre, l’informazione deve poter essere aggregab<strong>il</strong>e <strong>per</strong> formare <strong>una</strong> nuova<br />

informazione.<br />

Ciò deriva dall’osservazione che l’unione di più informazioni ha come risultato<br />

un’informazione nuova, diversa da ciasc<strong>una</strong> delle sue componenti. Viceversa,<br />

la scomposizione dell’informazione in entità elementari più semplici consente di<br />

massimizzare <strong>il</strong> riuso, la trasportab<strong>il</strong>ità e l’autoconsistenza di ciascun aggregato.<br />

Un ulteriore vantaggio è rappresentato dalla possib<strong>il</strong>ità di definire funzioni di<br />

accesso e di modifica in modo mirato.<br />

Al fine di mantenere le regole di strutturazione dell’informazione indipendenti<br />

dai contenuti informativi, onde evitare <strong>il</strong> rischio di contaminare <strong>il</strong> modello<br />

con problematiche relative a specifici contesti, viene applicato <strong>il</strong> “principio di<br />

responsab<strong>il</strong>ità”.<br />

In modo del tutto ortogonale ai contenuti informativi, si assume che l’informazione<br />

sia <strong>il</strong> risultato di produzioni iterative: ciascun passo vede un responsab<strong>il</strong>e<br />

(spesso, ma non sempre, coincidente con l’autore) che produce informazione<br />

a partire da informazioni già esistenti in forma più semplice. Tale assunzione è<br />

garantita dalla definizione stessa di informazione, poiché esiste sempre almeno<br />

un attore che crea e/o controlla l’informazione. Assumere a priori che <strong>il</strong> modello<br />

sia strutturato sulla base di tale principio risulta coerente con le dinamiche del<br />

workflow e i modelli ad oggetti.<br />

Lo stesso principio si può riscontrare nei sistemi blog e wiki, nei quali la<br />

composizione di informazioni avviene sulla base di contributi incrementali, gestiti<br />

da autorità con responsab<strong>il</strong>ità distinte, che assieme vanno a costituire un<br />

nuovo documento.<br />

L’informazione deve essere indipendente dalla locazione fisica. Questo punto<br />

intende mettere in evidenza che un’informazione è tale indipendentemente da<br />

dove sia fisicamente collocata. Spesso, infatti, la stessa informazione viene memorizzata<br />

in apparati fisici distinti ed eterogenei, che <strong>per</strong>ò non devono influire<br />

sui contenuti informativi. Questa affermazione potrebbe sembrare banale, ma<br />

agli effetti pratici la detenzione fisica dei dati da parte di <strong>una</strong> organizzazione<br />

risulta spesso essere ingessante <strong>per</strong> <strong>il</strong> sistema organizzativo ed informativo (anche<br />

internamente) che può risentire delle costrizioni imposte da normative o da<br />

pratiche adottate da un nucleo ristretto di aff<strong>il</strong>iati.<br />

L’informazione già esistente nelle organizzazioni è distribuita <strong>per</strong> definizione,<br />

<strong>per</strong> cui questo requisito è soddisfatto a priori; <strong>il</strong> problema da affrontare è come<br />

realizzarne l’acquisizione, l’arricchimento e la manutenzione in modo distribuito<br />

e consistente, guardando alla distribuzione già esistente come a un vantaggio da<br />

sfruttare, e non come a uno svantaggio da azzerare.<br />

Una caratteristica che non è obbligatoria ma fortemente desiderab<strong>il</strong>e, in<br />

quanto sostiene i requisiti di affidab<strong>il</strong>ità e scalab<strong>il</strong>ità, è che l’informazione sia replicata.<br />

La replicazione introduce un certo numero di vantaggi, come l’aumento<br />

137


<strong>InterDataNet</strong> Information Model I nodi informativi<br />

della disponib<strong>il</strong>ità dell’informazione, garantendone <strong>il</strong> recu<strong>per</strong>o a fronte di guasti,<br />

e <strong>il</strong> dimensionamento adattativo nel tempo del sistema in funzione della richiesta.<br />

Si osservi che IDN-IM non tratta direttamente <strong>il</strong> tema della replicazione,<br />

ma si limita ad ab<strong>il</strong>itarla. In altre parole, come sarà chiarito nella descrizione<br />

di IDN-SA nel capitolo 5, <strong>il</strong> modello <strong>per</strong>mette la realizzazione di sistemi <strong>per</strong> la<br />

replicazione dell’informazione, in grado di o<strong>per</strong>are in modo del tutto trasparente<br />

<strong>per</strong> l’utente.<br />

È necessario che l’informazione sia tracciab<strong>il</strong>e, di conseguenza <strong>il</strong> sistema deve<br />

essere dotato di uno storico e di un meccanismo di versionamento (versioning)<br />

dell’informazione. La sola presenza dell’informazione risulta sicuramente riduttiva<br />

e inespressiva nello svolgimento delle attività collaborative all’interno delle<br />

organizzazioni, le quali richiedono che sia possib<strong>il</strong>e tracciare la storia dell’informazione<br />

in quanto legata al workflow e all’authoring concorrente e <strong>per</strong> la<br />

determinazione a posteriori delle responsab<strong>il</strong>ità.<br />

È indispensab<strong>il</strong>e che l’informazione sia indirizzab<strong>il</strong>e in modo efficace e flessib<strong>il</strong>e<br />

sia sul piano telematico che come modello di supporto alle attività collaborative.<br />

La prassi di assegnare alias alla stessa informazione viene coadiuvata e<br />

formalizzata attraverso un opportuno sistema di nomi, mentre la loro gestione<br />

è delegata all’architettura stessa.<br />

Infine, bisogna tenere presente che un’informazione è tanto più ut<strong>il</strong>e quanto<br />

più è orientata alla collaborazione, ossia è stata creata con lo scopo di essere<br />

condivisa e sfruttata da più utenti, fac<strong>il</strong>itandone l’ut<strong>il</strong>izzo su larga scala.<br />

4.2 I nodi informativi<br />

La struttura del documento in IDN-IM è rappresentata da un grafo diretto<br />

aciclico (Directed Acyclic Graph, in breve DAG) [Die05].<br />

Il vincolo principale è che non sono <strong>per</strong>messi cicli, ossia sequenze di nodi<br />

attraversando le quali a partire da un nodo qualsiasi si finisce sullo stesso nodo.<br />

Si noti che <strong>una</strong> struttura ad albero è un caso specifico del DAG, in cui ciascun<br />

nodo ha al più un genitore: le strutture a DAG sono <strong>per</strong>ciò capaci di modellare<br />

tutte le risorse strutturate ad albero [Die05]. Questa proprietà rappresenta un<br />

vantaggio quando si passa dal modello informativo al modello dati.<br />

In IDN quindi le relazioni tra i nodi della struttura del documento sono<br />

gerarchiche, cioè esiste <strong>una</strong> relazione di tipo padre-figlio tale che <strong>il</strong> progenitore<br />

è sempre distinguib<strong>il</strong>e dal suo discendente, a differenza del caso della presenza<br />

di cicli.<br />

L’approccio IDN prevede che l’informazione non sia necessariamente memorizzata<br />

in un documento, ma anche eventualmente collegata nel documento e tra<br />

documenti, <strong>per</strong> cui non è detto che sia “fisicamente” codificata al suo interno.<br />

La metafora principale che è stata seguita nella progettazione del modello è<br />

138


<strong>InterDataNet</strong> Information Model I nodi informativi<br />

quella contenitore/contenuto: ogni elemento informativo può essere visto come<br />

<strong>il</strong> contenitore di elementi informativi più elementari, i contenuti, ottenuti a<br />

loro volta come composizione di elementi sempre più granulari; <strong>il</strong> procedimento<br />

procede fino al raggiungimento degli “atomi” non ulteriormente suddivisib<strong>il</strong>i.<br />

L’esempio dell’atomo è calzante: non ulteriormente suddivisib<strong>il</strong>i se ut<strong>il</strong>izzati con<br />

lo scopo di creare la “materia” informativa, ma potenzialmente scomponib<strong>il</strong>i <strong>per</strong><br />

altri scopi, quali la memorizzazione su supporto digitale in cui la granularità è<br />

sempre quella del bit. Un esempio di“atomo informativo”è senz’altro <strong>il</strong> cognome<br />

di <strong>una</strong> <strong>per</strong>sona all’interno di un atto giuridico che sarà contenuto nella sezione<br />

dedicata ai dati anagrafici, che non è diffic<strong>il</strong>e ipotizzare come parte costituente<br />

di <strong>una</strong> qualche altra sezione dell’atto stesso.<br />

L’informazione atomica (Atomic Information Unit, AIU), che quindi rappresenta<br />

l’entità informativa più elementare, è indivisib<strong>il</strong>e ed è definita come <strong>una</strong><br />

tripla .<br />

Ogni informazione atomica, <strong>per</strong>ché sia significativa nello spazio dei documenti<br />

definiti da IDN-IM, deve essere contenuta in un, e soltanto in un, nodo<br />

del grafo, detto informazione primitiva (PIU).<br />

Le informazioni primitive, oltre ad essere i bu<strong>il</strong>ding block dei documenti IDN-<br />

IM, hanno <strong>una</strong> caratteristica fondamentale: l’indirizzab<strong>il</strong>ità tramite nomi che ne<br />

riflettono la struttura. Ogni informazione primitiva è infatti identificata da almeno<br />

un nome canonico (ovvero che ne <strong>per</strong>mette direttamente l’identificazione)<br />

e da zero, uno o più alias (che ne <strong>per</strong>mettono l’identificazione indirettamente in<br />

quanto fanno riferimento ad altri nomi, alias o canonici). Nel momento in cui<br />

un’informazione primitiva viene aggregata da (contenuta in) un’altra informazione<br />

primitiva, acquisisce un nuovo alias derivato dal nome della PIU genitore<br />

che esprime <strong>il</strong> nuovo rapporto di parentela.<br />

Ogni nodo del grafo che non ha figli <strong>per</strong>ciò è detto foglia e contiene almeno<br />

un’informazione atomica; ogni nodo del grafo che non è <strong>una</strong> foglia aggrega (contiene)<br />

<strong>per</strong> definizione almeno un’informazione primitiva e può contenere <strong>una</strong> o<br />

più informazioni atomiche.<br />

4.2.1 Informazioni atomiche<br />

Come anticipato l’informazione atomica (Atomic Information Unit, AIU) è<br />

<strong>una</strong> tripla . I valori che vengono memorizzati sono soggetti<br />

a verifica sintattica e di ammissib<strong>il</strong>ità (eventualmente sulla base del tipo).<br />

Ad esempio consideriamo l’informazione atomica rappresentante<br />

<strong>il</strong> Codice di Avviamento Postale italiano <strong>per</strong> la città di Firenze. Il<br />

nome è un’etichetta che identifica la AIU nel contesto in cui è collocata (all’interno<br />

di <strong>una</strong> PIU) e <strong>per</strong>tanto, <strong>per</strong> <strong>il</strong> generico utente che inserisce/definisce <strong>il</strong><br />

dato, può avere un certo peso semantico.<br />

Il tipo esprime <strong>il</strong> concetto che <strong>il</strong> valore è un CAP e <strong>per</strong>tanto è un elemento<br />

139


<strong>InterDataNet</strong> Information Model I nodi informativi<br />

dell’elenco dei CAP stab<strong>il</strong>iti dalle Poste Italiane; così <strong>il</strong> valore “FI-50100” è<br />

sintatticamente scorretto e“01234”è sintatticamente corretto, ma inammissib<strong>il</strong>e.<br />

Visto che <strong>il</strong> modello non è <strong>una</strong> base di dati e non è dotato di algebra relazionale<br />

sembrerebbe impossib<strong>il</strong>e stab<strong>il</strong>ire se <strong>il</strong> requisito di accuratezza possa<br />

essere sempre soddisfatto. La risposta al problema consiste nell’ipotizzare che<br />

tutte le informazioni atomiche e primitive siano create e messe a disposizione<br />

da un’entità responsab<strong>il</strong>e che ne garantisce l’accuratezza. La definizione esatta<br />

del significato sarà poi demandata al responsab<strong>il</strong>e di quella informazione.<br />

Per quanto riguarda le informazioni atomiche questo è ottenib<strong>il</strong>e, senza <strong>per</strong>dere<br />

in generalità, tramite contenimento entro informazioni primitive. In altre<br />

parole ogni informazione atomica è associata ad <strong>una</strong> e <strong>una</strong> sola informazione<br />

primitiva la quale <strong>per</strong>mette di proiettare la tripla nello<br />

spazio dei documenti IDN. Questo è conseguenza dal fatto che ogni istanza<br />

di <strong>una</strong> qualsiasi tripla non è un’informazione atomica,<br />

ma può divenire tale se viene “inquadrata” nell’ambito dei documenti IDN e<br />

l’incapsulamento di cui sopra ha la finalità di svolgere questa o<strong>per</strong>azione.<br />

Un esempio che <strong>per</strong>mette di chiarire questo tema è relativo al concetto di<br />

responsab<strong>il</strong>ità dell’informazione appena citato: parafrasando ciò che è stato<br />

introdotto in precedenza ogni informazione presente in un qualsiasi documento<br />

IDN deve avere un responsab<strong>il</strong>e, ovvero l’entità che ha autorità su di essa. In<br />

questo contesto è sufficiente considerare <strong>il</strong> responsab<strong>il</strong>e come <strong>una</strong> proprietà,<br />

o attributo, dell’informazione. In questi termini l’incapsulamento della tripla<br />

all’interno di un’informazione primitiva <strong>per</strong>mette di farle<br />

ereditare <strong>il</strong> responsab<strong>il</strong>e di quest’ultima, rendendola quindi dotata dell’attributo<br />

necessario <strong>per</strong> poter appartenere allo spazio delle informazioni definite in IDN.<br />

In questo modo <strong>il</strong> problema della gestione delle informazioni viene semplificato:<br />

• da <strong>una</strong> parte viene ricondotto verso <strong>il</strong> gestore di quella informazione, <strong>il</strong><br />

quale ha le nozioni sufficienti a stab<strong>il</strong>ire le regole sintattiche e le condizioni<br />

a contorno;<br />

• dall’altra l’utente consumatore ha <strong>il</strong> dovere di cercare i valori e non più<br />

l’onere di acquisirli nuovamente.<br />

In questo modo si tende anche a realizzare <strong>il</strong> presupposto ai requisiti di<br />

unico inserimento dei dati nel sistema, <strong>per</strong>tinenza e non eccedenza ([Inn04]).<br />

Comunque <strong>per</strong> non rendere troppo rigido <strong>il</strong> modello dovrà essere tenuta in<br />

considerazione anche la possib<strong>il</strong>ità di:<br />

• inserire i dati con strategie di autonomia a responsab<strong>il</strong>ità diversificata;<br />

• correggerli ed arricchirli in fasi successive ed indipendenti.<br />

140


<strong>InterDataNet</strong> Information Model I nodi informativi<br />

4.2.2 Informazioni primitive<br />

È stato anticipato che le informazioni primitive modellano gli aspetti strutturali<br />

sfruttando <strong>il</strong> principio di aggregazione fra nodi. Ogni nodo contenente<br />

un’informazione primitiva può essere genitore di <strong>una</strong> serie di nodi contenenti<br />

altre informazioni primitive. L’unico vincolo esistente è che nella struttura non<br />

siano presenti cicli (ovvero ogni informazione primitiva non può essere figlia,<br />

nipote, pronipote, etc. o antenata di se stessa).<br />

Ogni informazione primitiva è quindi genitore di altre informazioni primitive<br />

e contiene al proprio interno un certo numero di informazioni atomiche. Si<br />

osservi come da questo caso generale si possano definire documenti, come casi<br />

particolari, introducendo ulteriori restrizioni.<br />

Ad esempio un vincolo che può essere introdotto riguarda la mutua esclusione<br />

fra l’aggregazione di altre PIU e <strong>il</strong> contenimento di AIU: in questi termini<br />

ogni informazione primitiva aggrega altre informazioni primitive senza contenere<br />

informazioni atomiche oppure contiene informazioni atomiche senza aggregare<br />

informazioni primitive. Documenti strutturati secondo questa modalità hanno<br />

le informazioni atomiche esclusivamente nelle foglie. Inoltre tutte le foglie contengono<br />

necessariamente informazioni atomiche e <strong>per</strong>tanto esiste <strong>una</strong> <strong>per</strong>fetta<br />

corrispondenza fra le foglie e le informazioni atomiche e fra gli altri nodi e le<br />

informazioni primitive.<br />

L’associazione al responsab<strong>il</strong>e avviene a livello di informazione primitiva:<br />

<strong>il</strong> responsab<strong>il</strong>e deve garantire la correttezza della struttura (legame logico tra<br />

le parti) e, <strong>per</strong> le informazioni atomiche incapsulate, la correttezza dei dati<br />

associati alle coppie .<br />

Per esempio si faccia l’ipotesi che la patente di guida (semplificata) contenga<br />

i seguenti elementi (<strong>una</strong> versione più appr<strong>of</strong>ondita di questo esempio verrà<br />

riportata nel capitolo 6):<br />

• anagrafica;<br />

• residenza;<br />

• categoria guida;<br />

• punti.<br />

In questo esempio la Motorizzazione Civ<strong>il</strong>e deve garantire la correttezza delle<br />

triple e ; inoltre<br />

deve garantire anche la corretta aggregazione delle informazioni di anagrafica e<br />

residenza. È l’anagrafe com<strong>una</strong>le del comune di nascita a garantire la correttezza<br />

delle informazioni atomiche relative ai dati anagrafici. È <strong>il</strong> comune di residenza<br />

a garantire la correttezza dell’indirizzo.<br />

141


<strong>InterDataNet</strong> Information Model Relazioni strutturali tra nodi e documenti<br />

Da un punto di vista astratto è possib<strong>il</strong>e considerare le informazioni primitive<br />

come <strong>il</strong> punto di accesso all’informazione complessiva che si sv<strong>il</strong>uppa da esse fino<br />

alle foglie, come rappresentato in figura 4.1.<br />

4.3 Relazioni strutturali tra nodi e documenti<br />

In IDN-IM sono definiti tre principali tipi di collegamento:<br />

• Collegamenti di aggregazione. Per esprimere le relazioni genitoriali tra i<br />

nodi del grafo all’interno dello stesso documento. Ad esempio, nella figura<br />

4.1, l’informazione primitiva A è genitore dell’informazione primitiva B.<br />

Si noti che i link di aggregazione uscenti hanno un nome locale relativo al<br />

nodo dal quale escono come sarà chiarito nel paragrafo 4.5.<br />

• Collegamenti di segnalazione (degli aggiornamenti). Per ab<strong>il</strong>itare <strong>il</strong> meccanismo<br />

di propagazione degli aggiornamenti. Se è definito un collegamento<br />

di segnalazione da A a B questo significa che se A viene aggiornata, <strong>il</strong><br />

sistema informatico autoritativo (responsab<strong>il</strong>e) su B verrà notificato relativamente<br />

all’aggiornamento di A. IDN-IM ut<strong>il</strong>izza questo tipo di link fra<br />

PIU come base del modello di versionamento in uso (descritto in 4.6), ma<br />

tali link sono stati introdotti come strumento attraverso <strong>il</strong> quale implementare<br />

generici meccanismi di notifica ut<strong>il</strong>izzab<strong>il</strong>i anche <strong>per</strong> scopi diversi<br />

(che possono dipendere dal contesto in cui verrà applicato IDN-IM).<br />

• Collegamenti di riferimento. Per esprimere relazioni tra documenti diversi<br />

(e quindi tra grafi diversi) e/o elementi esterni al modello. Questo tipo di<br />

collegamento è classificato come informazione atomica e <strong>per</strong>ciò è trattato<br />

come <strong>una</strong> normale tripla , dove <strong>il</strong> valore è <strong>il</strong> nome<br />

dell’elemento a cui viene fatto riferimento mentre <strong>il</strong> tipo è “link di riferimento”.<br />

I collegamenti di riferimento vengono memorizzati nelle PIU e<br />

non hanno influenze di alcun tipo sul comportamento del modello. In altre<br />

parole i link di riferimento vengono definiti e gestiti dall’ut<strong>il</strong>izzatore del<br />

modello IDN-IM, quest’ultimo si limita solo a memorizzarli.<br />

Si definisce <strong>il</strong> documento IDN come un insieme di nodi PIU (Primitive Information<br />

Unit), uno dei quali è detto radice, messi in relazione tra di loro<br />

attraverso collegamenti di aggregazione [PPCP07]. Applicando la definizione in<br />

modo ricorsivo, ciascun documento può essere considerato come un’aggregazione<br />

di documenti.<br />

Nella figura 4.1, l’informazione primitiva presente nel documento Doc1 <strong>il</strong> cui<br />

tipo è D è aggregata sia dall’informazione primitiva <strong>il</strong> cui tipo è B che da quella <strong>il</strong><br />

cui tipo è C tramite collegamenti i cui nomi locali sono 3 e 4 rispettivamente. In<br />

corrispondenza di ogni link di aggregazione è presente un link di segnalazione,<br />

142


<strong>InterDataNet</strong> Information Model Strutturare con criteri di responsab<strong>il</strong>ità<br />

Documento IDN - Doc1<br />

Radice<br />

Doc1 Type:A Tipo:A<br />

<br />

<br />

<br />

5<br />

1 2<br />

Documento<br />

IDN<br />

Type:B Tipo:B<br />

Type:C Tipo:C<br />

<br />

<br />

<br />

<br />

<br />

<br />

Documento<br />

IDN<br />

3 4<br />

Type:D Tipo:D<br />

<br />

<br />

<br />

Documento<br />

IDN<br />

Doc2<br />

Tipo:D<br />

<br />

<br />

Radice<br />

Doc2<br />

Tipo:E<br />

<br />

<br />

6 7<br />

Tipo:D<br />

<br />

<br />

Legenda tipi di link<br />

aggregazione<br />

riferimento<br />

segnalazione<br />

Figura 4.1: Esempio di documento IDN.<br />

mentre <strong>il</strong> collegamento di riferimento <strong>il</strong> cui nome locale è 5 e che lega <strong>il</strong> documento<br />

Doc2 a Doc1, non ha associato <strong>il</strong> corrispondente link di segnalazione di<br />

senso opposto.<br />

Il documento è strutturato <strong>per</strong>ché risulta dall’aggregazione di informazioni<br />

elementari, le informazioni primitive, le quali a loro volta contengono le informazioni<br />

atomiche. Questa struttura, determinata mediante l’applicazione del principio<br />

di responsab<strong>il</strong>ità, consente di introdurre <strong>una</strong> misura della granularità e dei<br />

livelli di dettaglio dell’informazione, in cui ciasc<strong>una</strong> parte è complessivamente<br />

individuab<strong>il</strong>e indirizzando <strong>il</strong> nodo di interesse.<br />

Quindi in IDN un documento è composto da informazioni atomiche che ne<br />

rappresentano <strong>il</strong> contenuto e da informazioni primitive che ne rappresentano le<br />

proprietà strutturali, cioè le relazioni tra i nodi, oltre alle caratteristiche dell’informazione<br />

definite nel modello stesso come ad esempio l’entità responsab<strong>il</strong>e del<br />

contenuto.<br />

4.4 Strutturare con criteri di responsab<strong>il</strong>ità<br />

La responsab<strong>il</strong>ità è un criterio ortogonale <strong>per</strong> definire e strutturare l’informazione<br />

a prescindere dal suo contenuto, basandosi sulla gerarchia delle organizzazioni:<br />

<strong>il</strong> problema della strutturazione è stato spostato su un piano<br />

organizzativo.<br />

In contesti specifici, come ad esempio nella Pubblica Amministrazione (ma<br />

non solo), <strong>per</strong> ogni nodo deve essere definita un’entità responsab<strong>il</strong>e (individuab<strong>il</strong>e<br />

anche grazie alle normative). In IDN-IM questo attore è <strong>una</strong> <strong>per</strong>sona fisica<br />

o giuridica che si occupa di garantire l’accuratezza dei dati, cioè la validità<br />

143


<strong>InterDataNet</strong> Information Model Identificazione di nodi e documenti<br />

delle informazioni atomiche contenute nel nodo, e la correttezza della struttura,<br />

ovvero delle relazioni logiche tra i nodi [PPC + 08]. Si noti che l’autore e <strong>il</strong> responsab<strong>il</strong>e<br />

di un nodo sono entità separate, e che <strong>una</strong> tripla <br />

contenuta in un’informazione primitiva eredita <strong>il</strong> responsab<strong>il</strong>e.<br />

Ogni informazione primitiva può contenere dati specifici da usare <strong>per</strong> verificare<br />

se l’utente ha i diritti <strong>per</strong> eseguire <strong>una</strong> certa o<strong>per</strong>azione, ad esempio<br />

l’aggiornamento, su un certo nodo. I diritti di accesso ad un particolare nodo<br />

da parte degli utenti possono essere garantiti con l’approccio delle ACL (Access<br />

Control List) [Tan94].<br />

4.5 Identificazione di nodi e documenti<br />

A livello del modello IDN-IM i nodi vengono identificati tramite nomi logici,<br />

detti LRI (Logical Resource Identifier). Per loro natura gli LRI che fanno<br />

riferimento alla medesima informazione sono tutti equivalenti, nel senso che <strong>per</strong>mettono<br />

di o<strong>per</strong>are sull’informazione allo stesso modo. La necessità di assegnare<br />

più nomi logici alla medesima informazione deriva dalla natura stessa dell’informazione<br />

nel momento in cui viene calata in un contesto di massimo riuso come<br />

nel caso del modello IDN-IM: la stessa informazione calata (riusata) in contesti<br />

diversi ha nomi diversi e questo è un dato di fatto che deriva dal comune modo<br />

di ragionare dell’essere umano. La “patente di Lucia” è <strong>il</strong> nome che <strong>per</strong> <strong>il</strong> sottoscritto<br />

potrebbe avere la patente di guida di Lucia; <strong>per</strong> Lucia <strong>il</strong> nome sarebbe<br />

“la mia patente”, mentre <strong>per</strong> la Motorizzazione Civ<strong>il</strong>e potrebbe essere qualcosa<br />

del tipo “. . . /FI/1998/NUM XYZ”.<br />

Nonostante questo <strong>il</strong> modello prevede due sotto-classi di LRI: canonici e<br />

alias. Ogni informazione è identificata <strong>per</strong> convenzione tramite uno o più nomi<br />

canonici e zero, uno o più alias. La convenzione prevede che quando <strong>il</strong> nodo viene<br />

creato gli venga assegnato un LRI canonico invariab<strong>il</strong>e nel tempo che dipende<br />

dal contesto nel quale <strong>il</strong> nodo viene creato. Gli LRI detti canonici possono<br />

essere assim<strong>il</strong>ati agli hard-link dei f<strong>il</strong>esystem Unix in quanto rappresentano <strong>una</strong><br />

“maniglia” <strong>per</strong> l’accesso diretto all’informazione a cui fanno riferimento.<br />

Gli utenti possono arbitrariamente assegnare ulteriori LRI secondo le loro<br />

necessità ai singoli nodi. Richiamando nuovamente l’esempio dei f<strong>il</strong>esystem Unix<br />

in relazione ai link simbolici, la modalità principale con la quale questo è reso<br />

possib<strong>il</strong>e è tramite la creazione di alias, ovvero LRI che fanno riferimento ad<br />

altri LRI (i quali possono essere a loro volta canonici o alias).<br />

Infine, come introdotto nel paragrafo 4.3, i nodi fanno parte di documenti<br />

strutturati a DAG, quindi ad essi sono costruib<strong>il</strong>i ulteriori LRI determinati dalla<br />

posizione assunta nella struttura.<br />

Per esprimere in modo più efficace questo concetto è possib<strong>il</strong>e fare riferimento<br />

ad un esempio. Nella figura 4.2 è mostrato un documento IDN, Doc1, che<br />

144


<strong>InterDataNet</strong> Information Model Identificazione di nodi e documenti<br />

contiene quattro nodi e quattro collegamenti di aggregazione di nome 1, 2, 3, e<br />

4.<br />

Documento IDN - Doc1<br />

nome:<br />

Doc1URI<br />

1<br />

3<br />

nome:<br />

Doc1URI/1<br />

2<br />

nome:<br />

Doc1URI/2<br />

4<br />

nomi:<br />

Doc1URI/1/3<br />

Doc1URI/2/4<br />

Figura 4.2: Esempio di relazioni tra documenti IDN-IM.<br />

Il nodo Doc1URI/1/3 ha questo nome in quanto figlio del nodo Doc1URI/1<br />

attraverso <strong>il</strong> collegamento di nome 3. Per lo stesso motivo, ha anche <strong>il</strong> nome<br />

Doc1URI/2/4 <strong>per</strong>ché è raggiungib<strong>il</strong>e anche dal nodo Doc1URI/2 attraverso <strong>il</strong><br />

collegamento di nome 4.<br />

In altre parole, ogni nome ha la seguente struttura [PPC + 08]:<br />

node_parent_name + / + link_name<br />

dove:<br />

• node_parent_name è <strong>il</strong> nome del nodo genitore;<br />

• + è l’o<strong>per</strong>atore di concatenazione tra stringhe;<br />

• link_name è <strong>il</strong> nome del collegamento che mette in relazione <strong>il</strong> genitore<br />

con <strong>il</strong> nodo da indirizzare.<br />

Nella figura 4.2, se si considera <strong>il</strong> nodo Doc1URI come radice locale i suoi<br />

successori hanno i seguenti nomi relativi: ./1, ./2, ./1/3 e ./2/4.<br />

Una caratteristica degli LRI è che, sfruttando <strong>una</strong> semplice convenzione (ancora<br />

analoga a quanto accade nei f<strong>il</strong>esystem), possono essere ut<strong>il</strong>izzati <strong>per</strong> identificare<br />

<strong>il</strong> singolo nodo oppure <strong>il</strong> documento radicato nel nodo in questione. La<br />

145


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

convenzione consiste nel considerare gli LRI che terminano con “/” identificatori<br />

di documenti mentre gli altri identificatori di nodi. La convenzione è inoltre<br />

tale <strong>per</strong> cui che se “...xyz/unLRI/” rappresenta <strong>il</strong> documento “X”, <strong>il</strong> nome LRI<br />

“...xyz/unLRI” (senza slash finale) rappresenta <strong>il</strong> nodo radice di “X”.<br />

Infine gli alias, che in ogni caso <strong>of</strong>frono la dereferenziab<strong>il</strong>ità diretta, possono<br />

essere invertib<strong>il</strong>i a livello globale oppure solamente a livello locale. Questo<br />

significa che se “A” è un alias di “B” è sempre possib<strong>il</strong>e raggiungere “B” partendo<br />

da “A” (dereferenziab<strong>il</strong>ità diretta). Per quanto riguarda la ri<strong>soluzione</strong> inversa è<br />

possib<strong>il</strong>e trovarsi di fronte a due casi:<br />

• invertib<strong>il</strong>ità globale; in questo caso a livello globale è possib<strong>il</strong>e risalire ad<br />

“A” partendo da “B”. Questo tipo di invertib<strong>il</strong>ità <strong>of</strong>fre un legame bidirezionale<br />

fra i due soggetti interessati dalla relazione instaurata dall’alias.<br />

Questo da un lato rende <strong>il</strong> legame più forte, ma può limitare la scalab<strong>il</strong>ità<br />

e la semplicità di realizzazione dell’alias, o<strong>per</strong>azione che richiede la<br />

collaborazione dell’organizzazione a cui fa capo l’elemento referenziato;<br />

• invertib<strong>il</strong>ità locale; in questo caso è possib<strong>il</strong>e risalire ad “A” partendo da<br />

“B” limitatamente al contesto dell’organizzazione a cui fa capo “A”. In altre<br />

parole all’interno di ogni organizzazione è possib<strong>il</strong>e effettuare la ri<strong>soluzione</strong><br />

inversa di tutti gli alias invertib<strong>il</strong>i globalmente e di tutti gli alias definiti<br />

internamente all’organizzazione stessa.<br />

4.6 Storico dei documenti<br />

Il mantenimento delle versioni (revisioni) dell’informazione e l’automazione<br />

della generazione delle stesse garantiscono la massima tracciab<strong>il</strong>ità, <strong>per</strong>mettendo<br />

di ricostruire l’evoluzione dell’informazione nel tempo a fronte delle modifiche.<br />

IDN-IM è stato dotato dei principi del modello UEVM (Unified Extensional<br />

Versioning Model) [ABCM99], che organizza le versioni di documenti strutturati<br />

come DAG riuscendo a versionare, con tecniche automatizzate, sia i contenuti<br />

che gli aspetti strutturali. Ulteriori dettagli sul versioning in IDN-IM sono<br />

disponib<strong>il</strong>i in [Chi05, Inn08].<br />

Ogni documento, se necessario, può disporre quindi di caratteristiche atte a<br />

memorizzarne l’evoluzione temporale, chiamata storico. Tale evoluzione, sebbene<br />

sia <strong>una</strong> caratteristica globale del documento, viene mantenuta memorizzando<br />

l’evoluzione delle singole informazioni che lo costituiscono (a livello di nodo).<br />

Le evoluzioni temporali delle singole informazioni (che si ricorda essere strutturate<br />

a DAG), pur essendo mantenute separate ed associate ad esse, non sono<br />

indipendenti: <strong>una</strong> modifica effettuata ad un’informazione che si trova ad un<br />

livello più basso della gerarchia si ri<strong>per</strong>cuote, grazie ai link di segnalazione, su<br />

tutti i suoi predecessori. Questo fa sì che lo storico della radice “comprenda”,<br />

146


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

seppur indirettamente, l’evoluzione temporale di tutto <strong>il</strong> documento. Volendo<br />

recu<strong>per</strong>are <strong>una</strong> data versione è previsto un meccanismo di navigazione nello<br />

storico che, partendo dalla radice ed attraversando i vari nodi del documento,<br />

<strong>per</strong>mette di ricomporlo come richiesto. È ut<strong>il</strong>e evidenziare come <strong>il</strong> meccanismo,<br />

basandosi su un modello estensionale, <strong>per</strong>metta, a differenza di altri modelli di<br />

versioning, di ri<strong>per</strong>correre lo storico del documento nel modo più naturale possib<strong>il</strong>e<br />

<strong>per</strong> l’utente: ogni versione del documento viene ricostruita correttamente<br />

sia <strong>per</strong> quel che riguarda i dati contenuti sia <strong>per</strong> quanto riguarda gli aspetti<br />

strutturali.<br />

Lo storico è interrogab<strong>il</strong>e esprimendo esplicitamente la versione desiderata,<br />

comunque è possib<strong>il</strong>e estendere l’interrogazione anche attraverso alcuni parametri<br />

di versione (descritti nel paragrafo 4.6.2).<br />

Per descrivere i meccanismi di gestione dello storico è ut<strong>il</strong>e inizialmente fare<br />

riferimento ad un documento costituito da un unico nodo e, successivamente,<br />

estendere <strong>il</strong> concetto al caso generale.<br />

Sotto l’ipotesi che ogni nodo, <strong>una</strong> volta creato, sia <strong>una</strong> grandezza immutab<strong>il</strong>e<br />

nel tempo l’o<strong>per</strong>azione di modifica dà vita ad un nuovo nodo. Si definisce<br />

versione un’informazione primitiva ottenuta modificando <strong>il</strong> contenuto informativo<br />

di un nodo esistente. Anche la nascita di <strong>una</strong> nuova informazione rientra<br />

in questa definizione considerando che tale o<strong>per</strong>azione può essere vista come la<br />

modifica dell’informazione nulla. Viene definito uno stato UPDATE che viene<br />

associato ad ogni informazione <strong>per</strong> determinare se è necessario generare nuove<br />

versioni oppure effettuare sovrascritture. Il valore assunto dallo stato può essere<br />

frozen o changing rispettivamente. Lo stato changing non verrà discusso ulteriormente<br />

in questo paragrafo in quanto modella documenti e/o informazioni<br />

non versionati.<br />

A questo punto può essere ut<strong>il</strong>e chiarire cosa si intende con “modifica” di<br />

un’informazione al variare del tipo di essa:<br />

• nel caso di informazione atomica si parla di cambiamento di uno dei tre<br />

elementi ;<br />

• nel caso di informazione primitiva si parla di cambiamento di <strong>una</strong> o più<br />

delle relazioni di aggregazione che escono dall’informazione in esame (quindi<br />

della struttura dei documenti che la contengono) oppure della variazione<br />

delle informazioni atomiche contenute (quindi anche dei link di riferimento<br />

che si ricorda essere un caso particolare di informazione atomica).<br />

È possib<strong>il</strong>e modificare solo e soltanto l’ultimo nodo creato all’interno dello<br />

storico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera è<br />

un insieme ordinato di revisioni. Viceversa <strong>per</strong> modificare un nodo che non sia<br />

l’ultimo occorre creare <strong>una</strong> diramazione o branch (figura 4.3).<br />

Mentre la creazione della versione successiva (internamente al ramo corrente)<br />

147


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

è un’o<strong>per</strong>azione trasparente all’utente <strong>il</strong> quale si limita a richiedere un“aggiornamento”<br />

dell’ultima versione disponib<strong>il</strong>e, la creazione di <strong>una</strong> nuova diramazione<br />

avviene sempre su esplicita richiesta. Ad esempio si consideri <strong>il</strong> ramo x al tempo<br />

t0 in figura 4.3. La richiesta di nascita di <strong>una</strong> diramazione a partire dalla<br />

prima versione x.0 al tempo t1>t0 comporta la creazione del ramo y contenente<br />

la nuova versione y.0. Al tempo t2>t1 la modifica di x.1 viene applicata nello<br />

stesso ramo con la revisione x.2.<br />

Branch x (t0) Branch x (t 1 > t 0 ) Branch x (t2 > t1 > t0)<br />

x.0 x.1 x.0 x.1 x.0 x.1 x.2<br />

Branch y (t1) Branch y (t2)<br />

y.0<br />

Figura 4.3: Generazione delle revisioni.<br />

Da un punto di vista concettuale effettuare un merge significa integrare<br />

le modifiche presenti su un branch in un altro branch. Nella pratica questa<br />

o<strong>per</strong>azione può essere effettuata secondo modalità diverse che variano con <strong>il</strong><br />

contesto.<br />

Supponendo quindi di o<strong>per</strong>are con documenti IDN-IM occorre stab<strong>il</strong>ire cosa<br />

significhi fondere informazioni atomiche e informazioni primitive, elementi che<br />

costituiscono i documenti presenti nei due branch di interesse.<br />

Il concetto di merge di informazioni atomiche è comunque necessario e si è<br />

scelto di implementare in IDN-IM delle modalità di fusione elementari a partire<br />

dalle quali sarà possib<strong>il</strong>e definire metodologie di merge più complesse in base<br />

alle specifiche esigenze del dominio applicativo di interesse.<br />

È possib<strong>il</strong>e definire un’o<strong>per</strong>azione di confronto fra due informazioni atomiche<br />

(che dipende dal tipo di informazione atomica trattata e quindi, in ultima analisi,<br />

dal contesto) che ne determina l’uguaglianza o la differenza. Nel primo caso<br />

<strong>il</strong> merge è banale e <strong>il</strong> risultato è l’informazione stessa; altrimenti l’o<strong>per</strong>azione<br />

di confronto può <strong>per</strong>mettere di stab<strong>il</strong>ire l’entità della differenza e si possono<br />

presentare le seguenti situazioni:<br />

• le informazioni sono diverse, ma confrontab<strong>il</strong>i nei contenuti: in via automatica<br />

o sotto la su<strong>per</strong>visione dell’utente è possib<strong>il</strong>e generare <strong>una</strong> terza<br />

informazione atomica sulla base delle altre due. Come caso particolare la<br />

nuova informazione può coincidere nei contenuti con <strong>una</strong> delle altre due;<br />

y.0<br />

148


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

• le informazioni non sono confrontab<strong>il</strong>i e <strong>per</strong>tanto non è definib<strong>il</strong>e/possib<strong>il</strong>e<br />

l’o<strong>per</strong>azione di merge.<br />

Per quanto riguarda le informazioni primitive, occorre specificare cosa si<br />

intende <strong>per</strong> uguaglianza tra di esse. Da un punto di vista astratto è possib<strong>il</strong>e<br />

considerarle come <strong>il</strong> punto di accesso all’informazione complessiva che si sv<strong>il</strong>uppa<br />

da esse fino alle foglie, come evidenziato nel paragrafo 4.2.2. Questo porta<br />

alla conclusione che <strong>il</strong> concetto di uguaglianza fra informazioni primitive non<br />

è esprimib<strong>il</strong>e esclusivamente sulla base del confronto del contenuto informativo<br />

dei nodi che le rappresentano, ma in generale occorre andare a considerare e<br />

confrontare ricorsivamente i nodi che tali informazioni primitive aggregano (in<br />

altre parole l’intero documento in esse radicato).<br />

A questo punto, in riferimento alla figura 4.4, è possib<strong>il</strong>e fornire la seguente<br />

definizione di merging: fondere (merge) due elementi A e B appartenenti a branch<br />

diversi dello stesso storico, significa generare un terzo elemento C ottenuto<br />

da essi a seguito dell’esecuzione di un determinato algoritmo. Il nuovo elemento<br />

C figura nello storico come successore sia di A che di B e, <strong>per</strong> convenzione, appartiene<br />

al ramo di A. La definizione e l’esecuzione dell’algoritmo di generazione<br />

non sono generalizzab<strong>il</strong>i in quanto dipendono dal dominio applicativo ovvero dal<br />

tipo di informazione rappresentata attraverso <strong>il</strong> documento IDN-IM: <strong>il</strong> modello,<br />

come precedentemente affermato, si limita ad <strong>of</strong>frire le funzionalità di base <strong>per</strong><br />

realizzare le o<strong>per</strong>azioni, ab<strong>il</strong>itando la possib<strong>il</strong>ità di creare merge arbitrariamente<br />

complessi.<br />

Storico dell'elemento<br />

A<br />

B<br />

C<br />

Fusione o Merge<br />

A,B in C.<br />

Figura 4.4: Merge di due nodi.<br />

Si osservi che, in questi termini, <strong>il</strong> merge è un’o<strong>per</strong>azione definita fra due<br />

branch che fonde <strong>il</strong> secondo sul primo. L’o<strong>per</strong>atore di “merge” non è quindi<br />

149


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

commutativo: fondere A e B su C è diverso da fondere B e A su C. Nel primo<br />

caso C appartiene al ramo di A mentre nel secondo al ramo di B.<br />

Alla luce del fatto che risulta possib<strong>il</strong>e modificare in modo trasparente solamente<br />

l’ultimo elemento di ogni ramo e del fatto che la creazione di un branch<br />

avviene sempre su esplicita richiesta, è possib<strong>il</strong>e affermare che IDN-IM è un<br />

modello che <strong>per</strong>mette l’authoring collaborativo senza la necessità di prevedere<br />

meccanismi di locking. Il motivo è che risulta sempre possib<strong>il</strong>e individuare<br />

i conflitti, <strong>per</strong>mettendo quindi di attuare le opportune politiche di gestione.<br />

Con conflitto si intende <strong>il</strong> tentativo di modificare due o più volte la medesima<br />

informazione in istanti diversi e può verificarsi qualora due utenti, l’uno indipendentemente<br />

dall’altro, accedano alla stessa informazione nella versione v (x)<br />

(che si ipotizza essere l’ultima disponib<strong>il</strong>e nel momento dell’accesso) e, dopo <strong>il</strong><br />

tempo necessario ad elaborare la modifica, tentino l’o<strong>per</strong>azione di salvataggio.<br />

Il primo di essi riuscirà nell’intento ed <strong>il</strong> sistema genererà la versione v (x+1). Il<br />

secondo invece verrà informato che la versione v (x) è diventata immutab<strong>il</strong>e a<br />

causa del fatto che non è più l’ultima versione disponib<strong>il</strong>e dell’informazione. A<br />

questo punto l’utente può decidere di attuare <strong>una</strong> delle seguenti strategie:<br />

• effettuare un merge (fusione) della propria modifica con quella apportata<br />

dall’altro utente. In questo caso si hanno due opzioni possib<strong>il</strong>i: l’abbandono<br />

dell’intenzione di apportare la modifica ad esempio <strong>per</strong>ché già realizzata<br />

dall’altro utente oppure la produzione della versione v (x+2) ottenuta dalla<br />

fusione di v (x) più le modifiche locali e v (x+1) 3 ;<br />

• creare un nuovo branch sul quale apportare le proprie modifiche (eventualmente<br />

da fondere nel ramo di partenza in un momento futuro).<br />

Ciò non esclude necessariamente che in ben determinati domini applicativi<br />

sia possib<strong>il</strong>e ut<strong>il</strong>izzare i metadati definib<strong>il</strong>i nel modello stesso <strong>per</strong> implementare<br />

opportuni meccanismi di locking al fine di aumentare l’awareness degli utenti.<br />

4.6.1 La propagazione delle modifiche<br />

Per poter implementare <strong>il</strong> modello di versioning UEVM è necessario prevedere<br />

un meccanismo che <strong>per</strong>metta di propagare le modifiche dei figli verso i<br />

genitori. Il modello quindi prevede, proprio <strong>per</strong> questo fine, i link di segnalazione<br />

che <strong>per</strong>mettono di risalire nella gerarchia dei nodi presenti nel dominio del<br />

grafo IDN-IM, come richiesto dal modello di versioning UEVM stesso.<br />

In corrispondenza dell’ultima versione all’interno di ogni branch di informazioni<br />

primitive <strong>per</strong> le quali si ha interesse a tracciare gli aggiornamenti delle altre<br />

3 Come nel caso del merge di due rami anche in questo caso v(x+2) può essere uguale a<br />

v (x) (<strong>il</strong> secondo utente decide di “annullare” le modifiche del primo utente) oppure diverso<br />

sia da v (x) che da v (x+1). Il caso v (x+2) = v (x+1) non è significativo in quanto coincide<br />

con l’opzione in cui <strong>il</strong> secondo utente rinuncia a creare v (x+2) lasciando v (x+1) come ultima<br />

versione dell’informazione.<br />

150


<strong>InterDataNet</strong> Information Model Storico dei documenti<br />

informazioni primitive ad un livello più basso della gerarchia nel grafo IDN, si<br />

hanno i link di segnalazione che risultano entranti sulla PIU stessa. I link di<br />

segnalazione completano la vista strutturale sulle informazioni.<br />

In maniera complementare in corrispondenza dei link detti non propaganti<br />

non si hanno i link di segnalazione nel senso opposto. Ogni link propagante<br />

ha tutte le caratteristiche dei link discusse in precedenza, ma è tale <strong>per</strong> cui<br />

le modifiche apportate ai nodi a valle del link non si ri<strong>per</strong>cuotono su quelli a<br />

monte.<br />

L’introduzione di questo tipo di relazione è necessaria <strong>per</strong> modellare quelle<br />

casistiche in cui occorre relazionare a partire dal documento (<strong>per</strong> aggregazione<br />

oppure <strong>per</strong> riferimento) l’informazione I specificatamente al tempo t = ti. A<br />

titolo esemplificativo è possib<strong>il</strong>e ipotizzare un documento che rappresenti <strong>il</strong> modulo<br />

di licenza di matrimonio di un impiegato: in questo tipo di documento è<br />

necessario inserire le informazioni relative alla posizione lavorativa del dipendente<br />

al momento in cui la richiesta stessa viene prodotta. Una variazione della<br />

posizione lavorativa dell’impiegato successiva al rientro della licenza matrimoniale<br />

non deve impattare sul documento appena citato, ma può/deve produrre,<br />

ad esempio, effetti sulla modalità di calcolo delle tasse che <strong>il</strong> lavoratore stesso<br />

dovrà versare al fisco.<br />

Documento al tempo t 0<br />

X1<br />

S1 S2<br />

A1 A2<br />

Y1 Z1<br />

Documento al tempo t 1<br />

A1<br />

Legenda<br />

link di aggregazione<br />

link di segnalazione<br />

nuova versione<br />

X1<br />

A2<br />

S3<br />

V2<br />

A3<br />

X2<br />

A4<br />

Y1 Y2 Z1<br />

V1<br />

Figura 4.5: Esempio di propagazione delle modifiche.<br />

Per chiarire le modalità con cui avviene la propagazione si faccia riferimento<br />

alla figura 4.5 nella quale <strong>il</strong> documento al tempo t0 è costituito da <strong>una</strong> radice<br />

X1 che aggrega due figli Y1 e Z1 tramite opportuni link di aggregazione, rispettivamente<br />

A1 e A2. Dato che, <strong>per</strong> ipotesi, tali link di aggregazione sono<br />

propaganti esiste un link di