Analisi e sperimentazione di tecnologie per la mutua autenticazione e trasferimento di credenziali tra siti federati

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SIENA FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Analisi e sperimentazione di tecnologie per la mutua autenticazione e trasferimento di credenziali tra siti federati Relatore Prof. Ing. Marco Maggini Correlatore Dott. Francesco Ulivi Tesi di Laurea di GIANNI BOZZI Anno Accademico 2005/2006

2 Indice INTRODUZIONE 4 CAPITOLO 1 6 Identificazione Digitale 6 CAPITOLO 2 10 Sicurezze e tecnologie STS: un esempio Profili di sicurezza web Protocolli di sicurezza a livello di trasporto - SSL XML Security standard XML Digital Signature (XML DigSig) XML Encryption (XML Enc) XML Key Management Specification (XKMS) WS-Security Security Token Security Assertion Markup Language (SAML) X Kerberos Policy Management WS-Trust WS-Policy WS-Privacy WS-SecurityPolicy Advanced Capabilities XML Access Control Markup Language (XACML) EXtensible right Markup Language (XrML) WS-SecureConversation WS-Authorization Service Provisioning Markup Language (SPML) Federate Identity Management WS-Federation Liberty Alliance Net Passport 45 CAPITOLO 3 49 Identificazione nel mondo bancario 49 CAPITOLO 4 52 Approfondimenti sul Trust Management Il Trust Management Trust Negotiation ed interoperabilità 56

3 4.3 Policy Protection 58 CAPITOLO 5 61 Stato dell arte all interno del Gruppo MPS Concetti di base Session Manager 63 CAPITOLO 6 67 Active Directory Federation Services di Microsoft Introduzione Active Directory Claim Partner Organization Federation Server e Federation Server Proxy Ambiente Federated Web SSO Ambiente Federate Web SSO con Forest Trust Ambiente Web SSO Fiducia federata Componenti di ADFS Federation Service Federation Service Proxy ADFS Web Agent ADFS snap-in Implementazione Risultati Possibili sviluppi 84 APPENDICE 86 Esempi di XML Security 86 BIBLIOGRAFIA 95

4 Introduzione In questo elaborato viene analizzato il problema dell identificazione digitale di un utente in un sistema federato di aziende fornitrici di servizi Web. Il problema relativo all autenticazione di un utente è nato insieme ai sistemi informatici, infatti già i primi computer necessitavano di una modalità sicura per l autenticazione dell utente in modo da garantire tanto la sicurezza dei dati contenuti nel calcolatore quanto quella della macchina stessa. Lo sviluppo di nuove tecnologie e la diffusione delle reti hanno richiesto una nuova evoluzione delle tecnologie per l identificazione. Nel tempo sono state proposte soluzioni per questo problema che mirano sia ad aumentare la sicurezza del canale di comunicazione, come SSL, sia a realizzare nuovi meccanismi inespugnabili anche su un canale che per propria natura presenta molti punti di vulnerabilità. Sono quindi state sviluppate molte soluzioni tecnologiche e procedurali che utilizzano vari dispositivi (ad esempio la firma digitale, i security token ed i certificati digitali) per identificare in maniera sicura un utente che accede ad una risorsa attraverso la rete. Nonostante gli studi approfonditi molte di queste tecnologie presentano ancora dei punti deboli e molte di queste sono proprietarie e quindi il loro uso è ristretto. Con l aumentare del numero di utenti della rete globale e con il suo orientamento verso i servizi è diventata essenziale la definizione di un sistema forte di autenticazione basato su un linguaggio standard così da renderla interoperabile e universalmente riconosciuta. L extensible Markup Language (XML) è stato quindi assunto come linguaggio candidato alla realizzazione di queste procedure. L evoluzione del Web apportata con i Web Service ha aperto uno scenario in cui i servizi possono superare le frontiere della singola azienda creando un Ecosistema informatico definito Azienda Estesa dai principali analisti. La realizzazione di questo però necessita di procedure che permettano ai singoli attori coinvolti la mutua autenticazione. I Web Service si sono imposti grazie all accettazione universale del loro standard quindi è necessario costruire su di questi un framework ugualmente riconosciuto. Per far questo i maggiori vendor mondiali (quali IBM, Microsoft, SUN, Oracle etc.) hanno partecipato alla definizione di standard definiti da un organismo super partes: la WS-I. Questo organismo ratifica i requisiti ad alto livello, la tecnologia necessaria a soddisfarli e gli standard di comunicazione per l interoperabilità dei Web Service tra cui appunto la WS-Security e non ultima la WS-Federation. La WS-I ha il compito di dettare gli standard e su di questi alcune aziende hanno sviluppato sia in maniera proprietaria che Open Source una serie di sistemi di federazione, quali.net Passport e Liberty Alliance. Lo sviluppo di questi permette agli utenti, autenticati da un partner della federazione, di accedere ai servizi forniti dalle altre aziende federate senza dover effettuare una nuova procedura di autenticazione, tale operazione è nota con il nome di Single Sign-On (SSO). Per avere una struttura interaziendale di questo tipo deve esserci una relazione

5 di fiducia tra le varie componenti della federazione, poiché ciascuna di queste deve fidarsi dell autenticazione fatta da un altra per permettere a clienti sconosciuti di accedere ai propri servizi. Proprio la necessità di stabilire rapporti di fiducia tra le varie parti di una federazione fornisce un opportunità alle banche, che sono per definizione delle entità fidate oltre ad essere ovviamente all avanguardia per quanto riguarda la sicurezza informatica. Lo scenario appena descritto mette quindi la banca al centro di quel sistema che ruota attorno al concetto di azienda estesa e questo può essere visto come l evoluzione della fornitura dei loro servizi telematici quali HomeBanking e CorporateBanking. In questo lavoro sono state studiate le problematiche appena introdotte contestualizzandole all esperienza del Gruppo Monte dei Paschi di Siena. In particolare vengono riportati i risultati di una simulazione effettuata su di un sistema federato basato su Active Directory Federation Services (ADFS), nel tentativo di comprenderne le potenzialità e studiarne l attuabilità all interno di un ambiente eterogeneo come quello gestito dal Consorzio Operativo Gruppo MPS.

6 Capitolo 1 Identificazione Digitale Sin dalla nascita dei primi sistemi informatici si è avvertita la necessità di renderli capaci di accertare l identità di un utente (persona fisica, hardware, software, o applicativo che sia) che desideri accedere ai loro servizi. Il procedimento attraverso il quale un utente viene riconosciuto da un sistema prende il nome di autenticazione. Questa dovrebbe avvenire nel modo seguente: 1) identificazione fisica dell utente (per le persone fisiche); 2) rilascio di credenziali del tipo username e password o di dispositivi per il riconoscimento (i token); 3) immissione nel sistema di queste credenziali; 4) utilizzo delle credenziali da parte dell utente; 5) riconoscimento dell utente da parte del sistema. L identificazione è una procedura organizzativo-tecnologica attraverso la quale si verifica l identità fisica dell individuo, le sue caratteristiche rispetto al servizio richiesto (ruolo, stato civile, fedina penale, ecc.) e si rilasciano le credenziali. Esistono tre tipologie di procedure di identificazione: de visu (viene identificato l individuo da personale preposto e vengono consegnate le credenziali, certamente la più sicura perché la più datata ), registrazione mista (viene chiesta una registrazione via Internet dell individuo alla quale farà seguito l invio delle credenziali via o web nonché di una parte del PIN, quella rimanente verrà inviata via raccomandata al destinatario) e la registrazione via web (viene chiesta una registrazione via Internet dell individuo il quale riceverà le credenziali vie o web, molto incline alle frodi). Storicamente già i primi sistemi di elaborazione a schede perforate utilizzavano un autenticazione basata sull uso di credenziali formate da username e password. Tali tecniche in realtà certificano soltanto che la persona che accede al sistema conosce delle informazioni segrete legate ad un certo account, senza affermare niente riguardo all identificazione. Discorso analogo avviene per le tecniche basate su certificati (o token), come le carte magnetiche o a radio frequenze. Un primo passo per cercare di realizzare una forma di autenticazione che fornisca garanzie anche riguardo all identificazione è stato quello dei sistemi biometrici, come la lettura dell iride, l impronta digitale ed il riconoscimento vocale. Purtroppo queste tecniche presentano delle probabilità di errore ancora troppo elevate per poter essere impiegate all interno di sistemi sicuri. Tuttavia vengono utilizzati per realtà con un basso numero di utenti, come alcuni laboratori, oppure per proteggere i dati di dispositivi personali, come i palmari, spesso all interno di un sistema ibrido che prevede anche l uso di un token o di una password.

7 Con lo sviluppo di Internet e della rete globale il problema dell autenticazione ha assunto un ruolo centrale grazie allo sviluppo dell e-commerce e più in generale delle transazioni sul web. In questi frangenti il problema di autenticazione cresce poiché l utente deve essere identificato dal server prima che questo rilasci i servizi e lo stesso utente chiede di sapere l identità esatta del server prima di effettuare un operazione (pagamento elettronico, inserimento di dati sensibili, inserimento di dati identificativi). Tutte queste comunicazioni avvengono attraverso lo scambio di messaggi su rete insicure, quindi richiedono alla base dei meccanismi che garantiscono la segretezza e l integrità dei dati. Il meccanismo più diffuso che cerca di garantire questi requisiti è la crittografia, una branca della matematica che trasforma il messaggio in chiaro in un altro che risulta essere leggibile soltanto da chi possiede un informazione aggiuntiva (detta chiave). Tuttavia è necessario anche che le due parti non abbiano la possibilità di ripudiare i messaggi inviati e ricevuti, ciò avviene utilizzando la firma digitale, la cui apposizione garantisce l autenticazione del messaggio e conseguentemente quella dell utente. La firma digitale non può consistere semplicemente in una digitalizzazione del documento originale, poiché un acker potrebbe tagliare dal documento digitale la parte contenente la firma e copiarla su un altro documento. Deve avere una forma che dipenda dal documento su cui viene apposta, per essere inscindibile da questo e garantirne l integrità persistente. Così facendo si fornisce la possibilità di poter valutare la correttezza del documento potendolo aprire con un software strettamente collegato a quello utilizzato per apporre la firma e quindi di provata fiducia. Si evitano così possibili sorprese dovute all uso di particolari funzioni, come i campi condizionali di Word, che producono una visione inesatta, o incompleta, del testo firmato. Per realizzare la firma digitale si utilizza una variante della crittografia a chiave pubblica (o asimmetrica) realizzata invertendo l uso classico delle chiavi, cioè si utilizza la chiave privata del mittente per firmare un documento, cifrando un suo digest, e quella pubblica per verificare la firma. Chiunque può verificare l'autenticità sia del documento che della firma utilizzando la chiave pubblica del mittente. Un metodo che è stato realizzato per fornire al destinatario la possibilità di procurarsi tale chiave è la Public Key Infrastructure (PKI), un sistema di certificazioni composto da entità fidate, strumenti e sistemi che sono usati per permettere l uso della tecnologia a chiave pubblica anche in ambienti con un alto numero di utenti. Tale infrastruttura sposta l operazione di autenticazione dell utente a monte delle applicazioni, rendendola indipendente da queste. Al centro della PKI ci sono degli enti di provata fiducia preposti alla certificazione di validità delle chiavi pubbliche: le Certification Authority (CA). Una CA autentica l associazione (utente, chiave pubblica) emettendo un certificato digitale, che consiste della chiave pubblica e di una lista di informazioni relative al suo proprietario, opportunamente firmate dalla CA. Per svolgere correttamente il suo ruolo, la CA mantiene un archivio di chiavi pubbliche sicuro, accessibile a tutti e protetto da attacchi in scrittura non autorizzati. La chiave pubblica della CA è nota agli utenti che la mantengono protetta da

8 attacchi esterni e la utilizzano per verificare la firma della CA stessa sui certificati. Un certificato digitale contiene: - un indicazione del suo formato (numero di versione); - il nome della CA che lo ha rilasciato; - un numero che lo individua univocamente all interno della CA emittente; - la specifica dell algoritmo usato dalla CA per creare la firma elettronica; - il periodo di validità del certificato (data di inizio e data di fine); - il nome dell utente a cui questo certificato si riferisce e una serie di informazioni a lui legate; - un indicazione del protocollo a chiave pubblica adottato da questo utente per la cifratura e la firma (nome dell algoritmo, suoi parametri, e chiave pubblica dell utente); - firma della CA eseguita su tutte le informazioni precedenti. Se all interno del sistema ci sono varie CA la verifica di un certificato risulta più complicata e avviene attraverso una catena di verifiche. Esistono varie tipologie di organizzazione delle CA: - gerarchica, con una struttura ad albero in cui ogni nodo certifica soltanto i propri figli, con in più alcuni rami trasversali. I problemi sono legati alla complessità di percorrenza della struttura; - non strutturata, una specie di web, con problemi legati alla scalabilità ed alla delega della fiducia; - PKI auto-gestita, fa tutto da sé, è lei la sua stessa CA e decide cosa fare; ovviamente manca la copertura globale nel caso in cui gli altri non si fidino di lei; - Web of trust, viene realizzato un contratto con chi realizza un browser per essere inseriti nella lista delle CA predefinite. Nella pratica si usano spesso forme più vaghe di firma legate ad una PKI auto-gestita. Ad esempio all interno del Monte dei Paschi i certificati utilizzati per i Web Service sono rilasciati dalla stessa banca, ed analogamente avviene per i certificati client dell Home Banking. Questo permette una gestione più dinamica dei certificati e soprattutto più economica, poiché il loro costo è nullo. Un sistema del genere presenta lo svantaggio che la firma ha validità soltanto all interno di quella struttura. Questo forse non rappresenta un grosso limite, anzi per certi versi fornisce una forma di sicurezza maggiore. Inoltre così facendo si evita di realizzare una struttura complicata come la CA. Il CA implicitamente prescrive un insieme di partecipanti, a cui ci si riferisce come security domain. I security domain possono essere differenti anche se sono basati sulla stessa infrastruttura di sicurezza, quale la PKI. Come si può immaginare, nel mondo reale esistono numerosi security domain, e non c è nessuna prospettiva per considerarli integrati in una singola infrastruttura di sicurezza. Il punto debole del meccanismo realizzato con PKI è rappresentato dai certificati revocati, cioè non più validi, che sono periodicamente pubblicati in

9 un archivio dalla CA. La frequenza di controllo di questi certificati e le modalità della loro comunicazione agli utenti sono cruciali per la sicurezza. La firma digitale descritta fino ad ora funziona bene per sistemi statici amministrati centralmente e basati sull identità (ad esempio un azienda), ma è necessario aggiungerle qualcosa per adattarla ad una realtà costituita da un organizzazione virtuale formata da diversi partner. Questa non presenta un nucleo amministrativo centrale che possa gestire l autenticazione, ma vuole comunque offrire agli utenti una vista unificata dei servizi. Gli utenti di tale organizzazione sono conosciuti almeno ad un partner, possono essere autorizzati ad usare i servizi di qualche altro e essere iscritti in qualsiasi momento da uno qualsiasi di questi. Siamo di fronte al più classico ed ampio caso in cui vengono utilizzati i Web Service.

10 Capitolo 2 Sicurezze e tecnologie Con lo sviluppo delle Organizzazioni Virtuali (azienda estesa) i Web Service assumono notevole importanza, poiché, essendo basati su tecnologie aperte, garantiscono l interoperabilità tra sistemi informatici diversi. Un Web Service è un applicazione le cui elaborazioni sono disponibili attraverso il protocollo http sulla porta 80. L applicazione server può essere interrogata con messaggi con una struttura prefissata, il Web Service elabora le richieste e fornisce una risposta al client in formato predefinito secondo uno specifico formato chiamato SOAP. Questo è un protocollo di comunicazione che si basa sullo scambio di dati in formato XML. Così facendo possono scambiare anche strutture dati anche complesse nel payload del messaggio. Un servizio SOAP è realizzato da: un URL che identifica l oggetto remoto da chiamare, il metodo che è invocato con una richiesta http che contiene un documento XML che specifica i parametri di ingresso, e la risposta che è una risposta http che contiene un documento XML con i valori dei parametri di uscita. Gli obiettivi di questo protocollo sono: aumentare l interoperabilità rispetto a soluzioni proprietarie (es. RMI), che si ottiene grazie all uso di XML e http; permettere una facile manutenzione ed aggiornamento; eliminare le limitazioni dovute alle politiche di sicurezza. I limiti sono legati al fatto che non considerano le problematiche proprie di un sistema di oggetti distribuiti, inoltre non è ottimale al livello di prestazioni. Questo dipende dal fatto che i dati sono serializzati in XML e la loro deserializzazione richiede di usare un parser XML per estrarre i dati dal payload. Dobbiamo anche ricordare che è un protocollo senza stato (come l http), quindi non è in grado di mantenere informazioni di stato fra una connessione e l altra; e che non gestisce la sicurezza, se non viene basato su https. Il protocollo SOAP definisce il modo di incapsulare i dati da scambiare fra host e, in caso di errore, definisce il formato del messaggio di fault. Vengono anche definite le regole di codifica dei dati utilizzando le definizioni di XML schema, e come effettuare una Remote Procedure Call. I messaggi SOAP sono delimitati dall envelope, e contengono un header ed un body: envelope contiene tutto ciò che fa parte del messaggio SOAP; header è la componente opzionale del messaggio, contiene regole di encoding per aggiungere funzionalità al messaggio; body: è la componente principale, e necessaria, di un messaggio SOAP, contiene tutte le informazioni da inviare al destinatario. Essendo strettamente legato all applicazione, ogni nodo intermedio non lo considera.

11 Altri aspetti importanti di questa tecnologia riguardano alcune definizioni relative alle specifiche dell interfaccia di un certo Web Service (WSDL - Web Services Description Language), al meccanismo per interrogare un server e conoscere quali particolari servizi sono disponibili (DISCO -Discovery of Web Services), ed al sistema usato per pubblicare i Web Service che un fornitore rende disponibili (UDDI - Universal Description Discovery and Integration). I Web Service trasformano il Web da orientato alle persone a orientato alle applicazioni, infatti i service provider mettono a disposizione servizi che sono integrabili nelle applicazioni e non più fruibili soltanto dall utente umano. All interno dell architettura dei Web Service sono definiti tre ruoli fondamentali: - Service Provider, che implementa il servizio e lo rende disponibile su Internet; - Service Requestor, un applicazione (client) che utilizza un Web Service (identificato dal suo end-point URL) per mezzo di una richiesta XML; - Service Registry, un servizio di pubblicazione e ricerca dei servizi. Vista l importanza rivestita dai Web Service possiamo facilmente capire come la loro sicurezza e quella delle rispettive applicazioni assuma una posizione cruciale per motivi finanziari, legislativi, di privacy, etc. I primi standard emersi per i Web Services si interessavano solo dell interazione tra le parti, senza preoccuparsi della cifratura, dell autenticazione o dell autorizzazione. Quindi si è reso necessario fornire un modello comprensivo di funzioni e componenti di sicurezza per i Web Services. Questo ha richiesto, e richiede tuttora, l integrazione dei processi e delle tecnologie attualmente disponibili con i requisiti di sistema che si presenteranno nelle applicazioni future. La volontà di unificare le tecnologie per la sicurezza dei Web Service implica che i requisiti funzionali dell applicazione devono essere indipendenti dal sistema usato, in modo tale da assicurare ai clienti la possibilità di costruire soluzioni interoperabili usando piattaforme eterogenee. Service registry Register services Discover services Service Requestor Get service description Invoke service Web service provider Architettura di un Web Service

12 Il vantaggio di tale modello è evidente: elaborando un architettura di sicurezza per i Web Service, le organizzazioni e i clienti possono essere sicuri che i loro investimenti e le loro risorse siano protetti da processi di business che sono in continua evoluzione, quali gli stessi Web Service. La sicurezza dei Web Service può essere realizzata sia a livello di trasporto che di messaggio. La prima modalità costituisce un approccio sbagliato poiché si scontra con la caratteristica fondamentale dei Web Service la totale indipendenza dalla piattaforma su cui vengono realizzati. Utilizzando una sicurezza a livello di messaggi le informazioni ad essa relativa sono contenute all interno dei messaggi SOAP stessi, con il vantaggio di permettere a parti di messaggi di essere trasportate in modo sicuro dai nodi intermediari, che potrebbero vedere o modificare il messaggio. Ad esempio, una porzione di messaggio può essere firmata da un mittente e cifrata per un particolare ricevente, che è l unico che la può decifrare. Numerosi security domain già esistono su Internet e Intranet e, sebbene le applicazioni e le entità partner nella organizzazione virtuale appartengano a uno o più di questi, è necessaria una loro interazione sotto il security domain boundary. Ogni partner ha la propria infrastruttura e il proprio meccanismo di sicurezza, ad esempio il PKI. Nel contesto dei Web Services, questi sistemi di sicurezza necessitano di interoperare su diversi security domain. L architettura di sicurezza nei Web Services definisce un modello astratto per questo scopo. 2.1 STS: un esempio Le moderne associazioni di imprese fanno realmente leva su infrastrutture IT per facilitare il proprio business, riducendo il ciclo di vita dei progetti e la gestione delle risorse. Le grandi organizzazioni impiegano applicazioni personalizzate per gestire le loro vendite interne, gli acquisti, gli stipendi e le finanze. Ci sono tecnologie intermedie che supportano sistemi costruiti in maniera personalizzata ed integrano applicazioni utilizzate per aumentare l efficienza operazionale e i gestione. Per esempio Enterprise Application Integration (EAI) è un processo che crea una infrastruttura integrata all interno di un azienda. EAI permette lo sviluppo di soluzioni software che stanno tra varie applicazioni all interno di un sistema e ne creano un package per armonizzare tutta l attività di affari. L integrazione all interno di sistemi per le imprese non è sufficiente. Forse il grande vantaggio dello sviluppo delle infrastrutture di Information Technology è che permette l integrazione di applicazioni attraverso i confini di più sistemi, provvedendo in maniera rapida alla collaborazione tra partner, clienti e fornitori. Si prenda ad esempio un tour operator che progetta e offre vacanze personalizzabili. Le vacanze prevedono tutte le informazioni relative alle destinazioni, gli hotel in cui soggiornare, i voli da prendere, etc. Siccome le vacanze sono personalizzabili, i clienti hanno alcuni livelli di flessibilità per scegliere i dettagli dell escursione, per esempio potrebbero scegliere tra i vari hotel o le varie compagnie di noleggio auto. Come può fare il tour operatore a gestire le prenotazioni di un sistema del genere? Come fa a sapere quali hotel, tra quelli disponibili, sono

13 liberi nelle date richieste? Sicuramente tutto ciò richiede una comunicazione tra i vari partner d affari. Il tour operator dovrà chiedere la disponibilità e prenoterà gli hotel scelti prima di confermare la prenotazione all utente. Lo scambio di dati attraverso la rete Internet tra partner di una stessa organizzazione virtuale comporta delle implicazioni per quanto riguarda la sicurezza. Essendo la rete di per sé insicura sono necessari degli accorgimenti. Un esempio è l inserimento di un firewall a fare da filtro per una certa sottorete (solitamente una rete intranet). Sostanzialmente gli obiettivi per la sicurezza che si cerca di garantire con l uso di un firewall sono: monitoraggio di tutto il traffico in ingresso; ricerca dell identità di chi richiede un servizio cercando di accedere e a specifiche risorse della compagnia; autenticazione degli utenti basandosi sulla loro identità, che può essere fornita attraverso gli indirizzi di rete o dei token; controllo della sicurezza e delle politiche di business filtrando gli accessi e verificando se il richiedente ha i diritti per accedere a quelle risorse; gestire tutto l apparato di cifratura dei messaggi permettendo di trasmettere sulla rete anche informazioni confidenziali di affari. Due o più partner di una organizzazione virtuale fornitrice di una serie di servizi combinati non necessariamente utilizzano sistemi informativi uguali. Ad esempio un azienda può utilizzare Java su dei server Solaris, mente un altra utilizza il.net. quello che ci interessa è riuscire a garantire l interoperabilità del servizio, indipendentemente dalla piattaforma su cui viene implementato. Se non fosse possibile utilizzare una tipologia unica per l invio dei messaggi tra i vari partner il costo delle operazioni (anche a livello di tempo) diventerebbe inadeguato agli scopi dell organizzazione. Una soluzione è data dallo sviluppo dei Web Service, cioè dal passaggio da un Web statico orientato alle persone ad uno dinamico, orientato ai servizi, all interno del quale è possibile utilizzare le architetture Service Oriented (SOA). Un ruolo importante in tale architettura è rivestito dai Server SOAP che si comportano come interpreti tra il mondo statico del web basato su messaggi HTML e quello dei Web Service, basato su applicazioni che poggiano proprio sul SOAP. Quando arriva la richiesta di un certo servizio, il Server SOAP invoca il metodo opportuno, prepara un messaggio di risposta e lo rinvia al cliente. A seconda della modalità con cui il Server SOAP interagisce con i provider dei servizi troviamo tre diverse tipologie di Web Service. La prima generazione dei Web Service presenta una semplice interazione uno ad uno. Il processo di esecuzioni si trova interamente all interno del dominio del servizio e non dipende in alcun modo da altri servizi esterni.

14 1. Un applicazione invia un messaggio di richiesta di un servizio al Server SOAP; 2. il Server SOAP invoca la classe interna che implementa il servizio in questione; 3. la classe realizza il task richiesto dal servizio e ritorna il risultato al Server SOAP; 4. il Server SOAP eventualmente autorizza la risposta SOAP e la invia all applicazione che la richiede. La seconda generazione di Web Service confedera o distribuisce l elaborazione dei metodi per le richieste ad altre applicazioni Web Service. In questo modo i fornitori dei servizi sono concatenati in maniera sequenziale per adempiere alla richiesta ricevuta da un applicazione esterna. La terza generazione di Web Service è un estensione logica della precedente. Quando la catena diventa troppo lunga o la logica di affari è complessa, le applicazioni federate viste in precedenza diventano della transazioni di Web Service. Supponiamo che il nostro Web server fornisca un certo numero di servizi accessibili a tutti gli utenti ed altri strettamente riservati solo ai partner commerciali. Il Server SOAP non è in grado di poter distinguere tra una richiesta che arriva da un cliente semplice o da un azienda partner. Anche inserendo un firewall non si riesce a distinguere le due tipologie di richieste, pertanto sembrerebbe che si venga a creare un buco nella rete. Ci sono due soluzioni a questo problema: utilizzare Server SOAP diversi per le due tipologie di richieste, in modo da specializzare su ciascuna di queste una policy di autenticazione. Tale soluzione è valida nel caso dei Web Service di prima generazione, mentre diventa molto costosa e complicata per le due generazioni successive. rendere il firewall capace di interpretare messaggi XML e SOAP. Questa soluzione è di gran lunga la migliore visto anche che permette l uso di standard per la sicurezza basati su XML e quindi l interoperabilità indipendentemente dalla piattaforma su cui lavorano le varie aziende partner.

15 Proprio questo secondo metodo deve essere ben specificato cercando di capire per bene sia come i vari standard XML collaborino all interno del firewall, sia quali sono le diverse tipologie di security token che si possono usare e come sono collegati alla firma digitale e alla cifratura dei dati. Si ritorni all esempio del tour operator fatto precedentemente, questi vuole prenotare alcune stanze presso un hotel ed avvalersi degli sconti riservati ai partner dell organizzazione (servizio nascosto agli utenti privati). Vediamo come viene processata una richiesta: 1. il servizio del tour operator invia la richiesta al Web Service dell hotel. Tale richiesta deve essere accompagnata da alcuni dati che ne dimostrino la provenienza da un partner fidato, per questo viene inserito un security token al suo interno ed una firma digitale che può garantire l integrità del messaggio. 2. Avviene all interno del XML firewall che deve provvedere all autenticazione e al controllo dell integrità del messaggio. Per quanto riguarda la prima proprietà viene analizzato il token che si trova all interno del messaggio. Per controllarne l integrità il firewall verifica la correttezza della firma apposta sul messaggio che dipende strettamente dal suo contenuto. Il Server SOAP ed XML firewall possono essere realizzati su due macchine diverse o su una stessa macchina. Nel primo caso è importante che non ci siano strade provenienti dall esterno che conducano direttamente al SOAP Server senza passare attraverso il firewall. 3. Il firewall XML inoltra la richiesta al Server SOAP. Solitamente tale messaggio consiste soltanto del body, poiché non sono più necessarie le informazioni per la sicurezza contenute nell header, che sono già state utilizzate per le operazioni di controllo dal firewall. 4. Il Server SOAP invoca il Web Service e prepara la risposta SOAP da rimandare indietro. 5. il Server SOAP invia la risposta indietro al firewall XML. 6. il firewall XML prepara il messaggio di risposta per il tour operator. Questo deve necessariamente includere tre cose: un security token che dimostra che la risposta arriva dal hotel, una firma digitale come prova dell autenticazione e dell integrità del messaggio

16 ed una cifratura dei dati confidenziali contenuti nel messaggio, come l importo dello sconto che viene applicato. 7. L hotel invia la propria risposta completa al tour operator. 8. Il tour operator processa il messaggio e legge lo sconto speciale inviatogli dall hotel. Un caso più complicato si ha quando il tour operator e l hotel non hanno una relazione di fiducia, ma il tour operator vorrebbe ugualmente avere uno sconto. Nel sistema abbiamo anche una nuova entità, un emarketplace. Si assume che l hotel ed il tour operator non si conoscano a vicenda per lo scambio dei messaggi, ma entrambe hanno una relazione fidata con l emarketplace. 1. Il tour operator vuole ottenere lo sconto speciale offerto dall hotel. Per prima cosa richiede all emarketplace di emettere un asserzione SAML dopo avergli inviato anche un security token che permetta a questi di autenticare il tour operator. 2. L emarketplace invia un asserzione SAML in risposta alla richiesta del tour operator. 3. Il tour operator inserisca la risposta SAML in un messaggio WS-Security e lo invia all hotel. In questo caso l asserzione SAML funziona come un security token. 4. Il firewall XML dell hotel processa il messaggio, estraendo l asserzione dal header e controllandone la validità. Una volta terminate in maniera positiva le operazioni di controllo il firewall ripulisce il messaggio delle informazioni per la sicurezza. 5. Il firewall XML invia il messaggio ripulito al Server SOAP. 6. Il Server SOAP dell hotel invoca il Web Service e prepara la risposta. 7. Il Server SOAP invia la risposta al firewall XML. 8. Il firewall XML crea tutti i dati necessari alla sicurezza informatica e li inserisce nella risposta SOAP. 9. Il firewall XML invia al tour operator un messaggio WS-Security.

17 10. Il tour operator processa il messaggio ricevuto, controlla i parametri di sicurezza ed estrae le informazioni necessarie per capire l esito delle richiesta di sconto fatta. 2.2 Profili di sicurezza web Protocolli di sicurezza a livello di trasporto - SSL Come già detto precedentemente la sicurezza dei Web Service può essere realizzata sia semplicemente a livello di trasporto che a livello di messaggi. In generale i protocolli di trasporto sicuri come SSL/TSL garantiscono la sicurezza durante la trasmissione, ma se i messaggi passano attraverso intermediari non completamente fidati, come per esempio macchine aziendali non protette, la sicurezza della comunicazione non è garantita. Inoltre una forma di sicurezza realizzata in questo modo non crea un sistema interoperabile orientato ai servizi, come è invece richiesto dalla natura stessa dei Web Service. Ci sono casi in cui un messaggio SOAP attraversa intermediari connessi da reti differenti, quindi i meccanismi di sicurezza devono essere adattati ai diversi protocolli di trasporto utilizzati; poiché questo tipo di trasformazioni potrebbe portare a violazioni della sicurezza, è bene utilizzare tecniche a livello di messaggio piuttosto che di canale di trasporto. Potremmo quindi affermare che la sicurezza richiesta dai Web Service è di tipo end-to-end anziché point-to-point come quella fornita dagli standard di sicurezza a livello di trasporto. Tra questi un ruolo di primo piano spetta allo standard SSL (Secure Socket Layer), quello maggiormente diffuso nelle transazioni di e-commerce. SSL è un protocollo a due strati che vuole garantire la sicurezza delle comunicazioni, la riservatezza dei dati (con cifratura simmetrica), l autenticazione delle identità (tramite presentazione di certificati digitali) e lo scambio della chiave segreta (con algoritmi di cifratura asimmetrici). I due livelli sono: Protocollo SSL Handshake, permette al server ed al client di autenticarsi a vicenda e di negoziare un algoritmo di crittografia, e le relative chiavi, prima che il livello di applicazione trasmetta o riceva il suo primo byte. Un vantaggio di SSL è la sua indipendenza dal protocollo di applicazione, in tal modo un protocollo di livello più alto può interfacciarsi sul protocollo SSL in modo trasparente; Protocollo SSL Record, è interfacciato su di un protocollo di trasporto affidabile come il TCP. Questo protocollo è usato per l'incapsulamento dei dati provenienti dai protocolli superiori. http SSL Handshake SSL Record TCP IP

18 SSL prevede una fase iniziale, detta di handshake, usata per iniziare una connessione TCP/IP. In particolare il risultato di tale fase è l'avvio di una nuova sessione che permette la contrattazione da parte del client e del server del livello di sicurezza da usare ed il completamento delle autenticazioni necessarie alla connessione. Quindi SSL procede con la cifratura (e/o con la messa in chiaro) della sequenza di byte del protocollo applicazione usato. Il funzionamento di questo protocollo SSL Handshake, supponendo che sia il client a fare il primo passo, si può riassumere nel seguente modo: I messaggi contrassegnati con * non sono obbligatori ed il messaggio change CipherSpec non fa parte del protocollo handshake ma viene inviato in quella posizione. Il client ed il server possono decidere di riabilitare una precedente sessione o di duplicarne un esistente invece di negoziare di nuovo i parametri di sicurezza; in questo caso si parla di riesumazione di sessioni. Il protocollo SSL Record prende i messaggi che devono essere trasmessi, li frammenta in blocchi di dati (record al più di 2 14 byte), opzionalmente li comprime, applica un MAC (Message Authentication Code che viene utilizzato per il protocollo dell integrità dei dati), li cifra, e trasmette il risultato. I dati ricevuti vengono decifrati, verificati, decompressi, e riassemblati, quindi vengono trasmessi al livello più alto. I blocchi creati dal Protocollo SSL Record sono organizzati in record SSLPlaintext la cui struttura è illustrata di seguito.

19 Tutti i record SSLPlaintext sono compressi, e prendono il nome di SSLCompressed. Tutti i record sono protetti usando gli algoritmi di crittografia e MAC definiti nel corrente CipherSpec. Le tecniche usate per le operazioni di crittografia e di MAC trasformano una struttura SSLCompressed in una SSLCiphertext. La decifratura inverte tale trasformazione. Le trasmissioni includono anche un numero di sequenza, in modo che i messaggi persi, alterati o intrusi siano rilevabili. Per notificare le eccezioni che possono avvenire nella comunicazione sono utilizzati i messaggi di alert. Questi contengono il livello di severità e una descrizione dell'evento occorso, ad esempio un messaggio con livello "fatal" si risolve con l'immediata terminazione della sessione. Come gli altri messaggi anche quelli di alert sono cifrati e compressi. Per chiudere una connessione, il client ed il server devono avviare lo scambio dei messaggi di chiusura. In particolare il messaggio close notify notifica al ricevente che il mittente non trasmetterà più su quella connessione. La sessione diviene non riesumabile se la connessione è terminata senza il dovuto messaggio close_notify con livello warning. 2.3 XML Security standard XML Security fornisce un insieme di standard mirati a soddisfare i requisiti della sicurezza. Questi standard sono progettati in maniera conforme ai paradigmi XML comuni e fanno leva su altri standard XML. Le caratteristiche principali sono: 1. definiscono dei vocabolari XML per rappresentare le informazioni di sicurezza, utilizzando le tecnologie XML per le definizioni. Queste definizioni sono usate in un gran numero di specifiche, in modo tale da assegnare un significato condiviso ai vari vocabolari XML. 2. utilizzano, quando è possibile, altri standard XML esistenti. 3. sono progettati per offrire la flessibilità e l estensibilità proprie del XML. Permettono di applicare la sicurezza a documenti ed elementi XML, così come classicamente avviene con documenti binari. Supportano, estendendoli, i vocabolari XML utilizzando i namespace XML e le definizioni di XML schema estensibili. 4. possono essere applicati alla sicurezza finale (end-to-end), che è particolarmente importante quando i messaggi XML sono instradati attraverso varie elaborazioni intermedie. Questo avviene perché la sicurezza è associata al dato anziché ad un canale

20 di trasporto. Comunque ciò non vieta che tale tecnologia sia utilizzata in combinazione con quelle di sicurezza del trasporto, come SSL/TLS o altre. 5. riutilizzano, quando è possibile, tecnologie di crittografia e di sicurezza già esistenti. Ad esempio i certificati X.509 V3 sono usati senza essere ridefiniti, ma semplicemente inserendoli in un testo. Anche algoritmi esistenti, come l algoritmo di hashing SHA1, sono utilizzabili all interno di questi standard associando un identificatore URI unico a ciascuno di essi e definendo il modo in cui possono essere usati nei modelli di esecuzione. Gli standard XML Security creano le basi per garantire la sicurezza ad altre tecnologie basate su XML, quali i Web Services e la Digital Rights Management. Vediamo ora i principali standard XML Security progettati, in maniera compatibile con la tecnologia XML, per soddisfare i requisiti di sicurezza XML Digital Signature (XML DigSig) XML Digital Signature è particolarmente importante poiché stabilisce un approccio basato sui vocabolari condivisi da molti altri standard. Ad esempio <KeyInfo>, definito dal XML Digital Signature viene utilizzato da molti altri standard. La funzionalità della firma risulta essere anche molto importante per quanto riguarda l integrità dei contenuti, così XML Digital Signature viene utilizzata all interno di molti altri standard per la sicurezza. La XML DigSig definisce i meccanismi necessari per supportare l intero range di creazione e verifica della firma digitale, inclusa la capacità di firmare e verificare un'ampia gamma di documenti, quali: 1) interi documenti XML, così come sue porzioni e suoi elementi; 2) altre tipologie di documenti, anche binari; 3) documenti composti; 4) proprietà che devono essere incluse in una firma; 5) contro-firme, cioè firme che ne includono altre. La XML DigSig permette l applicazione di più firme ad un documento XML, o a sezioni differenti di questo, creando così un ampia varietà di casistiche. Le specifiche del XML DigSig definiscono anche le tecniche che producono una verifica della firma robusta rispetto alle variazioni consentite nel XML, ad esempio l inserimento di spaziature. L interesse verso tale standard nasce dal fatto che risulta essere molto più flessibile degli algoritmi crittografici i quali lavorano soltanto su testi sintatticamente corretti. Per aumentare tale vantaggio viene effettuata un operazione di canonizzazione del documento, in modo tale da ridurre buona parte di queste variazioni e rendere interoperabili tutte le applicazioni.