Visione Generale. Versione 1.0 del 25/08/2009

Transcript

1 Visione Generale Versione 1.0 del 25/08/2009

2 Sommario 1 Premessa Le componenti applicative Porta di dominio Infrastrutture per la cooperazione Registro degli Accordi di Servizio e Ontologie/Schemi concettuali Sistema di Sicurezza e Identità Federata Sistema di Monitoraggio SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 2

3 IL CONTENUTO DEL PRESENTE DOCUMENTO PUÒ ESSERE RIPRODOTTO, IN TOTO O IN PARTE, PER TUTTI GLI SCOPI FUNZIONALI ALL ADESIONE AL SISTEMA SPICCA DI REGIONE CAMPANIA ED È ESCLUSO L UTILIZZO A FINI DI LUCRO. PER L UTILIZZO DI QUANTO DI SEGUITO RIPORTATO SI DOVRÀ, IN TUTTI I CASI, CITARE COME FONTE IL PRESENTE DOCUMENTO. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 3

4 1 Premessa Il processo di digitalizzazione delle Amministrazione Pubbliche (in breve AA.PP.), denominato e government o e gov, ha interessato ed interessa, a vario titolo, tutte la pubblica amministrazione nell interesse comune del miglioramento dell efficienza, economicità, e incremento dell accessibilità ai servizi pubblici a tutti i cittadini e imprese, intesi quali naturali stakeholder. L esperienza maturata negli anni ha evidenziato che la possibilità da parte di una AA.PP. di offrire un servizio ai cittadini e alle imprese, ma più in generale per garantire alle strutture delle AA.PP. di dar seguito alle proprie funzioni, spesso necessita di una stretta interazione tra esse. In pratica risulta indispensabile conquistare una visione di rete delle AA.PP. favorendo lo scambio e la comunicazione tra tutti i nodi della stessa. Tale consapevolezza, nell ambito del processo di e gov in atto, si traduce: nell esigenza di coordinamento di processi realizzati con il concorso di trattamenti distribuiti tra sistemi informatici di cui sono responsabili soggetti pubblici e privati, al fine di assecondare l esecuzione di procedimenti amministrativi e la produzione di atti e provvedimenti amministrativi nel rispetto delle norme sulla confidenzialità e riservatezza dei dati; nella necessità di garantire il coordinamento e la collaborazione dei trattamenti distribuiti tra più sistemi informatici appartenenti a più soggetti pubblici e privati, al fine di assicurare il funzionamento interno delle amministrazioni e di fornire servizi di utilità alle altre amministrazioni, ai cittadini, alle imprese e alle associazioni, in conformità con i compiti istituzionali delle diverse amministrazioni. Il Sistema Pubblico di Cooperazione (in breve SPCoop), il cui riconoscimento normativo in ultimo è avvenuto attraverso il Codice dell Amministrazione Digitale (Decreto legislativo 7 marzo 2005, n. 82 aggiornato dal D.Lgs. n. 159 del 4 aprile 2006), rappresenta la risposta alle necessità evidenziate. La Regione Campania, sensibile alle problematiche narrate, e nel pieno rispetto delle specifiche tecniche emanate a livello nazionale in materia (specifiche tecniche SPCoop predisposte dal CNIPA nel novembre 2005 e successive modificazioni 1 ), ha realizzato il Sistema di Interoperabilità e Cooperazione applicativa in Campania (di seguito SPICCA). SPICCA assicura alla Amministrazione Regionale le infrastrutture tecnologiche necessarie per: 1 Nello specifico si segnalano di documenti pubblica dal CNIPA: QUADRO TECNICO D INSIEME pubblicato V. 1.0 del 14/10/ 2005 TERMINI E DEFINIZIONI pubblicato V. 1.0 del 14/10/2005 ACCORDO DI SERVIZIO pubblicato V. 1.0 del 14/10/2005 PORTA DI DOMINIO pubblicato V. 1.0 del 14/10/2005 BUSTA DI E GOV pubblicato V. 1.1 del 14/10/2005 LINEE GUIDA ALL USO DELLA BUSTA E GOV pubblicato V. 1.1 del 21/04/2008 SERVIZI DI REGISTRO pubblicato V. 1.0 del 14/10/2005 SERVIZI DI SICUREZZA pubblicato V. 1.0 del 14/10/2005 CONVENZIONI DI NOMENCLATURA E SEMANTICA pubblicato V. 1.0 del 14/10/2005 ESERCIZIO E GESTIONE pubblicato V. 1.0 del 14/10/2005 SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 4

5 realizzare soluzioni informatiche che possano cooperare con gli altri attori istituzionali (altre Regioni, Ministeri, Province, Comuni, ecc ) al fine di incrementare la propria efficienza nel conseguimento degli obiettivi legati alle proprie funzioni; promuovere presso le AA.PP. del territorio di riferimento la implementazione di sistemi integrati che favoriscano la condivisione delle informazioni e il coordinamento delle attività di competenza attraverso la costituzione di una Comunity Network. Attraverso SPICCA si passa ad un modello più generale di interoperabilità che permette ad un qualsiasi servizio disponibile di essere fruibile da utenti e Enti, garantendo contemporaneamente la misurabilità della qualità globale del servizio. Infatti, i criteri identificati per la realizzazione di SPICCA sono elementi generali e funzionali, basati su standard aperti non proprietari, che garantiscono l'autonomia nella scelta delle tecnologie realizzative ed organizzative da parte dei diversi Enti che intendono erogare dei servizi. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 5

6 2 Le componenti applicative Il modello logico di riferimento di elaborazione distribuita SPICCA (nel seguito modello SPICCA), prevede che ogni singola infrastruttura informatica dei diversi Enti è vista come un dominio unitario vincolato a meccanismi standard di interfacciamento che sono resi accessibili da un unico punto di accesso ai sistemi. Lo scambio informativo tra i vari domini, che concretizza la interoperabilità e cooperazione applicativa dei sistemi appartenente alla federazione, avviene attraverso l esposizione di servizi offerti dai singoli domini (erogatore), che realizzano l accesso alle specifiche capacità elaborative di un dominio, e utilizzati per il soddisfacimento delle specifiche necessità da altri domini (fruitori). In questo scenario di offerta e domanda di servizi si evidenzia la necessità di elementi neutri, da una prospettiva elaborativa, che assicurano agli erogatori di manifestare la propria offerta di servizi e nel contempo ai fruitori di rintracciare i servizi a loro necessari. Quanto delineato permette, all interno del modello SPICCA, di individuare due nodi funzionali: NDOM nodo di dominio considerati quali elementi funzionali atomici, che: 1. nella veste di erogatore rappresentano i centri di 'business process' e quindi devono esporre i servizi applicativi opportunamente indicizzati indipendentemente dal modello cooperativo; 2. nella veste di fruitori, che intende utilizzare i servizi offerti da altri, presenta le necessità di localizzare il servizio migliore, in termini di efficienza o di costo, e usufruire di un ambiente sicuro. NAG nodo aggregatore che riveste un duplice ruolo funzionale, nello specifico deve: 1. aggregare servizi, ossia realizzare le componenti di intermediazione che hanno il compito fondamentale di costruire nuovi servizi aggregandone degli altri; 2. assicurare agli NDOM i meccanismi di base (registrazione e ricerca) che nel loro insieme garantiscono all intera federazione di dar luogo alla elaborazione distribuita. Tutto ciò si è concretizzato nell architettura di cui si evidenziano le seguenti componenti funzionali: 1. Porta di Dominio 2. Registro Accordi di Servizio e Ontologie/Schemi concettuali 3. Componenti per la sicurezza e identità federata 4. Componenti per il monitoraggio SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 6

7 I componenti per l integrazione e l interoperabilità (Porta di dominio e Registro Accordi di Servizio e Ontologie/Schemi concettuali) assicurano le seguenti funzionalità: la gestione della busta di e government la pubblicazione dei servizi la ricerca dei servizi la gestione della registrazione di nuovi servizi Le componenti della gestione della sicurezza e identità federata assicurano le seguenti funzionalità: l Autenticazione, l Autorizzazione ed il tracciamento degli accessi utente la federazione dei sistemi di identità e la gestione dei rapporti di trust tra gli Enti Infine, le componenti per il monitoraggio assicurano la raccolta centralizzata di tutti gli eventi (log) generati dai vari sistemi presenti. 2.1 Porta di dominio Dalle specifiche SPCoop, La Porta di dominio è l insieme dei componenti distribuiti che implementano le funzionalità infrastrutturali che permettono la messa in opera dello scambio di messaggi e dei requisiti di sicurezza e di qualità di servizio, a livello connessione e porta in modo indipendente dalla logica applicativa. Obiettivo della Porta di Dominio è consentire la comunicazione tra una PA che espone i propri servizi ed altre AAPP; la PDD è un componente che espone due interfacce: quella esterna deve aderire ad un set di standard per consentire l'interoperabilità con le PDD di altre PA; quella interna è dipendente dalle risorse tecnologiche interne del soggetto dell SPCoop. Dalla definizione appena data, si comprende come una Porta di Dominio a livello concettuale funga da Proxy per l'accesso alle risorse applicative tra diversi domini SPC. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 7

8 La specifica implementazione della PDD realizzata da Regione Campania, coerentemente lale specifiche tecniche impartite dal CNIPA in merito, prevede una suddivisione logicamente in una componente di Cooperazione ed una di Integrazione: la prima, rivolta verso l'esterno della PDD, è incaricata delle comunicazioni fra Porte di Dominio (busta e gov); la seconda interagisce con la logica e l'architettura dell'infrastruttura che deve servire (OpenPDD level 2 o E PROXY/I PROXY). Nello specifico delle caratteristiche della Porta di Dominio realizzata nell'ambito del Progetto SPICCA sono: Gestione completa Busta e Government con supporto dei profili: OneWay, Sincrono, Asincrono Asimmetrico e Asincrono Simmetrico Supporto completo ad OpenPDD L2:Porta Applicativa e Porta Delegata Gestione Sicurezza (WS Security): Token username/password, Token X.509 (firma elettronica) e Token SAML (di attributo e di autenticazione) Gestione Transazioni: Attive e Storico Gestione Diagnostici e Gov Gestione Attach: SOAP w/attachement WS I attach profile 1.x Gestione PKCS#7: Firma Allegati e Cirfratura Allegati Gestione trattamenti: Client Request, Client Response, Server Request e Server Response Gestione log centralizzata SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 8

9 Cooperazione via Publish&Subscribe: Interazione PUSH e Interazione PULL Notifica esito transazioni via Consolle web di configurazione e monitoraggio 2.2 Infrastrutture per la cooperazione In quanto segue si descrivono le infrastrutture di servizio implementate per assicurare l interoperabilità e cooperazione applicativa tra i sistemi informatici delle AA.PP. Campane e i principi di base per la concreta implementazione di nuovi servizi Registro degli Accordi di Servizio e Ontologie/Schemi concettuali Per istaurare una relazione di cooperazione tra sistemi è necessario definire un accordo esplicito sull'erogazione/fruizione delle prestazioni del servizio: l Accordo di Servizio (AS). Esso definisce le prestazioni offerte dal servizio e le modalità di erogazione/fruizione: le funzionalità del servizio, le interfacce di scambio dei messaggi tra erogatore e fruitore, i requisiti di qualità di servizio dell erogazione/fruizione ed i requisiti di sicurezza dell erogazione/fruizione. Inoltre, l'accordo di servizio mantiene un riferimento all ontologia/schema concettuale che definisce la semantica dell informazione veicolata dal servizio. Semplificando si può affermare la componente qui descritta consente la gestione, in tutti i suoi aspetti, dell Accordo di Servizio (e di Cooperazione), mettendo a disposizione tutte le necessarie funzioni a tale scopo. il registro SICA mette a disposizione un insieme di servizi infrastrutturali di registrazione e ricerca di informazioni. Nello specifico il REGISTRO DEGLI ACCORDI DI SERVIZIO E ONTOLOGIE/SCHEMI CONCETTUALI (in breve Registro SICA) consente la gestione degli stati, delle transizioni di stato e l accesso alle informazioni sullo stato delle seguenti risorse: SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 9

10 soggetti della comunità regionale; entità di cui tali soggetti sono responsabili; servizi presentati sulla comunità regionale di cui i soggetti sono titolari; accordi di servizio afferenti alla comunità regionale; punti di accesso dei servizi presentati nella comunità regionale. Soggetto Erogatore Erogatore e Fruitore Stipulano un Accordo di Servizio Soggetto Fruitore Il Soggetto Erogatore Inserisce l Accordo di Servizio nel Registro SICA Accordo di Servizio Amministratore RegistroSICA L amministratore del Registro SICA Valida e Pubblica l Accordo di Servizio Inserimento Accordo di Servizio Validazione e Pubblicazione Accordo di Servizio Di conseguenza il Registro SICA, come già accennato, consente: la gestione dei soggetti della comunità regionale; la registrazione di nuovi servizi; la pubblicazione e l amministrazione dei servizi; il monitoraggio dei livelli dei servizi; la sottoscrizione e notifica di eventi; la ricerca dei servizi; e non da meno, al fine di assicurare la piena integrazione della comunità regionale a tutto il mondo SPCoop, deve assicurare la sincronizzazione dei contenuti con il registro SICA generale implementato in ambito nazionale dal CNIPA. Il Registro SICA, secondo quanto indicato dalle specifiche CNIPA, nasce come estensione di un registro di servizi infrastrutturali di registrazione e ricerca di informazioni conforme allo standard UDDI (Universal Directory & Description Interface, il registro di servizi Web più usato e consolidato) aggiungendo a quest ultimo funzionalità di memorizzazione di documenti contenenti informazioni descritte in linguaggio XML. Nell'ambito di SPICCA è stato realizzato un Registro SICA, basato su architetture standard multipiattaforma, che prevede la suddivisione dell architettura dello stesso in due componenti fondamentali: componente di BackEnd e componente di FrontEnd. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 10

11 La seguente tabella sintetizza le interfacce offerta dall implementazione realizzata in Regione Campania. Funzionalità FrontEnd Funzionalità BackEnd Funzionalità CNIPA Ricerca Ricerca Servizio Ricerca Soggetto Ricerca Ontologia SicaInquiryOperations getdocument findservice findorganization findservicebyorganization finddistributedservice findmadeusedservice findas findontologia getdocumentontologia Funzionalità di Ricerca Pubblicazione Nuovo Servizio Nuovo Servizio da Ontologia Nuovo Servizio Figlio Lista Servizi Amministrazione Nuovo Soggetto Nuova Ontologia Lista Ontologie Servizi da Pubblicare Servizi Pubblicati Visualizzazione Stato Servizi Amministrazione Utenti Lista Utenti Registra Nuovo Utente SicaPublishOperations publishorganization publishservicewithontologia publishservice publishservicechild updatestateservice publishontologia Funzionalità di Registrazione Servizi Funzionalità di Registrazione Soggetti Funzionalità di Registrazione Ontologie Funzionalità di Gestione Funzionalità di Gestione Sistema di Sicurezza e Identità Federata La componente qui descritta rappresenta il modulo di SPICCA legato alla gestione degli accessi in sicurezza alle applicazioni software (web e document based). In particolare, si tratta di moduli software legati all Autenticazione, all Autorizzazione ed al tracciamento dell utilizzo delle risorse da parte degli SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 11

12 utenti. Al fine di assicurare il corretto utilizzo della componente sono definite le modalità (linee guida) secondo le quali i sistemi di gestione degli accessi dei diversi Enti devono interoperare, al fine di garantire l accesso federato ai servizi: la soluzione prevede la creazione di una "federazione" di Enti, in cui ciascun Ente eroga in sicurezza dei servizi verso la comunità regionale. È utile definire alcuni concetti: le entità che espongono i servizi applicativi in modo protetto vengono denominate Service Provider (SP). Il loro obiettivo è quello di controllare l accesso alle risorse esposte, in modo da garantirne l utilizzo solo da utenti autenticati/autorizzati le entità che espongono le funzionalità di autenticazione utente sono denominate Identity Provider (IdP). Il loro scopo è quello di fornire le necessarie informazioni di autenticazione ai SP, in modo da abilitare le richieste di servizio degli utenti. L Identità Federata si può quindi definire come l insieme di tecnologie, standards ed accordi che permettono ad un insieme di SP di accettare come validi gli identificatori utente gestiti da un altro insieme (non necessariamente distinto) di Identity Provider. Una tale comunità di providers (SP ed IdP) viene tipicamente denominata federazione (federation) o circle of trust. Un tale approccio implementa implicitamente il Single Sign On (SSO), ovvero la possibilità per un utente di autenticarsi presso il suo Identity Provider di riferimento e, successivamente, di accedere ai servizi esposti da tutti i Service Providers della Federazione. Questo approccio comporta però la presenza di accordi di trust tra providers e l adozione di uno standard comune per lo scambio delle credenziali o asserzioni. L Identità Federata può essere realizzata sia in ambienti web based che in ambienti basati su scambi di messaggi in formato XML e webservices (Document Based), o in ambienti dove sono previsti entrambi. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 12

13 Nel primo caso l utente accede, mediante browser, ad un sito web esposto da un partner, inserendo nell header della richiesta anche le informazioni di autenticazione / attributo (secondo il protocollo ed il formato concordato). Il sito web prevede un meccanismo di protezione che filtra le richieste ricevute e verifica l identità ed il livello di autorizzazione dell utente mediante i meccanismi specificati dallo standard adottato (SAML). In questo caso si parla di Web based Single Sign On (SSO), in particolare, di Federated SSO (F SSO). Nel secondo caso, i partner comunicano tra loro mediante documenti XML per richiedere ed esporre servizi (mediante webservices/busta e Gov). In questo caso l Identità Federata è realizzata inserendo degli opportuni Token di Sicurezza all interno dell Header dei messaggi SOAP (SAML, certificati X.509, Login/Password, ecc.) secondo quanto descritto dallo standard Web Services Security (WS Security). In questo caso si parla di Web Services Security Management Sistema di Monitoraggio Questa componente permette di tracciare e monitorare applicativi che si basano su Log4J, fornendo meccanismi di filtraggio, ricerca sui Log, generazione di report verticali e di analisi. Il sistema di tracciabilità può essere suddiviso in tre sottosistemi: Sensore Terminale Log Server WebApplication Administration Log Console SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 13

14 Il sottosistema del Sensore Terminale include i componenti che riguardano la parte client del sistema di tracciabilità, occupandosi dell invio garantito dei log al sottosistema Server. Il sottosistema del Log Server, include i componenti che si interessano del processing dei log giunti al server. La WebApplication Administration Log Console è un'applicazione web che fornisce funzionalità per l amministrazione del log server da remoto e di ricerca di log secondo parametri definiti. L architettura del sistema è stata pensata in maniera tale da garantire che il log inviati arrivino al server e vengano salvati sul database. Per l invio dei log al server viene utilizzata la tecnologia JMS (Java Message Service), che fornisce una piattaforma comune per lo scambio di messaggi. Il log dall applicazione avviene utilizzando il Framework log4j strumento tipico per rispondere alle tipiche esigenze di applicazioni Java. Attraverso la definizione di Appender è possibile inviare i log a destinazioni svariate. In questo caso il JMSAppender permetterà l invio di log, realizzati secondo opportune specifiche per tracciare eventi ed operazioni verificatesi, attraverso code JMS. Al fine di garantire il corretto invio dei log, nel caso in cui si verificano problemi durante l invio, il salvataggio del log avviene in locale. Nel Log Server è poi presente un provider JMS, basato su ActiveMQ. Il vantaggio della tecnologia JMS è quello di mantenere completamente separato il sistema di messagging utilizzato dall applicazione che lo utilizza. L applicazione viene scritta in maniera assolutamente standard utilizzando gli oggetti ed i metodi di SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 14

15 JMS lasciando assoluta libertà di scelta sul motore di messagging a patto che questi supporti l interfaccia JMS. ra le funzionalità supportate vi sono: consegna asincrona dei messaggi possibilità di selezionare i messaggi supporto per messaggi di tipo publish/subscribe Il componente che consuma i log giunti alla coda JMS è il LogConsumer, che esegue le opportune azioni di filtraggio per l elaborazione del log e registrazione su RDBMS, file, ecc. Tramite la log console sono gestiti i parametri di configurazione utilizzati dalle altre componenti del sottosistema di Log. Inoltre, la Log Console consente la ricerca e visualizzazione dei log con tecniche basate sull'analisi OLAP. SPICCA: Visione Generale v.1.0 del 25/08/2009 Pagina 15