Meccanismi di Identity Management per la fruizione di servizi offerti da diversi Service Provider in modalità Single Sign On nel cloud

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in protocolli per reti mobili Meccanismi di Identity Management per la fruizione di servizi offerti da diversi Service Provider in modalità Single Sign On nel cloud Anno Accademico 2013/2014 Candidato: Alessandro Del Prete matr. N46/867

2 Indice Indice... II Introduzione... 3 Capitolo 1: Cloud computing Infrastructure as a service (IaaS) Platform as a service (PaaS) Software as a service (SaaS)... 5 Capitolo 2: Identity and access management Autenticazione Single sign on (SSO) Federazione Autorizzazione Gestione dell IAM come SaaS (IDaaS)... 8 Capitolo 3: Tecnologie per l autenticazione federata Security Assertion Markup Language (SAML) SAML assertions SAML protocol SAML binding SAML profile SSO con SAML Shibboleth Identity provider Service provider Where Are You From (WAYF) Funzionamento di Shibboleth Procedura di autenticazione Esempio concreto di utilizzo di Shibboleth Capitolo 4: Autenticazione federata per servizi cloud Un esempio di architettura Struttura dell architettura L architettura DNA nel cloud Uno scenario di autenticazione in una virtual DIME network Autenticazione nella DIME network Autorizzazione nella DIME network Autenticazione tra domini differenti Conclusioni Bibliografia

3 Introduzione Con l aumentare dei servizi fruibili via web si è avuto un notevole incremento del numero di registrazioni da parte di un singolo utente, tutto ciò costringe gli utenti a dover ricordare un considerevole numero di dati per l autenticazione e i service provider a dover memorizzare dati per un numero sempre crescente di account. È in questa situazione che si avverte l esigenza di una autenticazione unica. In questo elaborato, dopo una breve introduzione al cloud computing ed ai principali obiettivi dell Identity and Access Management, ci concentreremo su tecniche e metodologie per garantire la sicurezza in un ambiente cloud, ponendo particolare attenzione all autenticazione. Nello specifico approfondiremo il linguaggio SAML e l Identity Provider Shibboleth al fine di rendere possibile un autenticazione federata attraverso Single Sign On. Per concludere verrà trattato, come esempio di applicazione di quanto detto all interno di uno scenario cloud. 3

4 Capitolo 1: Cloud computing Con il termine cloud o più propriamente cloud computing ci si riferisce all insieme di tecnologie offerte da un provider sotto forma di servizio che permettono all utente di memorizzare o elaborare dati grazie all utilizzo di risorse software o hardware distribuite in rete (tipicamente internet). Un provider di cloud computing offre i seguenti servizi: Infrastructure as a service (IaaS) Platform as a service (PaaS) Software as a service (SaaS) 1.1 Infrastracture as a Service (IaaS) L Iaas è la prima forma di cloud computing. Questo servizio offre all utente la possibilità di utilizzare macchine fisiche o, più frequentemente, virtuali attraverso la rete. Le macchine virtuali sono preferite in quanto è possibile adattare le risorse allocate sulla base delle richieste dell utente, in questo modo è possibile avere un numero maggiore di macchine rispetto a quelle fisiche. La gestione del SO e di tutto il software è a carico dell utente, nonché la gestione di una parte dell hardware. Per far uso di questo servizio si deve installare un immagine del SO sulla macchina dell utente e un applicazione software sul cloud. 4

5 1.2 Platform as a Service (PaaS) In questa seconda forma di cloud computing all utente viene offerta una piattaforma (tipicamente comprensiva di SO, ambiente di esecuzione dei linguaggi di programmazione, web server, database) sulla quale si possono sviluppare ed eseguire applicazioni software senza doversi far carico della gestione dei livelli hardware e software sottostanti. Le risorse allocate alla macchina virtuale che ospita la piattaforma sono gestite automaticamente sulla base della richiesta di calcolo dell utente. 1.3 Software as a Service (SaaS) Questo è il sistema di cloud computing più complesso, che prevede la possibilità per l utente di utilizzare software e database presenti sul cloud senza preoccuparsi nemmeno dello sviluppo dell applicazione, in quanto è direttamente il provider a fornirle. Le applicazioni software sono installate direttamente sul cloud e possono essere accedute da vari clients. Non è necessario per l utente gestire né l hardware né la piattaforma su cui eseguono le applicazioni, questo risparmia all utente la necessità di installare software sulla sua macchina client e semplifica la manutenzione dei cloud. 5

6 Capitolo 2: Identity and access management L identità digitale è definita come la rappresentazione di un entità con uno o più attributi (informazioni sull entità) che ne rendono possibile l identificazione in un dato contesto. Con il termine identity and access management (IAM) si identifica l insieme di funzioni, come autenticazione, management, amministrazione, il cui obiettivo è controllare e gestire le informazioni sugli utenti al fine di garantire la sicurezza di un sistema. Queste informazioni solitamente sono: Informazioni che servono ad autenticare l utente Informazioni riguardanti le azioni che l utente è autorizzato a fare Informazioni su chi può accedere e modificare le precedenti L IAM si può ridurre a tre funzioni basilari: Creazione e gestione di identità La gestione degli accessi (autenticazione) La personalizzazione dei servizi sulla base delle autorizzazioni dell utente Nella gestione dell identità sono coinvolti solitamente tre entità: Il client (colui che vuole usufruire di un servizio) Il service provider (colui che offre il servizio) L identity provider (l entità deputata a verificare e gestire l identità 6

7 degli utenti) 2.1 Autenticazione La gestione degli accessi avviene attraverso l autenticazione, che è la verifica che l utente è chi afferma di essere. La forma più semplice di autenticazione è la verifica della conoscenza di username e password, questo meccanismo ha il vantaggio della semplicità sia per l utente che per provider dei servizi che richiedono l autenticazione, invece lo svantaggio è che si basa solamente sulla conoscenza della password. Un meccanismo di autenticazione per essere sicuro dovrebbe verificare i seguenti campi: Qualcosa che l utente conosce (es. password) Qualcosa che l utente ha (es. certificato digitale o token) Qualcosa che l utente è (es. impronte digitali) Tanti più campi verificherà il meccanismo di autenticazione scelto, tanto più sarà sicuro ma tanto più sarà complesso sia da gestire che da utilizzare. Quindi è necessario cercare il giusto compromesso tra sicurezza e facilità di utilizzo tenendo presente le esigenze specifiche del sistema in questione. 2.2 Single Sign On (SSO) Alla base del single sign on (SSO) vi è la possibilità per un utente di accedere a varie applicazioni dello stesso provider mediante un unica autenticazione. Il SSO ha effetti benefici sia sull utente sia sul provider, in quanto l utente deve ricordarsi un numero minore di password e quindi eviterà di scegliere password semplici e facili da indovinare oppure eviterà di scriverle, neutralizzando i due più grandi rischi del sistema username/password. Di conseguenza i provider dovranno memorizzare 7

8 meno dati per ogni utente risparmiando spazio. 2.3 Federazione È anche possibile accedere a applicazioni di provider differenti mediante l autenticazione verso un unico provider, questo meccanismo, che è un estensione del SSO, è chiamato federazione. Per permettere ciò esistono diversi protocolli di comunicazione, come SAML (security Assertion Markup Language), che permettono a organizzazioni diverse, appartenenti alla stessa federazione, di scambiarsi informazioni riguardanti l autenticazione di un utente. Quando un utente si autentica ad un sito o ad un applicazione sfruttando un altra autenticazione già eseguita si dice che esegue un autenticazione federata. 2.4 Autorizzazione Una volta che un utente è stato autenticato bisogna stabilire a quali contenuti può accedere. Questo passaggio è realizzato assegnando un ruolo, da parte degli amministratori del sito, agli utenti o a gruppi di utenti. Le autorizzazioni e quindi i contenuti accessibili possono variare in base a: L identità dell utente (ruolo) La posizione dell utente o il tipo di dispositivo dal quale sta accedendo Altri fattori quali l orario o il giorno Informazioni che provengono da siti esterni 2.5 Gestione dell IAM come SaaS (IDaaS) Un possibile modo per gestire l IAM è dato dall Identity as a service (IDaaS), ossia la gestione dell identità e degli accessi fatta attraverso cloud. Questo tipo di soluzione ha tutti i vantaggi tipici del cloud, ossia permette 8

9 all utente di disinteressarsi della memorizzazione e della gestione dei dati. Nell IDaaS l applicazione che gestisce l IAM e memorizza i dati sugli utenti è posizionata in un cloud e gestita da un IDaaS provider ed i servizi relativi all identità sono offerti come SaaS. Un concetto fondamentale nell IDaaS è che l applicazione che si occupa dell IAM sia multi-tenant, cioè che diversi utenti possano condividere le stesse risorse in modo trasparente. Questo significa che la stessa applicazione memorizza i dati di più clienti ma i clienti non devono poter accedere a dati non di loro proprietà, anzi i clienti non dovrebbero proprio esser al corrente di dati non loro, presenti nell applicazione. La multitenancy è così importante nella gestione dell IAM via cloud perché permette notevoli risparmi in termini sia economici che di tempo per la gestione della piattaforma. L architettura di una piattaforma IDaaS dovrebbe essere basata su un applicazione, che sia cloud-based e multitenant, che offre tutti i servizi necessari all IAM. Nonostante ciò oggi è molto comune trovare soluzioni ibride che non siano completamente cloud-based ma che facciano uso del cloud solo per una parte dei loro compiti. Ciò perché molte organizzazioni non vogliono affidare completamente i loro dati ad un ente esterno (IDaaS provider) per motivi di sicurezza. Per esempio è possibile che un organizzazione memorizzi sul cloud i dati degli impiegati utilizzando pseudonimi al posto dei veri nomi. Solamente all interno dell organizzazione stessa saranno poi memorizzate le associazioni tra pseudonimi e nomi. 9

10 Capitolo 3: Tecnologie per l autenticazione federata Per realizzare un autenticazione federata si adottano differenti tecnologie, quali un Identity Provider, che è l elemento che si occupa di gestire e verificare le identità degli utenti, ed un linguaggio per lo scambio di queste informazioni tra diverse parti. In questo capitolo verranno discussi Shibboleth e SAML. 3.1 Security Assertion Markup Language (SAML) SAML è un formato standard basato su XML per lo scambio di dati riguardanti autenticazione e autorizzazione tra due parti, solitamente tra Identity Provider e Service Provider. Grazie a questo linguaggio è possibile lo scambio di informazioni in maniera sicura al fine di permettere l utilizzo di meccanismi quali SSO tra organizzazioni diverse SAML assertions SAML si basa su delle asserzioni, che sono i messaggi scambiati contenenti informazioni sulla sicurezza. Le asserzioni sono inviate dall identity provider al service provider e contengono degli statement, sulla base dei quali il SP prenderà la decisione se consentire o meno l accesso dell utente ad una data risorsa. Esistono tre tipi di statement: Authentication statements 10

11 Questo statement serve a garantire al SP che l utente si è autenticato con l IdP. Nello statement è incluso l authentication context che contiene informazioni in merito all autenticazione; Attribute statements Questo statement serve a indicare che l utente è associato a certi attributi (sono una coppia nome-valore) e serve per prendere decisioni in merito all accesso ad alcune risorse; Authorization decision statements In questo statement di solito si dice che l utente A è autorizzato a proseguire con l azione B sulla risorsa R. Le possibilità di questo statement sono limitate e pertanto si consiglia di utilizzare XACML (di cui parleremo in seguito) per lo scambio di autorizzazioni; SAML protocol Oltre alle asserzioni è necessario, al fine di comunicare, stabilire la struttura dei messaggi di richiesta e risposta. A questo scopo si utilizza SAML protocol, che serve a identificare quali elementi SAML (incluse le asserzioni) compongono i messaggi scambiati ed in quale ordine. Una richiesta o risposta scambiata mediante SAML protocol prende il nome di query. Esistono tre tipi di query: Authentication query Attribute query Authorization decision query SAML binding Con SAML binding si definisce un mapping tra un messaggio definito nel protocollo SAML e un protocollo di comunicazione che ne permette l invio. Per esempio, nel binding più comune, i messaggi 11

12 SAML sono incapsulati in messaggi SOAP, che a loro volta sono racchiusi in messaggi HTTP SAML profile Un SAML profile stabilisce come utilizzare le asserzioni, i protocolli e i binding finora descritti per portare a termine una data azione. Si può definire un SAML profile come l insieme di specifiche per il corretto utilizzo di SAML in un dato contesto. Il più importante SAML profile è il web-browser SSO SSO con SAML Per descrivere l utilizzo di SAML bisogna introdurre tre ruoli: L utente L identity provider Il service provider Tipicamente l utente richiede un servizio al SP che deve ricevere dall IdP una identity assertion e sulla base di questa asserzione, decidere se consentire o meno l accesso alla risorsa. Prima di inviare l asserzione al SP, l IdP potrebbe richiedere dei dati all utente (username e password) al fine di autenticarlo. Un IdP può inviare asserzioni a diversi SP, così come è possibile che un SP accetti asserzioni da più IdP. Supponiamo che un utente già autenticato dal SP A provi ad accedere al SP B e che i due SP utilizzino lo stesso IdP. In tal caso, quando il SP B richiede all IdP l identity assertion dell utente, riceverà immediatamente una risposta. Non sorge il bisogno per l utente di inserire nuovamente username e password, perché risulta effettivamente già autenticato presso l IdP. Ciò permette all utente di accedere alla risorsa senza doversi 12

13 autenticare nuovamente nel nuovo SP, questo è il funzionamento di un autenticazione federata con SSO. 3.2 Shibboleth Shibboleth è un sistema open-source basato sul linguaggio OASIS SAML che si occupa di gestire autenticazione e autorizzazione di utenti sfruttando il concetto di identità federata e SSO. Il sistema Shibboleth è composto da due elementi: l IdP (Identity Provider) e il SP (Service Provider) Identity provider L IdP è l elemento responsabile dell autenticazione che è formato da quattro componenti: Handle service (HS), che si occupa di autenticare gli utenti attraverso un meccanismo di autenticazione scelto dall organizzazione e di creare un handle token che serve a verificare l identità dell utente una volta autenticato; Attribute authority (AA), che gestisce le richieste di attributi del SP, applicando politiche sulla privacy al momento del rilascio degli attributi; Directory service, che immagazzina gli attributi sugli utenti del sistema ed è esterno a Shibboleth; Authentication mechanism, che si preoccupa di verificare login e password all atto dell autenticazione ed è anch esso esterno a Shibboleth Service provider Il SP è dove sono memorizzate le risorse alle quali gli utenti vogliono accedere. Al SP è demandato il controllo degli accessi sulla base delle informazioni inviate dall IdP. Un SP è spesso composto da tante 13

14 applicazioni ma ciò nonostante è comunque considerato un entità unica. Il SP è così composto: Assertion consumer service (ACS), che è responsabile della ricezione dei messaggi SAML utili ad instaurare un ambiente sicuro; Attribute requester (AR), che riceve gli attributi e li passa al RM; Resource manager (RM), che intercetta le richieste provenienti dagli utenti per delle risorse e prende decisioni sull accesso, sulla base degli attributi dell utente Where Are You From (WAYF) L ultimo componente di Shibboleth è opzionale e si chiama WAYF (where are you from) e serve a collegare un utente con la sua organizzazione. Quando l utente prova ad accedere ad una risorsa verrà reindirizzato ad una pagina, sulla quale potrà scegliere a quale organizzazione appartiene. Nella fase successiva, l utente visualizzerà la pagina della sua organizzazione per l autenticazione. Questo componente è particolarmente utile se lo stesso IdP è utilizzato da più organizzazioni differenti. 3.3 Funzionamento di Shibboleth Shibboleth sposta verso le strutture di appartenenza degli utenti il ruolo di dare garanzie sulla loro identità, a differenza di servizi quali IDaaS che affidano questo compito a strutture terze. Attraverso Shibboleth è possibile, con un unica autenticazione, accedere a diversi servizi anche di diverse organizzazioni, a patto di avere regole condivise per l autenticazione e l autorizzazione degli utenti all interno della federazione Procedura di autenticazione L autenticazione attraverso Shibboleth avviene secondo i seguenti passi, 14

15 (come mostrato anche in figura): 1) L utente prova ad accedere ad una risorsa protetta sul SP; 2) Shibboleth reindirizza l utente al WAYF (se presente) dove può scegliere il suo IdP; 3) L utente visualizza la pagina del suo IdP, in particolare quella del HS, dove inserisce i dati per l autenticazione; 4) L HS autentica l utente e crea un handle (pseudonimo) che lo identifichi, dopo invia l handle all AA ed all ACS; 5) L ACS controlla l handle e lo trasferisce all AR e così facendo instaura una sessione; 6) L AR utilizza l handle che ha ricevuto per richiedere gli attributi dell utente all AA; 7) L IdP dopo aver controllato se può rilasciare gli attributi dell utente li invia all AR; 8) L AR riceve gli attributi e li inivia al RM che quindi carica la risorsa desiderata dall utente. 15

16 3.3.2 Esempio concreto di utilizzo di Shibboleth Supponiamo che un utente voglia autenticarsi per utilizzare un determinato servizio presente su un server A. Il server A, che svolge il ruolo di SP, non accetta la richiesta e la gira al WAYF. L utente comunicherà al WAYF le informazioni che lo identificano, le quali verranno inviate al HS appartenente all IdP. A questo punto l HS richiede all utente di non effettuare direttamente il login sul server A ma di effettuarlo presso di sé, ossia attraverso Shibboleth. Effettuato il login presso l HS, ossia dopo aver confrontato i dati immessi dall utente con quelli contenuti in un DB apposito, l utente viene autenticato. Vi è ora la necessità di passare le informazioni al SP, di questo si occupa Shibboleth, attraverso un asserzione SAML. L utente è quindi autenticato presso il server A, che, tuttavia, non conosce gli attributi dell utente e quindi non sa quali sono le sue autorizzazioni. Al fine di ricevere gli attributi il server A invierà una richiesta all Attribute Authority (AA), che riconosce il SP e invia gli attributi richiesti. A questo punto l utente può accedere ai servizi per i quali è autorizzato sul server A ed inoltre può anche accedere ad un eventuale server B, a patto che questo utilizzi lo stesso IdP. Ciò è possibile perché l IdP, quando il server B richiede l autenticazione dell utente, riceverà subito un asserzione SAML, dal momento che l utente è già stato autenticato in precedenza. 16

17 Capitolo 4: Autenticazione federata per servizi cloud 4.1 Un esempio di architettura Il design di un architettura cloud può essere molto complesso da parte del service provider, per semplificare questo problema si può ricorrere alla progettazione di servizi basati sul cloud Struttura dell architettura L architettura DIME, che sta per Distributed Intelligent Managed Element, si basa su due reti sovrapposte: La signaling network La service network Questo consente ai vari task, che compongono l architettura, di eseguire funzioni di controllo (inizializzazione, monitoraggio, analisi, riconfigurazione dovuta a variazioni di carico di lavoro, ecc ) parallelamente ai servizi offerti dalla macchina. Una DIME network è composta da vari DIME locali, che sono unità di calcolo composte dai task FCAPS, ossia: Fault (F) Configuration (C) Accounting (A) Performance (P) 17

18 Security (S) Ognuno di questi task è collegato al canale di signaling. All intero di ogni DIME locale è presente un coordinatore che serve a gestire i vari task che lo compongono e che prende il nome di MICE (Managed Intelligent Computing Element). L obiettivo del MICE è quello di ricevere le istruzioni tramite il task C (attraverso il canale di signaling), prelevare l input dal canale dei dati e scrivere l output, una volta elaborato, sullo stesso canale. In una DIME network è possibile programmare ogni MICE per svolgere una funzione specifica, poi collegando in cascata vari DIME e organizzandoli secondo un Directed acyclic graph (DAG) (per vedere l ordine in cui vanno eseguiti i MICE), è possibile realizzare servizi più complessi. 18

19 4.1.2 L architettura DNA nel cloud La DIME network architecture si adatta alla perfezione alle esigenze del cloud computing in cui essa è implementata attraverso server virtuali e per questo si chiama virtual DNA. Le difficoltà di progettare un ambiente basato su cloud risiedono nell esigenza di offrire servizi complessi (IaaS, Paas, SaaS) e contemporaneamente monitorare le performance e la sicurezza. Inoltre nelle architetture cloud è presente la necessità di adattare automaticamente le risorse disponibili e riconfigurare le macchine virtuali all occorrenza. Una generica architettura cloud si basa su 3 livelli: Virtual machine monitor (VMM) Virtual infrastructure Manager (VIM) Cloud manager (CM) Il primo livello (VMM) è composto dalle macchine virtuali che offrono i servizi richiesti ai livelli superiori. Il secondo livello (VIM) è composto dal software che si preoccupa di gestire le macchine virtuali presenti sui server. In particolar modo il VIM alloca e dealloca le macchine virtuali, gestisce le immagini dei SO utilizzati e inizializza la rete virtuale per far comunicare le varie macchine tra loro. Questo livello offre il servizio di IaaS, che può mettere a disposizione dell utente sia una singola macchina virtuale, sia un insieme di macchine virtuali interconnesse da una rete privata. L ultimo livello (CM) è il livello di astrazione più elevato. Basandosi sull infrastruttura offerta dal livello precedente, il CM è capace di offrire una piattaforma su cui utilizzare i servizi desiderati. Questo tipo di servizio è classificato come PaaS o SaaS. 19

20 L ultimo livello è il più complicato da progettare in quanto deve essere tollerante ai guasti, deve essere configurabile, deve garantire la sicurezza e le performance. Per gestire queste esigenze, viene in aiuto l architettura DIME vista in precedenza. Ogni virtual machine ospiterà un DIME locale e la DIME network sarà composta da tutte le macchine virtuali offerte dall IaaS. La comunicazione tra i DIME avverrà attraverso una rete virtuale ma sarà del tutto uguale a quella delle normali DIME networks. In esse i comandi verranno passati al task C e l input sarà inviato al MICE che lo elaborerà, dopo l elaborazione il MICE scriverà l output sul data channel. Ogni DIME offrirà un particolare servizio ma sarà possibile collegare più DIME in cascata per offrire servizi più complessi. Con questa struttura è molto semplice per il provider controllare i singoli servizi offerti da ogni DIME oppure l intera infrastruttura, perché basterà 20

21 utilizzare il signaling path ed i relativi task di controllo. 4.2 Uno scenario di autenticazione in una virtual DIME network La sicurezza dei dati custoditi in un cloud è un aspetto di primaria importanza, ciò rende necessarie misure di protezione come autenticazione degli utenti e criptaggio dei dati custoditi sul cloud. I dati necessitano di esser criptati per evitare intercettazioni durante la comunicazione a livello rete. Dal momento che di solito la comunicazione avviene attraverso HTTP, il protocollo maggiormente usato per questa evenienza è SSL/TLS. Comunque è importante tener presente che la sicurezza dei dati e della comunicazione è a carico del service provider qualora si adotti un cloud del tipo SaaS, mentre è totalmente a carico dell utente nel caso di IaaS. Ricordandoci la struttura di una DIME network, formata da vari DIME locali, ognuno dei quali composto da 5 thread (FCAPS), sarà subito ovvio che il thread deputato a svolgere queste funzioni è il thread S (security). Dal momento che la DIME network sarà usata da diversi utenti, ognuno dei quali avrà accesso a diversi servizi è necessaria una procedura di autenticazione per ogni utente. Per garantire ciò sono necessari due diversi controlli: L autenticazione, per controllare l identità dell utente; L autorizzazione, per controllare a quali servizi l utente può accedere. Una prima soluzione prevede di far autenticare l utente su ogni DIME utilizzato nella rete. Questa soluzione seppur corretta teoricamente non è realizzabile dato l alto numero di DIME e di utenti presenti nella rete. 21

22 Per semplificare la procedura di autenticazione è necessario utilizzare il meccanismo, già trattato in precedenza, detto Single Sign On. In questo modo l utente dovrà autenticarsi presso un Identity Provider (IdP) e ogni DIME nella rete si fiderà dell autenticazione avvenuta presso l IdP attraverso un meccanismo di trust. Per quanto riguarda le autorizzazioni, queste saranno contenute nell account dell utente all interno dell IdP. In questo modo l utente eviterà di avere un account su ogni DIME e quindi di doversi autenticare più volte. Un altro vantaggio è dato dalla possibilità di aggiungere DIME alla rete senza che gli utenti debbano registrarsi sul nuovo DIME, avendo così una maggiore flessibilità. Per garantire la sicurezza in una DIME network è necessario aggiungere dei nuovi componenti alla rete: Un Identity provider Un authorization manager Un accounting repository Questi tre componenti saranno presenti su virtual machines indipendenti, 22

23 presenti nella virtual infrastructure e capaci di comunicare con i DIME attraverso il signaling path Autenticazione nella DIME network Quando un utente vuole accedere a dei servizi attraverso la DIME network deve prima di tutto provare la sua identità all IdP, presente nella virtual infrastructure, che ha il compito di verificare le identità degli utenti. Per far ciò l utente contatterà, attraverso la signaling network, il task S del DIME con cui vuole comunicare. Qualora l utente non sia autenticato, il nodo DIME reindirizzerà la richiesta all IdP. Interagendo con l IdP l utente potrà autenticarsi e stabilire quindi un security context. Attraverso questo security context ora l utente potrà accedere al nodo. Se l utente in seguito dovesse aver bisogno di nuovi nodi non ci sarà bisogno di ripetere la procedura ma si potrà tranquillamente usare il security context già esistente Autorizzazione nella DIME network Dopo aver eseguito l autenticazione è necessario stabilire a quali servizi e quindi a quali nodi DIME l utente può accedere. Per questo motivo è necessario l authorization manager. L authorization manager utilizza un particolare linguaggio, detto XACML, che serve a specificare le politiche per il controllo degli accessi utilizzando cinque elementi: Attributi, che sono delle caratteristiche di una risorsa, un azione o un ambiente su cui è fatta la richiesta di accesso, per esempio lo user-name, il nome del file a cui si vuole accedere o l ora dell accesso; Funzioni, che sono le possibili operazioni che l utente può fare sui dati; Regole, che rappresentano dei vincoli che l utente deve rispettare; 23

24 Policy, che sono un insieme di regole; Policy set, che è un insieme di policy. Quando un utente vuole accedere ad un servizio, contatta il nodo che offre quel servizio, a sua volta il nodo invia una richiesta, attraverso la signaling network, all AM. Questa richiesta è intercettata da un modulo interno all AM, chiamato PEP, formattata in XACML e inviata ad un altro modulo detto PDP. Il PDP valuta la richiesta sulla base delle policy salvate nel policy repository ed invia il risultato al PEP. Il PEP valuta la risposta del PDP e prende la decisione finale che verrà inviata al nodo che inizialmente aveva inviato la richiesta attraverso la signaling network. Per concludere, il nodo DIME, sfruttando il thread A, salverà le operazioni effettuate nell accounting repository Autenticazione tra domini differenti Fin ora abbiamo sempre supposto che l IdP e i DIME fossero tutti nello stesso dominio, però le cose continuano a funzionare anche qualora questo non sia vero. Supponiamo di avere più domini e di voler utilizzare un DIME workflow distribuito, ossia il servizio richiesto è fornito da vari DIME non tutti nello stesso dominio. In questo scenario è importante che tutti i DIME indipendentemente dal dominio accettino il trust dell IdP. Se questo è vero, una volta instaurato un security context con l IdP, si potranno utilizzare tutti i DIME, indipendentemente dal loro dominio e dal dominio dell IdP. L unico accorgimento necessario è la configurazione dei DIME, nello specifico dei thread S, non appartenenti al dominio dell IdP, in modo tale che accettino i trust di un IdP di un dominio differente. 24

25 Per esempio supponiamo di avere una DIME network i cui nodi siano ospitati da due cloud differenti e collegati attraverso Internet. Ciò potrebbe avere senso per motivi economici oppure perché ogni cloud ospita servizi legati all area geografica in cui si trova. Il workflow che interessa all utente è composto dai servizi S1 S2 S3 S4, dove i primi 3 sono ospitati dal cloud A, mentre l ultimo è nel cloud B. Quando l utente accede al servizio S1 viene reindirizzato all IdP del dominio A per l autenticazione. Una volta eseguita con successo l autenticazione potrà accedere ai primi 3 servizi del suo workflow come abbiamo già visto in precedenza, mediante l autenticazione unica. In seguito, non appena l utente proverà ad accedere al servizio 4, il DIME che ospita il servizio chiederà all IdP informazioni riguardo il security context dell utente e riceverà, analogamente ai servizi prima di lui, la conferma dell avvenuta autenticazione. Tutto ciò avverrà a patto che la richiesta sia 25