controlli di accesso su web services gis via proxy filtering

CONTROLLI DI ACCESSO VIA PROXY FILTERING PER WEB SERVICES GIS A. Galeaa, S. Menegonb, P. Brunettib
a
MPBA – ITC­irst, via Sommarive, 18, 38100 Povo (Trento) – e­mail: [email protected]
b
MPA Solutions, via Lung'Adige San Nicolò, 18, 38100 Trento – e­mail: menegon,[email protected]
KEY WORDS: WebGIS, distributed authentication, OGC standards, WMS, WFS, WMC, GML, Single sign­on. RIASSUNTO
Nelle applicazioni WebGIS moderne è uso comune il raccogliere informazioni e mappe da più servizi web. Nel caso tipico, gli utenti web vengono autenticati da un server WebGIS centrale per poi essere rediretti a differenti web services, i quali forniranno i dati richiesti per mezzo di protocolli OGC standard come WFS o WMS.
Rendere sicuro l'accesso ad un'applicazione WebGIS distribuita come quella appena descritta richiede che i dati di autenticazione siano propagati a tutti i web services che la compongono. La propagazione manuale di questi dati è però soggetta ad errori, e anche se esistono molte soluzioni di single sign­on, non riteniamo che alcuna di queste si adatti in modo semplice ad un framework WebGIS.
Proponiamo quindi un'implementazione di regole di accesso sufficientemente fini e gestite centralmente per controllare gli utenti di un'applicazione WebGIS distribuita. La nostra soluzione si avvale di un servizio proxy che orchestra comunicazioni XML criptate tra i diversi web services che compongono l'applicazione. Il proxy fa inoltre uso di un meccanismo di caching per ridurre il traffico non necessario e la latenza di rete.
Un primo prototipo per sperimentare questa soluzione, basato su prodotti OpenSource (Apache, PHP, SQLite), è già stato applicato al sistema di sorveglianza per incidenti stradali SIM­PAT MITRIS, ed è attualmente in fase di test; ci aspettiamo di avere un'implementazione completa per l'estate 2007. Il lavoro è stato parzialmente supportato dalla Provincia Autonoma di Trento e dal Ministero delle Infrastrutture e Trasporti.
ABSTRACT
A common usage pattern in modern WebGIS applications is to collect layers and map data from multiple web services. In the typical case, web clients authenticate with a central WebGis server, and are then redirected to multiple web services that will provide the requested data via standard OGC protocols like WFS or WMS.
Securing access to a distributed WebGIS application like the one described above requires authentication data to be propagated to all of the web services that compose it. Manual propagation is error prone, and while many single sign­
on solutions are possible, we are aware of none that could easily fit in with the WebGIS framework.
We propose a simple method for implementing centrally managed and fine­grained access controls rules for the clients of a distributed WebGIS application. Our solution relies on a proxy server which orchestrates secured XML communications among the different web services that compose the application. The proxy makes also use of a caching mechanism, to reduce unnecessary network traffic and latency.
Proof of concept code, based on OpenSource tools (Apache, PHP, SQLite) has been applied to SIM­PAT MITRIS road accident surveillance system and it is currently under test. A full­fledged implementation is expected for Summer 2007. The work is partially funded by Provincia Autonoma di Trento and Ministero delle Infrastrutture e Trasporti. INTRODUZIONE
1.1 Standard di interoperabilità
Negli ultimi anni hanno preso corpo alcune importanti iniziative di standardizzazione, rivolte a strutturare in modo organico un mondo estremamente frammentato come quello dell’informazione geografica. Gli standard introdotti si propongono di specificare metodologie, applicazioni e servizi per la gestione, l’acquisizione, l’elaborazione, l’analisi, la pubblicazione e lo scambio di dati geografici, così da assicurare lo sviluppo di infrastrutture GIS tra di loro interoperabili. Le principali iniziative in questo ambito sono certamente il progetto ISO/TC211 (parzialmente recepito dalle norme europee CEN/TC287 e italiane UNI EN ISO 19101) e gli standard proposti dall’Open Geospatial Consortium, Inc.® (OGC). Poiché i gruppi di lavoro che sottostanno ai due progetti operano in stretto contatto tra di loro, è garantita la complementarietà delle problematiche affrontate e sono evitate sovrapposizioni e incongruenze tra le specifiche prodotte. Tra i due, gli standard dell’OGC sono quelli che focalizzano maggiormente sugli aspetti implementativi del software; allo stesso tempo, definiscono numerose specifiche tecniche per i servizi geospaziali web based, il che li rende di fondamentale importanza nello sviluppo di servizi di WebMapping e di WebGIS in generale.
Fortunatamente, gli standard proposti dall’OGC non sono rimasti solo sulla carta: la loro diffusione è stata molto ampia, e le specifiche più mature (tra cui spiccano per la loro importanza WMS: Web Map Service e WFS: Web Feature Service) sono già implementate in molteplici progetti software.
Nell’ambito dei WebGIS, uno dei principali vantaggi della diffusione di tali standard è la nascita di strumenti web per la navigazione, consultazione e gestione dei dati. Strumenti di questo tipo non sono più legati ad un particolare software, ma consentono invece all'utente di accedere contemporaneamente a dati forniti da più servizi tra loro completamente indipendenti, eventualmente implementati con software e su piattaforme differenti. L’interoperabilità è garantita dal fatto che client e server comunicano utilizzando il medesimo standard.
Per completare lo scenario descritto in precedenza, aggiungiamo l’eventualità che i diversi server da cui il WebGIS attinge i dati contengano informazioni sensibili; il loro accesso dovrà perciò essere regolato e differenziato in maniera precisa relativamente alle credenziali ed ai privilegi di ciascun utente. Nasce perciò l’esigenza di dotarsi di una infrastruttura che permetta, attraverso un’unica interfaccia, l’autenticazione distribuita su ciascuno dei servizi geografici; è infatti impensabile che l’utente, per poter accedere alle informazioni presenti nei diversi server, si autentichi singolarmente con ciascuno di essi.
Il presente documento vuole proporre una soluzione generale al problema dell'autenticazione distribuita nei WebGIS di ultima generazione, che sia sufficientemente modulare da garantirne la facile integrazione nei sistemi già esistenti e contemporaneamente tanto robusta da soddisfare i requisiti di sicurezza connessi alla protezione e distribuzione dei dati in Internet. Verrà dunque descritta in dettaglio la nostra soluzione, evidenziando le problematiche connesse alla sua implementazione in un case study reale.
1.2 Un esempio di WebGIS: SIM­PAT MITRIS
Il sistema SIM­PAT (Sistema Integrato di Monitoraggio degli incidenti stradali della Provincia Autonoma di Trento) è un servizio completo per il controllo del rischio da incidenti stradali, in grado di segnalare le situazioni critiche sul reticolo viario e di valutare i costi associati. Il principale strumento realizzato è un'infrastruttura informatica per raccogliere in modo accurato, tempestivo e completo i dati dei rilievi provenienti dalle diverse forze dell'ordine (Carabinieri, Polizie) e collegarli al Sistema Informativo Sanitario. Il progetto fa parte del Centro Integrato di Monitoraggio del traffico della PAT e il suo sviluppo è coordinato da ITC­irst.
Il client WebGIS del progetto SIM­PAT permettere di accedere in modo trasparente ad informazioni geografiche pubblicate da numerosi server WMS / WFS (sviluppati con MapServer e PHP/MapScript) tra loro indipendenti. I principali dati disponibili sono:
– Trentino Base: tematismi del SIAT della Provincia di Trento (ad esempio DEM, OFDC, CTP, idrografia);
– SIM­PAT: dati puntuali degli incidenti stradali in provincia di Trento, con le relative informazioni rilevate dalle forze dell’ordine nel luogo dell’incidente e i dati sanitari associati ai feriti;
– FaunaTN: dati puntuali degli incidenti stradali che hanno coinvolto fauna selvatica in provincia di Trento, con associate le informazioni dei rilievi della Polizia Forestale.
Il client WebGIS sviluppato da MPA Solutions, è basato sul software OpenSource MapBuilder. Una delle motivazioni all’utilizzo di questo strumento risiede nella sua solida implementazione di numerosi standard dell’OGC: infatti, MapBuilder è stato originariamente concepito per essere un client WMC (Web Map Context), come specificato dall’Open GIS Consortium (OGC). Successivamente le sue funzionalità sono state estese introducendo ­per esempio­ il supporto per il WFS­T (transactional Web Feature Services), la visualizzazione di documenti GML.
In questo sistema è necessario consentire l'accesso esclusivamente ad utenti identificati ed autorizzati: infatti i dati relativi a rilievi su incidenti stradali (sia SIM­PAT che FaunaTN) e alcuni dati di base in SIAT Trentino (come le Ortofoto Digitali) sono strettamente riservati e l'accesso a queste informazioni deve essere rigidamente controllato. Ci si deve assicurare, inoltre, che il livello di dettaglio informativo visibile ad ogni utente sia correlato alle sue credenziali personali.
Data la peculiare natura delle informazioni che raccoglie, il nuovo di sorveglianza per incidenti stradali SIM­PAT MITRIS è stato il banco di prova ideale per sperimentare la fattibilità del nostro sistema di autenticazione distribuita.
ARCHITETTURA ATTUALE
1.3 Il flusso attuale delle informazioni
In un sistema distribuito, l'utente si collega ad un server WebGIS primario, da cui riceve un elenco dei dati disponibili; tale server gli fornisce un'interfaccia di lavoro (un front­end web) ed un elenco dei dati disponibili (ad esempio, una lista di layer). Il front­end, che viene eseguito nel browser dell'utente, è responsabile di recuperare ed aggregare i dati veri e propri, prelevandoli dai server che compongono l'applicazione.
Figura 1: diagramma di flusso di un sistema standard
Nell'architettura appena descritta si nota come i diversi server non effettuino comunicazioni dirette con il WebGIS: il flusso delle informazioni è conseguenza delle richieste dell'utente.
1.4 Analisi e mitigazione dei rischi principali
Anche senza effettuare una completa analisi di rischio, il precedente diagramma mette in luce la difficoltà di gestire in modo sicuro un'applicazione che faccia uso di dati sensibili con un'architettura di sistema come quella appena descritta. Nel diagramma riportato, infatti, il server WebGIS è l'unico componente ad essersi accertato dell'identità dell'utente, e sono dunque possibili accessi diretti ai server secondari: è sufficiente conoscere il loro indirizzo e la modalità di interrogazione per accedere ai dati sensibili, a meno che questi non risiedano interamente sul server principale.
Dato che mantenere uno stretto controllo sugli accessi ai dati è un requisito imprescindibile per molte applicazioni GIS, occorre implementare un meccanismo che consenta ad i server secondari di riconoscere un utente valido: a questo scopo, molte applicazioni web distribuite utilizzano un sistema noto come single­sign­on (in breve SSO). A grandi linee, tale sistema consiste in un database di utenti centralizzato ed accessibile a tutti i server coinvolti, ed un meccanismo automatico di trasporto delle credenziali da un server all'altro. Purtroppo, non esiste un'architettura standard di SSO da usare come riferimento, e anche le metodologie utilizzate per applicare architetture SSO a sistemi esistenti vengono selezionate caso per caso: tra le soluzione note, non ne abbiamo trovata alcuna che a nostro parere si prestasse in modo semplice a risolvere il problema. PROPOSTA DI UN SISTEMA DI PROTEZIONE
1.5 Un'architettura con controllo di accesso
Per migliorare la sicurezza del sistema MITRIS abbiamo optato per la realizzazione di una soluzione ad hoc: ci siamo posti il preciso scopo di eliminare la possibilità di transazioni non autorizzate ai componenti di un sistema web­based distribuito (di cui i WebGIS sono un caso particolare). Inoltre, è stato fatto uno sforzo per progettare un middleware che avesse il minor impatto possibile sulle componenti già esistenti – sia in termini di modifiche al codice attuale, che in termini di efficienza prestazionale.
L'intero sistema di scambio informazioni tra il server di autenticazione ed i server secondari si basa su due componenti. Il primo è realizzato con una libreria che tiene traccia dell'identità e dei privilegi di accesso dell'utene, libreria che occorre integrare con il sistema di autenticazione del server primario. Il secondo componente è invece un particolare proxy HTTP, che viene interposto tra l'utente ed i server secondari per proteggerli dagli accessi non autorizzati. Queste due componenti dialogano tra loro usando semplici richieste HTTP.
Il codice da noi sviluppato per i due componenti è stato realizzato in PHP per il web server Apache; l'implementazione peraltro è facilmente portabile ad altri linguaggi ed ambienti, e la validità dell'approccio proposto non è certamente limitata al solo scenario di utilizzo a cui noi siamo interessati.
La principale novità del nostro approccio è dovuta alla relativa indipendenza dei componenti: nella nostra architettura è possibile utilizzare un proxy per ogni server contenente dati sensibili, oppure un proxy per più servers; inoltre i proxy non contengono informazioni sui server che li dovranno contattare, e quindi più server WebGIS possono interfacciarsi in modo trasparente con gli stessi proxy. Infine, il proxy è indipendente dall'effettivo protocollo di comunicazione usato nelle richieste, e richiede solo che queste utilizzino HTTP o HTTPS come meccanismo base di trasporto.
1.6 Diagramma aggiornato del flusso delle informazioni
Il seguente diagramma fornisce una visione sintetica di come la nostra soluzione incide sul flusso delle comunicazioni tra i vari componenti del servizio distribuito; per semplicità, nel grafico è mostrato un solo server secondario, protetto dal relativo proxy.
Figura 2: diagramma aggiornato del flusso delle informazioni
Come si nota, le richieste dati non vanno più direttamente ai server secondari, ma vengono intercettate dal componente proxy. Questo si incarica di recuperare i diritti di accesso dell'utente (ACL è l'acronimo di access control list), che vengono forniti dal server principale (grazie alla nostra libreria) sotto forma di una coppia di filtri IN/OUT. Se l'ACL nega l'accesso, l'utente viene rediretto ad una pagina di errore; in caso contrario, il proxy applica il filtro IN alla richiesta dell'utente, recupera dal server secondario i dati, applica quindi il filtro OUT e rispedisce all'utente il risultato.
1.7 Mutua autenticazione dei componenti
Lo schema appena descritto, pur molto flessibile e apparentemente sicuro, soffre a sua volta di un grave problema: l'autenticazione mutua dei componenti del sistema. Infatti, se le comunicazioni tra il server principale ed i proxy non vengono adeguatamente protette, rimane comunque possibile per un malintenzionato sufficientemente abile utilizzarle a suo vantaggio.
Senza modificare in nulla i due componenti realizzati, ci siamo avvalsi delle possibilità offerte dal web server Apache per la gestione delle richieste in modalità criptata: dato che la comunicazione tra i componenti è di natura HTTP, può essere posta sul protocollo sicuro HTTPS (in modo da non essere intercettabile da malintenzionati). Gli indirizzi URL posti sotto HTTPS forniscono un certificato X509 che garantisce il richiedente dell'identità del server da cui provengono; inoltre, con Apache è possibile ottenere l'autenticazione mediante certificato X509 anche del richiedente. In questo modo, i due componenti sono mutuamente autenticati, ed è impossibile per un terzo introdursi nella comunicazione.
1.8 Migliorare le prestazioni
I componenti aggiuntivi che controllano gli accessi introducono un ritardo nelle comunicazioni degli utenti, poiché necessitano di un continuo scambio di dati per confermare la validità delle richieste degli utenti. Per evitare il degrado prestazionale derivante dal traffico di richieste molto più elevato sul server principale, abbiamo introdotto nella nostra architettura un sistema di caching locale delle credenziali utente. Ogni proxy mantiene l'elenco delle ACL già richieste al server principale; in questo modo è in grado di evitare il continuo scambio di dati per una stessa sessione utente. Se sulla sessione non è stato rilevato traffico per un intervallo di tempo configurabile, l'ACL relativa viene eliminata dalla cache. La cache è implementata grazie ad uno storage locale basato sul database opensource SQLite.
Per evitare la finestra di vulnerabilità di una sessione nel tempo intercorrente tra il logout dell'utente dal server principale e lo scadere della sua cache sui proxy, abbiamo deciso di implementare anche un meccanismo, invocato dal server primario, per invalidare la cache di un utente su ogni proxy all'atto della sua disconnessione. Questo sistema, che utilizza il design pattern noto come Publisher/Subscriber per tenere traccia delle relazioni tra il server principale ed i proxy, si avvale anch'esso di uno storage locale basato su SQLite.
1.9 Implementazione dei filtri
Per completare la descrizione del nostro sistema, rimane ancora da mostrare come sia effettuato il vero e proprio controllo di accesso da parte del componente proxy.
Dato che le richieste utente si possono facilmente riscrivere come XML (peraltro, spesso già sono in questo formato), abbiamo deciso di utilizzare dei fogli di stile: le ACL fornite dal server primario sono dei file XSLT. Il proxy si limita ad applicare ad ogni richiesta dell'utente le trasformazioni contenute nella parte di filtro in ingresso, ottenendo così una nuova richiesta da girare ad un server secondario, oppure un errore di accesso da riportare all'utente. La risposta del server viene a sua volta trasformata con lo stile contenuto nel filtro di uscita delle ACL, ed il risultato è finalmente mandato all'utente.
In questo modo, la comprensione del formato delle richieste dell'utente può essere mantenuta esternamente al proxy, che può dunque venire riutilizzato per proteggere molteplici protocolli di scambio senza bisogno di modifiche.
SVILUPPI FUTURI
1.10 Regole per il controllo di accesso
Le ACL implementate nel nostro prototipo offrono al momento solo un controllo di validità delle credenziali dell'utente, ma il sistema che abbiamo ideato si presta a controlli molto più fini. Ad esempio, potrebbe essere costruito facilmente un filtro in ingresso che consente ad un utente ospite di richiedere solo alcuni layers, oppure solo alcune zone geografiche. Il filtro in uscita consente di effettuare operazioni altrimenti complesse, come ad esempio anonimizzare i dati di una tabella contenente dettagli sensibili, prima di fornirla ad utenti che non abbiano sufficienti privilegi.
Prevediamo la creazione di una famiglia di filtri prefabbricati, ciascuno dotato di opportuni parametri di configurazione, che si possano usare come blocchi di costruzione per impostare le effettive ACL da associare ad utenti o gruppi di utenti.
Un esempio potrebbe essere un blocco che consenta l'accesso ad i dati di un singolo comune; l'identificativo del comune sarà usato come parametro. Questo blocco, dopo aver specificato “Trento” come parametro di configurazione, potrebbe essere incluso all'interno della lista di controlli di accesso per i dipendenti del comune di Trento ai quali supponiamo di voler limitare le query geografiche.
1.11 Interfaccia di creazione e gestione integrata nel WebGIS
Una volta pronti i blocchi di controllo parametrizzati descritti nel precedente paragrafo, vorremmo integrare nel nostro sistema MITRIS anche un'interfaccia amministrativa che consenta di definire le ACL complete e di associarle a gruppi o ad utenti singoli.
In questo modo avremo una gestione più agevole delle regole di controllo da parte degli amministratori del sistema, che saranno in grado di impostare privilegi di accesso molto raffinati in base alle tipologie dell'utente, senza però la complicazione di conoscere intimamente le regole XSLT sottostanti.
CONCLUSIONI
La necessità di un sistema di controllo di accesso fine per applicazioni distribuite ci ha portato allo studio e ad una prima implementazione di architettura, in cui l'enforcement delle ACL è ottenuto dalla cooperazione di un middleware di autenticazione e autorizzazione integrato con il server principale e di più proxy utilizzati come wrapper per i web services secondari.
L'architettura da noi immaginata ha il pregio di un elevato livello di flessibilità e di un bassissimo costo di integrazione con progetti esistenti. L'impatto sulle prestazioni, almeno per applicazioni data­intensive come i sistemi WebGIS, risulta decisamente trascurabile rispetto ai benefici; inoltre, l'indipendenza del componente proxy dallo specifico protocollo di comunicazione usato lo rende facilmente riutilizzabile in più contesti.
La soluzione proposta è stata sviluppata basandosi interamente su software libero (Apache, PHP, SQLite), così da perseguire quello spirito di sviluppo aperto a tutti i contributi che secondo noi dovrebbe muovere la realizzazione di ogni software di pubblico interesse, anche –o forse soprattutto­ quando è dedicato alla sicurezza. Lo scopo motivante di questa presentazione è quello di rendere disponibili alla comunità GFOSS i risultati ottenuti sinora, con la speranza di ottenere del feedback che porti ad un miglioramento ulteriore di una soluzione che auspichiamo possa diffondersi ed essere utilizzata negli scenari più disparati.
L'implementazione della soluzione descritta nel presente articolo rappresenta per noi solo il primo passo di uno sforzo volto a migliorare la sicurezza complessiva dell'architettura del sistema SIM­PAT MITRIS. Produrre un rapporto approfondito di threat analisys, che metta in luce le debolezze esistenti e consenta di prioritizzare gli interventi di mitigazione dei rischi, sarà il prossimo passo verso una gestione più sicura dei dati sensibili presenti in MITRIS.
BIBLIOGRAFIA
European Union, ­ “Directive of the European Parliament and of the Council establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)”, 17 January 2007, Brussels.
http://www.europarl.europa.eu/sides/getDoc.do?pubRef=­//EP//NONSGML+JOINT­TEXT+C6­2006­
0445+0+DOC+PDF+V0//EN&language=EN (accesso del 30 gennaio 2007)
Open Geospatial Consortium ­ “Web Map Context Documents”, 2005
http://www.opengeospatial.org/standards/wmc#overview (accesso del 30 gennaio 2007)
OASIS Standard ­ “eXtensible Access Control Markup Language (XACML) Version 2.0”, 2005
http://docs.oasis­open.org/xacml/2.0/access_control­xacml­2.0­core­spec­os.pdf (accesso del 30 gennaio 2007)
Fateh­Moghadam, P., Dallago, G., Piffer, S., Zanon, G., Menegon, S., Fontanari, S., Furlanello, C. ­ “Epidemiology of Road Traffic Accidents in the province of Trento: first results of an integrated surveillance system (MITRIS)”, Epidemiol Prev., 2005.
Fateh­Moghadam, P, Dallago, G., et all. “Un sistema di sorveglianza integrato degli incidenti stradali in provincia di Trento”, Rapporto Osservasalute, 2005. P. Eugster, P. Felber, R. Guerraoui, and A.­M. Kermarrec ­ “The many faces of publish/subscribe”, Technical Report DSC ID, 2003
http://citeseer.ist.psu.edu/article/eugster03many.html (accesso del 30 gennaio 2007)
Open Geospatial Consortium ­ "Geography Markup Language (GML) Implementation Specification", 2003
http://www.opengeospatial.org/standards/gml (accesso del 30 gennaio 2007)
Architecture And Standards Working Group, ­ “INSPIRE AST Position Paper”, 2002, Brussels. http://www.ec­gis.org/inspire/reports/position_papers/inspire_ast_pp_v4_3_en.pdf (accesso del 30 gennaio 2007)
Open Geospatial Consortium ­ “Web Feature Service Implementation Specification”, 2002.
http://www.opengeospatial.org/standards/wfs (accesso del 30 gennaio 2007) Open Geospatial Consortium ­ “Web Map Service Implementation Specification”, 2001
http://www.opengeospatial.org/standards/wms (accesso del 30 gennaio 2007)
W3C ­ “XSL Transformations (XSLT)”, 1999
http://www.w3.org/TR/xslt (accesso del 30 gennaio 2007)
Neuman, B. C. ­ “Proxy­based authorization and accounting for distributed systems”, In Proceedings of the 13th International Conference on Distributed Computing Systems, 1993 , pages 283­291. http://clifford.neuman.name/papers/pdf/9305_proxy­pbaa­neuman­icdcs93.pdf (accesso del 30 gennaio 2007)