ICAR
Skip Navigation LinksHOME PAGE » ICAR PLUS » RAPPORTO ICARPLUS » Il framework SPCoop
CISIS

Il Framework SPCoop

Nel corso di questi ultimi anni la definizione di architetture e standard aperti atte a favorire e supportare l’interoperabilità applicativa fra i sistemi informativi è stato un elemento essenziale ai fini dello sviluppo di applicazioni e servizi delle Pubbliche amministrazioni centrali e locali.
Negli anni ’80 la tendenza in tutta Europa è stata quella di dotare le pubbliche amministrazioni di sistemi informativi flessibili e robusti con l’obiettivo di supportare i processi burocratici ad essi collegati.  Negli anni ‘90 e fino agli inizi del decennio attuale l’interesse si è spostato verso l’apertura di tali sistemi al mondo internet, principalmente ai fini della realizzazione di iniziative di e-Government, e la definizione di un primo livello di interconnettività condiviso fra le amministrazioni.
Agli inizi dell’anno 2000 in Italia, il CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione), attraverso il progetto SPC (Sistema Pubblico di connettività) ha definito l’ infrastruttura tecnologica, le strutture organizzative e le regole tecniche per la fornitura di servizi di connettività alle pubbliche amministrazioni, e sta ora procedendo al pieno dispiegamento di un framework tecnologico, denominato Sistema Pubblico di Cooperazione (SPCoop),al fine di supportare  i servizi di interoperabilità e cooperazione applicativa.

Il SPCoop  è un insieme di standard tecnologici e di servizi infrastrutturali il cui obiettivo è di permettere l’interoperabilità applicativa tra i sistemi informativi delle Pubbliche Amministrazioni al fine di garantirne la piena integrazione dei dati, delle informazioni e dei procedimenti amministrativi.
Il modello architetturale di riferimento dell’SPCoop è basato su architettura SOA (Service-Oriented Architecture) e si appoggia sui servizi offerti dallo strato di connettività denominato Sistema Pubblico di Connettività (SPC), l’infrastruttura di rete ad uso esclusivo delle Pubbliche amministrazioni.

Con il completamento del dispiegamento del framework SPCoop si raggiungerà, finalmente, l’obiettivo di avere una infrastruttura unica, basata su standard condivisi e che consentirà agli utenti di avere una visione integrata di tutti i servizi delle pubbliche amministrazioni  centrali e locali, indipendentemente dal canale di erogazione permettendo quindi l’integrazione del patrimonio informativo della pubblica amministrazione in un ottica di graduale e sostenibile evoluzione tecnologica ed organizzativa.

SPC2.jpg

 Fig. Modello architetturale Spcoop

Nel modello SPCoop la cooperazione applicativa si basa sulla possibilità da parte degli enti interessati (Amministrazioni Centrali, Regionali ed Enti locali), di poter erogare e fruire di servizi applicativi, in particolare la cooperazione si traduce in un accordo tra le parti che trova la sua formalizzazione nell’Accordo di Servizio.
L’Accordo di servizio è la descrizione formale dei servizi applicativi e definisce le prestazioni del servizio e le modalità di erogazione/fruizione in termini di:

  • interfaccia del servizio, intesa come insieme di operazioni offerte dal servizio
  • punti d’accesso (endpoint) presso cui effettivamente il servizio è dispiegato,
  • protocollo conversazionale
  • livelli di qualità del servizio garantiti (SLA)
  • requisiti e caratteristiche di sicurezza del servizio
  • descrizione della semantica del servizio e della semantica dell‘informazione veicolata dal servizio

In particolare un Accordo di servizio si compone di due parti, quella comune e quella specifica:

  • la prima può contenere oltre alle specifiche di interfaccia (WSDL) e di conversazione (WSBL) anche altri documenti come allegati (documenti non formali di interesse per l'Accordo di Servizio in un qualsiasi formato) e specifice semiformali (XML, UML, HTML o anche in linguaggio naturale).
  • la seconda invece può contenere oltre alle specifiche dei porti di accesso (WSDL) anche altri documenti come allegati(documenti non formali di interesse per l'Accordo di Servizio in un qualsiasi formato), specifice semiformali (XML, UML, HTML o anche in linguaggio naturale), specifiche dei  livelli di qualità del servizio SLA (WS-Agreement e WSLA), e specifiche di sicurezza associata al servizio e redatte mediante WS-Policy o in linguaggio naturale.

Una volta formalizzati gli Accordi di Servizio e sviluppate le applicazioni interessate da tali accordi, la cooperazione in termini di erogazione e fruizione di servizi applicativi può avvenire solo utilizzando una componente infrastrutturale fondamentale nel disegno Spcoop, ovvero la Porta di Dominio.

La Porta di Dominio è la componente infrastrutturale che funge da “porta di ingresso” verso il dominio per quegli Enti che vogliono fruire dei servizi erogati, e da “porta di uscita” dal dominio per quegli Enti interni al dominio che vogliono fruire di servizi erogati esternamente. Essa rappresenta di fatto la piattaforma sulla quale vengono pubblicate le interfacce applicative dei servizi, questo logicamente non implica che i componenti software che erogano tali servizi devono risiedere sulla stessa piattaforma, in questo caso la PDD svolge semplicemente la funzione di proxy/dispatcher verso  altre piattaforme di back end che ospitano le realizzazioni dei servizi offerti.

Per consentire lo scambio di messaggi tra i servizi esposti dalle Porte di dominio delle diverse amministrazioni viene utilizzato un protocollo, comunemente detto “Busta di e-gov”, che  di fatto è una estensione della versione 1.1 del protocollo standard SOAP (Simple object acces protocol). La particolare necessità di estendere le caratteristiche del protocollo SOAP discende dai particolari obiettivi fissati dal piano d'azione di eGovernment in Italia, il quale prevede che le informazioni necessarie alla gestione del servizio siano uniformate per rispondere ai requisiti di SPCoop in materia di sicurezza ed affidabilità, preservando nel contempo l'autonomia di ciascuna amministrazione nella definizione del proprio contenuto applicativo. Prevede l’utilizzo di un header predisposto appositamente, che elaborato dalle porte di dominio, è in grado di veicolare tutte le informazioni necessarie al fine di supportare la sicurezza point-to-point, l’affidabilità della trasmissione e la tracciatura di tutte le comunicazioni; tutto questo in maniera trasparente alle applicazioni che fanno uso delle Porte. La busta di e-gov risulta logicamente suddivisa in due parti: una che contiene le informazioni infrastrutturali e l’altra che veicola il contenuto applicativo del servizio oggetto dell’interazione, questo sia per mantenere totalmente autonome le Amministrazioni nella definizione del contenuto applicativo sia per uniformare le informazioni necessarie alla gestione dello scambio in modalità sicura e affidabile.

 

SPC1.jpg

Fig. Comunicazione tra porte di dominio

 

 Nella figura sono mostrate due differenti amministrazioni che per tramite delle Porte di Dominio si scambiano messaggi contenenti dati ed informazioni, in particolare, ciascuna porta può svolgere il ruolo di erogatore e fruitore in base alle specifiche esigenze di cooperazione. In particolare l'Ente erogatore, tramite la sua porta di dominio, offre i suoi servizi applicativi; l’ente fruitore sempre tramite la sua porta di dominio, utilizza quei servizi applicativi e la comunicazione in termini di erogazione/fruizione avviene tramite scambio di messaggi opportunamente codificati.

A questo punto per un utente di una pubblica amministrazione che intende accedere al Sistema Pubblico di Cooperazione, in particolare per fruire dei servizi offerti dal Registro Sica di seguito illustrati, è necessario munirsi di credenziali che rientrano nel concetto di identità digitale.

L'identità in senso digitale consiste di dati digitali che descrivono univocamente una persona o una cosa (genericamente, un'entità) e di informazioni circa la relazione del soggetto con altre entità. La tipologia delle transazioni nelle quali un'identità viene coinvolta influenza la complessità della sua rappresentazione.
Tali credenziali possono essere rilasciate da apposite componenti infrastrutturali di SPCoop oppure provenire da sistemi di autenticazione già in uso localmente nelle amministrazioni; in quest'ultimo caso l'infrastruttura dovrà ritenere valide tali credenziali. Si viene così a parlare di identità "federate" e di federazioni tra Amministrazioni.
La gestione federata di Identità digitali prevede la creazione di relazioni di fiducia tra realtà diverse per l'identificazione e l'autorizzazione degli utenti di una di esse ad accedere alle risorse governate da un'altra.
La gestione Federata di identità digitale converge verso lo standard SAML v2.0 (Security Assertion Markup Language), favorendo l'interoperabilità e l'applicazione del modello verso domini di SAML. Infatti tale architettura, prevede le funzioni di Identity Provider, Attribute Authority, Profile Authority e Service Provider. Inoltre lo standard SAML v 2.0 introduce dei profili e use case di utilizzo, con l'obiettivo di specializzare e migliorare l'interazione tra i servizi, molti dei quali sono una derivazione delle specifiche Liberty Alliance e Shibboleth. Infine per favorire il processo di federazione e di interoperabilità, ogni dominio di cooperazione della pubblica amministrazione (centrale e locale) dovrà dotarsi di un'architettura di Federated Access Management, per poter svolge le funzioni di garante delle credenziali (Identity Provider) e degli attributi di ruolo (Attribute Authority) per i soggetti.

Per consentire la corretta identificazione e gestione dei servizi, dei soggetti coinvolti e delle relative porte di dominio, l'architettura Spcoop ha reso disponibili opportuni Servizi infrastrutturali per la cooperazione applicativa brevemente detti SICA.

Le regole tecniche definiscono i SICA come “l'insieme delle regole, dei servizi e delle infrastrutture condivise che abilitano l'interoperabilità e la cooperazione applicativa fra le Amministrazioni e l'accesso ai servizi applicativi da queste sviluppati e resi disponibili sul SPC”[DPCM_08]. Il compito dei SICA, che sono centralizzati e indipendenti dalle singole amministrazioni, è quello di mantenere una serie di registri che vengono interrogati dalle porte di dominio per l’elaborazione dei messaggi applicativi.
Dal punto di vista funzionale, i servizi SICA offrono i seguenti servizi:

  • Servizi di registro SICA: che offrono le funzionalità a supporto della gestione completa del ciclo di vita degli Accordi di Servizio e degli Accordi di Cooperazione.
  • Servizio di catalogo schemi e Ontologie: si tratta di un repository che raccoglie i modelli concettuali (ontologie) e gli schemi dati (XML schema) con i quali è possibile descrivere i servizi applicativi. Inoltre la formalizzazione del significato dei servizi e degli schemi consentiranno di effettuare ricerche non più attraverso semplici parole chiave bensì basate sui concetti.
  • Servizio Indice dei soggetti: mette a disposizione una serie di funzionalità atte a gestire la rubrica degli utenti e operatori della PA
  • Servizi a supporto del processo di qualificazione delle Porte di Dominio e del Registro Secondario: mettono a disposizione specifiche funzionalità a supporto delle Amministrazioni che intendono procedere alla qualificazione della Porta di dominio per erogare/fruire di servizi in ambito Spcoop e del Registro Sica secondario al fine di testarne la sincronizzazione con il registro SICA Generale.
  • Servizio di certificazione e di Gestione Federata delle Identità Digitali: mettono a disposizione specifiche funzionalità di identity ed access management previste dal Sistema.

SPC3.jpg

Fig.Servizi infrastrutturali di Cooperazione applicativa

L’esercizio di questi servizi sono supportati dal Centro Gestione dei servizi infrastrutturali di  interoperabilità, cooperazione ed accesso (CG-SICA), che dalla fine del 2008 li rende disponibili a tutti gli utenti delle Amministrazioni Pubbliche.

Per una più esaustiva trattazione degli argomenti inerenti il modello SPCoop tenuti si rimanda al seguente link.