Porta di dominio

La Porta Di Dominio (PDD) ha lo scopo di assicurare che lo scambio elettronico di informazioni tra le Pubbliche Amministrazioni abbia le stesse caratteristiche di quello tradizionale (carta, firma, protocollo, fax...)^[1]. Il concetto di PDD è stato deprecato^[2] dal Piano Triennale per l'Informatica nella Pubblica Amministrazione 2017-2019, approvato dal Presidente del Consiglio in data 31 maggio 2017, introduce un nuovo Modello di interoperabilità che supera il modello precedente (SPCoop).

Il concetto di Dominio

Si definisce il dominio come l'insieme delle risorse - tra cui procedure, dati e servizi - e delle politiche di una determinata organizzazione. Il dominio è anche il confine di responsabilità di un'organizzazione, in particolar modo per quanto riguarda le politiche relative al suo sistema informativo.

Scopo dell'architettura cooperativa è di abilitare l'integrazione degli oggetti informativi (procedure e dati) e delle politiche di diversi domini, favorendo la comunicazione tra entità omogenee garantendo autonomia alle singole amministrazioni e lasciando inalterato il loro patrimonio informativo.

La Porta di Dominio

L'interoperabilità fra amministrazioni deve svilupparsi attraverso le porte di dominio, sulla base di standard definiti a livello nazionale in modo tale che:

siano identificati i servizi ed i dati che ogni amministrazione decide di rendere disponibili sulla rete;
siano rispettate, per ogni servizio esposto, le politiche di sicurezza, di accesso e di controllo di qualità e correttezza dei servizi erogati, stabilite dall'amministrazione erogante.

L'amministrazione che invia le informazioni in modo elettronico ad un'altra, sarà garantita del fatto che la destinataria (e non altri) le abbia ricevute, così come la ricevente potrà trattare le informazioni elettroniche ricevute con pari dignità di quelle che oggi riceve con i metodi tradizionali, considerati fino ad ora gli unici probanti ai fini del procedimento amministrativo. Questo dovrà essere possibile indipendentemente da come viene realizzata la porta di dominio (fornitore, linguaggi, tecnologia…) in quanto la sua interfaccia è stata definita.

L'allegato n.2 (Rete Nazionale: caratteristiche e principi di cooperazione applicativa) emesso dal Dipartimento per l'Innovazione e le Tecnologie definisce le principali linee guida per le amministrazioni che vogliano realizzare servizi on-line interagendo con i sistemi informativi di altre amministrazioni. In tali indicazioni la porta di dominio costituisce l'elemento tecnologico che realizza la cooperazione. Ogni porta di dominio a livello concettuale funge da proxy per l'accesso alle risorse applicative che si trovano all'interno dello stesso dominio.

La porta di dominio fa parte del modello organizzativo del Sistema Pubblico di Connettività e Cooperazione (SPC) e come tale trova naturalmente posto nella progettazione concettuale piuttosto che in quella logica o fisica^[3]. In particolare, a livello concettuale esiste una sola porta per ogni dominio, che rappresenta la somma di tutti gli apparati preposti all'accesso delle risorse del dominio.

I sistemi informatici che, attraverso la porta di dominio, si affacciano al SPC possono appartenere a diverse categorie:

un sistema monolitico, o comunque operante su un singolo nodo presso un'amministrazione di piccole dimensioni;
un sistema distribuito su più nodi collegati in rete locale presso un'amministrazione di dimensioni maggiori;
una rete di area (per es. aggregazione di comuni, comunità montana, rete provinciale o regionale), alla quale sono collegati i sistemi informatici di amministrazioni anche diverse.

La Cooperazione Applicativa

La Porta di Dominio consente a ciascuna PA che espone i propri servizi ad altre PA di comunicare facilmente con loro condividendo e adottando gli stessi protocolli (dove "protocolli" è usato in senso lato). Ogni ente è in grado di fungere sia da fornitore sia da consumatore di un dato servizio. È quindi facile comprendere che la PDD è un componente a due facce: quella esterna deve aderire ad un set di standard per consentire l'interoperabilità con le PDD di altre PA, mentre quella interna è dipendente dalle risorse interne dell'ente. La "Cooperazione Applicativa" (la logica che abilita applicazioni e infrastrutture diverse ad interagire) prevede che ogni Porta di Dominio sia logicamente suddivisa in una componente di Cooperazione ed una di Integrazione: la prima, rivolta verso l'esterno della PDD, è incaricata delle comunicazioni fra Porte di Dominio, mentre la seconda interagisce con la logica e l'architettura dell'infrastruttura che deve servire. A seconda che una data PDD svolga il ruolo di fornitore o di consumatore è chiamata, rispettivamente Porta Applicativa o Porta Delegata. Le comunicazioni avvengono sempre fra Porte Delegate e Porte Applicative.

I paradigmi di comunicazione

I paradigmi di cooperazione applicativa che devono essere supportati dalle porte di dominio sono riconducibili a due tipologie principali: la richiesta di servizio e la comunicazione di evento.

La richiesta di servizio consiste nella richiesta da parte di un dominio di un servizio erogato da un dominio servente e si suddivide a sua volta in 'Interrogazione' (se la richiesta non comporta modifiche di alcun oggetto del dominio servente) e 'Transazione', nel caso in cui la richiesta produca una variazione permanente di qualche oggetto dell'applicativo del dominio servente.

Un Evento, invece è il cambiamento di valore di un oggetto applicativo in un dominio sorgente che ha significato anche per altri domini detti destinatari. La notifica dell'evento non prevede la risposta da parte dei destinatari.

In base al tipo di richiesta, si profilano i seguenti due scenari di cooperazione:

Cooperazione per richiesta di servizio

La richiesta di servizio consiste in un messaggio prodotto da una applicazione di un dominio cliente e diretto ad una applicazione di un dominio servente. Il messaggio determina l'esecuzione di una applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata all'applicazione cliente. La risposta è un'indicazione certa che l'applicazione servente ha attuato la richiesta e che abbia avuto esito positivo/negativo. Dal punto di vista dell'interazione amministrativa, la richiesta di servizio è sempre sincrona. La richiesta di servizio può essere di due tipi:

interrogazione: richiesta di servizio finalizzata all'acquisizione di un'informazione del dominio servente ma che non modifica alcun oggetto applicativo interno allo stesso dominio servente;
transazione: richiesta di servizio destinata a produrre una variazione permanente in un oggetto applicativo del dominio servente.

Ogni ente è in grado di fungere sia da "fornitore" che da "consumatore" di un dato servizio. La porta di dominio che invoca la richiesta di servizio deve dapprima contattare il Catalogo Servizi per ricavarne i dettagli tecnici e le interfacce necessarie alla comunicazione. Vediamo quindi una schematizzazione della sequenza degli scambi dal punto di vista di un'amministrazione che desideri utilizzare un certo servizio informativo esposto da un altro ente:

L'amministrazione A necessita di un servizio da parte dell'amministrazione B e ricerca nel Catalogo Servizi se B è in grado di fornirlo;
Il Catalogo Servizi fornisce un link contenente la descrizione della amministrazione B e l'indirizzo internet (una URL) cui è possibile inviare le richieste per usufruire del servizio cercato. L'amministrazione B aveva infatti in precedenza pubblicato le specifiche di utilizzo del proprio servizio nel Catalogo Servizi.
La porta di dominio di A esamina il formato richiesto da B per formulare la richiesta di servizio. Dalle informazioni inserite nella struttura di descrizione del servizio, A è in grado di comporre una richiesta di servizio e decifrare opportunamente la risposta fornita da B.

Cooperazione per Eventi

La comunicazione di un evento consiste nell'invio di un messaggio da parte di un'applicazione allo scopo di informare altre applicazioni di uno o più domini destinatari dell'avvenuto cambiamento delle informazioni relative ad un oggetto applicativo o della creazione di un nuovo oggetto applicativo. Il messaggio inviato contiene anche le informazioni, nuove o modificate, che descrivono l'evento stesso. L'interazione tra gli interlocutori avviene in modo indiretto, intermediata da una infrastruttura di servizio (detta di Publish and Subscribe) che fornisce servizi per la pubblicazione di un evento e di sottoscrizione agli eventi stessi. In questo scenario ad esempio un Comune, a fronte della richiesta di cambio residenza da parte di un cittadino, pubblica l'evento Cambio Residenza, insieme a tutti i dati ad esso relativi, sul sistema di Publish and Subscribe. Quest'ultimo si occupa di notificarlo poi, in modo opportuno, a tutte le amministrazioni che avevano preventivamente sottoscritto quell'evento specifico.

Profili di collaborazione

In termini generali, si assume che ciascuna collaborazione applicativa preveda lo scambio di una coppia di messaggi: una richiesta inviata da una porta di dominio a cui fa seguito una risposta da parte di un'altra porta di dominio. Si prevedono collaborazioni realizzate tramite lo scambio di messaggi in modalità sincrona e asincrona. Per convenzione, il sincronismo viene visto dal punto di vista della porta presso la quale ha inizio ogni episodio di collaborazione:

in uno scambio sincrono la porta del dominio cliente invia la propria richiesta applicativa ed attende la risposta della porta del dominio servente;
in uno scambio asincrono, la risposta della porta del dominio servente può essere inviata in un tempo successivo e la porta del dominio cliente non rimane quindi in attesa.

La scelta della modalità sincrona o asincrona può dipendere da aspetti legati alla latenza delle procedure amministrative (ad esempio la necessità di intervento umano per l'apposizione della firma digitale di un pubblico ufficiale). Tuttavia, in linea di principio, tale scelta può dipendere anche da scelte di carattere esclusivamente tecnologico.

La busta di eGovernment

Per scambiare messaggi applicativi fra porte di dominio viene utilizzata la busta di eGovernment (e-Gov)^[4] che è la definizione del formato di codifica e del contenuto dei messaggi SOAP, utilizzati per implementare, sotto forma di Web services, i servizi esposti dalle Porte Applicative delle amministrazioni. Il formato della busta di eGovernement è stata definita dal Centro Tecnico della Rete Unitaria della PA (attualmente DigitPA) nei documenti di linee guida a supporto dell'implementazione dei progetti di eGovernment. Ogni messaggio scambiato tra porte di dominio si compone di due parti principali:

una parte di busta, che contiene le indicazioni relative al mittente, il destinatario (intese come porte di dominio), al servizio richiesto ed al profilo di collaborazione utilizzato; tale busta viene in generale gestita dalle componenti di collaborazione delle porte di dominio e deve quindi essere il più generale possibile;
una parte di contenuto applicativo, rappresentato dalle informazioni effettive previste per quel tipo di servizio e di scambio (p. es. i dati identificativi personali di una richiesta di informazioni anagrafica).

Lo strumento utilizzato per definire un formato dei dati condiviso tra tutte le amministrazioni, a prescindere dai sistemi "legacy" e dalle basi dati, è XML. SOAP è invece utilizzato come standard per veicolare le informazioni codificate con XML sulla rete Internet, mediante il protocollo HTTP. In generale, il tipo di struttura da utilizzarsi per busta e contenuto dipende dal tipo di messaggio e dalle esigenze di carattere normativo. In questo senso, in base alla normativa vigente possono essere definiti tre tipi di messaggi:

messaggi che non richiedono l'uso della firma digitale;
messaggi che richiedono l'uso della firma digitale come sola garanzia di provenienza delle informazioni (ai sensi del d.P.R. 445/2000);
messaggi che richiedono l'apposizione della firma digitale da parte di un pubblico ufficiale.

Si noti che i messaggi di tipo 1) e 2) si prestano ad un trattamento interamente automatizzato, mentre i messaggi di tipo 3) richiedono, tipicamente, un intervento manuale di firma da parte di un pubblico ufficiale. I documenti a valore legale possono essere firmati digitalmente come allegati binari PKCS #7 (in base alla circolare AIPA CR/24); gli altri contenuti XML possono essere firmati digitalmente per fornire una prova della loro provenienza. Una firma opzionale può essere inclusa nell'intestazione utilizzando gli standard XML SOAP Security e XML Signature e potrebbe, ad esempio, essere usata per garantire la fonte di provenienza delle informazioni (art. 43 del D.P.R. 445/2000). La scelta delle strutture specifiche per la busta di e-government da utilizzare nello scambio dei messaggi costituisce una parte integrante della definizione preliminare dei servizi e non può costituire una variante da negoziarsi per ciascuno scambio. Dal punto di vista amministrativo, la struttura XML SOAP incorpora anche il ruolo della segnatura informatica in formato XML del messaggio in quanto riporta i dati minimi della registrazione di protocollo. La struttura XML SOAP può inoltre essere inclusa in una struttura MIME allo scopo di allegare al messaggio uno o più documenti applicativi, in base allo standard XML SOAP with attachments.

Normativa di riferimento

Viene riportato qui di seguito un elenco di documenti di riferimento relazionati con il componente di porta di dominio:

Linee guida per la Rete Nazionale (C.U.18 gennaio 2001);
Allegato tecnico Rete Nazionale (C.U.18 gennaio 2001);
DPR 28 dicembre 2000 n. 445: Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa; pone implicitamente la necessità di una forte interazione informatica tra le P.A. per poter soddisfare i requisiti di legge;
Il DPCM 31/10/2000 e la circolare AIPA CR/28 del 7/5/2001 disciplinano le modalità di interconnessione tra diversi sistemi di protocollo informatico e la loro integrazione con la posta elettronica e la firma digitale. In particolare, la normativa prevede la possibilità di trattamento automatico delle informazioni scambiate tra sistemi di protocollo diversi;
Il DPCM 8/2/1999: "Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici"; disciplina tra le altre cose le modalità tecniche di apposizione e verifica della firma digitale;
La circolare AIPA CR/24 del 19 giugno 2000: stabilisce le linee guida fondamentali per l'interoperabilità dei sistemi basati sulla firma digitale. Tale circolare stabilisce tra l'altro il formato di riferimento per i certificati X.509, che riportano le chiavi pubbliche di sottoscrizione e le informazioni salienti riguardo al sottoscrittore, ed il formato dei documenti digitali firmati, con riferimento alla specifica pubblica PKCS#7

Note

^ SPCoop: Porta Di Dominio (PDF), su agid.gov.it.
^ Linee Guida per il passaggio al nuovo modello di interoperabilità (PDF), su agid.gov.it.
^ SPCoop: Quadro d'insieme (PDF), su agid.gov.it.
^ SPCoop: busta di eGovernment (PDF), su agid.gov.it.

Voci correlate

Principali siti di riferimento

Ministro per l'Innovazione e le tecnologie, su innovazione.gov.it.
DigitPA - Ente Nazionale per la Digitalizzazione della Pubblica Amministrazione, su digitpa.gov.it.
Sviluppo OpenSource della Porta Di Dominio, su openspcoop.org.