Dipartimento di Informatica
Corso di Laurea Magistrale in Informatica
TESI DI LAUREA
SaaS
S
: a proposal for
Secure Software as a Service
Relatore: Prof.ssa Laura RICCI
Candidato: Andrea TARQUINI
dei paradigmi maggiormente usati per la creazione di servizi, applicativi e solu-zioni usufruibili online su larga scala. Tuttavia, nonostante gli evidenti benefici, si sottovalutano ampiamente le ripercussioni delle filosofie Cloud sulle tematiche di privacy e sicurezza dei dati personali. I recenti scandali mediatici hanno evi-denziato che il Cloud è diventato uno strumento importantissimo per agenzie di intelligence e governi internazionali nei settori dello spionaggio e del controllo di massa. Questa tesi affronta e analizza tali problematiche proponendo una filosofia ed un framework crittografico per l’implementazione di servizi SaaS sicuri deno-minati SaaSS, in grado di garantire all’utente finale la riservatezza e l’integrità
dei propri dati rispettandone la privacy. La tesi non si limita soltanto ad una proposta astratta di plausibili soluzioni, ma analizzando le moderne tecnologie e filosofie di sviluppo in ambito SaaS (come REST, HTTP e OAuth2) propo-ne anche una reale ed attuale guida all’implementaziopropo-ne di servizi sicuri di tipo SaaSS.
1 Introduzione 4 2 Prerequisiti: protocolli e architetture 14
2.1 REST: un analisi teorica . . . 14
2.1.1 I vincoli . . . 14 2.1.2 Uniform Interface . . . 20 2.2 REST e HTTP . . . 23 2.2.1 Risorse indirizzabili . . . 24 2.2.2 HTTP verbs . . . 27 2.2.3 HTTP Status Code . . . 29 2.2.4 Content Negotiation . . . 32 2.2.5 Caching . . . 34
2.2.6 CORS: Cross-Origin Resource Sharing . . . 35
2.3 Il framework OAuth 2 . . . 36
2.3.1 Una panoramica . . . 37
2.3.2 Il protocollo astratto . . . 38
2.3.3 I quattro flussi principali (grant type) . . . 41
3 Cloud Computing: stato dell’arte 44 3.1 Cloud Computing secondo il NIST . . . 45
3.1.1 Definizione e caratteristiche essenziali . . . 45
3.1.2 Modelli di servizio . . . 46
3.1.3 Modelli di distribuzione . . . 48
3.2 Cloud Computing odierno: da Startup a Multinazionali . . . 49
3.2.1 SaaS: una visione reale . . . 49
3.2.2 SaaS: guida all’implementazione . . . 51
3.2.3 SaaS, REST e OAuth2: un semplice esempio . . . 55
3.3 Cloud Computing e sicurezza . . . 59
3.3.1 Datagate: la nostra vita in Cloud . . . 60
3.3.2 Social SSO: un problema nascosto . . . 65
4 SaaSS: Secure Software as a Service 69 4.1 L’idea: crittografia lato client . . . 70
4.2 Strumenti, definizioni e notazioni . . . 71
4.2.1 Schemi crittografici . . . 71
4.2.2 Link crittografici . . . 73
4.3 Una classica Access Control List . . . 76
4.3.1 Attori e componenti . . . 77
4.3.2 Il principio . . . 77
4.3.3 Operazioni e Complessità . . . 80
4.3.4 Stima delle performance . . . 84
4.3.5 Problemi e miglioramenti . . . 86
4.4 Una soluzione scalabile: Izzie . . . 88
4.4.1 Attori e componenti . . . 88
4.4.2 Izzie: principi generali . . . 89
4.4.3 Read Access Control: idea base . . . 95
4.4.4 Strumenti avanzati . . . 99
4.4.5 Read Access Control: ottimizzazioni . . . 100
4.4.6 Write Access Control . . . 101
4.4.7 Operazioni tipiche e Complessità . . . 106
4.4.8 Estensioni . . . 112
5 SaaSS: guida all’implementazione 113 5.1 SaaSS e la filosofia REST . . . 113
5.1.1 Client/Server . . . 114
5.1.2 Stateless, Uniform Interface, Cache e Layered System . . . 117
5.1.3 Code on demand . . . 118
5.2 SaaSS, REST e HTTP . . . 119
5.2.1 Risorse HTTP . . . 119
5.2.2 Operazioni Principali . . . 123
5.3 SaaSS e OAuth2 . . . 130
5.3.1 Implementazione di un proprio server OAuth2 . . . 130
5.3.2 Il Social SSO . . . 134
5.4 IzzieDocs: un proof of concept . . . 135
5.4.1 Obiettivi e caratteristiche . . . 136
5.4.2 Analisi dei requisiti . . . 136
5.4.3 Implementazione: filosofie e tecnologie . . . 138
5.4.4 Implementazione: alcuni screenshot . . . 141 6 Conclusioni e Sviluppi futuri 144 A Ambienti per test crittografici 146
Elenco delle figure 147
Elenco delle tabelle 149
Ringraziamenti 150
Introduzione
L’ultimo decennio è stato caratterizzato da notevoli mutamenti ed innovazioni tec-nologiche che hanno drasticamente avuto un impatto socio-culturale sull’intera umanità. Basti pensare alla crescente diffusione di dispositivi quali gli smart-phone, i tablet e di tutti quei dispositivi e tecnologie che hanno rivoluzionato il modo di comunicare e socializzare delle persone, anche esterne al mondo scientifi-co, informatico e dell’ICT. Pochi comprendono però che un tale successo è anche dovuto alla continua evoluzione di tutti i protocolli e di tutte le tecnologie che consentono di fatto l’interconnessione globale tra reti informatiche, o meglio, se-condo la contrazione della locuzione inglese interconnected networks, tale successo è dovuto proprio ad internet.
Internet oggi rappresenta di fatto uno dei principali motori dello sviluppo economico mondiale, è sinonimo di globalizzazione e viene usato da imprendito-ri, aziende, multinazionali e anche da nuove realtà di business (come le startup) come una vetrina sul mondo per l’erogazione dei propri servizi e per l’accresci-mento del proprio business [56] [16] [15] [42]. Sulla base di tali motivazioni la fine degli anni 90 è stata caratterizzata dalla comparsa di interessanti filosofie e soluzioni il cui scopo è quello di permettere ad aziende e realtà di business di dimensione più limitata di sfruttare le potenzialità di internet senza il bisogno di dover acquistare e mantenere un’importante infrastruttura di rete ed IT [13] [60] [20]. É in questi anni infatti che viene usato per la prima volta il termine Cloud Computing [17], nascono inoltre importanti realtà pioniere ed oggi leader e protagoniste di soluzioni Cloud come SalesForce, VMWare ed Amazon. Dagli inizi degli anni 2000, anche i giganti dell’IT hanno iniziato a capire l’impatto e
l’importanza delle nuove correnti di pensiero e di utilizzo degli approcci Cloud incominciando ad abbracciare e a proporre soluzioni per potenziare e condividere le proprie infrastrutture (servizi business oriented), nonché per creare una serie di nuovi servizi destinati all’enorme mole di utenti finali (ovvero le persone comuni, i nuovi "consumatori" di internet). Google, nel 2004, è tra primi colossi a lanciare un servizio di Cloud Computing che presto diventerà tra i più diffusi al mondo: Gmail. Nel 2006, la stessa Google comincia ad offrire una serie di ulteriori servizi browser oriented e le Google Apps iniziano a concorrere con programmi di uso comune esclusivamente desktop (come Word ed Excel). Nel 2006 inoltre, Amazon sbarca nel panorama Cloud con AWS (Amazon Web Services), una collezione di servizi interamente fruibile online che consente a sviluppatori (e quindi a impre-se) di creare veri e propri servizi che sfruttano risorse hardware e computazionali offerte e gestite da Amazon. Ma il boom dei servizi Cloud è stato registrato pro-prio negli ultimi 5 anni ed è tuttora terreno fertile, forte dell’enorme diffusione dei dispositivi in grado di connettersi alla rete e alle nuove frontiere di evoluzione di internet come l’IOT (Internet of Things) [9] [34]. Il Cloud Computing non è quindi più visto solo come una risorsa ed un’opportunità per favorire la nascita di nuove realtà di business e di startup limitando di fatto i costi di avvio di impresa dovuti alla creazione di un’infrastruttura IT, ma si è trasformato in un vero e proprio modello di business su vasta scala che ha permesso la creazione di servizi orientati verso l’utente finale, a basso costo ma altamente sostenibili e scalabili. Tra questi ultimi vale certamente la pena citare i diffusissimi Google Docs, Dro-pbox, Office365, ma anche Spotify o Netflix ed in generale tutti quei servizi che offrono servizi on demand all’utente finale.
Il Cloud Clomputing è maturato quindi negli anni risolvendo una serie di innumerevoli problemi iniziali e proponendo soluzioni innovative sia in ambito business che in ambito consumer tanto che diverse correnti filosofiche e di pensiero sono state accostate a tale termine accendendo anche numerosi dibattiti su cosa sia davvero il Cloud Computing. Una definizione molto astratta, flessibile ma autorevole, che riassume le caratteristiche essenziali, i paradigmi e i vincoli per le soluzioni di Cloud Computing è stata pubblicata dal NIST (National Institute of Standards and Technology) in [45] nel 2011 e corrisponde alla definizione adottata nell’intera dissertazione. Tra i vari modelli di servizio il NIST denomina e definisce gli applicativi ed i servizi di Cloud Computing principalmente diretti all’utente
finale con il termine Software as a Service (SaaS) da cui deriva anche il titolo di questa dissertazione: SaaSS: Secure Software as a Service. Lo studio proposto in
questa dissertazione è infatti il risultato "teorico" di un progetto condotto presso il laboratorio di ricerca R&D di eLearnSecurity, un’azienda leader nel ramo della formazione in sicurezza informatica ed in collaborazione con il Dipartimento di Informatica dell’Università di Pisa. L’obiettivo è infatti quello di risolvere uno dei maggiori problemi legati all’uso di soluzioni di Cloud Computing, ovvero il problema della sicurezza dei dati personali e della privacy, una questione che affligge principalmente proprio i servizi e le soluzioni di tipo SaaS.
La questione dei dati personali e della privacy è stato sempre un tema con-troverso e dibattuto sin dagli albori delle filosofie Cloud, tuttavia il problema è attualmente molto sottovalutato e spesso poco considerato dai soggetti consumer di soluzioni di tipo SaaS tradizionali e sociali (ovvero le persone comuni, magari poco consce sul reale funzionamento delle soluzioni IT che stanno usando). Ciò che manca nella società attuale è la consapevolezza che soluzioni come Dropbox, Google Drive, Google Docs ma anche gli stessi social network, grazie al Cloud Computing immagazzinano un’enorme quantità di informazioni e di dati che ci riguardano in modo molto stretto e altamente personale. Basti pensare che il backup di fotografie, memorizzate in modo assolutamente gratuito in soluzioni Cloud come Dropbox che ne consentono di fatto un uso su ogni dispositivo e piat-taforma è forse una delle attività più comuni degli ultimi anni per la stragrande maggioranza delle persone. Il paradigma è mutato e sta tuttora mutando, inter-net non è più solo una vetrina per aziende e realtà di business, anzi chi è dietro la vetrina oggi sono proprio le persone, con i propri gusti, le proprie passioni, i propri interessi, i propri affari ed i propri affetti. Un nuovo modello di business si è diffuso negli ultimi anni, servizi sempre più a basso costo o anche totalmente gratuiti con l’obiettivo di collezionare quanti più dati possibili sul consumatore finale per creare prodotti e soluzioni che riescano a soddisfare ogni bisogno. É chiaro che queste evoluzioni delle strategie economiche e dei modelli di marke-ting rendono vulnerabile, in maniera più o meno importante, la privacy di una persona, ma è anche vero che di fatto quando si usa un servizio di tipo SaaS, in generale si sottoscrivono delle politiche di consenso al trattamento dei dati personali (policy agreement) che rendono il consumatore "consapevole" di come i suoi dati verranno utilizzati. Le politiche di consenso ai dati possono certo fornire
un’indicazione sulla bontà e sulle intenzioni delle aziende promotrici del servizio SaaS, ma ciò che spaventa maggiormente è che anche le più corrette politiche sui dati sono inutili quando entrano in gioco i reali attacchi informatici mirati a sot-trarre e a sfruttare informazioni sensibili. Avere i propri documenti, i propri affari e anche contenuti sui propri affetti (come foto o video) memorizzati "in chiaro" da qualche parte nel mondo è un problema assolutamente da non sottovalutare, i data center e i servizi di Cloud Computing sono infatti il "giardino dell’eden" per hacker, ma anche per attività di spionaggio e monitoraggio.
Proprio le tematiche di spionaggio, programmi sorveglianza di massa ed in-tercettazioni sono state il soggetto negli ultimi anni di veri e propri casi mediatici che hanno visto come protagonisti le principali organizzazioni di intelligence e i principali governi mondiali come la statunitense NSA (National Security Agency) o l’inglese Government Communications Headquarters. Quello che ha suscitato più scalpore è stato l’inizio di una serie di rivelazioni ed inchieste giornalisti-che (denominate Datagate [32]) pubblicate dal The Washington Post e dal The Guardian dal mese di giugno del 2013 volte a rivelare dettagli sulle operazioni di sorveglianza e compromissione di massa (come PRISM [29] [44] [58] [52] e MU-SCULAR [5] [6] [28]) che vede partecipi non solo le agenzie governative mondiali come l’NSA, ma anche i maggiori provider di IT e Cloud Computing come Goo-gle, Facebook, Microsoft, Yahoo!, ed Apple. Se si pone uno sguardo sulla storia e sulle origini di Internet un fatto molto bizzarro è che uno degli obiettivi primari che hanno spinto allo studio della prima rete di computer è proprio legato agli ambiti militari, di difesa e di intelligence durante la guerra fredda dei primi anni 60 [35]. Analizzando la situazione attuale, sembra che l’avvento di internet ab-bia portato le attività di monitoraggio, intercettazione, spionaggio e controllo a livelli ben oltre superiori alle aspettative dell’epoca. Si può dire oramai che una nuova rivelazione o un nuovo scandalo che vede protagonisti le maggiori agenzie di sicurezza internazionali sia all’ordine del giorno. É importante sottolineare che questa dissertazione non vuole analizzare, commentare o prendere una posizione a riguardo delle intercettazioni o dei programmi di sorveglianza, leciti o illeciti che siano. Si ritiene infatti che attività di controllo e di monitoraggio siano senza ombra di dubbio attività necessarie per impedire particolari situazioni di pericolo o che ledono in generale alla sicurezza nazionale, come ad esempio la prevenzione di plausibili attacchi terroristici. Tuttavia attività di intelligence e di
intercetta-zione spesso si spingono ben oltre varcando la barriera del diritto personale alla privacy e diventando un pretesto per la raccolta di informazioni a fini politici, sociali ed economici.
Obiettivi
Uno degli obiettivi di questo elaborato è quindi quello di proporre una soluzione al problema della privacy e della sicurezza dei dati personali memorizzati su Cloud che possa garantire all’utente finale la segretezza, la consistenza e l’integrità dei propri dati nonostante l’uso di soluzioni di Cloud Computing. Tale obiettivo è molto ambizioso, perché di solito introducendo maggiore sicurezza si riduce in modo drastico l’usabilità o l’esperienza d’uso di un generico servizio che è proprio uno dei maggiori successi del Cloud Computing e uno dei requisiti fondamen-tali per gli utenti finali. Inoltre non solo è necessario proporre una soluzione che riesca ad abbattere il famoso trade-off sicurezza/usabilità ma occorre anche fare attenzione e rispettare tutti i vincoli e i requisiti delle soluzioni di Cloud Computing.
É necessaria quindi prima un’analisi sullo stato dell’arte che permetta di iden-tificare in modo corretto e non ambiguo cosa si intende per Cloud Computing: definizione standard, caratteristiche e modelli. Occorre poi analizzare come le realtà di business (da startup a multinazionali) abbiano recepito tali direttive, e quali sono le tecnologie che hanno contribuito ad un così rapido proliferare di servizi e soluzioni per l’utente finale (Software as a Service: SaaS). Non meno importante è anche un’analisi più dettagliata dei principali problemi legati alla sicurezza dei dati e alla privacy, guidati anche da reali documenti (presunti top secret) trapelati dalle recenti inchieste giornalistiche. Il capitolo 3 si occupa del-l’analisi di tutti questi aspetti sullo stato dell’arte, sfruttando i principali concetti tecnologici proposti nel capitolo 2 come requisiti.
Una volta analizzata l’attuale situazione sia filosofico/astratta che tecnologi-ca delle soluzioni di tipo SaaS si può procedere verso lo studio di una plausibile soluzione. Il capitolo 4 è dedicato all’analisi teorica ed astratta di un framework che permette di introdurre una S aggiuntiva al modello SaaS definendo di fatto una nuova filosofia per gli sviluppatori di servizi applicativi di Cloud Computing che siano sicuri dal punto di vista dell’utente finale e denominati SaaSS: Secure
dapprima il problema della protezione dei dati personali per poi raggiungere e soddisfare anche i vincoli del Cloud Computing. Quindi vengono dapprima intro-dotte le idee, le tecniche e gli strumenti crittografici necessari alla protezione di informazioni e di dati non strutturati (od organizzati), adottando un approccio piatto ("flat") che però risulta inadatto in situazioni caratterizzate da un alto numero di risorse (informazioni) ed attori (utenti), dove la scalabilità diventa un requisito fondamentale. Di conseguenza, basandosi sui risultati (in termini di performance crittografiche) appresi dal modello piatto, viene proposto anche un framework scalabile ed adatto a quelle situazioni che necessitano di un organizza-zione dei dati e delle informazioni più strutturata e complessa (come ad esempio un file system). Il tutto si basa sull’idea di utilizzare, in modo non convenzionale ed innovativo, strumenti crittografici classici come schemi di cifratura simmetrica ed asimmetrica per costruire una struttura dati crittografica multi livello che sia efficiente e scalabile ma che mantenga elevato il livello di sicurezza intrinseco. Andando più nel dettaglio, ciò si traduce nello studio, nell’identificazione e nella costruzione di una serie di passi crittografici (denominati nella sezione 4 come link crittografici) che permettano di proteggere entità astratte quali risorse (ad esempio file) e collezioni di risorse (ad esempio directory) mantenendo però inal-terate le caratteristiche principali dei servizi SaaS comuni, come la possibilità di condivisione con clienti (in generale utenti finali) o gruppi di clienti (in generale gruppi di utenti).
Dato che questa dissertazione è nata grazie ad una stretta collaborazione tra università e azienda (eLearnSecurity), un altro obiettivo molto importante è quel-lo di utilizzare gli studi e i risultati teorici ottenuti, per proporre una reale guida all’implementazione che possa essere effettivamente usata dagli sviluppatori per la creazione di generici servizi di tipo SaaSS. Il capitolo 5 è dedicato di conseguenza
all’effettiva messa in atto di quanto proposto nel capitolo 4, ovviamente sfruttan-do le filosofie e le best practice analizzate nello stato dell’arte e nei prerequisiti (capitoli 2 e 3). Inoltre nel capitolo 5 viene brevemente descritto anche un reale servizio di tipo SaaSS sviluppato presso il reparto R&D di eLearnSecurity come
Proof Of Concept il cui obiettivo è quello di verificare tutto lo studio effettuato in questa dissertazione proponendo un semplice servizio leggero ed usabile per la creazione di documenti sicuri sulla piattaforma Google Drive.
Organizzazione dettagliata
Capitolo 2 - Prerequisiti: protocolli e architetture
Il capitolo ha l’obiettivo di presentare in modo sufficientemente esaustivo alcune tra le attuali filosofie e le tecnologie che vengono maggiormente uti-lizzate per l’implementazione di servizi di tipo SaaS. Il Cloud Computing infatti è un paradigma composto da diversi stili architetturali che non impo-ne in modo stretto l’utilizzo di particolari tecnologie o protocolli. Tuttavia esistono delle filosofie, delle tecnologie e dei protocolli che meglio riesco-no a soddisfare i propositi ed i vincoli del Cloud Computing. Se si parla di servizi di tipo SaaS una tra le filosofie più diffuse è sicuramente REST (REpresentational State Transfer), introdotta da Roy Fielding nella sua tesi di dottorato (anno 2000) [24]. REST è anch’essa una filosofia, composta da delle linee guida e vincoli che Fielding ha introdotto con l’obiettivo di fornire una teoria unificata per la creazione e l’evoluzione di applicazioni distribuite. Non a caso Fielding è tra i principali autori e pionieri dello standard HTTP e del progetto Apache, e la sua impronta è particolarmen-te evidenparticolarmen-te nelle specifiche HTTP [7] [22] [8] [23] che si può definire come un’implementazione conforme alla filosofia REST. Tuttavia nonostante la filosofia REST sia stata proposta nel 2000, non è stata di fatto recepita in modo corretto dagli sviluppatori fino a 10 anni più tardi. L’esplosione dei servizi SaaS e l’esigenza di servizi leggeri, scalabili e consumabili da ogni dispositivo (per mezzo di API remote) ha permesso agli sviluppatori di riscoprire i reali dettami dell’HTTP (pienamente conforme alla filosofia REST) raggiungendo lo stato di maturità tanto promosso da Fielding nei suoi lavori e nei suoi talk. É solo negli ultimi anni infatti che viene dato un notevole peso alle specifiche HTTP non solo dal punto di vista sintattico e necessario al funzionamento del protocollo di comunicazione, ma soprat-tutto semantico e relativo al reale significato del formato dei messaggi che sono coinvolti. Il capitolo analizza quindi la filosofia REST e gli aspetti dell’HTTP più semantici e necessari per la costruzione di API che caratte-rizzano ogni servizio di Cloud Computing SaaS che si rispetti. Brevemente viene anche analizzato il framework di autorizzazione OAuth2, che rappre-senta uno dei meccanismi di autorizzazione meglio conformi alla filosofia REST e ampiamente usato per l’aggiunta di livelli di sicurezza alle comuni
API che caratterizzano i servizi SaaS.
Si tenga presente che questo capitolo deve essere inteso come un punto di riferimento e di approfondimento a supporto dei temi trattati nei capitoli 3 e 5. Tali capitoli danno infatti per scontate nozioni e filosofie di svilup-po orientate a REST, HTTP e OAuth2 utilizzandoli come strumenti per la risoluzione di problemi e per la proposta di soluzioni. Aver compreso in mo-do adeguato tali strumenti è infatti molto importante per avere una visione completa sui servizi di Cloud Computing di tipo SaaS e di conseguenza per essere in grado di proporre soluzioni non solo astratte, ma anche corrette ed estremamente attuali dal punto di vista implementativo e per la costruzione di reali servizi.
Capitolo 3 - Cloud Computing: stato dell’arte
Lo stato dell’arte sul Cloud Computing è assolutamente necessario per com-prendere il problema che questa dissertazione vuole risolvere e in che modo intende farlo. Il capitolo si pone l’obiettivo di definire in modo corretto e non ambiguo cosa sia realmente il Cloud Computing analizzando una fonte molto autorevole e recente come la definizione ufficiale pubblicata dal NIST nel 2011: The NIST definition of cloud computing [45]. Una volta defini-ti i concetdefini-ti, le caratterisdefini-tiche e i modelli del Cloud Compudefini-ting il capitolo propone una visione meno astratta delle soluzioni Cloud moderne presen-tando brevemente come le filosofie e le tecnologie di sviluppo moderne (tra cui REST, HTTP e OAuth2 proposte nel capitolo 2) vengano utilizzate da startup e multinazionali per soddisfare le definizioni ed i dettami principali definiti dal NIST per il modello SaaS.
Una volta compresa anche la panoramica tecnologica il capitolo può final-mente focalizzarsi sui reali problemi di sicurezza dei dati personali e della privacy che affliggono le più comuni e diffuse soluzioni di tipo SaaS. A tal proposito vengono riportati e discussi alcuni tra i principali scandali me-diatici degli ultimi anni che hanno come tema la sorveglianza e il controllo di massa tra cui il DataGate che vede come protagonista l’oramai famo-so Edward Snowden. L’analisi non è esclusivamente storico giornalistica, bensì vengono riportate e analizzate le slide ufficiali (ritenute top secret) promulgate da Snowden che forniscono interessanti indicazioni tecniche sul
funzionamento reale di operazioni e programmi come PRISM [29] [44] [58] [52] e MUSCULAR [5] [6] [28]il cui obiettivo è la raccolta di informazioni dai maggiori provider di servizi sociali e di Cloud Computing. Tali indicazioni sono fondamentali per lo studio di una contromisura efficace ed adeguata, oggetto del Capitolo 4.
Capitolo 4 - SaaSS: Secure Software as a Service
Il capitolo 4 rappresenta la parte più importante di questa dissertazione, riportando tutti i risultati teorici più rilevanti oggetto dello studio del pro-blema della protezione dei dati in servizi di tipo SaaS. Quello che emerge dallo studio è la necessità dell’utilizzo di tecniche crittografiche lato client (quindi sul device dell’utente) che riescano a rendere di fatto le operazio-ni di cifratura e decifratura esclusivamente dipendenti dall’utente finale. Il capitolo introduce gli strumenti crittografici necessari alla costruzioni di un framework crittografico (denominato Izzie) sufficientemente astratto ed adattabile ad ogni tipologia di servizio reale che si intende implementare. Il framework viene presentato con un’approccio molto graduale ed incrementa-le, in modo da risolvere il problema della privacy dell’utente finale riuscendo a non violare le caratteristiche e i vincoli delle soluzioni di tipo SaaS. Il fra-mework Izzie da solo è sufficientemente astratto da rappresentare una vera filosofia a se stante, nello stile di REST, che può essere implementata in base alle esigenze in modo più o meno completo e avvalendosi delle tecnolo-gie crittografiche che meglio si adattano al particolare tipo di servizio che si intende implementare. Nonostante l’approccio astratto, non si dimentichi che l’obiettivo finale è quello della creazione di reali servizi SaaSS che oltre
ai vincoli del Cloud Computing consentano agli sviluppatori di adottare gli stessi approcci e strategie implementative che caratterizzano i moderni ser-vizi SaaS. Di conseguenza, come per quanto già avvenuto con la definizione di REST e di HTTP da parte di Fielding, anche nello studio del framework crittografico Izzie è stato adottato un approccio orientato a quanto appreso dal mondo reale, considerando ciò che è effettivamente implementabile con le moderne tecnologie, filosofie e stili di progettazione e programmazione. Il capitolo quindi mano a mano che si presentano problemi, strategie e so-luzioni, si impegna anche ad una loro corretta verifica ed analisi che funge da base per le evoluzioni del framework. Questo approccio di verifica
spe-rimentale diretta consente in definitiva di costruire il framework in modo incrementale rispettando i vincoli del Cloud Computing, in particolare la scalabilità.
Capitolo 5 - SaaSS: guida all’implementazione
Il capitolo 5 fornisce la base ed il punto di partenza per un’effettiva im-plementazione di un servizio di tipo SaaSS: Secure Software as a Service.
Appresa l’attuale situazione e maturità dei servizi SaaS (capitolo 3), lo svi-luppatore può seguire le filosofie di sviluppo sicuro proposte dal framework Izzie (capitolo 4) ed utilizzare le moderne idee e tecnologie di sviluppo (capitolo 2). Questo capitolo ha proprio l’obiettivo di unire questi passi proponendo una guida implementativa che sia agile, attuale e sufficiente-mente flessibile da permettere di essere applicata per l’implementazione di un qualsiasi servizio sicuro di tipo SaaSS. Il capitolo esplorerà di
conseguen-za i legami tra la filosofia di sviluppo REST e il nuovo modello SaaSS, per
poi concentrarsi sull’applicazione effettiva delle tecnologie e dei protocolli HTTP e OAuth2 per la costruzione definitiva di servizi sicuri e conformi alle moderne filosofie di sviluppo e ai dettami del Cloud Computing. Il capitolo espone brevemente anche la fase di studio ed implementazione di un semplice ma operativo Proof Of Concept, risultato pratico dell’intero lavoro congiunto tra università e azienda (eLearnSecurity). Il POC consi-ste in un’applicazione completamente di tipo SaaSS che consente di creare,
editare, gestire e condividere documenti sicuri all’intero della famosa piat-taforma SaaS offerta da GoogleDrive. L’obiettivo del POC è ovviamente quello di verificare in modo definitivo l’intero studio oggetto della tesi, dal-le filosofie crittografiche astratte proposte dal framework Izzie all’effettiva fase di implementazione secondo le linee guida moderne, oltre che a quel-lo di creare un vero servizio che possa essere utile ai molti intenzionati a sfruttare gli enormi benefici del Cloud Computing con un elevato standard di sicurezza.
Prerequisiti: protocolli e
architetture
2.1 REST: un analisi teorica
Il termine REST (Representational State Transfer) fu introdotto per la prima volta da Roy Fielding nella sua tesi di dottorato: Architectural Styles and the Design of Network-based Software Architectures [24]. La dissertazione si focalizza sull’indagine retrospettiva dell’architettura generale scelta per implementare il World Wide Web. Fielding è infatti anche uno dei principali autori e pionieri delle specifiche HTTP [7] [23] e nel suo elaborato introduce REST come una serie di principi basilari e pattern. REST non è quindi una vera e propria specifica o standard, piuttosto è una filosofia, uno stile di progettazione e un insieme di linee guida e best practice formalizzate dopo un’attenta analisi sulle risorse e le tecnologie disponibili per la creazione di applicazioni distribuite. Nelle pagine seguenti verranno sinteticamente analizzati i principi e le motivazioni cardine della filosofia REST usando volutamente l’impronta semantica adottata da Fielding nel Capitolo 5 della sua tesi di dottorato [24].
2.1.1 I vincoli
L’assioma di base su cui Fielding basa la sua dissertazione è che, senza imporre alcun vincolo, i sistemi tendono ”naturalmente” a evolvere in maniera entropica, portando a spiacevoli situazioni progettuali: come sistemi costosi da creare e
difficili da mantenere o far evolvere. In [24] Fielding esplora quindi il dominio degli stili delle architetture distribuite partendo da un limite inferiore da lui definito ”spazio nullo” (null space), ossia un sistema senza vincoli, rappresentato da organizzazioni dotate di sistemi a basso grado di maturità in cui tutte le risorse tecnologiche sono disponibili, tutti gli stili sono ammessi, senza regole né limiti. Continuando lungo la direttrice evolutiva, Fielding ha poi definito lo stato di totale maturità caratterizzato da sistemi che rispettano i vincoli da lui definiti e che quindi possono essere definiti compatibili con le linee di guida REST (o comunemente detti RESTful)
REST si basa quindi sul fatto che la scalabilità e la crescita del Web siano di-retti risultati di pochi principi (vincoli) di progettazione: Client-Server, Stateless, Cacheable, Uniform interface, Layered system, Code-On-Demand (opzionale).
Client-Server
Il semplice stile architetturale Client-Server è il primo tra i vincoli imposti da Fielding. Il principio dietro questa scelta è la netta separazione degli ambiti o interessi (separation of concern) tra le due entità, il produttore (server) e il consu-matore (client). La filosofia proposta da Fielding è quella di separare l’interfaccia utente e l’interpretazione dei dati (parte client) dalla loro effettiva memorizzazione e gestione (parte server). Così facendo si ottiene un triplice vantaggio:
• incremento della portabilità dell’interfaccia client su diverse piattaforme • scalabilità della parte server dovuta alla notevole semplificazione dei suoi
compiti
• le due componenti possono essere sviluppate (e successivamente possono evolvere) in modo autonomo ed assolutamente indipendente
Nonostante questi concetti risalgano agli anni 2000, le idee di Fielding risultano estremamente attuali. La figura 2.1 mostra infatti come sia possibile implementa-re le due componenti (Client e Server) usando alcune tra le tecnologie disponibili attualmente.
É chiaro però che affinché ciò sia effettivamente realizzabile, entrambe le parti debbano essere in grado di interagire senza ambiguità e soprattutto mantenendo il vincolo implicito di disaccoppiamento (meglio conosciuto nel mondo dei pattern
Figura 2.1: Client/Server
come loose coupling tra le componenti). Il vincolo Client-Server, da solo, non è quindi sufficiente. Occorre che le due parti siano in grado di interagire attraverso un’interfaccia comune (vincolo "Uniform Interface").
Stateless
Questo vincolo riguarda il modo con cui il client e il server interagiscono nel tempo. Fielding impone che la comunicazione tra le parti deve essere "senza stato in natura". Questo significa che ogni richiesta (da client a server) deve (già) contenere tutte le informazioni necessarie per essere elaborata (figura 2.2), senza usufruire di qualche vantaggio ottenuto mediante la memorizzazione di dati (relativi allo stato) da parte del server. Lo stato di una sessione quindi (come ad esempio l’avvenuta autenticazione) deve essere interamente mantenuto lato client. Tre sono i motivi di questa scelta:
• visibilità: un sistema di monitoraggio riesce a comprendere la natura della richiesta immediatamente (non è necessario salvare alcuno stato)
• affidabilità: la gestione e il recupero dei fallimenti parziali viene semplificata • scalabilità: non essendoci stato, si evita l’allocazione di risorse e si semplifica
Sebbene possa sembrare un vincolo semplice e sensato, questo è forse uno dei più controversi e male interpretati dagli sviluppatori, che tendono a memorizzare sul server informazioni relative allo stato della comunicazione con un particolare client. Tra i motivi più comuni abbiamo l’autenticazione, la sicurezza o anche funzionalità particolari (come il carrello della spesa nei servizi di e-commerce).
Figura 2.2: Client/Server-Stateless
Uniform interface
Il vincolo Uniform Interface definisce quali caratteristiche deve possedere l’inter-faccia tra il client (chi usa il servizio/API) e il server (chi offre il servizio/API). Come già anticipato, l’idea è quella di applicare il principio del decoupling, ovvero il disaccoppiamento tra le due entità, che quindi saranno in grado di evolvere in modo indipendente l’una dall’altra. Affinché questo sia possibile Roy Fielding ha proposto 4 principi guida, che, data la loro importanza, saranno discussi nella sezione 2.1.2. Brevemente, si anticipa che sono necessarie delle convenzioni e dei principi per l’identificazione e la rappresentazione delle risorse, nonché per la loro manipolazione e interazione (figura 2.3).
Figura 2.3: Client/Server-Stateless-UniformInterface
Cache
La realizzazione Stateless del servizio implica dei vantaggi, ma può anche intro-durre un degrado delle performance della rete. Infatti poiché il server non me-morizza informazioni sullo stato della comunicazione, ad ogni richiesta il client deve inviare un numero maggiore di informazioni affinché il server sia in grado di interpretare la richiesta senza ambiguità. Per migliorare quindi l’efficienza della rete Fielding impone l’uso della Cache. Questo significa che tutti i dati che il server invia al client come risposta devono essere marcati come cacheable oppure non-cacheable (sintetizzato in figura 2.4). Nel primo caso (cacheable) il client può benissimo evitare di eseguire richieste successive ad una stessa risorsa conte-nuta nella cache aumentando di fatto l’efficienza, la scalabilità ed anche il senso delle performance verso l’utente finale (diminuisce in media la latenza di intera-zione). É importante inoltre scegliere un adeguato trade-off nell’uso di contenuti disponibili in cache. Il rischio è quello di aumentare l’efficienza della rete, ma diminuire di fatto l’affidabilità e l’integrità tra i dati contenuti in cache e quelli effettivamente presenti nel server.
Figura 2.4: Layered System
Layered System
Questo vincolo è stato volutamente inserito per favorire la scalabilità delle com-ponenti in Internet ("Internet-scale requirements"). Avere un sistema stratificato infatti permette l’implementazione efficiente di politiche di bilanciamento del ca-rico ("load balancing"), di caching, ma anche di politiche di sicurezza (ad esempio mediante l’uso di firewall o controllori di accesso).
Un esempio in figura 2.4. In particolare il client non è in grado di stabilire se è realmente connesso con il server (il punto finale della catena) oppure se riceve una risposta da un firewall o da qualche componente che implementa la
cache. Questo fatto è proprio dovuto al vincolo di disaccoppiamento tra client e server, che rende facile implementare componenti (e servizi) intermediari che incrementino l’esperienza d’uso, la scalabilità, la sicurezza senza di fatto rendere il sistema complesso dal punto di vista implementativo o evolutivo.
Code-On-Demand (opzionale)
Il server può essere in grado di estendere o personalizzare le funzionalità del client semplicemente rendendo disponibile del codice sotto forma di applet o script. Il client quindi eseguendo il codice può incrementare il numero di funzionalità supportate. Questo vincolo è opzionale e deve essere usato con cautela per evitare potenziali legati alla sicurezza (un server non fidato potrebbe essere in grado di iniettare codice malevolo nel client).
2.1.2 Uniform Interface
Il vincolo Uniform Interface è forse quello più importante e funge da prerequisito e da premessa per altri vincoli di tipo architetturale (come il vincolo Client/Ser-ver). Data l’importanza, Fielding divide questo principio in altri 4 vincoli (o pre-requisiti) che uniti formano l’interfaccia uniforme che è a cardine dell’intera filo-sofia REST: Resources and Resource Identifiers, Representations,Self-Descriptive messages,HATEOAS.
Resources and Resource Identifiers
Le risorse giocano un ruolo centrale e fondamentale nell’architettura REST. In generale una risorsa è caratterizzata da una qualsiasi informazione o dato (anche strutturato) a cui si può dare un nome. Alcuni esempi di risorse possono essere:
• un oggetto venduto online • i dati anagrafici di una persona • un articolo scientifico
• un contratto di affitto
Affinché il principio dell’interfaccia uniforme venga rispettato, la filosofia RE-ST richiede di assegnare a tutte le risorse un identificativo univoco. Dato che ci troviamo nell’ecosistema del Web, il perfetto identificatore di risorse è lo stan-dard URI (Uniform Resource Identifier). Non dimentichiamoci infatti che lo stesso Fielding è uno dei massimi autori degli standard che compongono il web e dello stesso standard URI [8].
É importante notare che per risorsa non si intende esclusivamente un’entità singola: un catalogo di libri infatti può essere benissimo identificato come una risorsa (ed avere un proprio URI), a sua volta composta da una serie di altre risorse (libri) identificate da altrettante URI.
Brevemente quindi un URI è una stringa che identifica univocamente una risorsa generica. In generale la sintassi di un URI è la seguente:
< scheme >:< scheme specif ic part >
dove lo schema (<scheme>) è a sua volta uno standard che specifica la sintassi e la semantica della parte specifica dell’URI (<scheme-specific-part>). Tra gli schemi più comunemente usati troviamo http, ftp, mailto, telnet, ma anche ISSN (codici a barre). Per approfondimenti sulle specifiche adottate dagli schemi ritenuti validi si faccia riferimento a [37]. A noi interesserà particolarmente lo schema HTTP, approfondito nella sezione 2.2.
Dato che l’analisi di REST si focalizza sull’implementazione di servizi Web oriented, l’interesse è rivolto particolarmente alla specializzazione degli URI de-nominata URL - Uniform Resource Locator in figura 2.5.
Figura 2.5: URI: URL - URN
Un URL (Uniform Resource Locator) è un URI che, oltre a identificare una risorsa, fornisce mezzi per agire su di essa o per ottenere una "rappresentazione" della risorsa descrivendo il suo meccanismo di accesso primario o la sua "ubica-zione" ("location") in una rete [8]. Un Uniform Resource Name o URN invece è un URI che identifica una risorsa all’interno di un namespace, ma, a differenza
del URL, non permette l’identificazione della locazione della risorsa stessa. Un esempio di URN è il codice ISBN: questi identifica univocamente un libro, ma non ci dà alcuna informazione sulla locazione dello stesso. .
Representations
Il concetto di "rappresentazione" è molto importante, perché di fatto le infor-mazioni (i dati) che compongono una risorsa sono memorizzati (lato Client o Server) in un formato che non ci è dato conoscere (su file? su database? secon-do uno speciale formato di markup?). Tuttavia, gli attori REST eseguono delle operazioni sulle risorse (come la cancellazione, la modifica o la semplice inter-pretazione) semplicemente usando la "rappresentazione che posseggono di tale risorsa": ovvero una serie di dati e metadati che descrivono la risorsa in modo completo (tra i più comuni: HTML, JSON, XML). Così facendo non necessaria-mente due attori REST sono tenuti ad avere i medesimi dati/meta-dati per una stessa risorsa. Ad esempio un’applicazione potrebbe usare una rappresentazione XML mentre un’altra applicazione potrebbe aver bisogno di una rappresentazione JSON. I due formati sono molto diversi, ma rappresentano la medesima risorsa allo stesso istante di tempo per le due applicazioni.
Self-Descriptive messages
Ogni messaggio scambiato tra gli attori REST include tutte le informazioni neces-sarie per elaborare il messaggio senza ambiguità. Per esempio il messaggio deve includere il formato dei dati che incapsula, il tipo di operazione che deve essere eseguita, il tipo di risposta desiderata, e così via. Nella sezione 2.2 si analizzerà il dettaglio il protocollo HTTP: in particolare analizzandone tutti le caratteristiche e le convenzioni per adempire a questo vincolo in modo elegante e semanticamente corretto e appropriato (secondo le idee di Fielding).
HATEOAS
HATEOAS è l’acronimo di Hypermedia as the Engine of Application State ovvero l’uso degli hypermedia come motore dello stato delle applicazioni. Il termine hy-permedia (ihy-permedia) è un termine derivato come estensione di hypertext (iperte-so) per indicare un insieme di informazioni eterogenee, quali grafica, audio, video
e testo. Il termine è usato per dare peso anche ad una sorta di multimedialità nelle informazioni e nelle risorse, non limitandosi soltanto all’interpretazione di dati sotto forma di caratteri o testo.
Questo vincolo è forse quello più controverso e meno recepito nelle moderne applicazioni che seguono la filosofia REST. In breve si impone che il client non debba assumere a priori che una particolare azione sia disponibile per una parti-colare risorsa. Il vincolo HATEOAS serve infatti a disaccoppiare client e server in modo da consentire al server di evolvere autonomamente le proprie funzionalità. Al fine di rispettare questo vincolo, il server deve restituire nella risposta anche l’insieme delle possibili azioni effettuabili sulla risorsa.
Un client REST pertanto non ha bisogno di conoscere preliminarmente come interagire con una particolare applicazione o con un server; tutto quello di cui ha bisogno è una conoscenza generica degli hypermedia. Uno stile diametralmente opposto a questo è costituito, per esempio, dalle architetture orientate ai servizi (SOA), in cui i client e i server interagiscono attraverso un’interfaccia fissa, ben definita e documentata e implementata attraverso un linguaggio di descrizione dell’interfaccia (come WSDL, Schema XML, IDL, etc.).
Sebbene, unito al vincolo opzione di Code-On-Demand, questa filosofia per-metta effettivamente di far evolvere Server e Client in modo assolutamente indi-pendente, è chiaro che queste direttive sono le meno recepite attualmente. Ad esempio nell’implementazione di API, si tende a progettare la parte client dan-do per scontata la disponibilità di particolari risorse e delle azioni eseguibili su di esse, privilegiando il disaccoppiamento implementativo (e legato alla scala-bilità architetturale, di piattaforma, e di progettazione) piuttosto che a quello effettivamente semantico promosso da Fielding.
2.2 REST e HTTP
Sebbene di Fielding si sia focalizzato principalmente sui principi semantici e sulla filosofia a cardine dell’architettura REST (Capitolo 5 - [24]), non bisogna dimen-ticare che egli è uno dei principali pionieri delle specifiche e delle definizioni del protocollo HTTP ([7] [23]), dello standard URI [8], ed inoltre contribuisce al pro-getto Apache HTTP Server di cui è co-fondatore. É normale quindi che REST sia molto legato a queste tecnologie, come descritto nel Capitolo 6 - Experience and
Evaluation della stessa dissertazione di Fielding [24]. Il capitolo descrive infatti l’esperienza e le lezioni apprese nell’applicazione della filosofia REST durante la creazione degli standard HTTP ed URI, oltre che la diffusione di queste tecnolo-gie sotto forma di librerie e progetti (in primis Apache HTTP Server). Sebbene la trattazione di Fielding sia molto discorsiva e di semplice lettura, non manca di concetti e spunti per un’efficiente implementazione di servizi web, API, e stili implementativi molto attuali anche 15 anni dopo. Il suo lavoro è stato infatti più volte ripreso nel corso degli anni da ogni punto di vista; sia semantico e pretta-mente teorico, che anche implementativo e prettapretta-mente orientato allo sviluppo di servizi Web e librerie di comunicazione.
Toccare a fondo ogni aspetto della filosofia REST non è lo scopo di questa dissertazione. Tuttavia per comprendere a pieno il lavoro svolto, soprattutto dal punto di vista implementativo e delle difficoltà e sfide che spesso comporta, è necessaria (e fondamentale) anche una panoramica su come il protocollo HTTP venga effettivamente usato ed interpretato al giorno d’oggi dagli sviluppatori. Nelle pagine seguenti verranno approfonditi ed analizzati gli aspetti del protocollo HTTP che spesso vengono messi in secondo piano e male interpretati ma che sono fondamentali per essere conformi alla filosofia REST. Mentre resta semplice e scontato capire il motivo per cui il protocollo HTTP rispetti i vincoli più generali di REST come Client-Server o Layered System, vincoli come Uniform Interface o Stateless non sono associati in modo immediato allo standard HTTP, spesso per una carenza di conoscenza della semantica dello stesso HTTP e molto spesso anche per l’ostinazione nel seguire delle filosofie di progettazione mal fondate ed ormai obsolete per l’evoluzione degli attuali servizi web e cloud based.
2.2.1 Risorse indirizzabili
La sezione 2.1.2 descrive come il concetto di Risorsa sia fondamentale nella fi-losofia REST. In generale ogni risorsa deve essere identificata in modo univoco. Tuttavia, dato che si parla di Web e di architetture Client/Server è molto im-portante anche la possibilità di recuperare le informazioni di una risorsa in modo semplice, nonchè la possibilità di agire di essa (modifica, aggiornamento, can-cellazione). É per questo che in 2.1.2 Fielding introduce il concetto di URI ed URL.
Lo schema HTTP
Se parliamo di World Wide Web lo schema (protocollo) di riferimento è l’Hypertext Transfer Protocol (HTTP) (sottoinsieme delle URL). Per questo motivo d’ora in poi si farà riferimento a risorse di tipo HTTP, sfruttando appunto il suddetto protocollo (definito in modo approfondito in [7] e [23]) per il recupero e l’inte-razione con ogni risorsa localizzabile con il paradigma REST. Brevemente, uno schema schema HTTP è composto da:
http://hostname<:port></path><?querystring><#fragment identifier> Senza scendere nello specifico sulla semantica dello schema (per approfondimenti si faccia riferimento a [8]), la filosofia REST si concentra sulle sezioni hostname e path per l’identificazione ed il naming delle risorse. É chiaro che la prima serve a localizzare (in generale) una risorsa all’interno del Web (mediante l’uso dello risoluzione dei nome DNS), mentre la seconda caratterizza in modo appropriato una risorsa tra quelle contenute nella locazione dell’hostname. Alcuni esempi di semplici risorse Web o HTTP sono riportati nel listato 2.1.
1 # una o g g e t t o con i d 7863728 venduto su un ecommerce 2 http : / / ecommercestore . com/ products /7863728
3
4 # l a pagina w i k i REST d i w i k i p e d i a v e r s i o n e i n g l e s e
5 http : / / en . w iki p e d ia . org / wiki / R e p r e s e n t a t i o n a l _ s t a t e _ t r a n s f e r 6
7 # l e i n f o r m a z i o n i s u l l a sede d i Pisa d e l l ’ azienda ABC 8 http : / / abccompany . com/ l o c a t i o n s / Pisa
9
10 # l e i n f o r m a z i o n i m e t e r e o l o g i c h e a Pisa d e l l ’ ora c o r r e n t e 11 http : / / weather . com/ europe / i t a l y / p i s a /now
Listato 2.1: Risorse HTTP
É importante ricordare inoltre che una collezione di risorse è una risorsa a tutti gli effetti, alcuni esempi sono riportati nel listato 2.2.
1 # La l i s t a d e i l i b r i d i avventura
2 http : / /www. movies . com/ c a t e g o r i e s / adventure 3
4 # La l i s t a d e i p r o f e s s o r i d i una U n i v e r s i tà 5 http : / /www. myuniversity / p r o f e s s o r s
6
7 # La l i s t a d e i c o r s i t e n u t i d a l p r o f e s s o r Rossi 8 http : / /www. myuniversity / p r o f e s s o r s / Rossi / c o u r s e s
Listato 2.2: Collezioni come Risorse HTTP
Query String
Un altro aspetto molto importante e da non sottovalutare soprattutto nel design di API e nella creazione e progettazioni di risorse Web è la possibilità, offerta dallo schema HTTP di costruire delle interrogazioni più o meno complesse sulle stesse risorse usando le Query String, ovvero una stringa di caratteri che viene usata per inviare al server uno o più parametri (per approfondimenti si faccia riferimento a [8]). Molti puristi sono contrari all’uso di questa sintassi nell’identificazione di risorse. Tuttavia un buon compromesso di utilizzo consente di rendere le URL utilizzate nei servizi Web che si vogliono implementare estremamente esplicative, nonché facilmente interpretabili sia da sviluppatori che da utilizzatori del Web. Per essere più chiari, alcuni esempi sono riportati nel listato 2.3.
1 # La l i s t a d e i l i b r i d i avventura d e l 2014
2 http : / /www. movies . com/ c a t e g o r i e s / adventure ? year =2014 3
4 # una o g g e t t o con i d 7863728 d i c o l o r e rosso venduto su un
ecommerce
5 http : / / ecommercestore . com/ products /7863728? c o l o r=red
Listato 2.3: QueryString nelle Risorse HTTP
Fragment Identifier
Se le Query String vengono poco prese in considerazione dai puristi del REST, il Fragment Identifier spesso non viene nemmeno menzionato in letteratura. Dal punto di vista della nomenclatura delle risorse questa scelta è assolutamente moti-vata dato che il Fragment Identifier è la sezione dell’URL che viene comunemente usata per indicare una parte (sotto-risorsa) o una posizione all’interno della ri-sorsa principale. Tuttavia questo frammento ha una funzionalità e caratteristica molto interessante. Secondo lo standard HTTP infatti, un generico client non deve inviare il frammento al server durante una generica richiesta HTTP. Tutti
i comuni browser seguono alla lettera lo standard, e di fatto i frammenti non vengono inviati al server. Dal punto di vista della sicurezza questa può essere una grande opportunità per arricchire l’URL di una risorsa con informazioni che devono essere interpretate solo client-side: basti pensare a delle chiavi di cifratura per informazioni riservate e strettamente personali.
2.2.2 HTTP verbs
La filosofia REST enfatizza l’uso di un’interfaccia uniforme tra le varie compo-nenti (client - server - intermedie) in modo da ridurre il coupling tra le operazioni (semantica) e la loro reale implementazione (come anticipato in 2.1.2). Questo ovviamente dal punto di vista del reale utilizzo di tecnologie REST richiede che ogni risorsa supporti un set comune e ben noto di operazioni, ognuna con una proprio comportamento e semantica ben definita e non ambigua. A questo scopo, lo standard HTTP definisce un insieme di operazioni che ogni risorsa può sup-portare (comunemente chiamanti verbi). Di seguito vengono proposti alcuni tra i verbi più usati nelle architetture REST, ognuno corredato di semantica infor-male la cui definizione è quella largamente approvata e usata dagli sviluppatori allo stato attuale d’arte e di maturità di REST. Per approfondimenti si faccia riferimento allo standard HTTP ([7] [23]), ma anche a trattati propri sull’uso e implementazione di REST nelle varie tecnologie come [30] [49][55].
Definizione 2.1 (Verbo idempotente). Un metodo (o verbo, o operazione) è detto idempotente se non vi è alcuna differenza osservabile fra l’effetto di una singola richiesta ed N sue richieste multiple consecutive (a parità di contenuto della richiesta).
Definizione 2.2 (Verbo sicuro). Un metodo (o verbo, o operazione) è detto sicuro se la sua esecuzione non altera lo stato della risorsa su cui viene invocato (ovvero è un’operazione read-only)
• GET è in assoluto uno dei verbi principali e più usati. La sua semantica è caratterizzata da una semplice richiesta (o operazione) di lettura della risor-sa che gode della proprietà di idempotenza ed è considerata un’operazione sicura. Pertanto, se non vengono eseguite altre operazioni, la ripetizio-ne dell’operazioripetizio-ne GET su una risorsa (anche ad intervalli differenti) deve
produrre sempre lo stesso risultato. In passato (e purtroppo anche odier-namente) le specifiche HTTP venivano (sono) male interpretate (e spesso neanche consultate) sia dagli sviluppatori client che server side, rendendo di fatto i servizi web non conformi alla filosofia REST e anche allo stesso standard HTTP. Quanto detto è infatti riportato nelle specifiche RFC già del 1999 ([22] sezione 9.1) e poi ripreso nelle nuove versioni [23].
Esempio.Lettura dello stato di un sensore di temperatura installato sul de-vice identificato dalla risorsa ( mydede-vice.me/temperature ). La temperatura è di 37 gradi. 1 GET / temperature HTTP/1.1 2 Host : mydevice . me 3 4 200 OK HTTP/1.1 5 Content Type : t e x t / p l a i n 6 Content Length : 4 7 37
• POST è un’operazione che nella filosofia REST viene usata principalmente per la creazione delle risorse. Lo standard HTTP la definisce come non-idempotente ed non-sicura. Non sicura perché è chiaro che lo stato della risorsa viene modificato (in particolare creato), mentre non idempotente perché eseguire multiple operazioni POST causa di fatto la creazione di altrettante risorse.
Esempio. Creazione di un nuovo utente del servizio exampleservice. Notare che la risposta contiene l’URI della nuova risorsa appena creata per un uso successivo (utente con ID 23).
1 POST / user HTTP/1.1 2 Host : e xa mp l e s e r vi c e . com 3
4 201 Created HTTP/1.1
5 Location : e x a m p l e s e r vi c e . com/ user /23
• PUT è un’operazione comunemente usata per l’aggiornamento dello stato di una risorsa (rappresentata dall’URI data). Nel caso in cui la risorsa rap-presentata dall’URI sia inesistente, la semantica di PUT impone di creare
la risorsa in questione. PUT ovviamente è un metodo non-sicuro a causa dell’aggiornamento dello stato della risorsa. Tuttavia gode della proprie-tà di idempotenza, infatti richieste medesime e successive di aggiornamento producono lo stesso effetto osservabile sulla risorsa (anche se inesistente alla prima richiesta, a differenza di POST).
Esempio. Modifica dell’utente precedentemente creato da POST. In questo caso viene inserito il nome per l’utente con ID 23.
1 PUT / user /23/name HTTP/1.1 2 Host : e xa mp l e s e r vi c e . com 3 Content Type : t e x t / p l a i n 4 Marco Rossi
5
6 200 OK HTTP/1.1
• DELETE è l’operazione comunemente usata per la cancellazione delle risorse (come sempre rappresentate e identificate da un URI). DELETE è ovviamente un metodo non-sicuro ma tuttavia idempotente, successive richieste di cancellazione causano infatti il medesimo effetto della prima. Esempio. Cancellazione dell’utente precedentemente creato da POST.
1 DELETE / user /23 HTTP/1.1 2 Host : e xa mp l e s e r vi c e . com 3
4 200 OK HTTP/1.1
Tra i verbi più famosi, ma meno usati troviamo anche HEAD, OPTIONS, TRACEe CONNECT. Queste operazioni sono di solito utilizzate in situazioni più particolari e meno comuni, ad esempio nel caso in cui siano necessari meccani-smi di sicurezza (OPTIONS), o di tunneling (CONNECT). Per approfondimenti sulla semantica si faccia riferimento allo standard HTTP. Dal punto di vista im-plementativo e dello sviluppo di codice invece può essere molto utile consultare [30] [49] [55].
2.2.3 HTTP Status Code
Secondo le specifiche HTTP, ad ogni risposta (dovuta ovviamente ad una qualsiasi richiesta HTTP secondo i verbi visti in 2.2.2) deve essere associato un codice di
stato Status Code. Le specifiche definiscono la semantica di circa 60 codici di stato (ognuno di composto da 3 cifre intere) dove la prima cifra ne indica la classe di appartenenza tra le 5 seguenti.
• 1xx: Informativo. Codici poco usati che indicano semplicemente che il server ha ricevuto la richiesta e sta continuando le sue mansioni.
• 2xx: Successo. La richiesta è stata ricevuta, compresa in modo corretto ed accettata.
• 3xx: Redirezione. Per soddisfare la richiesta il client deve effettuare altre operazioni, di solito contattare altre risorse temporaneamente disponibili su altri URI.
• 4xx: Errore del Client. La richiesta non può essere soddisfatta perché sin-tatticamente scorretta. Il client deve quindi formulare delle richieste valide altrimenti il server non è in grado di elaborarle.
• 5xx: Errore del Server. Il server non è riuscito a soddisfare una richiesta valida a causa di errori interni non dipendenti dalla sintassi della richiesta. Sebbene lo standard offra un’ampia varietà di codici, negli anni passati gli svi-luppatori si sono limitati ad usarne solo i pochi principali, spostando la semantica effettiva nel corpo della risposta. Questo modo di fare non è assolutamente con-forme alla filosofia REST ed è di fatto un modo sbagliato di usare il protocollo HTTP. É molto comune ad esempio trovare applicazioni web in cui ogni generica risposta sia caratterizzata dal singolo codice di stato 200 (OK) per ogni tipo di operazione (creazione, modifica, errore client, errore server, ecc...); eventuali erro-ri o situazioni particolaerro-ri vengono interamente specificate nel corpo della erro-risposta con una sintassi (e una semantica) esclusivamente dipendente dall’applicazione web. Odiernamente, in seguito all’avvento del Cloud Computing e alla riscoperta dell’HTTP come effettiva implementazione della filosofia REST per la costruzione di API semplici ma estremamente espressive, i servizi web si stanno evolvendo e stanno diventando sempre più conformi nell’utilizzare i codici di stato già pensati ed ideati per le loro esigenze. Di seguito viene proposto un elenco dei codici di stato più comunemente usati attualmente dai servizi conformi alla filosofia REST, comprensivo di semantica definita dallo standard HTTP:
200 - OK : La richiesta è andata a buon fine, il corpo della risposta contiene la rappresentazione della risorsa interrogata.
201 - Created: La richiesta è stata soddisfatta e il risultato è la creazione di una nuova risorsa. L’URI della nuova risorsa è di solito contenuta in un apposito header di risposta (Location) oppure nel corpo della risposta. 204 - No Content: Il server ha elaborato adeguatamente la richiesta, ma la
risposta non è provvista del corpo. Questo stato viene di solito usato per indicare al client che non è necessario analizzare il corpo della risposta. 301 - Moved Permanently: Alla risorsa è stato assegnato un nuovo (e
permanen-te) URI. Tutte le richieste successive devono essere effettuate al nuovo URI contenuto nella risposta (di solito in un apposito header come Location). 304 - Not Modified: La risorsa non ha ricevuto modifiche dalla richiesta
prece-dente. Di solito usato per implementare meccanismi di chaching.
400 - Bad Request: La richiesta non può essere elaborata a causa di un errore nella sintassi.
403 - Forbidden: Richiesta valida, ma il server si rifiuta di eseguirla.
401 - Unauthorized: Simile a 403, ma in questo caso il server si rifiuta di eseguire la richiesta perché l’autenticazione (necessaria) non è andata a buon fine. 404 - Not Found: Il server non è riuscito a trovare alcuna risorsa per quella
particolare richiesta.
405 - Method Not Allowed: Il metodo (verbo) non è tra quelli supportati dalla risorsa in questione.
500 - Internal Server Error: Il server si è trovato in uno stato inaspettato e non è riuscito a portare a termine la richiesta.
503 - Service Unavailable: Il server è momentaneamente non disponibile (in genere sovraccarico oppure in manutenzione).
2.2.4 Content Negotiation
La Content Negotiation (negoziazione del contenuto) viene descritta nella se-zione 12 dello standard HTTP [22] come il processo di selese-zione della miglior rappresentazione per una data risposta nel caso in cui siano disponibili più di una rappresentazione. In genere le esigenze sulla rappresentazione delle risposta variano a seconda del client che si utilizza per interrogare la risorsa, ad esempio la migliore rappresentazione per un cellulare in Giappone potrebbe non essere la stessa per un lettore di feed RSS di un utente inglese.
In genere per la negoziazione dei contenuti vengono usati appositi header HTTP (sia lato client che server) definiti nello standard. I più usati lato client (nella richiesta) sono:
Accept: specifica quali sono i media-type accettabili come risposta (descritti successivamente).
Accept-Charset: indica quali sono i set di caratteri accettabili nella risposta (ad esempio: iso-8859-5 o unicode-1-1.
Accept-Encoding: indica quali sono le codifiche (in genere di compressione) accettate come risposta ed interpretabili dal client.
Accept-Language: specifica qual’è la lingua preferita nella risposta (molto utile in caso si servizi web multi lingua).
User-Agent: descrive il particolare client che esegue la richiesta (in genere usa-to dal server per discriminare il tipo di browser o di dispositivo che sta richiedendo un servizio).
Il server a sua volta può usare appositi header per indicare la rappresentazione della risposta. Tra i più comuni troviamo:
Content-Type: indica il media-type del corpo della risposta Content-Length: indica la lunghezza (in byte) del corpo risposta Content-Language: indica la lingua usata nel corpo della risposta
É chiaro che attualmente gli header di Content Negotiation maggiormente usati sono Accept e Content-Type. Questo perché sono in genere implementati ed usati automaticamente dai browser e dai server web sia che si usi effettiva-mente una filosofia REST o meno. Dato che stiamo descrivendo REST e HTTP occorre menzionare quali sono i Content Type più diffusi e comuni da usare per la negoziazione dei contenuti tramite gli header Accept e Content-Type:
text/plain: content-type predefinito, che indica un semplice messaggio di testo. text/html: forse il tipo maggiormente usato nel web (grazie ai browser). In genere viene usato nelle risposte HTTP per informare l’user-agent (il client) che il corpo della risposta deve essere interpretato come una pagina HTML image/gif - image/jpeg - image/png: content-type che indicano i formati di immagine comunemente usati. Ovviamente se si tratta di una risposta è richiesto che il client sia fornito di un display in grado di visualizzarli. text/xml - application/xml: due dei più comuni tipi usati quando l’informazione
che si intende scambiare è di tipo xml.
application/json: JSON sta per Javascript Object Notation ed è una notazione leggera e indipendente dal formato del testo che sta prendendo sempre più piede nei moderni servizi web (a discapito di XML).
É importante sottolineare il fatto che tutte queste convenzioni e strumenti offerti dallo standard HTTP si adattano benissimo al vincolo di Uniform Interface (in particolare Self-Descriptive messages) discusso nell’analisi della semantica di REST proposta di Fielding (sezione 2.1).
Esempio.Rappresentazione XML di un utente a sinistra, rappresentazione JSON di un utente a destra. Notare l’header Accept e l’header Content-Type in ambedue le richieste/risposte.
1 GET / u s e r s /1234 HTTP/1.1 2 Host : webofthings . com 3 Accept : a p p l i c a t i o n /xml 4 5 HTTP/1.1 200 OK 6 Content Type : a p p l i c a t i o n /xml 7 8 <user>
9 <name>Marco Rossi </name> 10 </user>
1 GET / u s e r s /1234 HTTP/1.1 2 Host : webofthings . com 3 Accept : a p p l i c a t i o n / j s o n 4 5 HTTP/1.1 200 OK 6 Content Type : a p p l i c a t i o n / j s o n 7 8 {
9 "name " : " Marco Rossi " 10 }
2.2.5 Caching
In molti sistemi distribuiti, la capacità di gestire la cache è cruciale. La cache permette di incrementare le performance dei servizi o applicazioni web evitan-do di inviare richieste (o risposte) che non sono necessarie. HTTP prevede dei meccanismi che consentono di gestire dati cached in modo corretto e senza errori (attraverso appositi Header). Il primo tra tutti è l’header Last-Modified (conte-nuto di solito nelle risposte HTTP) che indica il momento (orario e data) in cui la risorsa richiesta ha subito l’ultima modifica. Ad ogni successiva richiesta il client può inviare tale orario nell’header If-Modified-Since per capire se lo stato della ri-sorsa è cambiato. Nel caso di un cambiamento il server risponderà con una nuova rappresentazione della risorsa ed un nuovo header di Last-Modified (con un nuovo orario), altrimenti il server conforme alla filosofia REST può inviare una risposta con codice di stato 304-Not Modified. Tuttavia dato che date e orari sono diffi-cili da manipolare e soprattutto da sincronizzare recentemente si sta diffondendo (nella filosofia REST) l’uso di un altro tag descritto dallo standard http: l’ETag. Occorre immaginare questo tag come una sorta di MD5 o SHA1 dei byte della rappresentazione della risorsa. Se una risorsa cambia di stato, automaticamente ne cambia anche la sua rappresentazione (via Content-Negotiation) e anche il suo ETag. Il client quindi ogni qual volta vuole conoscere la rappresentazione di una
risorsa può inviare un header If-Non-Match contenente il valore dell’ultimo ETag ricevuto ed agire poi in base alla risposta (nuova rappresentazione o codice 304). Esempio. Caching con ETag nella richiesta di un libro con codice 12345. Nella prima risposta viene restituito un ETag per la risorsa libro. Nella seconda richie-sta il valore dell’ETag viene usato nell’header If-None-Match, ma la risorsa non ha subito modifiche e il codice HTTP 304 viene restituito dal server.
1 GET /book /1234 HTTP/1.1 2 Host : books . com
3 Accept : a p p l i c a t i o n /xml 4 5 HTTP/1.1 200 OK 6 Content Type : a p p l i c a t i o n /xml 7 ETag : 328987 8 <book> 9 <name>JavaEE 7</name> 10 </book> 1 GET /book /1234 HTTP/1.1 2 Host : books . com
3 Accept : a p p l i c a t i o n /xml 4 I f Non Match : 328987 5
6 HTTP/1.1 304 Not Modified
2.2.6 CORS: Cross-Origin Resource Sharing
Le richieste CORS (Cross-Origin Resource Sharing) entrano in atto quando un generico browser cerca di accedere ad una risorsa (solitamente mediante una chiesta di tipo AJAX) che non appartiene al dominio di appartenenza della ri-sorsa in cui il browser si trova in quel determinato momento. Ad esempio se si suppone di dover eseguire una richiesta AJAX ad una particolare api dal do-minio www.mydomain.com al dodo-minio www.otherdomain.com, per questioni di sicurezza il browser blocca le richieste http su domini esterni (in questo caso www.otherdomain.com). Questo perché i browser rispettano quella che è chiama-ta same origin policy, ovvero un imporchiama-tante concetto di sicurezza che impedisce l’accesso a particolari risorse da domini diversi di quelli di appartenenza.
Nella filosofia REST questo concetto di sicurezza è molto stringente, basti pensare a quanti servizi web usino API per l’autenticazione o per altri servizi (storage, cloud, ecc...) offerte dai big dell’IT mondiale come Google, Amazon, Facebook, e così via. Il meccanismo per ovviare a questo inconveniente (stando attenti sempre all’aspetto della sicurezza) consiste nell’uso di particolari header di risposta di tipo Access-Control che istruiscono il browser su come comportarsi
durante le richieste e le risposte di tipo cross origin. In generale il browser (che si trova su una risorsa di dominio A), prima di ogni richiesta cross origin (su un generico dominio B) invia una richiesta di tipo OPTION e attende dal server (del dominio B) istruzioni su come gestire chiamate cross-origin verso quel dominio (B). La risposta del server (di B) conterrà in generale appositi header di Access-Control che specificano quali sono i metodi, i domini e gli header supportati da richieste cross-origin. Il browser così istruito potrà poi effettuare la reale richiesta cross origin verso il dominio B (se pertinente). Questi concetti sono molto sottili e spesso difficili da comprendere per gli sviluppatori alle prime armi, non è nello scopo di questa dissertazione entrare nei dettagli, ma è bene citare queste problematiche e meccanismi visto che sono cruciali per la creazioni di API. Per approfondimenti si faccia riferimento alle raccomandazioni W3C in [54].
2.3 Il framework OAuth 2
OAuth 2.0 è un framework di autorizzazione definito nelle specifiche RFC 6749 [38] che consente ad applicazioni di terze parti di ottenere un accesso limitato a determinati servizi HTTP. Il framework permette infatti sia di orchestrare una vera e propria interazione di approvazione tra il proprietario di una risorsa e il servizio HTTP che la ospita (per conto dell’applicazione di terze parti), sia di permettere ad un’applicazione di terze parti di ottenere l’accesso alla risorsa per proprio conto (mediante opportuni meccanismi e credenziali). Non è negli scopi di questa dissertazione trattare in maniera completa ed esaustiva le funzionalità offerte dal framework OAuth2, tuttavia è necessaria un’analisi preliminare per comprendere i problemi che risolve, il legame con i moderni servizi web e perché venga oramai adottato dai maggiori provider (Facebook, Google, Twitter, ecc...) come meccanismo di autorizzazione per l’uso dei loro servizi. Questa sezione è quindi da intendersi come una presentazione delle funzionalità e delle caratteristi-che principali del framework OAuth. Per approfondimenti si può far riferimento sia alle specifiche ufficiali [38], sia alle specifiche sezioni della documentazione relativa ad OAuth2 dei maggiori provider (tra cui Facebook e Google).
