Aspetti di sicurezza dei web services

Capitolo 2    Il caso di studio  6  
usate per autenticare un client o un’indicazione del percorso che un 
messaggio dovrebbe prendere. 
 ξ  SOAP body (corpo), che contiene la parte significativa del messaggio. 
Un messaggio SOAP valido deve avere un elemento body. 
Un servizio web è descritto mediante una descrizione del servizio, che specifica in 
modo formale tutte le informazioni necessarie per la sua invocazione: ad 
esempio la localizzazione, il formato dei messaggi, il protocollo di trasporto. 
La descrizione dei servizi web è anch'essa basata su un apposito formato 
XML: WSDL (Web Services Description Language). 
Una delle caratteristiche più interessanti dei web services è la possibilità di 
utilizzarli per comunicazioni e scambi di informazioni automatici: non 
interazione tra persona e applicazione (come avviene nella navigazione sul 
web) bensì interazione tra applicazioni. La descrizione formale e 
standardizzata dei servizi web, infatti, consente la ricerca e l'utilizzo dei web 
services senza richiedere necessariamente l'intervento umano. 
Ad esempio, un agente software potrebbe essere istruito per svolgere un 
determinato compito utilizzando automaticamente un servizio web; altrettanto 
automaticamente, l'agente potrebbe interrogare un repertorio di servizi web 
per cercare altri servizi di cui avesse bisogno. La classificazione dei servizi web 
è basata su un terzo formato XML, UDDI (Universal Description Discovery 
and Integration). 
L’utilizzo dei web services nei sistemi informatici aziendali consente 
l’interazione fra piattaforme diverse, purché rispettino gli standard definiti, 
rendendo possibile ad esempio, ad un client Java di dialogare con un servizio 
web implementato con il linguaggio Visual Basic .NET. 
Inoltre, allo stesso tempo, il servizio web può esporre le funzionalità di 
qualsiasi tipo di applicazione, da un programma Java ad un’applicazione 
COBOL su Mainframe, consentendo l’integrazione di sistemi legacy, purché si 
costruisca un web service che li “incapsuli”. 
Per sistema legacy s’intende un sistema informativo di valore ereditato dal 
passato. I concetti fondamentali sono appunto di valore (cioè critico per il 
business dell’azienda) e ereditato dal passato (spesso il suo primo nucleo risale 
ad oltre un decennio fa ed è quindi progettato secondo vecchie concezioni). 
Generalmente i sistemi legacy sono realizzati su architetture basate su 
Mainframe (grande calcolatore centrale), cui si collegano terminali poco 
sofisticati. Molti sistemi legacy sono tecnologicamente superati, però sono 
sistemi affidabili, il cui funzionamento continuo è indispensabile. 
Capitolo 2    Il caso di studio  7  
Attualmente molte aziende sono interessate all’evoluzione dei propri sistemi 
legacy, per rispondere ai nuovi e mutevoli requisiti di business 
dell’organizzazione. 
 Le principali metodologie utilizzate sono: 
 ξ  Downsizing, trasformazione verso architetture client-server. 
 ξ  Incapsulamento, definizione di un’interfaccia di alto livello, richiamabile 
tramite interfacce client standard, che mascherano la reale struttura del 
software. 
Il problema principale nello sviluppo di servizi web che incapsulano sistemi 
legacy è quello della sicurezza. Di solito ogni applicazione legacy è protetta da 
una propria politica di sicurezza, con la quale il gestore del sistema specifica 
chi sono gli utenti autorizzati e le abilitazioni di ciascuno alle funzionalità e ai 
dati dell’applicazione.  
Nel momento in cui un’azienda espone le proprie applicazioni legacy tramite 
servizi web, è necessario creare un’infrastruttura di sicurezza che garantisca 
l’accesso agli utenti autorizzati e protegga l’integrità e la riservatezza dei 
messaggi scambiati attraverso la rete intranet/internet. 
Tuttavia, le specifiche di base dei servizi web (SOAP, WSDL, UDDI), non 
sono sufficienti per realizzare applicazioni sicure. Se si desidera realizzare un 
servizio web protetto, infatti, è necessario creare una soluzione personalizzata. 
La maggior parte degli sviluppatori sfrutta l'infrastruttura di protezione del 
protocollo di trasporto sottostante il servizio in questione, tipicamente HTTP.  
I web services sono sinonimo di interoperabilità, e di conseguenza le 
applicazioni che si basano su tali architetture devono poter godere della 
massima scalabilità disponibile. Per questo motivo si preferisce spostare più ad 
“alto livello” le informazioni di sicurezza, inserendole nell’intestazione 
(Header) dei messaggi SOAP, in modo da rendersi indipendenti dal particolare 
protocollo di trasporto utilizzato. 
Nell'aprile 2002, Microsoft, IBM e VeriSign hanno compiuto i primi passi per 
rispondere a questa esigenza attraverso la pubblicazione della specifica WS-
Security, che definisce un insieme standard  di intestazioni SOAP, che è 
possibile utilizzare per implementare integrità e riservatezza nelle applicazioni 
che utilizzano i servizi Web. La specifica WS-Security definisce un 
meccanismo standard per lo scambio di messaggi sicuri in un ambiente di 
servizi web e fornisce un importante livello di base che aiuta gli sviluppatori a 
realizzare servizi web più sicuri [4].  
In WS-Security viene definito un elemento intestazione SOAP (SOAP 
Header) che trasporta i dati relativi alla protezione. Se si utilizza la firma XML 
(XML Signature), questa intestazione può contenere le informazioni definite 
Capitolo 2    Il caso di studio  8  
dallo standard XML Signature che indicano in che modo il messaggio è stato 
firmato, quale chiave è stata usata e il valore risultante della firma. In modo 
analogo, se un elemento all'interno del messaggio è crittografato, l'intestazione 
di WS-Security può contenere le informazioni di crittografia, ad esempio 
quelle specificate dallo standard XML Encryption. WS-Security non specifica 
il formato della firma o della crittografia. Specifica, invece, come incorporare 
in un messaggio SOAP le informazioni sulla protezione, definite in base ad 
altre specifiche.  
Oltre a sfruttare protocolli esistenti per l'autenticazione, l'integrità e la 
riservatezza dei messaggi, WS-Security definisce un meccanismo per il 
trasferimento di semplici credenziali dell'utente mediante l'elemento 
UsernameToken. Definisce, inoltre, un elemento BinarySecurityToken per l'invio di 
token binari utilizzati per la crittografia o la firma dei messaggi. 
Nell'intestazione i messaggi possono memorizzare informazioni sul mittente, 
sul modo in cui il messaggio è stato firmato e sul modo in cui è stato 
crittografato. Poiché mantiene tutte le informazioni sulla protezione nella 
parte SOAP del messaggio, WS-Security rappresenta una soluzione end-to-
end per la protezione dei servizi Web.  
Dal momento che tutte le informazioni sono incluse nel messaggio stesso, il 
tipo di trasporto utilizzato è indifferente. Il messaggio è ugualmente protetto, 
indipendentemente dal fatto che venga trasmesso via HTTP o tramite posta 
elettronica.  
Quando si utilizzano dei meccanismi di sicurezza è necessario specificare le 
politiche di sicurezza, con le quali si definiscono i requisiti di sicurezza per un 
particolare servizio web.  
Per esempio, se un servizio web è protetto da WS-Security è necessario 
specificare le tipologie di credenziali richieste dal servizio (certificati digitali, 
password, ecc.), così come gli algoritmi accettati per la firma e  la crittografia 
dei messaggi. 
Microsoft e IBM hanno pubblicato il documento WS-Policy, che definisce un 
approccio generale per specificare le politiche di sicurezza dei web services [9]. 
Con il documento WS-SecurityPolicy sono stati definiti degli elementi XML per 
descrivere le politiche relative alle caratteristiche specificate in WS-Security. 
Con queste politiche è possibile descrivere in modo non ambiguo i requisiti di 
sicurezza dei web services [10]. 
Leggendo queste politiche i consumatori del servizio web possono conoscere 
con esattezza i requisiti di sicurezza richiesti per accedere al servizio.  
Capitolo 2    Il caso di studio  9  
Le specifiche WS-Security e WS-SecurityPolicy sono solo alcune delle 
specifiche che costituiscono il progetto GXA (Global XML Web Services 
Architecture) della Microsoft [2].  
 
 
Figura 1: Le principali specifiche GXA. 
 
Attualmente il progetto GXA è composto da una decina di specifiche molte 
delle quali ancora in fase di studio mentre altre sono già avviate al processo di 
standardizzazione. Sulla base di WS-Security le principali specifiche che 
compongono l’architettura GXA sono illustrate in Figura 1. 
Capitolo 2    Il caso di studio  10  
1.2 Scopo della tesi. 
La tesi si inserisce nel contesto descritto con lo studio e lo sviluppo di un caso 
di studio, con il quale è stato possibile verificare concretamente le possibilità 
offerte da queste nuove tecnologie. Lo scenario implementato consiste in un 
servizio web “protetto” da una politica di sicurezza, configurabile da un 
amministratore delle politiche.  
La politica di sicurezza è descritta da un documento XML strutturato 
seguendo le specifiche WS-Policy e WS-SecurityPolicy. 
Il servizio web sviluppato (sigla ACLI) espone alcune funzionalità di un 
sistema legacy esistente. Il sistema legacy gestisce  l’aggiornamento 
dell’anagrafica clienti da parte della forza di vendita. L’applicazione client, per 
accedere al servizio, deve fornire delle credenziali, in modo da soddisfare i 
requisiti della politica di sicurezza. Le credenziali supportate sono descritte 
dalla specifica WS-Security. L’amministratore delle politiche può aggiornare la 
politica di sicurezza, attraverso un servizio web, che funge da PAP (Policy 
Administration Point). È compito del PAP accedere al servizio web ACLI, 
comunicandogli la nuova politica in vigore (“push della politica”).  
Quando un’applicazione invia una richiesta SOAP al servizio web, si attiva il 
modulo software PEP (Policy Enforcement Point), che analizza il messaggio 
SOAP ricevuto e lo confronta con la politica di sicurezza. Il modulo software 
PDP (Policy Decision Point) invia al chiamante una risposta SOAP con i dati 
richiesti se le credenziali fornite soddisfano i requisiti di sicurezza specificati, 
altrimenti genera un messaggio d’errore che descrive il problema riscontrato. 
La figura seguente visualizza uno schema a blocchi che evidenzia le interazioni 
fra il servizio web e gli altri componenti del sistema (client, PEP, PDP, PAP). 
Client
Servizio Web
ACLI
Richiesta
PEP
PDP
Servizio Web
PAP
Repository
Politiche
Repository
Politica
Risposta
Push Politica
 
Figura 2: Schema a blocchi dello scenario implementato.