I quattro flussi principali (grant type)

Come anticipato, una concessione di autorizzazione o authorization grant secondo le specifiche [38] è una sorta di credenziale che rappresenta l’avvenuta autorizza- zione del proprietario della risorsa ad accedere alle sue risorse protette. Questo authorization grant viene usato quindi dal client per ottenere un access token con cui effettivamente richiedere le risorse protette. Le specifiche [38] definiscono quattro tipi diversi di grant: il codice di autorizzazione (authorization code), il grant implicito (implicit), le credenziali (password) del proprietario della risorsa (resource owner password credentials) e le credenziali del client (client creden- tials). Inoltre le specifiche forniscono anche dei meccanismi per estendere questi grant e definirne di nuovi.

É molto importante notare che il tipo di grant effettivamente da usare dipende molto dal tipo di client in gioco, dai grant supportati dal server, dal livello di sicurezza che si vuole ottenere e dalle tecnologie e protocolli di autenticazione che si stanno usando. Il framework offre volutamente diverse strategie per permettere agli sviluppatori di soddisfare ogni loro esigenza, senza però avere la necessità di reinventare o reimplementare meccanismi e protocolli diversi, con una potenziale perdita di sicurezza, efficacia e scalabilità.

Di seguito viene riportata un’analisi introduttiva dei quattro grant offerti dal framework. Viene volutamente mantenuta l’impronta sintattica e semantica adot- tata dalle specifiche ufficiali. Per ogni grant trattato si può fare riferimento alla sezione 4 delle specifiche [38] sia per approfondimenti che per esempi più concreti o situazioni tipiche.

Authorization Code

Il grant authorization code viene usato principalmente quando è il server di au- torizzazione a fare completamente da intermediario tra il client e il proprietario della risorsa. Invece di chiedere l’autorizzazione direttamente al proprietario della risorsa (come mostrato nel punto A della figura 2.6) il client redirige il proprieta- rio della risorsa verso il server di autorizzazione (usando le capacità del suo user agent), che a sua volta (una volta autenticato) redirige il proprietario della risorsa indietro verso il client con l’aggiunta di un codice di autorizzazione indicato nelle specifiche come authorization code.

Prima di redirigere il proprietario della risorsa indietro verso il client insieme all’authorization code, il server di autorizzazione autentica il proprietario della risorsa e ottiene la sua autorizzazione ad emettere il codice di autorizzazione. Dato che il proprietario della risorsa si autentica esclusivamente con il server di autorizzazione le sue credenziali non vengono di fatto condivise con il client (che funge da applicazione di terze parti). Il flusso segue poi quanto mostrato in 2.6 a partire dal punto C, con l’ovvio uso del codice di autorizzazione ricevuto come Authorization Grant. Questa è ovviamente solo una sintesi dei complessi principi dietro questo particolare flusso di autenticazione/autorizzazione, per approfondi- menti si può consultare la sezione 4.1 delle specifiche OAuth2 [38], comprensiva di protocollo dettagliato ed effettivo utilizzo mediante HTTP.

Il codice di autorizzazione inoltre fornisce importanti benefici dal punto di vista della sicurezza, come l’abilità di autenticare il client, la possibilità di inviare il token di autorizzazione direttamente al client (presentando il codice di auto- rizzazione) senza la necessità di passare per l’user agent del proprietario della risorsa.

Implicit

Il grant implicit fa uso di un flusso di autorizzazione semplificato ed ottimizzato per i client implementati nei browser che usano un linguaggio di scripting come il Javascript. Nel flusso di autorizzazione implicito, invece di emettere un codice di autorizzazione, al client viene fornito direttamente un access token (sempre come risultato dell’autenticazione da parte del proprietario delle risorse). Il grant di tipo implicito quindi fa si che nessuna credenziale intermediaria (come il codice di autorizzazione visto in precedenza) venga emessa dal server di autorizzazione. Più nello specifico, nell’emissione del token di accesso, il server di autorizzazione non autentica direttamente il client, piuttosto (nei casi più comuni) l’identità del richiedente può essere verificata attraverso degli appositi URI di redirezione (redirection URI ) usati per l’emissione dell’access token al client. L’access token di conseguenza viene esposto direttamente all’user agent del proprietario della risorsa.

Il flusso implicito migliora la reattività e l’efficenza di quelle applicazioni client implementate nei browser, dato che riduce di fatto il numero di passi necessari all’emissione di un access token (non c’è bisogno di ottenere prima il codice di

autorizzazione). Tuttavia è chiaro che questo ha un impatto intrinseco sulla sicurezza dell’intero flusso e degli attori che entrano in gioco.

Questa è ovviamente solo una sintesi dei complessi principi alla base di questo flusso, mirata esclusivamente a fornire un punto di partenza all’uso del flusso implicito. Per capire appieno il funzionamento ed i casi d’uso tipici è necessario approfondire e consultare la sezione 4.2 delle specifiche OAuth2 [38], comprensiva di protocollo dettagliato ed effettivo utilizzo mediante HTTP.

Resource Owner Password Credentials

Questo grant consente di usare direttamente le credenziali del proprietario delle risorse (ad esempio nome utente e password) come Authorization Grant (si inizia direttamente dal punto C della figura 2.6). Ovviamente questo tipo di situazione dovrebbe solo essere usata quando c’è un alto grado si fiducia tra il proprietario della risorsa e l’applicazione client interessata e soprattutto quando gli altri tipi di grant non sono disponibili. Tuttavia nonostante vengano usate direttamente le credenziali del proprietario della risorsa, dato che queste ultime vengono usate solo per una singola richiesta di access token, il client può evitare di memorizzarle. Nel caso in cui il token sia necessario per un lungo periodo di tempo, data l’alta fiducia verso il client, si può fare in modo di richiedere un access token di lunga validità o usare i meccanismi offerti sempre dal protocollo OAuth2 per la richiesta di un refresh token (approfondimenti e chiarimenti sempre nelle specifiche complete [38] sezione 4.3).

Client Credentials

Questo tipo di flusso utilizza delle credenziali esclusive per il client (od una forma equivalente di autenticazione del client invece che del proprietario della risorsa). É chiaro che questo tipo di grant può essere usato (e implementato) per quelle risorse protette che possono essere anche sotto il controllo di un generico client oppure la cui autorizzazione all’accesso sia stata concessa dal server di autorizzazione mediante altri meccanismi. Questo comporta una sorta di registrazione da parte del client verso il server di autorizzazione, mediante apposite credenziali esclusive per il client (approfondimenti e chiarimenti come al solito in [38] sezione 4.4).

Cloud Computing: stato dell’arte

Attualmente il termine Cloud Computing viene usato per indicare ogni sorta di prodotto o astrazione che si avvicini ad un servizio "on-demand" e che fornisce un determinato set di funzionalità fruibili mediante l’uso della rete. Questa de- finizione è del tutto impropria in moltissimi casi, ma ciò non toglie che oramai sia un termine divenuto di moda e che viene spesso usato (abusato) per avva- lorare le qualità e le funzionalità dei servizi offerti da molte compagnie. L’uso improprio del termine è spesso causa di accesi dibattiti tra le diverse scuole di pensiero adottate dagli sviluppatori e non mancano inoltre i casi in cui l’abuso del termine venga considerato una vera e propria trappola di marketing. É per que- sti motivi che come primo punto dello stato dell’arte viene riportato lo standard e l’ideologia adottata e applicata nello studio dei problemi e delle soluzione che sono oggetto di questa dissertazione. Il modello adottato è la definizione di Cloud Computing secondo il NIST (National Institute of Standards and Technology) e la relativa terminologia associata ad essa. Una volta definita la terminologia e la filosofia di pensiero (riferita al termine Cloud Computing), viene effettuata un’a- nalisi sulla reale situazione del Cloud Computing odierno mettendo a confronto le strategie di utilizzo ed implementazione tra multinazionali e startup che basano il loro business sulle varie forme di Cloud Computing. Dal punto di vista tecno- logico si intuirà e capirà perché le tecnologie analizzate nel capitolo 2 siano di fatto diventate la best practice nella progettazione e implementazione di servizi Cloud. Infine, una volta completo il quadro tecnologico e storico, l’attenzione si concentrerà sui principali problemi di sicurezza nell’uso del Cloud Computing, principalmente dal punto di vista della privacy dell’utente finale.

3.1 Cloud Computing secondo il NIST

Il National Institute of Standards and Technology (NIST) è un’agenzia del go- verno degli Stati Uniti d’America che si occupa della gestione delle tecnologie attraverso la collaborazione con le industrie e realtà pubbliche o private al fine di sviluppare standard, tecnologie e metodologie che favoriscano la produzione e il commercio. Il cloud computing è un paradigma in evoluzione. La definizione proposta dal NIST in [45] caratterizza importanti aspetti del cloud computing ed è destinata a servire come mezzo di ampi confronti tra servizi cloud e strategie di distribuzione degli stessi, e per fornire una base di discussione in merito a quello che è inteso come cloud computing e a come debba essere usato al meglio nel ramo delle tecnologie per l’informazione. I modelli di servizio e di distribuzione definiti in [45] tuttavia costituiscono soltanto una semplice tassonomia (e linea guida) che non ha in alcun modo lo scopo di prescrivere o limitare qualsiasi metodo di distribuzione, fornitura di servizi, o attività di impresa.