Definizione delle interfacce di colloquio fra le componenti

Transcript

1 Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1

2 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA DI DISTRIBUZIONE Versione Data Paragrafi Modificati AGGIORNAMENTI Motivo Modifica /07/2004 Prima stesura /07/ , , , 3.1.2, Raggruppamento dei paragrafi 2.1 e 2.2 nel paragrafo Messaggio di trasporto delle registrazioni di Protocollo Raggruppamento dei paragrafi 2.3 e 2.4 sotto il nuovo paragrafo Messaggio di Comunicazione non conforme Uniformato il messaggio di avvenuta protocollazione per comunicazioni inviate da soggetti non pubblici accreditati con quello previsto per il messaggio di protocollo (Conferma Ricezione). Per distinguere la natura del mittente, nei campi CodiceAmministrazione e CodiceAOO dell Identiticatore del MessaggioRicevuto si inserirà la stringa COMUNICAZIONE. Inoltre nel campo NumeroRegistrazione sempre contenuto nell Identiticatore del MessaggioRicevuto si inserirà il message ID della comunicazione. Messaggio di Comunicazione da soggetto non pubblico accreditato: evidenziato quanto segue: - come risposta all invio di una comunicazione sarà restituito al soggetto non pubblico accreditato esclusivamente il message ID - i messaggi di accettazione e di non accettazione sono pubblicati sul framework CA. Il proxy applicativo attestato sul CRIC provvederà a leggere tutti i messaggi di notifica riguardanti una comunicazione non conforme inviata da un soggetto non pubblico accreditato tramite web application, e li registra sullo storage. - Il soggetto non pubblico accreditato potrà successivamente visualizzare le notifiche riguardanti una comunicazione inviata. 2

3 1.2 20/07/ Trasferimento del paragrafo 4.4 nel corpo del capitolo 2. Aggiunta immagine (Figura 1) sulla Ricezione messaggi da soggetti esterni al CART. Specificate altre due tipologie di soggetti esterni: - Pubblica Amministrazione che invia messaggi non conformi alla circolare AIPA/CR/28 - Pubblica Amministrazione che non utilizza sistemi sicuri di trasporto quali la posta elettronica certificata Aggiunta la seguente precisazione: Il proxy applicativo potrà distinguere i messaggi di avvenuta protocollazione per soggetti non pubblici accreditati dagli altri per mezzo della valorizzazione dei tag relativi a CodiceAmministrazione e CodiceAOO: se i tag sono valorizzati con il testo COMUNICAZIONE allora il Proxy Applicativo richiederà al framework CA di pubblicarli sulla coda dei soggetti non pubblici accreditati. 3

4 CONVENZIONI UTILIZZATE NEL DOCUMENTO Sezione Contenuto Significato Figure schematiche interoperabilità Figure schematiche interoperabilità Schemi DTD Identifica l iter seguito dai messaggi di notifica. Identifica l iter seguito dai messaggi di protocollo. Identifica un contenitore obbligatorio di altre informazioni Schemi DTD Identifica un contenitore facoltativo di altre informazioni Schemi DTD Identifica una informazioni elementare obbligatoria Schemi DTD Identifica una informazioni elementare facoltativa Schemi DTD Schemi DTD Schemi DTD Identifica una informazione che può essere ripetuta una o più volte Identifica una informazione che può essere ripetuta nessuna, una o più volte Collega in sequenza un contenitore alle informazioni contenute Schemi DTD Collega un contenitore alle informazioni contenute, ed indica che le informazioni sono tra loro alternative 4

5 Indice 1. Introduzione Glossario Messaggi per interoperabilità di protocollo Messaggio di trasporto delle registrazioni di Protocollo Messaggio di Comunicazione non conforme Messaggio di Anomalia di trasporto Messaggio di Comunicazione da soggetto non pubblico accreditato Messaggio di Avvenuta protocollazione a soggetto non pubblico accreditato Interfacce SIL-Proxy Applicativo Interfaccia per SIL evoluti Ricezione dei messaggi di comunicazione non conformi Invio messaggio di avvenuta protocollazione Interfaccia per SIL non evoluti Ricezione dei messaggi di comunicazione non conforme Invio messaggio di avvenuta protocollazione Appendice DTD messaggio comunicazione non conforme Formato testo messaggio di comunicazione non conforme Busta SOAP e.protocollo di trasporto tra Proxy Applicativo e SIL Gestione delle anomalie di trasporto Riferimenti...25 Indice delle figure Figura 1 - Ricezione messaggi da soggetti esterni al CART... 9 Figura 2 - Ricezione messaggio di anomalia di trasporto...11 Figura 3 - Invio messaggio da un soggetto non pubblico accreditato...13 Figura 4 - Restituzione messaggio di avvenuta protocollazione...14 Figura 5 - Schema del DTD di anomalia dit trasporto...20 Figura 6 - Busta SOAP di trasporto per messaggi di comunicazione non conforme

6 1. Introduzione Il presente documento è di integrazione al documento di Definizione delle interfacce di colloquio fra le componenti pubblicato da Regione Toscana sul sito Vengono trattate di seguito le modalità di gestione di quei messaggi inviati da soggetti esterni alla Rete Telematica Regione Toscana ad Enti o Amministrazioni aderenti al progetto e.toscana B2. Nel seguito del documento si farà riferimento a tali messaggi con il termine comunicazioni, per distinguerli dalle altre tipologie di messaggio descritte nel documento interfacce [2] Glossario Si riportano di seguito le definizioni di alcune entità fondamentali per la comprensione degli argomenti trattati nel presente documento, estrapolate dal documento di riferimento per l indicazione delle linee guida del servizio di trasmissione di documenti informativi mediante posta elettronica certificata [1]: Punto di accesso: è il punto che fornisce i servizi di accesso per l invio di messaggi di posta certificata. Il punto di accesso fornisce i servizi di accesso dell utente, emissione della ricevuta di accettazione, imbustamento del messaggio originale nel messaggio di trasporto. Punto di ricezione: Entità che riceve il messaggio all interno di un dominio di posta certificata. Corrisponde alla macchina destinata alla ricezione dei messaggi per il dominio, Effettua i controlli sulla provenienza/correttezza del messaggio ed emette la ricevuta di presa in carico, imbusta i messaggi errati in un messaggio di anomalia di trasporto. Punto di consegna: Entità che effettua la consegna del messaggio nella casella di posta elettronica dell utente di posta certificata destinatario (nell ambito della infrastruttura CART del gateway attestato sul CRIC). Ricevuta di accettazione: È la ricevuta, contenente i dati di certificazione, rilasciata al mittente dal punto di accesso a fronte dell invio di un messaggio di posta certificata. La ricevuta di accettazione è firmata con la chiave del gestore di posta certificata del mittente. Ricevuta di presa in carico: È emessa dal punto di ricezione verso il gestore di posta certificata mittente per attestare l avvenuta presa in carico del messaggio da parte del dominio di posta certificata di destinazione. Nella ricevuta di presa in carico sono inseriti i dati di certificazione per consentirne l associazione con il messaggio a cui si riferisce. Ricevuta di avvenuta consegna: Il punto di consegna emette al mittente la ricevuta di avvenuta consegna nel momento in cui il messaggio è inserito nella casella di posta certificata del destinatario. È rilasciata una ricevuta di avvenuta consegna per ogni destinatario al quale il messaggio è consegnato. La ricevuta di avvenuta consegna porta in allegato i dati di certificazione e, per i destinatari primari del messaggio, il messaggio originale. 6

7 Ricevuta di errore di consegna: Nel caso in cui il punto di consegna sia impossibilitato a consegnare il messaggio nella casella di posta certificata del destinatario, il sistema emette una ricevuta di errore di consegna per indicare l anomalia al mittente del messaggio originale. Messaggio originale: È il messaggio originale inviato da un utente di posta certificata prima del suo arrivo al punto di accesso. Il messaggio originale è consegnato all utente di posta certificata di destinazione per mezzo di un messaggio di trasporto che lo contiene. Messaggio di trasporto: È il messaggio creato dal punto di accesso, all interno del quale è inserito il messaggio originale inviato dall utente di posta certificata ed i relativi dati di certificazione. Il messaggio di trasporto è firmato con la chiave del gestore di posta certificata mittente. Il messaggio di trasporto è consegnato immodificato nella casella di posta certificata di destinazione per permettere la verifica dei dati di certificazione da parte del ricevente. Messaggio di anomalia di trasporto: Quando un messaggio errato/non di posta certificata deve essere consegnato ad un utente di posta certificata, il messaggio è inserito in un messaggio di anomalia di trasporto per evidenziare l anomalia al destinatario. Il messaggio di anomalia di trasporto è firmato con la chiave del gestore di posta certificata del destinatario. Dati di certificazione: Sono un insieme di dati che descrivono il messaggio originale e sono certificati dal gestore di posta certificata del mittente. I dati di certificazione sono inseriti nelle varie ricevute e sono trasferiti all utente di posta certificata di destinazione insieme al messaggio originale per mezzo di un messaggio di trasporto. Tra i dati di certificazione sono: data ed ora di invio, mittente, destinatario, oggetto, identificativo messaggio, ecc. Gestore di posta certificata: È un entità che gestisce uno o più domini di posta certificata con i relativi punti di accesso, ricezione e consegna. È titolare della chiave usata per la firma delle ricevute e dei messaggi di trasporto. Si interfaccia con altri gestori di posta certificata per l interoperabilità con altri utenti di posta certificata. Dominio di posta certificata: Corrisponde ad un dominio DNS dedicato alle caselle di posta elettronica degli utenti di posta certificata. All interno di un dominio di posta certificata tutte le caselle di posta elettronica devono appartenere ad utenti di posta certificata. L elaborazione dei messaggi di posta certificata (ricevute utente, messaggi di trasporto, ecc.) deve avvenire anche nel caso mittente e destinatario appartengano allo stesso dominio di posta certificata. Casella di posta certificata: È una casella di posta elettronica alla quale è associata una funzione che rilascia delle ricevute di avvenuta consegna al ricevimento di messaggi di posta certificata. Una casella di posta certificata può essere definita esclusivamente all interno di un dominio di posta certificata. 7

8 Utente di posta certificata: È un utente a cui è assegnata una casella di posta certificata. Utilizza il punto di accesso del proprio gestore di posta certificata per inviare messaggi di posta certificata. 2. Messaggi per interoperabilità di protocollo. Ad integrazione di quanto riportato nel documento interfacce [2] vengono descritte di seguito le varie modalità di gestione dei messaggi inviati ad un SIL da parte di un soggetto esterno al CART. Una prima distinzione va fatta tra soggetti non pubblici accreditati e soggetti esterni. Soggetti non pubblici accreditati sono cittadini o imprese non dotati di un servizio di posta certificata ma in possesso di un certificato (di accesso) rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana. Soggetto esterno è un soggetto che rientra in una delle seguenti tipologie: - soggetto non pubblico provvisto di firma digitale - soggetto non pubblico che invia comunicazioni attraverso un generico provider di posta certificata - soggetto non pubblico non provvisto di firma digitale Altri possibili soggetti che potrebbero inviare messaggi ad un SIL sono i seguenti: - Pubblica Amministrazione che invia messaggi non conformi alla circolare AIPA/CR/28 - Pubblica Amministrazione che non utilizza sistemi sicuri di trasporto quali la posta elettronica certificata In entrambi i casi, i messaggi verranno riconosciuti dal punto di ricezione del dominio di posta elettronica certificata di RTRT come anomalie di trasporto (nel primo caso perché non è presente o non è valida la segnatura e nell altro caso perché il messaggio proviene da un provider di posta non certificata) e quindi possono essere considerati allo stesso modo dei soggetti esterni. Per una maggiore comprensione dello scenario descritto nei paragrafi seguenti, si faccia riferimento alla Figura 1 - Ricezione messaggi da soggetti esterni al CART. 8

9 Soggetto non pubblico accreditato Casella di posta certificata Soggetto esterno AOO esterna al CART CRIC Web Application Gateway Proxy Applicativo Comunicazione non conforme Anomalia di trasporto Messaggio di trasporto delle registrazioni di Protocollo Coda Comunicazione_NomeSIL Coda Protocollo_NomeSIL Figura 1 - Ricezione messaggi da soggetti esterni al CART Quando il gateway di posta certificata va ad interrogare la casella di posta elettronica certificata di una determinata AOO può trovarsi di fronte a diversi tipi di messaggio provenienti sia da soggetti esterni che da AOO esterne al CART. Comunque tutte le tipologie possono essere ricondotte alle seguenti: 1. Messaggi di trasporto delle registrazioni di Protocollo. 2. Messaggi di Anomalia di Trasporto riconosciuti dal punto di ricezione del dominio di posta certificata. Nel primo caso ci si trova di fronte ad una tipologia di messaggio già trattata nel documento interfacce [2] al paragrafo 2.1: il messaggio viene imbustato e.toscana ed inviato al FrameworkCA per la pubblicazione sulla coda Protocollo_NomeSIL. I messaggi del secondo tipo vengono considerati Comunicazioni non conformi e dopo essere stati imbustati e.toscana, vengono inviati al FrameworkCA per la pubblicazione sulla coda Comunicazione_NomeSIL. L ultima tipologia che deve essere trattata riguarda i messaggi provenienti da soggetti non pubblici accreditati, per i quali si è scelto di uniformare la struttura del messaggio da consegnare al SIL al fine di presentare un unica struttura di busta di trasporto indicata nel seguito del documento col termine comunicazione non conforme allo standard e.toscana. Queste comunicazioni vengono inviate dal Proxy Applicativo presente sul CRIC al FrameworkCA per la pubblicazione sulla coda Comunicazione_NomeSIL. 9

10 Criteri utilizzati dal Gateway per distinguere un tipo di messaggio dall altro. Per eseguire dei controlli preliminari senza bisogno di sbustare il messaggio, il gateway potrà utilizzare il subject del messaggio stesso. I testi standard che è possibile trovare come prefissi aggiunti dal sistema di posta certificata al subject del messaggio originario sono indicati nel documento [3]. - Se il subject contiene il testo POSTA CERTIFICATA è probabile che il messaggio sia del primo tipo; la certezza sarà data dalla presenza del file segnatura.xml all interno del messaggio stesso. Se non è presente la segnatura il messaggio sarà classificato del secondo tipo. - Se il subject contiene il testo ANOMALIA MESSAGGIO allora verrà identificato come messaggio del secondo tipo. - Tutti gli altri casi verranno riconosciuti come messaggi del primo tipo (subject contenente il testo CONSEGNA oppure ACCETTAZIONE) Messaggio di trasporto delle registrazioni di Protocollo Vedere descrizione nel paragrafo 3.2 del documento di specifica delle interfacce [2]. 10

11 2.2. Messaggio di Comunicazione non conforme Il messaggio di comunicazione non conforme rappresenta due tipologie di messaggi: Messaggio di anomalia di trasporto recapitato nella casella di posta elettronica certificata Comunicazione da soggetto non pubblico accreditato inserita tramite web application attestata sul CRIC A seguire si descrivono in dettaglio i due tipi di messaggio Messaggio di Anomalia di trasporto Il messaggio è l elaborazione del messaggio di Anomalia di trasporto prodotto dal sistema di posta certificata del destinatario a fronte di una comunicazione inviata da un soggetto esterno. Le fasi da 1 a 3 della Figura 2 sono descritte nell appendice 4.4 del presente documento. CRIC Gateway 4 Messaggio di anomalia di trasporto 3 Dominio di posta certificata Punto di consegna Framework CA Messaggio di anomalia di trasporto 2 NAL 5 Punto di ricezione 1 SIL Messaggio di posta non certificata Figura 2 - Ricezione messaggio di anomalia di trasporto 11

12 Il gateway verifica, nelle singole caselle di posta certificata dei destinatari dei messaggi, la presenza di messaggi di anomalia di trasporto prodotti dal sistema di posta elettronica certificata. I messaggi presenti nella casella sono letti dal gateway, che apre la busta di anomalia di trasporto, compone la busta e.toscana allegando il messaggio originale e la pubblica mediante il Framework CA sulla coda del SIL di destinazione (4-5). La costruzione della busta e.toscana viene completata con l aggiunta di un allegato riportante tutte le informazioni di spedizione incluse negli header del messaggio di anomalia di trasporto (riferimento DTD in appendice 4.1). Il Framework CA ha le caratteristiche di sicurezza sufficienti a garantire l avvenuta consegna del messaggio al SIL destinatario. Il Proxy Applicativo attestato sul NAL non deve produrre messaggi di notifica in quanto questa è gestita dal dominio di posta elettronica certificata al momento della ricezione Messaggio di Comunicazione da soggetto non pubblico accreditato In questo scenario il messaggio è utilizzato per comunicare alle Amministrazioni Pubbliche / Enti aderenti al progetto e.toscana B2, le comunicazioni inviate da parte di soggetti non pubblici accreditati (cittadini, imprese) non dotati di un servizio di posta certificata ma in possesso di un certificato (di accesso) rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana. Per l invio delle comunicazioni i soggetti non pubblici accreditati utilizzano una interfaccia web posizionata nel CART, che autentica il soggetto e consente l invio ad una delle AOO presenti sull indice regionale per mezzo di un proxy applicativo che si interfaccia con il CRIC. Dalla stessa interfaccia il soggetto non pubblico accreditato potrà interrogare il sistema per acquisire i messaggi di servizio relativi alla comunicazione inviata (messaggio di accettazione, messaggio di non accettazione, messaggio di avvenuta consegna, messaggio di avvenuta protocollazione). Per la realizzazione di questa funzione è prevista la realizzazione di una interfaccia web dalla quale sarà possibile indicare la/le Amministrazioni destinatarie delle comunicazione, inserire il testo esplicativo della comunicazione stessa, ed allegare a quest ultima eventuali documenti digitali firmati. Per uniformare la modalità di trasporto di questi messaggi al SIL destinatario, si è scelto di utilizzare lo stesso formato dei messaggi di comunicazione non conformi. Il messaggio che il proxy applicativo sul CRIC invia mediante il framework CA sulla coda del SIL di destinazione, è costituito da una busta e.toscana contenente un file conforme al DTD in appendice 4.1 con il messaggio originario inserito tramite l interfaccia web e con eventuali documenti firmati allegati. A livello funzionale (vedi Figura 3), il soggetto non pubblico accreditato, dopo essersi opportunamente autenticato con il certificato di accesso rilasciato dalla autorità di certificazione riconosciuta ed interoperante con la CA di RTRT, invia la comunicazione alla Amministrazione Pubblica / Ente aderente al progetto e.toscana B2 compilando la relativa form offerta dalla web 12

13 application (1). A seguito della richiesta sarà immediatamente generato il message ID che potrà poi permettere di seguire l iter del messaggio fino alla sua consegna. Il message ID sarà legato al soggetto non pubblico accreditato per mezzo del codice fiscale / partita IVA estratto dal Common Name (CN) contenuto nel certificato X.509 rilasciato da Regione Toscana ed utilizzato per accreditarsi alla web application. La web application, alla ricezione della comunicazione, la spedisce tramite interfaccia al Proxy Applicativo (2a), il quale dopo i controlli formali compone la busta e.toscana contenente come allegati il messaggio di comunicazione non conforme e il file contenente i dati riepilogativi della comunicazione. Successivamente invia la busta e.toscana tramite CART (3) e produce un messaggio di accettazione (2b). La notifica di errori in fase di costruzione della busta e.toscana da parte del Proxy Applicativo, viene notificata per mezzo di un messaggio di non accettazione (2b). Il messaggio di accettazione ed il messaggio di non accettazione vengono inviati, tramite il framework CA, sulla coda predisposta per i soggetti non pubblici accreditati. Sarà compito del proxy applicativo attestato sul CRIC andare a leggere tali messaggi, unitamente agli eventuali messaggi di avvenuta consegna ed avvenuta protocollazione di seguito descritti, e renderli disponibili per future interrogazioni da parte del soggetto non pubblico accreditato. Al termine dell invio della comunicazione sarà restituito al soggetto non pubblico accreditato il messaggi ID prodotto, per mezzo del quale potrà successivamente visualizzare l iter della comunicazione, tramite una apposita funzione predisposta sulla web application. 1 6 Soggetto non pubblico accreditato 4a CRIC 4a Web Application 2a Proxy Applicativo 2b Messaggio di accettazione / Messaggio di non accettazione 3 Framework CA 4a 4 Messaggio di avvenuta consegna NAL 5 SIL Figura 3 - Invio messaggio da un soggetto non pubblico accreditato 13

14 La busta e.toscana viene consegnata al Proxy Applicativo ricevente a cui afferisce il SIL destinatario mediante specifica coda (4). Il Proxy Applicativo la sbusta e mette a disposizione il messaggio di comunicazione al SIL destinatario (5). Quando il Proxy Applicativo acquisisce i messaggi di comunicazione dalla coda, invia il Messaggio di avvenuta consegna sulla coda predisposta per i soggetti non pubblici accreditati Messaggio di Avvenuta protocollazione a soggetto non pubblico accreditato A seguito della ricezione di un messaggio di Comunicazione da soggetto non pubblico accreditato, se richiesto, il SIL destinatario potrà inviare un messaggio notifica di avvenuta protocollazione. 4 Soggetto non pubblico accreditato Messaggio di Avvenuta Consegna 3b CRIC Web Application 4 Proxy Applicativo 3a Framework CA 2 Messaggio di Avvenuta consegna 3b NAL Messaggio di avvenuta 1a protocollazione Messaggio di Accettazione / Messaggio di non Accettazione 1b SIL Figura 4 - Restituzione messaggio di avvenuta protocollazione 14

15 Per uniformare il "messaggio di avvenuta protocollazione" in risposta a comunicazioni non conformi provenienti da soggetti non pubblici accreditati con quello previsto in risposta a messaggi di protocollo, si è scelto di utilizzare lo stesso formato del messaggio di conferma ricezione descritto nel documento interfacce [2]. Per dettagli sulla struttura di tale messaggio fare riferimento a quanto descritto nel successivo paragrafo Quindi il SIL (vedi Figura 4) invia il messaggio di avvenuta protocollazione al Proxy Applicativo attestato sul NAL di riferimento (1a). Il proxy applicativo esegue i controlli formali, a seguito dei quali, se verifica anomalie (XML non valido,...) compone il messaggio di non accettazione (1b) e lo rende disponibile al SIL mittente. Se invece il proxy applicativo non verifica anomalie, compone la busta e.toscana contenente il messaggio di avvenuta protocollazione e lo invia tramite CART (2) producendo un messaggio di accettazione (1b). Il proxy applicativo potrà distinguere i messaggi di avvenuta protocollazione per soggetti non pubblici accreditati dagli altri per mezzo della valorizzazione dei tag relativi a CodiceAmministrazione e CodiceAOO: se i tag sono valorizzati con il testo COMUNICAZIONE allora il Proxy Applicativo richiederà al framework CA di pubblicarli sulla coda dei soggetti non pubblici accreditati. Il Proxy Applicativo attestato sul CRIC andrà a leggere in tale coda, sbusterà i messaggi (nella coda sono in formato e.toscana), aggiornerà lo stato della richiesta (3b) nello storage ed invierà il Messaggio di avvenuta consegna sulla coda del SIL mittente (3b). In qualsiasi momento, utilizzando il message ID, il soggetto non pubblico accreditato potrà verificare lo stato del messaggio inviato tramite apposita interfaccia web descritta in precedenza (4). 15

16 3. Interfacce SIL-Proxy Applicativo 3.1. Interfaccia per SIL evoluti Ricezione dei messaggi di comunicazione non conformi Il SIL potrà ricevere un messaggio di comunicazione non conforme interrogando un apposito webservice attestato sul Proxy Applicativo. Ogni SIL evoluto dovrà quindi implementare un client SOAP in grado di comporre ed inviare un messaggio nel formato di busta SOAP, nella cui body part saranno contenuti i parametri necessari (nome SIL, nome evento) a ricevere i messaggi di comunicazione non conforme relativi al singolo SIL. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER RICEZIONE MESSAGGIO NON CONFORME>?wsdl invocando semplicemente il metodo relativo alla ricezione dei messaggi. Il client, quindi, invia la busta SOAP, ed a seguito della richiesta, il Proxy Applicativo restituirà il messaggio nel formato descritto in appendice 4.3 ( vedi Figura 6). Al termine della ricezione del messaggio, il client del SIL comunicherà al Proxy Applicativo l esito, sia nel caso positivo che negativo (ad esempio per interruzione sul canale di comunicazione), per mezzo di un acknowledgement. Il SIL evoluto dovrà quindi implementare un ulteriore client SOAP in grado comporre ed inviare il messaggio di acknowledgement nel formato di busta SOAP, nella cui body part sono contenuti i parametri (nome SIL, nomeevento, ack=si/no, descrizione eventuale errore) necessari a comunicare al proxy applicativo l esito della comunicazione. Per la composizione della busta il client si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER ACK>?wsdl invocando semplicemente il metodo relativo alla comunicazione dell esito della comunicazione. In mancanza della ricezione dell acknowledgement il Proxy Applicativo renderà disponibile al SIL il messaggio che non ha ricevuto correttamente per un numero N di volte, configurabile a livello di singolo SIL Invio messaggio di avvenuta protocollazione Se previsto, al termine della ricezione di un messaggio di comunicazione non conforme ed a protocollazione avvenuta, il client del SIL comunicherà al Proxy Applicativo la avvenuta protocollazione. Il SIL evoluto dovrà quindi implementare un client SOAP in grado comporre ed inviare il messaggio di avvenuta protocollazione allo stesso modo descritto nel paragrafo

17 (Invio messaggi di protocollo) del documento interfacce [2] per i messaggi di trasporto delle registrazioni di Protocollo. Una conferma di ricezione è codificata come una struttura che contiene almeno una attachment part avente nome Conferma.xml. Tale attachment part contiene un documento XML strutturato nel modo indicato di seguito: <?xml version="1.0" encoding="utf-8"?> <ConfermaRicezione> <Identificatore> <CodiceAmministrazione> </CodiceAmministrazione> <CodiceAOO> </CodiceAOO> <NumeroRegistrazione> </NumeroRegistrazione> <DataRegistrazione> </DataRegistrazione> </Identificatore> <MessaggioRicevuto> <Identificatore> <CodiceAmministrazione> </CodiceAmministrazione> <CodiceAOO> </CodiceAOO> <NumeroRegistrazione> </NumeroRegistrazione> <DataRegistrazione> </DataRegistrazione> </Identificatore> </MessaggioRicevuto> </ConfermaRicezione> In particolare, nella sezione <MessaggioRicevuto> verranno riportate le informazioni relative al mittente del messaggio che è stato protocollato che, essendo un soggetto non pubblico accreditato, non sarà legato ad alcuna AOO o amministrazione. Il SIL dovrà, quindi, valorizzare i tag relativi a CodiceAmministrazione e CodiceAOO con il testo COMUNICAZIONE, ed inserire le informazioni relative a NumeroRegistrazione (che valorizzerà con il MessageID) e DataRegistrazione di cui dispone (perchè presenti nel messaggio originario ricevuto). Per la composizione della busta SOAP il client del SIL si potrà anche avvalere della elaborazione della descrizione WSDL presente sul Proxy Applicativo all indirizzo: WEB SERVICE PER INVIO>?wsdl invocando semplicemente il metodo relativo all invio dei messaggi Interfaccia per SIL non evoluti Per SIL non evoluto si intende un sistema informativo locale che implementa una versione di Protocollo Informatico non AIPA/CR/28 e quindi non in grado di comporre buste SOAP secondo le modalità descritte nei paragrafi precedenti. Per questa tipologia di SIL, il Proxy Applicativo permette una interazione secondo un formato basato su sintassi XML o testuale (TXT) (a secondo della configurazione del SIL stesso), in grado di contenere un subset di dati minimo ma adeguato, in accordo a quanto descritto nella circolare AIPA/CR/28. 17

18 Per quanto riguarda la richiesta di un evento da parte di un SIL non evoluto, viene stabilito un formato standard per facilitare il colloquio con il Proxy Applicativo. La richiesta avviene tramite una GET http al seguente indirizzo: me_sil=<nome_sil>&formato=<formato>&step=<step> I parametri utilizzati hanno il significato seguente: <NOME_EVENTO> <NOME_SIL> <FORMATO> <STEP> è il parametro che identifica la tipologia di evento che il SIL vuole ricevere; è il nome del SIL richiedente; indica il formato XML o TXT in cui il client del SIL preferisce visualizzare il messaggio; di default il formato scelto è XML; è il parametro che permette di implementare il meccanismo di acknowledgement per la ricezione dei messaggi secondo l algoritmo descritto nei paragrafi successivi. Nel caso in cui il formato scelto dal SIL fosse XML, il messaggio contenente l evento destinato al SIL e sarà strutturato nel modo seguente: <EVENTO> <! -- Corpo del Messaggio --> </EVENTO> dove Corpo del Messaggio è il contenuto di un messaggio rappresentante un singolo evento destinato al SIL Ricezione dei messaggi di comunicazione non conforme Per la ricezione dei messaggi di comunicazione non conforme il Proxy Applicativo offre una interfaccia HTTP che permette al Sistema Informativo Locale di prelevare i messaggi ad esso destinati. Il formato dei messaggi restituiti al SIL potrà essere XML o TXT (configurabile tramite l apposito parametro <FORMATO> in fase di richiesta messaggi). La richiesta dei messaggi avviene tramite una o più GET http al seguente indirizzo: =<NOME_SIL>&formato=<FORMATO>&step=<STEP> La prima richiesta effettuata dal SIL dovrà prevedere il parametro <STEP> = 0. Il Proxy Applicativo risponderà inviando, del messaggio di anomalia di trasporto, il solo file riportante i dati riepilogativi della comunicazione non conforme. Nella richiesta successiva, con parametro <STEP> = 1, il Proxy Applicativo restituirà il messaggio originale. Infine il SIL dovrà inviare un ultima richiesta, valorizzando il parametro <STEP> = 2; tale richiesta verrà interpretata dal Proxy Applicativo come acknowledgement di conferma ricezione del messaggio inviato. 18

19 Ogni GET attiva un timeout, configurabile su ogni Proxy Applicativo in base al di tipo di <STEP> (per differenziare la ricezione del file iniziale contenente i dati riepilogativi da quella del messaggio originale). La prima richiesta da parte del SIL attiverà il primo timeout, dopo di che: se la richiesta successiva arriva entro il termine del timeout, la parte di messaggio di anomalia di trasporto precedentemente inviata si intende ricevuta correttamente dal SIL. se la richiesta successiva arriva dopo il timeout o non arriva, la parte di messaggio di anomalia di trasporto precedentemente inviata si intende non ricevuta correttamente ed il messaggio di anomalia di trasporto viene di nuovo reso disponibile per un numero di volte configurabile a livello di singolo SIL. Per avere la certezza che il SIL abbia ricevuto correttamente il messaggio di anomalia di trasporto con il messaggio originale allegato il Proxy Applicativo, quindi, dovrà ricevere dopo lo <STEP> = 0, altri due <STEP> di richiesta messaggi entro i timeout previsti. Nel caso si verifichi un errore di natura qualsiasi in fase di ricezione, il SIL potrà segnalare un acknowledgement di errore tramite una GET al seguente indirizzo: =<NOME_SIL>&ack=no l effetto di questo acknowledgement di errore fa si che il Proxy Applicativo passi all elaborazione del messaggio successivo. In ogni caso, i messaggi correttamente inviati dal Proxy Applicativo al SIL non verranno più riproposti al SIL. Le specifiche del formato TXT sono definite in appendice Invio messaggio di avvenuta protocollazione Se previsto, al termine della ricezione di un messaggio di comunicazione non conforme ed a protocollazione avvenuta, il SIL potrà segnalare la avvenuta protocollazione del messaggio allo stesso modo descritto nei paragrafo e (Invio messaggi di protocollo per SIL non evoluti) del documento interfacce [2]. Nel caso di utilizzo della modalità tramite web browser (form http), si dovrà specificare la tipologia messaggio di conferma di ricezione nell apposita list box del web browser utilizzato, nei campi minimi della segnatura specificare il Message ID come numero di registrazione, la data di registrazione, e valorizzando il CodiceAOO ed il CodiceAmministrazione con il testo COMUNICAZIONE. Nel caso di automatizzazione del procedimento di invio informazioni da SIL a Proxy Applicativo (post http) le informazioni dovranno essere passate in modo analogo a quanto descritto in precedenza. 19

20 4. Appendice Non tutti gli schemi dei DTD riportati a seguire sono esplosi fino all ultimo livello. Per il dettaglio completo fare comunque riferimento alla definizione del DTD. Tutti i campi data definiti nei seguenti DTD, sono da intendersi in formato ISO 8601 esteso (i.e. aaaa-mm-gg), mentre i campi ora devono essere in formato ISO 8601 esteso (i.e. hh:mm:ss[,ddd] - ad esempio 16:09:19,710; si noti che l'indicazione dei millisecondi è opzionale) DTD messaggio comunicazione non conforme Figura 5 - Schema del DTD di anomalia dit trasporto <?xml version="1.0" encoding="utf-8"?> <!-- L'elemento "nonconforme" identifica la radice --> <!-- Il DTD viene utilizzato per notificare i dati riepilogativo del messaggio di comunicazione non conforme, ovvero di: - un messaggio errato o di posta ordinaria inviato ad Sistemi Informativi Locali nell'ambito della rete regionale toscana attraverso un sistema di posta certificata - un messaggio di posta elettronica certificata inviata da un soggetto non pubblico accredito tramite un intermediario certificato - un messaggio di comunicazione inserito da un soggetto non pubblico accreditato in possesso di un certificato di accesso rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana--> <!ELEMENT nonconforme (intestazione, dati)> <!-- Identitica la natura della comunicazione: - "ANOMTRASP": messaggio errato o di posta ordinaria inviato ad Sistemi Informativi Locali nell'ambito della rete regionale toscana attraverso un sistema di posta certificata - "NONPAINT": da soggetto non pubblico accreditato attraverso un sistema intermediario di posta certificata 20

21 - "NONPAWEB": da soggetto non pubblico accreditato in possesso di un certificato di accesso rilasciato da una autorità di certificazione riconosciuta ed interoperante con la CA di Rete Telematica Regionale Toscana --> <!ATTLIST nonconforme tipologia (ANOMTRASP NONPAINT NONPAWEB) #REQUIRED> <!-- Intestazione del messaggio di comunicazione non conforme --> <!ELEMENT intestazione (mittente)> <!-- Identificativo del mittente del messaggio originale --> <!ELEMENT mittente (#PCDATA)> <!-- Dati del messaggio di posta certificata --> <!ELEMENT dati (idmessaggio, data, consegna*, errore-esteso?, risposta)> <!-- Identificativo del messaggio originale --> <!ELEMENT idmessaggio (#PCDATA)> <!-- Identitica se inviare o meno il messaggio di avvenuta protocollazione --> <!ATTLIST idmessaggio avvenutaprotocollazione (noninvio invio) #REQUIRED> <!-- Data/ora di elaborazione del messaggio --> <!ELEMENT data (giorno, ora)> <!-- Giorno nel formato "aaaa-mm-gg" --> <!ELEMENT giorno (#PCDATA)> <!-- Ora locale in formato "hh:mm:ss" --> <!ELEMENT ora (#PCDATA)> <!-- Destinatario al quale era indirizzato il messaggio originale --> <!ELEMENT consegna (#PCDATA)> <!-- Descrizione errore --> <!ELEMENT errore-esteso (#PCDATA)> 21

22 4.2. Formato testo messaggio di comunicazione non conforme I campi da utilizzare per i messaggi di comunicazione non conforme, sono stati ricavati dai campi obbligati previsti dal DTD relativo (vedi 4.1). Il formato testo, di seguito definito, sarà utilizzato dai SIL non in grado di ricevere il messaggio in formato XML e quindi sarà compito del Proxy Applicativo trasformare il file XML ricevuto nel corrispondente file di testo. Le informazioni sono definite nel formato <nome >=<valore> e sono separate dalla stringa **. Tipologia=NonConforme** intestazione=< Intestazione del messaggio di comunicazione non conforme>** mittente=< Identificativo del mittente del messaggio originale>** idmessaggio=< Identificativo del messaggio originale>** giorno=< Giorno di elaborazione del messaggio nel formato "aaaa-mm-gg" >** ora=< Ora di elaborazione del messaggio nel formato "hh:mm:ss" >** consegna=< destinatario al quale era indirizzato il messaggio >** consegna=< destinatario al quale era indirizzato il messaggio >** errore=< descrizione del messaggio >** protocollazione=<si NO indica se inviare o meno al mittente la notifica di avvenuta protocollazione >** 22

23 4.3. Busta SOAP e.protocollo di trasporto tra Proxy Applicativo e SIL La busta SOAP di Trasporto utilizzata per l invio e la richiesta di messaggi tra SIL e Proxy, si compone di più parti che contengono informazioni sui parametri e gli eventuali allegati necessari al corretto invio e ricezione dei messaggi di protocollo riferiti alla circolare AIPA/CR/28. SOAPMessage SOAPPart SOAPEnvelope SOAPHeader Headers:.. SOAPBody: documento XML di risposta (anomaliatrasoporto.xml) AttachmentPart MIME HEADERS: Content-Transfer-Encoding=base64 Allegati: <messaggio originario>.eml Figura 6 - Busta SOAP di trasporto per messaggi di comunicazione non conforme Per i messaggi di comunicazione non conforme la busta di trasporto SOAP (Figura 6) è composta dal solo allegato del messaggio originario codificato in base64. Le informazioni riepilogative del messaggio originale (riferimento paragrafo 4.1) sono invece contenute nella body part della busta stessa. 23

24 4.4. Gestione delle anomalie di trasporto Di seguito si descrive la modalità di generazione delle anomalie di trasporto da parte del sistema di posta certificata di Regione Toscana secondo quanto indicato nel documento [3]. Il punto di ricezione del dominio di posta certificata di Regione Toscana (vedi Figura 2), a fronte dell arrivo di un messaggio (1), verifica la correttezza/natura del messaggio in ingresso, ovvero effettua le seguenti verifiche: Controllo dell esistenza della firma: il sistema verifica la presenza della struttura S/MIME di firma all interno del messaggio in ingresso Controllo che la firma sia stata emessa da un gestore di posta certificata: il punto di ricezione estrae il certificato usato per la firma del messaggio in ingresso e ne verifica la presenza all interno dell indice dei gestori di posta certificata Controllo della validità della firma: è verificata la correttezza della firma S/MIME del messaggio effettuando il ricalcolo degli algoritmi di firma Se tutti i controlli non hanno esito positivo il sistema stabilisce che il messaggio in ingresso è un messaggio di trasporto errato o di posta ordinaria, lo imbusta in un messaggio di anomalia di trasporto e successivamente lo inoltra verso il punto di consegna. Nel messaggio di anomalia di trasporto è inserito come allegato il messaggio originale completo di header, testo ed allegati, in formato conforme alla RFC Il messaggio di anomalia di trasporto eredita dal messaggio originale i seguenti header che dovranno essere riportati immodificati: Received To Cc Return-Path Message-ID Dovranno invece essere modificati, o inseriti se necessario, dal sistema di posta certificata gli header sotto elencati: X-Trasporto: errore Date: [data di arrivo del messaggio] Subject: ANOMALIA MESSAGGIO: [subject originale] From: [mittente originale] <posta-certificata@[dominio_di_posta]> Reply-To: [mittente originale (inserito solo se assente) ] Il corpo del messaggio di anomalia di trasporto è composto da un testo che costituisce la parte immediatamente leggibile del destinatario del messaggio secondo un modello che riporti i seguenti dati: 24

25 Anomalia del messaggio Il giorno [data] alle ore [ora] ([zona]) è stato ricevuto il messaggio [subject] proveniente da [mittente] ed indirizzato a: [destinatario1] [destinatario2]... [destinatarion] Tali dati non sono stati certificati per il seguente errore: [descrizione sintetica errore riscontrato] Il messaggio originale è incluso in allegato. Il punto di consegna provvederà successivamente a consegnare il messaggio di anomalia di trasporto ai destinatari del messaggio originale attraverso la infrastruttura CART. 5. Riferimenti [1] Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione, Guida ai servizi di Indice Pubblica Amministrazione e Posta Certificata, 15 dicembre [2] Regione Toscana, Documento specifiche interfaccia SIL, Giugno [3] Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione, Allegato tecnico alle linee guida del servizio di trasmissione di documenti informatici mediante posta elettronica certificata, 29 maggio