LINEE GUIDA PER LO SVILUPPO DI SERVIZI DI FRONT END
Versione 1.0
Linee guida per lo sviluppo di servizi di front end
2
RIEPILOGO REVISIONI E VERSIONI PRECEDENTI
Versione Motivo Data Redatto da Distribuito a
1.0 Primo rilascio 30/06/2014
Silvia Ghiani (Lepida)
Giovanni Grazia (RER)
Luigi Zanella (CCD)
Davide Boari (CCD)
Martina Forconi (CCD)
Pubblicato su
sito Lepida
Spa sezione
MAD
Linee guida per lo sviluppo di servizi di front end
3
INDICE DEL DOCUMENTO
1 Scopo del documento .................................................................................................... 4 1.1 Elenco delle fonti giuridiche e tecniche di rilievo ............................................................................ 5
2 Mappa dei documenti del MAD ..................................................................................... 7 3 I termini utilizzati per definire le linee guida ................................................................ 8 4 Classificazione dei servizi ........................................................................................... 11 5 Check list per la progettazione di un servizio di Front End ..................................... 12
5.1 Passo 1: la mia interfaccia è accessibile? ................................................................................... 13
5.1.1 Accessibilità 13
5.2 Passo 2: la mia interfaccia è usabile? .......................................................................................... 14
5.3 Passo 3: il mio servizio è “sicuro”? .............................................................................................. 15
5.3.1 Autenticazione 16
5.3.2 Autorizzazione 18
5.3.3 Validazione dei dati ............................................................................................................................ 18
5.3.4 Gestione delle sessioni utente ............................................................................................................ 18
5.3.5 Logging 19
5.3.6 Utilizzo di ICAR ER per la cooperazione applicativa .......................................................................... 19
5.4 Passo 4: con quali servizi di back end posso integrare il mio servizio per sfruttare appieno il MAD? ........................................................................................................................................... 20 5.4.1 Integrazione con servizi di Back end documentali .............................................................................. 20
5.4.2 Integrazione con servizi di Back end territoriali .................................................................................. 21
5.4.3 Integrazione con i servizi di Back end di anagrafe ............................................................................. 23
6 Linee guida per i servizi di visura ............................................................................... 25 6.1 DossiER ....................................................................................................................................... 26
7 Linee guida per la realizzazione di servizi di front end ............................................. 28 7.1 Servizi di istanza .......................................................................................................................... 28
7.2 Accesso come intermediari .......................................................................................................... 28
7.3 Pagamento di oneri ...................................................................................................................... 29
7.4 Firma elettronica della pratica ...................................................................................................... 29
7.5 Invio della pratica all’Ente ............................................................................................................ 32
8 Il catalogo delle anagrafi certificanti e dei servizi ..................................................... 33
Linee guida per lo sviluppo di servizi di front end
4
1 SCOPO DEL DOCUMENTO
Il presente documento si inserisce nell’ambito delle Linee di azione per la Semplificazione (in attuazione
della legge regionale n. 18/2011, della deliberazione di Giunta regionale n. 983 del 16 luglio 2012 e della
risoluzione dell’Assemblea Legislativa n. 3209 del 2 ottobre 2012) tracciate dalla Regione Emilia-Romagna.
La Regione ha delineato con la d.G.R. n. 983/2012 (allegato 2B: “Disegno della PA Digitale:
dematerializzata, interconnessa e cooperativa”) il “Modello di Amministrazione Digitale” (MAD). Il MAD
rappresenta il modello concettuale cui la Regione guarda al fine di ripensare la propria organizzazione e
azione amministrativa in un’ottica di semplificazione.
Il MAD persegue l’obiettivo di favorire l’integrazione e la cooperazione applicativa fra gli enti della CN-ER
come mezzo per snellire e rendere più efficiente la PA. L'integrazione fra i diversi enti della CN-ER abilita la
possibilità per i servizi relativi ad una funzione di un ente di comunicare in tempo reale con i servizi relativi ad
altre funzioni dello stesso ente o di enti diversi.
Lo scopo di questo documento è fornire delle linee guida su come progettare servizi di front end che
garantiscano:
• l’integrazione con i servizi di back end e le infrastrutture realizzati all’interno del MAD
• la conformità con la normativa sull’accessibilità
• la conformità con le principali prassi per la gestione della sicurezza
Le linee guida sono rivolte a:
• Progettisti di sistemi informatici
• Responsabili di sistemi informativi
Le linee guida non contengono specifiche tecniche legate all’implementazione dei sistemi ma si
preoccupano di fornire le indicazioni per una corretta progettazione dei sistemi ed un corretto utilizzo dei
servizi infrastrutturali e di back end esistenti.
Le linee guida si focalizzano sui soli servizi rilevanti ai fini dell’attuazione del MAD, in particolare per i servizi
di front end prendono in considerazione la realizzazione di servizi appartenenti alle seguenti tipologie:
• Servizi di visura
• Servizi di istanza
• Servizi di calcolo
Linee guida per lo sviluppo di servizi di front end
5
Nell’esprimere il contenuto delle linee guida sono utilizzate le parole chiave DEVE, NON DEVE,
OBBLIGATORIO, VIETATO, DOVREBBE, CONSIGLIATO, NON DOVREBBE, SCONSIGLIATO,
POTREBBE, OPZIONALE che devono essere interpretate in conformità con RFC 21191. In particolare:
• DEVE, OBBLIGATORIO, NECESSARIO (corrispondenti a MUST, REQUIRED, SHALL in RFC 2119)
significano che la definizione è un requisito assoluto: la specifica deve essere implementata, la
consegna è inderogabile.
• NON DEVE, VIETATO (corrispondenti a MUST NOT, SHALL NOT in RFC 2119) significano che c’é
proibizione assoluta di implementazione di un determinato elemento di specifica.
• DOVREBBE, CONSIGLIATO (corrispondenti a SHOULD, RECOMMENDED in RFC 2119)
significano che in particolari circostanze possono esistere validi motivi per ignorare un requisito, non
implementare una specifica o derogare alla consegna, ma le implicazioni correlate alla scelta
devono essere esaminate e valutate con attenzione.
• NON DOVREBBE, SCONSIGLIATO (corrispondenti a SHOULD NOT, NOT RECOMMENDED in
RFC 2119) significano che in particolari circostanze possono esistere validi motivi per cui un
elemento di specifica è accettabile o persino utile, ma, prima di implementarlo, le implicazioni
correlate dovrebbero essere esaminate e valutate con attenzione.
• PUÒ, OPZIONALE (corrispondenti a MAY, OPTIONAL RFC 2119) significano che l’implementazione
di un elemento della specifica è facoltativa.
Le parole chiave nel testo sono segnalate in maiuscolo (ad es. “DEVE”).
1.1 Elenco delle fonti giuridiche e tecniche di rilievo
Le linee guida sono state prodotte in conformità alle norme nazionali e regionali ed alle specifiche
dell’Agenzia per l’Italia Digitale vigenti alla data e seguendo le best practice del settore; come tutti i
documenti del MAD, infine, le linee guida potranno evolvere per recepire cambiamenti normativi e nuove
pratiche di rilevo.
• CAD – Codice dell’Amministrazione Digitale (Decreto Legislativo n. 82/2005 e ss. mod. e int., in
particolare quelle apportate con il Decreto-Legge n. 179/2012 recante “Ulteriori misure urgenti per la
crescita del Paese”, convertito con L. n. 221/2012);
• DPCM 22 febbraio 2013 - Regole tecniche in materia di generazione, apposizione e verifica
delle firme elettroniche avanzate, qualificate e digitali, ai sensi degli articoli 20, comma 3, 24,
comma 4, 28, comma 3, 32, comma 3, lettera b), 35, comma 2, 36, comma 2, e 71. (13A04284);
• Legge 4/2004 del 9 gennaio 2004 - Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici;
1 http://www.ietf.org/rfc/rfc2119.txt
Linee guida per lo sviluppo di servizi di front end
6
• Decreto 20 Marzo 2013, che aggiorna i requisiti di accessibilità per i siti web della PA; • Decreto Legislativo 196/2003 del 30 giugno 2003 - Codice in materia di protezione dei dati
personali;
• Legge Regionale dell’Emilia-Romagna n. 11/2004 - “Sviluppo regionale della società
dell'informazione”;
• Legge Regionale 7 Dicembre 2011, N.18 - Misure per l’attuazione degli obiettivi di
semplificazione del sistema amministrativo regionale e locale - Istituzione della sessione di
semplificazione
• D.G.R. n. 983/2012, con cui è stato approvato il “Documento del Tavolo permanente per la
Semplificazione in preparazione della Sessione per la Semplificazione 2012 (L.R. 18/2011)”,
recepita e approvata con risoluzione dell’Assemblea Legislativa ER del 2/10/2012, n. 3209;
• Det. D.G. Affari Istituzionali e Legislativi n. 8861/2012 “Costituzione del Gruppo Tecnico Tematico per la Informatizzazione delle procedure degli atti attraverso un sistema di interconnessione
telematica di tutta la PA, per l’attuazione della L.R. n. 18 del 2011”;
• D.G.R. n. 2013/2012 “Piano degli interventi per la semplificazione relativo alla Prima linea di
azione Informatizzazione dei procedimenti amministrativi e interoperabilità delle pubbliche
amministrazioni";
• MAD – Modello di Amministrazione Digitale (contenuto nella deliberazione di Giunta regionale n.
2013/2012 “Piano degli interventi per la semplificazione”);
• Standard e specifiche internazionali sull’interoperabilità fra pubbliche amministrazioni (es.
Programma Europeo ISA)
Linee guida per lo sviluppo di servizi di front end
7
2 Mappa dei documenti del MAD
Le linee guida si collocano all’interno della gerarchia dei documenti del Modello di Amministrazione Digitale.
Linee guida per lo sviluppo di servizi di front end
8
3 I TERMINI UTILIZZATI PER DEFINIRE LE LINEE GUIDA
Al fine di assicurare la massima chiarezza e non ambiguità del linguaggio, in questo Capitolo si descrivono i
termini utilizzati per definire le linee guida. I termini sono stati collezionati in tre gruppi:
Banca dati
Si definisce Banca dati una collezione omogenea di dati riguardanti un particolare ambito di competenza.
Fonte: Linee guida decertificazione
Anagrafe
Banca dati che censisce, in modo univoco, oggetti o soggetti di interesse della Pubblica Amministrazione. Le anagrafi possono essere istituite in applicazione di specifiche disposizioni di legge o possono essere istituite come base di conoscenza necessaria per l'espletamento di compiti istituzionali della Pubblica Amministrazione.
Fonte: MAD
Esempi: Registro delle imprese, anagrafe della popolazione, anagrafe comunale degli immobili, Registro
delle persone giuridiche, catasto strade, ….
Anagrafe certificante
E’ un’anagrafe in grado di certificare l'esistenza e/o il possesso di determinate caratteristiche di un oggetto o di un soggetto in uno specifico momento .
Fanno parte dell'anagrafe certificante le sole caratteristiche che il titolare dell‘anagrafe è in grado di certificare, NON fanno parte dell’anagrafe certificante le caratteristiche non certificabili dal titolare dell’anagrafe.
Normalmente è il titolare dell'anagrafe che dichiara la propria anagrafe come certificante.
Fonte: Linee guida decertificazione
Esempi: Registro delle imprese, anagrafe della popolazione, anagrafe comunale degli immobili, registro delle
persone giuridiche, catasto strade, ….
Linee guida per lo sviluppo di servizi di front end
9
Esempio di caratteristiche non certificabili: l’anagrafe della popolazione non è in grado di certificare la
professione di un cittadino, in quanto il titolare della gestione dell’anagrafe della popolazione non governa il
processo di aggiornamento dell’attributo riferito al soggetto presente nell’anagrafe.
Servizio
Il servizio è un sistema di comunicazione messo a disposizione da un particolare dominio applicativo attraverso il quale un'applicazione chiamante è in grado di interagire con le banche dati e i processi del dominio stesso.
Fonte: MAD
Esempi: servizio di visura di una unità immobiliare, il servizio riceve in input gli identificativi catastali di un
immobile e restituisce in output i dati dell’immobile.
Servizi di Back End
E' l'insieme di servizi – cioè, sistemi di comunicazione - che, interagendo con le banche dati, mettono a disposizione delle applicazioni che invocano i dati in forma nativa o elaborata.
Fonte: MAD
Back Office
Sistemi legacy presenti all’interno degli enti (es. Tributi, SUAP, Edilizia)
Fonte: MAD
Esempi: Sistema software di gestione dell’anagrafe della popolazione di un comune.
Servizi di Back End di Anagrafe
Sono servizi di back end che permettono l’interrogazione delle anagrafi. Le attività che possono essere svolte sono assimilabili al concetto di visura (ad es. per consultare dati anagrafici della popolazione, delle imprese o degli immobili).
Fonte: MAD
Esempi: Servizi PARIX per accedere ai dati delle imprese.
Linee guida per lo sviluppo di servizi di front end
10
Servizio di Front End
Servizi che richiamano i servizi di back end per rendere disponibili all’utente finale una serie di funzionalità on line, attraverso una pluralità di canali, quali Web, Mobile ed altri.
Fonte: MAD
Esempio: Servizio di consultazione dati anagrafici
Sistema di Front End
Applicazioni comprendenti più servizi di front end che utilizzano i servizi di back end per rendere disponibili all’utente finale una serie di funzionalità on line, attraverso una pluralità di canali, quali Web, Mobile ed altri.
Fonte: MAD
Esempi: Servizi Demografici online (comprendenti più servizi di front end demografici, come la consultazione
dei propri dati anagrafici, il cambio di abitazione, etc…)
Linee guida per lo sviluppo di servizi di front end
11
4 CLASSIFICAZIONE DEI SERVIZI
Obiettivo di questo capitolo è arrivare ad una classificazione delle diverse tipologie di servizi di Front End
interessati dalle linee guida, val a dire tutti i servizi di front end rivolti a cittadini, imprese o intermediari.
Come detto sopra, i servizi di front end richiamano i servizi di back end per rendere disponibili all’utente
finale una serie di funzionalità on line, attraverso una pluralità di canali, quali Web, Mobile ed altri.
Esempi di servizi di questo tipo sono i servizi demografici (cambio di abitazione, richiesta certificato con
timbro digitale), i servizi tributari (visualizzazione propri cespiti, calcolo tributi, etc…) e i servizi autorizzatori e
concessori (ad es. SUAP, OSAP Provinciale, etc…).
Al fine della redazione delle linee guida per lo sviluppo di servizi di front end, tuttavia, si ritiene necessario
classificare i servizi più ad alto livello, non ritenendo opportuno entrare nello specifico ambito applicativo.
A tal riguardo, si individuano, pertanto, le seguenti macro-categorie:
• servizi di visura: questi servizi interrogano i servizi di back end di visura per mostrare all’utente
finale delle informazioni di suo interesse. Sono esempi di questa categoria la visualizzazione dei
propri dati anagrafici o la visualizzazione dei dati relativi agli immobili di proprietà.
• servizi di istanza: questi servizi consentono agli utenti di compilare dei moduli online, sfruttando
l’integrazione con vari servizi di back end per facilitare la compilazione dei dati necessari, e di
inoltrare l’istanza agli enti preposti, utilizzando diverse modalità (PEC, invio al back office). Esempi di
questi servizi sono il Procedimento Unico dello Sportello Unico delle Attività Produttive o il Cambio di
Residenza.
• servizi di calcolo: interrogano servizi di calcolo di back end per fornire all’utente finale risultati di
calcoli che possono essere anche basati su dai provenienti da altri servizi di back end: un esempio è
il Calcolo della somma da pagare per un tributo comunale che fornisce i parametri al servizio di
calcolo interrogando prima il servizio di back end di estrazione dei propri cespiti.
Linee guida per lo sviluppo di servizi di front end
12
5 CHECK LIST PER LA PROGETTAZIONE DI UN SERVIZIO DI FRONT END
La check list che segue ha l’obiettivo di fornire le linee guida per la progettazione di un servizio di front end.
Come anticipato, queste linee guida non entrano nello specifico di un ambito applicativo: l’obiettivo non è,
quindi, stabilire come debba essere concepito un servizio di visura dei dati anagrafici o di inoltro di
un’istanza di rimborso IMU (quali dati, in che ordine, etc..).
L’obiettivo è, invece, definire una serie di criteri da utilizzare durante l’implementazione del servizio, in modo
da riusare, il più possibile, componenti informatiche e prassi messe a disposizione dal MAD, minimizzando
l’effort:
• di realizzazione del servizio da parte del fornitore
• di utilizzo del servizio da parte dell’utente finale.
La seguente check list si articola in 4 passi, come di seguito
• Passo 1: Obiettivo è progettare l’interfaccia del servizio di front end seguendo la normativa
sull’accessibilità
• Passo 2: Obiettivo è progettare l’interfaccia del servizio di front end seguendo gli standard relativi
all’usabilità
• Passo 3: Obiettivo è progettare il servizio di front end seguendo le linee guida regionali in termini di
sicurezza (autenticazione, autorizzazione, validazione dei campi, gestione delle sessioni e logging)
• Passo 4: Obiettivo è progettare il servizio tenendo conto delle possibilità offerte dai servizi di back
end facenti parte del MAD (servizi documentali, territoriali, di anagrafe)
Linee guida per lo sviluppo di servizi di front end
13
5.1 Passo 1: la mia interfaccia è accessibile?
5.1.1 Accessibilità
In termini di accessibilità, le linee guida fanno riferimento alla normativa nazionale, costituita dalla Legge n.
4/2004 per i siti web della Pubblica Amministrazione.
Tale legge è stata aggiornata nel tempo, con:
• il decreto legge 179/2012, che ha l’obiettivo di garantire il principio fondamentale di accessibilità
totale a tutti i cittadini di informazioni e servizi erogati dalla pubblica amministrazione e da tutti coloro
che percepiscono fondi pubblici per lo sviluppo di servizi basati su tecnologie internet. tramite
decreto il 20/03/2013
• il decreto del 20/03/2013, che aggiorna i requisiti di accessibilità, prendendo a riferimento le linee
guida WCAG 2.0 del W3C, meno stringenti sotto l’aspetto della conformità del codice e ottimizzate
per l’operatività delle tecnologie legate alle applicazioni Web di nuova generazione nonché
all’accessibilità dei documenti.
Linee guida per lo sviluppo di servizi di front end
14
Per i dettagli dei nuovi requisiti, si faccia riferimento all’Allegato A del già citato DM 20/3/2013, reperibile
all’URL
http://www.gazzettaufficiale.it/atto/serie_generale/caricaArticolo?art.progressivo=0&art.idArticolo=1&art.versi
one=1&art.codiceRedazionale=13A07492&art.dataPubblicazioneGazzetta=2013-09-
16&art.idGruppo=0&art.idSottoArticolo1=10&art.idSottoArticolo=1&art.flagTipoArticolo=1#art
Vale la pena sottolineare come i nuovi requisiti, indipendenti dalla tecnologia utilizzata per lo sviluppo, si
applichino in settori anche differenti dalla pubblicazione di siti web; in particolare si fa riferimento a
“informazioni o servizi su reti internet, intranet o extranet, su supporti informatici removibili (quali ad esempio
cd-rom, dvd) che possono essere utilizzati anche in stazioni di lavoro non collegate ad una rete telematica.”
Si evidenziano, infine, alcuni aspetti di particolare importanza se si considera lo sviluppo di un servizio front
end, vale a dire:
• non esiste più il vincolo relativo alla necessità di far funzionare tutto in assenza di script, si richiede
però un uso corretto dei linguaggi di Scripting per garantire l’accessibilità agli utenti con disabilità;
• Le WCAG 2.0 (ed il decreto) consentono anche l’uso di contenuti non accessibili, purché non
impediscano agli utenti di accedere alle informazioni e servizi della pagina web;
• il criterio relativo ai processi completi: quando un servizio è erogato mediante un processo che si
sviluppa su più pagine web allora tutte le pagine web ad esso relative devono essere conformi,
anche quando tali pagine si trovino su siti diversi (es. inoltro ad un sistema di pagamento);
• anche i documenti elettronici eventualmente fruibili tramite un servizio di front end devono essere
conformi ai requisiti tecnici di accessibilità: qualora questo non sia possibile, devono essere forniti
sommario e descrizione degli scopi dei documenti stessi in forma adatta ad essere fruita con
le tecnologie compatibili con l’accessibilità e devono essere indicate in modo chiaro le modalità di
accesso alle informazioni equivalenti a quelle presentate nei documenti digitali non accessibili.
5.2 Passo 2: la mia interfaccia è usabile?
L’accessibilità vista nel paragrafo precedente non è l’unico aspetto da tenere presente nella progettazione di
un’interfaccia; c’è un altro concetto che riveste grande importanza: l’usabilità.
L’usabilità definisce il grado di facilità e soddisfazione con cui si compie l'interazione tra l'uomo e uno
strumento, in questo caso l’interfaccia di un servizio di front end.
Un’interfaccia “non usabile” è infatti un servizio che, anche laddove sia conforme alla legge sull’accessibilità
(la legge Stanca n. 4/2004), non garantisce di per sé il pieno accesso alle funzionalità e ai contenuti, senza
la comprensione dei quali è impossibile se non a volte addirittura “dannosa”, anche in termini di malessere
psicologico, la fruizione dei servizi e delle informazioni on line.
Linee guida per lo sviluppo di servizi di front end
15
Rivolgendosi a un'utenza eterogenea ed estremamente differenziata (giovani, anziani, professionisti,
imprenditori, etc…), i front end (siti e applicazioni) esposti dalla PA devono contenere informazioni e servizi
facilmente utilizzabili da tutti.
Un servizio di front end, per garantire il diritto di accesso alle informazioni ed alle varie funzionalità abilitate,
deve quindi essere progettato considerando le esigenze di tutti gli utenti, qualsiasi sia la loro competenza
informatica o abilità fisica.
L'usabilità non è una caratteristica intrinseca del sito, ma fa riferimento all''interazione tra l'utente ed il
servizio; inoltre, essa non va intesa come un dato acquisito una volta per tutte, ma come un obiettivo di
miglioramento della "user experience" da perseguire costantemente.
In questo contesto, è importante individuare da subito le tipologie di utenti interessati al servizio: una prima
fondamentale suddivisione è fra cittadini ed utenti PA: le due classi di utenti possono avere, infatti,
necessità differenti che porteranno a diverse considerazioni, ad esempio, sulla strutturazione delle
interfacce.
L'usabilità deve essere dunque definita e ricercata nel corso della progettazione, verificata insieme agli utenti
in un processo iterativo di controllo e correzione, nonché valutata alla fine del processo.
Il CAD stabilisce i principi generali per la progettazione dei siti web, ricordando che è obbligo delle pubbliche
amministrazioni realizzare siti istituzionali che rispettino i principi di elevata usabilità e reperibilità, chiarezza
di linguaggio e semplicità di consultazione.
L'obiettivo deve essere il miglioramento della qualità del sito e l'aumento della soddisfazione dei cittadini, cui
può fare seguito una riduzione dei costi di assistenza agli utenti e un perfezionamento dell'immagine
complessiva dell'ente e della pubblica amministrazione in generale.
Per le linee guida da seguire al fine di progettare un servizio di front end usabile, si rimanda ai lavori del
Gruppo di Lavoro sull’Usabilità (GLU), sorto per iniziativa del Dipartimento della Funzione Pubblica (DFP).
L'obiettivo è definire, previa sperimentazione, uno strumento metodologico che supporti le attività di
progettazione e sviluppo editoriale dei siti pubblici nella valutazione delle criticità di navigazione e
interazione con gli utenti.
Per maggiori informazioni, fare riferimento a http://www.funzionepubblica.gov.it/glu.aspx.
5.3 Passo 3: il mio servizio è “sicuro”?
Nella progettazione e realizzazione dei servizi di front end è buona regola valutare le minacce di sicurezza e
le contromisure disponibili relativamente a dati e informazioni. E’ consigliato fare riferimento a quanto
previsto nel “Disciplinare tecnico in materia di sicurezza delle applicazioni informatiche nella Giunta della
Regione Emilia-Romagna”.
Linee guida per lo sviluppo di servizi di front end
16
Come indicato nel disciplinare, un’applicazione è sicura quando è in grado di preservare confidenzialità,
integrità e disponibilità delle risorse assicurando costantemente:
• l’identificazione dell’utente che accede alle risorse;
• la limitazione degli accessi alle risorse;
• la comunicazione sicura con l’esterno;
• la conservazione sicura dei dati.
Durante la progettazione e la realizzazione di un servizio di front end, gli aspetti da tener presente in materia
di sicurezza sono i seguenti:
• autenticazione
• autorizzazione
• validazione dei dati
• gestione delle sessioni utente
• logging
Nel seguito vedremo i meccanismi di sicurezza da implementare per ognuno degli aspetti sopra elencati.
5.3.1 Autenticazione
Innanzitutto, è necessario definire i punti del servizio di front end che necessitino di autenticazione;
successivamente, occorre scegliere un meccanismo di autenticazione che presenti le seguenti
caratteristiche:
• disattivazione delle credenziali non utilizzate da un certo periodo (ad es. 180 gg);
• non riutilizzo dei codici di identificazione già impiegati assegnandoli ad altri utenti (neanche in tempi
diversi);
• meccanismi di lockout per la disabilitazione di un account non più utilizzato da un certo periodo;
• meccanismi di reset della password;
• meccanismi di cifratura delle password, che non devono mai essere conservate o trasmesse in
chiaro (per es. utilizzo di hash per la memorizzazione delle password, utilizzo di protocolli di
comunicazione cifrati come HTTPS, ecc.);
• meccanismi di controllo della robustezza delle password: prevedere meccanismi di controllo che
consentano esclusivamente l'utilizzo di password corrispondenti a determinati criteri di complessità
All’interno del MAD è presente l’infrastruttura di autenticazione federata Federa, che offre ai servizi di front
end chiamanti un servizio di back end infrastrutturale per consentire l’autenticazione.
Federa presenta intrinsecamente i meccanismi di autenticazione sopra elencati ed è a disposizione come
servizio di back end infrastrutturale a chiunque voglia integrare il proprio servizio di front end: di
Linee guida per lo sviluppo di servizi di front end
17
conseguenza, nella progettazione di un servizio di front end secondo queste linee guida, DEVE essere
utilizzato Federa, qualora ovviamente il servizio preveda autenticazione.
Rimandando alla documentazione specifica relativa a Federa per i dettagli, si intende in questa sede
specificare le azioni principali da svolgere qualora si debba integrare un servizio di front end (service
provider, nella terminologia Federa) con l’infrastruttura Federa:
• Registrazione all’url
http://federazione.lepida.it/federa/partecipa-subito/richiesta-di-partecipazione-per-servizi
Fra i dati da fornire in fase di registrazione, è necessario indicare le informazioni necessarie alla
creazione dei cosiddetti Circle of Trust (COT), vale a dire insiemi di service provider ed identity
provider omogenei in termini di:
o Livello minimo di affidabilità dell’identità digitale ad essi associato.
o Livello minimo di password policy ad essi associato.
o Elenco minimo degli attributi utente restituiti a valle dell’autenticazione.
Queste scelte dipenderanno dalla tipologia e dall’ambito del servizio di front end che si deve
integrare: un servizio di visura anagrafica, ad esempio, dal momento che andrà a leggere dati
personali dall’anagrafe della popolazione, richiederà un livello di affidabilità alto (consegna
credenziali a seguito di riconoscimento de visu o tramite smart card o invio di documentazione
idonea) e password policy media e (lunghezza 8 caratteri, scadenza 6 mesi, etc…).
• download del toolkit per l’integrazione ed implementazione: sono scaricabili dall’url
http://federazione.lepida.it/documentazione/documentazione-tecnica/guida-all-integrazione
i toolkit e la documentazione tecnica per procedere all’integrazione del servizio di front end (service
provider) con l’infrastruttura Federa.
Nel caso in cui si stia sviluppando modificando un sistema o un servizio di front end che abbia già degli
utenti registrati presso un Identity Provider interno, questo DEVE essere federato (deve entrare cioè a far
parte della Federazione), oppure gli utenti DEVONO essere migrati all’interno dell’Identity Provider Federa.
N.B: si noti che, qualora il servizio di front end si stia sviluppando sul Framework People, l’integrazione con
Federa è nativa, essendo offerta al servizio di front end dal componente di autenticazione di People Sirac,
già integrato con Federa.
Linee guida per lo sviluppo di servizi di front end
18
5.3.2 Autorizzazione
Se l’autenticazione deve essere gestita da un provider di autenticazione esterno al servizio di front end,
come Federa, le politiche di autorizzazione, vale a dire decidere quali categorie di utenti abbiano a
disposizione determinate funzionalità, DEVONO essere, invece, gestite all’interno del servizio.
L’obiettivo è fare fronte ad accessi non autorizzati ai dati, modifiche non consentite di dati e, in generale,
esecuzione di operazioni non consentite dalle varie tipologie di utenti.
In particolare, è NECESSARIO:
• implementare meccanismi di separazione dei privilegi per garantire l’utilizzo delle risorse in funzione
di differenti profilazioni degli utenti;
• utilizzare il principio del "minimo privilegio" nell'attribuzione dei permessi, ovvero abilitare l’accesso
alle sole risorse indispensabili e negarlo a tutte le restanti;
• stabilire, in caso di applicazioni web, dove sia necessario applicare la separazione dei privilegi tra
aree ad accesso pubblico ed aree ad accesso riservato;
• Limitare al minimo, ed evitare dove possibile, l’accesso alle risorse di sistema (file, cartelle, registry,
log, ecc.).
5.3.3 Validazione dei dati
Un altro aspetto importante, per quanto concerne la sicurezza di un servizio di front end, è legato alle
contromisure atte ad arginare le minacce causate, ad esempio, da Stringhe “nocive” inserite in query, form,
cookie e header http: esecuzione di comandi, cross-site scripting (XSS), SQL injection, buffer overflow,
denial-of-service.
Tali contromisure hanno a che fare con la validazione dei dati inseriti dall’utente; in particolare prevedono:
• La validazione di input ed output per controllare che siano rispondenti a quanto l’applicazione si
aspetta in termini di:
o formato dei dati;
o sintassi
o dimensioni.
• Che tale validazioni siano lato server (dove per comodità vengano implementate validazione lato
client, esse devono essere accessorie a quelle effettuate lato server).
5.3.4 Gestione delle sessioni utente
Per fare fronte a minacce di
• session hijacking, vale dire l’utilizzo (letteralmente il “dirottamento”) di una sessione web per
accedere a risorse senza disporre dei permessi necessari;
Linee guida per lo sviluppo di servizi di front end
19
• spoofing, val a dire l’impersonificazione illegittima di un utente;
si rendono NECESSARIE le seguenti contromisure:
• prevedere meccanismi di protezione delle credenziali utilizzate per il riconoscimento dell’utente dopo
il login.
• limitare la durata delle sessioni ad un periodo di tempo definito in funzione delle caratteristiche
funzionali dell'applicazione e prevedere il blocco della sessione allo scadere di tale periodo.
• proteggere i cookie di autenticazione di sessione tramite l’utilizzo del protocollo TLS o cifrandone il
contenuto.
• implementare il meccanismo di logout di Federa, che permette all'utente di forzare la chiusura della
sessione applicativa ed il logout in generale dagli altri servizi di front end appartenenti allo stesso
CoT.
5.3.5 Logging
Fondamentale è anche il tema del logging, necessario per poter dimostrare un'eventuale azione illecita
compiuta da un utente; a tal fine, si CONSIGLIA di:
• definire in fase di progettazione quali sono gli eventi chiave per la sicurezza dell’applicazione da
rilevare tramite logging.
• registrare nei log, dove tecnicamente possibile, i seguenti eventi applicativi:
o autenticazione applicativa (login e logout, riusciti e non);
o modifica di funzioni amministrative (per es. la disabilitazione delle funzioni di logging, la
gestione dei permessi, ecc.).
• prevedere meccanismi di controllo e modifica del livello di granularità dei dati rilevabili
• prevedere la possibilità di registrare, all'interno di ogni voce di log, le seguenti informazioni:
o data/ora dell’evento;
o luogo dell’evento (per es. macchina, indirizzo IP, ecc.);
o identificativo dell'entità che ha generato l’evento (per es. utente, servizio, processo, ecc.);
o descrizione dell’evento.
• prevedere meccanismi di conservazione dei log in file su cui sia possibile effettuare esclusivamente
la scrittura incrementale.
5.3.6 Utilizzo di ICAR ER per la cooperazione applicativa
L’Emilia Romagna si è dotata di un’infrastruttura di cooperazione applicativa, chiamata ICAR ER, che
permette lo scambio di informazioni tra sistemi informativi di Enti diversi, realizzando la circolarità e
l’interoperabilità fra i servizi e le applicazioni delle Pubbliche Amministrazioni, attraverso il Sistema di
Linee guida per lo sviluppo di servizi di front end
20
Pubblica Connettività (SPC), e nel rispetto delle specifiche SpCoop, lo standard nazionale per la
cooperazione applicativa fra gli Enti della Pubblica Amministrazione.
ICAR ER garantisce all’intera infrastruttura dei servizi e delle soluzioni l'interoperabilità come servizio
infrastrutturale e la cooperazione applicativa; in particolare il sistema ICAR-ER DEVE essere coinvolto in
tutte le istanze di connessione end-to-end che attraversano, entrando o uscendo, i confini istituzionali di un
ente.
5.4 Passo 4: con quali servizi di back end posso integrare il mio servizio per sfruttare appieno il MAD?
Una componente fondamentale del MAD è costituita dai servizi di back end, da quei servizi, cioè, richiamabili
dai servizi di front end per interagire con banche dati e anagrafi.
Dove applicabile, nella progettazione di un servizio di front end si dovrà tenere conto dell’eventuale presenza
di servizi di back end con cui integrarsi, nelle modalità descritte nel seguito per ogni tipologia di servizi di
back end (documentali, territoriali o di anagrafe).
5.4.1 Integrazione con servizi di Back end documentali
Per quanto riguarda l’ambito documentale, in Emilia Romagna è stato elaborato e messo a disposizione
degli enti un modello concettuale, funzionale ed applicativo, in ambito documentale condiviso e concordato,
utile ai processi di innovazione e dematerializzazione: tale modello è denominato GeDoc.
La Regione Emilia-Romagna, cogliendo la specificità di diverse tipologie di servizi documentali e nell’ottica di
sostenere la diffusione del modello GeDoc sul territorio regionale, ha realizzato poi un sistema, denominato
Doc/er, che implementa i servizi documentali standardizzati ed espone tutte le interfacce previste nel
modello GeDoc, fungendo inoltre da “collante” e da “comunicatore” verso tutti i servizi documentali
specializzati.
Il modello GeDoc offre quindi un catalogo di servizi documentali a disposizione di sistemi verticali che
debbano integrare funzionalità di tipo documentario.
Si distinguono, all’interno del modello GeDoc, due diverse tipologie di sistemi verticali:
• sistemi verticali di filiera, costituiti da sistemi di back office o da servizi di front end
• sistemi verticali di registro, per la gestione di atti, mandati, etc…
I sistemi verticali, per poter interagire con i servizi a catalogo tramite le interfacce standard GeDOC, devono
seguire un processo di standardizzazione: tale processo è denominato “qualificazione” (e le applicazioni
divengono “qualificate”) e costituisce il motore che consente l’implementazione del modello GeDoc sul
Linee guida per lo sviluppo di servizi di front end
21
territorio emiliano-romagnolo, avviando un percorso virtuoso tale da permettere progressivamente di
uniformare le applicazioni grazie allo standard introdotto dal modello stesso.
L’obiettivo della qualificazione di un sistema verticale di filiera (i servizi di front end, oggetto di queste linee
guida, come visto sopra rientrano in questa tipologia), è di far fruire a quest’ultimo dei servizi del modello
GeDoc, attraverso l’integrazione con il sistema Doc/er.
L’integrazione si realizza attraverso l’attuazione dei seguenti requisiti OBBLIGATORI:
• allineamento sincrono delle anagrafiche gestite in comune tra i due Sistemi;
• riversamento dei documenti definitivi nel sistema verticale all’interno del sistema Doc/er e successivi
aggiornamenti in caso di modifiche che dovessero intervenire in corso d’opera;
• interrogazioni del titolario e dei fascicoli da parte del sistema verticale ai fini della classificazione e
fascicolazione dei documenti;
• richieste di protocollazione e fascicolazione dei documenti;
• richieste di registrazione particolare dei documenti;
• richiesta di creazione di nuovi fascicoli;
• ricerca e visualizzazione dei documenti archiviati in Doc/er in base ai diritti dell’utente, anche se
prodotti da altre applicazioni;
Sono, inoltre, presenti i seguenti requisiti OPZIONALI:
• recupero informazioni di dettaglio sulla conservazione dei documenti, ove necessario;
• riversamento dei documenti in fase di produzione (document), integrazione opzionale;
• Utilizzo degli altri servizi disponibili (p.e. servizio di verifica dei formati, verifica delle firme, timbro
digitale, ecc…), ove necessario
5.4.2 Integrazione con servizi di Back end territoriali
Anche in ambito territoriale, così come in ambito documentale, è stato definito dalla Regione Emilia
Romagna un modello concettuale di riferimento, denominato Ge-IT, finalizzato a rendere interoperabili e
confrontabili le fonti dati geografiche gestite ai diversi livelli (regionale e locale) ed alla costituzione di una
base di conoscenza condivisa del territorio.
L'obiettivo del modello è definire il modo in cui gli enti, a prescindere dalle modalità con vengono gestisti
internamente, possa rendere fruibili ed interoperabili i dati territoriali in modo da creare una base di
conoscenza completa e condivisa dell'intero territorio regionale.
Il modello Ge-IT prevede un catalogo di servizi di back end territoriali che offrono varie funzionalità (servizi di
visualizzazione in mappa, accesso ai dati geografici, geocodifica, conversione di coordinate, etc…).
Linee guida per lo sviluppo di servizi di front end
22
Nella progettazione di un servizio di front end, si DOVRANNO richiamare tali servizi ogniqualvolta si
intendano implementare i seguenti requisiti:
• Validazione dei riferimenti territoriali, per tutti i servizi per i quali sia previsto l'inserimento di un
indirizzo o di un riferimento catastale nel territorio del Comune di competenza; tale funzionalità
DEVE validare il riferimento rispetto all'ACI del Comune fornendo all'utente elementi per l'eventuale
disambiguazione del toponimo (es.: si digita COSTA, il sistema elenca tutte le vie che contengono la
parola COSTA). In assenza di una ACI presso il comune la validazione PUO' essere effettuata
sfruttando il Database Topografico Regionale e relativi servizi.
• Recupero riferimento territoriale, per tutti i servizi per i quali sia previsto l'inserimento di un
indirizzo o di un riferimento catastale nel territorio del comune di competenza; all'utente POSSONO
essere messe a disposizione le seguenti funzioni di natura geografica:
o verifica visuale: presentazione di una mappa centrata sull'indirizzo o sul mappale catastale
digitato nei campi alfanumerici (con indirizzo e mappale evidenziati) con la possibilità di
attivare come sfondo per l'inquadramento la foto aerea, il db topografico o altri sfondi
tassellati.
o selezione da mappa: possibilità di selezionare in mappa il numero civico o il mappale di
interesse cliccando direttamente in mappa (in alternativa alla digitalizzazione del nome o dei
codici). Sulla mappa saranno attivi strumenti di navigazione interattiva e di
geolocalizzazione.
o recupero da coordinate: quando non esistono riferimenti visibili (ad es.: definizione di una
pratica SUAP con posizionamento in una zona agricola prova di numeri civici o altro nelle
vicinanze).
• Recupero oggetto territoriale, per i servizi nei quali sia richiesta la scelta di un oggetto che ha una
sua collocazione territoriale (ad esempio per l'iscrizione di un bambino all'asilo, la scelta dell'asilo)
POSSONO essere messe a disposizione dell'utente le seguenti azioni:
o verifica visuale. Il sistema apre la mappa e la centra rispetto un riferimento territoriale
passato alla funzionalità (es.: indirizzo di residenza del richiedente, l'utente può poi
modificare il centramento della mappa con gli strumenti interattivi e di geolocalizzazione); in
mappa sono rappresentati gli oggetti di interesse (es.: gli asili) che costituiscono un altro
parametro della chiamata al servizio di Back end territoriale.
o ricerca oggetti. L'utente può visualizzare i soli oggetti che si trovano a meno di X metri da
un certo punto (es.: la propria abitazione); la distanza può essere calcolata sia prevedendo il
viaggio in auto o il viaggio a piedi.
o interrogazione oggetti. L'utente può, cliccando sulla mappa, ottenere informazioni di sintesi
sul singolo oggetto (per gli asili ad esempio orari, moduli previsti, disponibilità della
refezione, disponibilità del pre o post scuola, ecc...).
Linee guida per lo sviluppo di servizi di front end
23
o selezione oggetto. L'utente può selezionare l'oggetto di interesse (l'asilo al quale vuole
iscrivere il figlio) cliccandolo sulla mappa.
• Visualizzazione cartografica. Per la visualizzazione cartografica i servizi di front end DEVONO
utilizzare i componenti di interfaccia web (widget) costituiti da mappe interattive con le quali si
accede a mappe di origine regionale o locale. I servizi di Back end forniscono sfondi sia tassellati
statici (veloci e fluidi) che sfondi dinamici WMS (più lenti ma rappresentano le variazioni sui db in
tempo reale e consentono più flessibilità nella definizione dei contenuti e degli stili).
• Scarico cartografia. Molte pratiche necessitano di elaborati cartografici allegati dove sono definiti i
dettagli planimetrici degli interventi per cui si redige un’istanza (vedi SUAP). I front end che erogano
questo tipo di servizio DEVONO adottare quelli esposti a livello regionale sul DBTopogtrafico o
servizi con comportamento analogo che attingono a banche dati geografiche locali. Tale cartografia
costituirà per i tecnici la base su cui redigere gli elaborati. Lo scarico potrà essere interfacciato da un
widget di mappa che consente di definire l’area di interesse in maniera più intuitiva.
• Conversione coordinate. Sempre funzionale ad allegare progetti e rilievi a pratiche da sottomettere
ad un Ente è la possibilità di conversione di coordinate. L’utente in possesso di elaborati nati per
qualsiasi ragione in sistemi di riferimento differenti da quelli in uso in Regione di cartografia può
convertire l’elaborato utilizzando algoritmi e parametri standard. I servizi di front end che prevedono
questo tipo di funzioni DEVONO usare i servizi di conversione di coordinate ufficiali della regione.
• Disegno oggetto/evento. Possibilità di indicare interattivamente su una mappa la localizzazione o
la geometria di un oggetto o di un evento oggetto di una pratica da istanziare. L’oggetto potrà essere
disegnato in modalità georeferenziata su un mappa interattiva dotata di funzionalità di editing
(semplificato). L’oggetto (o gli oggetti) disegnati saranno individuabili univocamente da un
identificativo fornito dal servizio di Back end e memorizzabile nell’applicazione client.
Successivamente potrà essere richiamata un servizio per ottenere informazioni (l’estensione
territoriale, l’area, la geometria) o un’immagine georeferenziata dell’oggetto disegnato. Per la
realizzazione di questi servizi si POSSONO usare le librererie GeoER.
5.4.3 Integrazione con i servizi di Back end di anagrafe
Come definito nelle linee guida per la progettazione dei servizi di back end, i servizi di back end di anagrafe
POTRANNO essere richiamati per le seguenti finalità:
• visura per chiave di identificazione univoca: restituzione di dati anagrafici di una entità ricevendo
in input una chiave di identificazione univoca;
• ricerca delle chiavi per proprietà della classe: ricerca della chiave identificativa di una istanza
sulla base del valore di una o più proprietà;
• validazione: verifica esistenza di un’istanza in un’anagrafe certificante, ai fini di poter importare la
chiave nella banca dati dell’Amministrazione procedente;
Linee guida per lo sviluppo di servizi di front end
24
• object referencing: riallineamento delle chiavi fra banche dati di amministrazioni terze e l’anagrafe;
qualora una amministrazione abbia importato nelle proprie banche dati riferimenti alle chiavi di una
anagrafe questi servizi supportano il riallineamento periodico segnalando le variazioni intervenute;
• estrazione massiva: estrazione di sottoinsiemi di dati dall’anagrafe per l’esportazione in formato
digitale o per la produzione di report o elenchi;
Esempi di invocazione dei servizi di back end di anagrafe da parte di servizi di front end sono i seguenti:
• interrogazione dei servizi di back end di anagrafe di ambito demografico, che espongono cioè i dati
dell’anagrafe della popolazione (una delle anagrafi certificanti del MAD), ogniqualvolta siano
necessarie informazioni anagrafiche relative ad un soggetto, al suo stato di famiglia, stato civile o
posizione elettorale;
• interrogazione dei servizi di back end di anagrafe esposti dal Parix-Gate, che forniscono i dati
dell’anagrafe delle imprese (una delle anagrafi certificanti del MAD) che hanno sedi sul territorio
regionale, ogniqualvolta siano necessarie informazioni relative ad un’azienda (elenco sedi, persone
fisiche dotate di cariche, etc…);
• interrogazione dei servizi di back end di anagrafe ACI, che espongono i dati dell’anagrafe comunale
degli immobili (una delle anagrafi certificanti del MAD), ogniqualvolta saranno necessarie, infine,
informazioni relative ad un immobile.
Linee guida per lo sviluppo di servizi di front end
25
6 LINEE GUIDA PER I SERVIZI DI VISURA
Come detto precedentemente, i servizi di front end di visura interrogano servizi di back end al fine di
visualizzare dati di interesse.
I servizi di front end di visura possono essere rivolti:
• ad utenti esterni alla PA, come cittadini, imprese o intermediari: fanno parte di questa tipologia
• i servizi per la visualizzazione dei dati anagrafici dei cittadini, che interrogano i servizi di back
end relativi all’anagrafe della popolazione;
• i servizi per la visualizzazione dei dati di un’impresa, che interrogano i servizi di back end
esposti da Parix, l‘anagrafe delle imprese;
• i servizi di visualizzazione dei dati di un immobile, che interrogano i servizi di back end
esposti l’anagrafe comunale degli immobili.
• ad utenti interni alla PA: questo è il caso di servizi che consentono agli operatori della PA di
recuperare i dati di cittadini o imprese, necessari allo svolgimento delle proprie mansioni,
direttamente dai vari sistemi di back office della stessa PA o di PA distinte, senza doverli richiedere
agli stessi cittadini o imprese sotto forma di certificati2.
In entrambi i casi, a meno che le visure non siano eseguite all’interno di processi di inoltro di particolari
istanze (ad esempio la visualizzazione del proprio nucleo familiare in un’istanza di cambio di abitazione), è
opportuno che i servizi di front end che si progetti un unico sistema che consenta la visualizzazione integrata
di dati provenienti da fonti eterogenee.
In questo modo si avrà la possibilità di consultare dati diversi in maniera integrata, consentendo la
visualizzazione di fascicoli (fascicolo del cittadino, dell’immobile, dell’impresa), contenenti dati provenienti da
2 L'innovazione introdotta dalla legge 183/2001 (art. 15, c.1) ha apportato variazioni alla norme in materia di
certificati, come previsto dal precedente DPR. 445/2000; le modifiche in oggetto, in particolare, hanno
permesso l'introduzione della "decertificazione" come strumento di semplificazione amministrativa nei
rapporti tra Cittadini, Imprese e Pubblica Amministrazione (d'ora in poi, indicata genericamente come PA). A
partire dal 2012, infatti, la PA può continuare a rilasciare certificati, ma soltanto nei casi in cui tali documenti
siano usati dai destinatari – cittadini e imprese – nei rapporti con altri soggetti privati. Il certificato usato dal
privato in un rapporto con la PA è invece considerato nullo e il funzionario pubblico che lo acquisisce è
passibile di sanzione per violazione di dovere d’ufficio (d.P.R. n. 445/2000, art. 40, commi 1 e 2, e art. 74,
co. 2, lettera a). Il principio sancito dalla legge, pertanto, impone alle amministrazioni e ai gestori di pubblici
servizi di non richiedere più agli Utenti alcun certificato già in possesso di altre amministrazioni.
Linee guida per lo sviluppo di servizi di front end
26
fonti eterogenee ed appartenenti a PA distinte e, oltre all’evidente risparmio economico, il cittadino o la PA
fruitrice non dovranno imparare ad utilizzare tanti sistemi diversi.
Per ottenere questi fascicoli, occorre interrogare fonti provenienti da varie PA: questo punto introduce una
complessità non banale, derivante dal tema delle convenzioni, necessarie quando una PA intenda usufruire
di dati di titolarità di un’altra PA.
Questo aspetto suggerisce a maggior ragione l’utilizzo di servizi di visura centralizzati, con schemi
convenzionali predefiniti, da proporre alle PA che intendono mettere a disposizione di un sistema
centralizzato i propri dati, in modo da evitare il proliferare di convenzioni one to one fra PA e PA.
Un’opportunità in questo senso è data dalla piattaforma DossiER, di titolarità della Regione Emilia Romagna
ed erogata, come servizio, da Lepida SpA; che sarà brevemente descritta nel paragrafo seguente.
6.1 DossiER
DossiER si pone come un punto di accesso unico alla documentazione e alle informazioni, o più in generale
ad entità informative, messe a disposizione dalla PA e relative a:
• Soggetti che possono avere rapporti con la Pubblica Amministrazione e che sono individui
nell’esercizio delle loro funzioni, ad esempio, di cittadino, di professionista, di legale rappresentante
di impresa, o di avente diritti su un oggetto (vedi sotto).
• Oggetti che hanno un ruolo nei procedimenti della Pubblica Amministrazione come, ad esempio,
immobili o veicoli soggetti ad immatricolazione.
Se, da un lato, tale sistema costituisce per il cittadino la soluzione ad un problema fortemente sentito, ovvero
l’accesso facilitato a tutta la propria documentazione disponibile presso gli Enti, dall’altro lato lo stesso
sistema costituisce un elemento fondamentale anche per gli utenti della Pubblica Amministrazione che
hanno necessità di recuperare informazioni su soggetti o oggetti distribuite sulle singole pubbliche
amministrazioni regionali.
Attraverso DossiER:
• Il cittadino accede ovunque, in ogni momento, e in modo più efficiente, ai dati e documenti della
Pubblica Amministrazione che lo riguardano,
• Il professionista, nell’esercizio delle proprie attività, accede ad informazioni e documenti che sono
gestiti dalla Pubblica Amministrazione e che riguardano soggetti terzi od oggetti che questi
possiedono;
• L’utente di un’amministrazione procedente può recuperare e scambiare con altri utenti di PA
informazioni e documenti riguardo soggetti ed oggetti necessari all’attività amministrativa di
competenza.
Linee guida per lo sviluppo di servizi di front end
27
I due oggetti che stanno alla base di DossiER sono:
- le Fonti: sono le “sorgenti” che possono essere collegate a DossiER e da cui DossiER preleva le
informazioni richieste dall’utente. Esempi di fonti possono essere:
• Il gestionale delle pratiche SUAP di un determinato comune
• sezioni particolari dell’archivio corrente di un determinato ente
• l’anagrafe della popolazione di un determinato comune
- le Entità informative: sono le “unità di informazione” che DossiER consente di ricercare all’interno delle fonti
disponibili; le entità informative possono essere di varie tipologie. Esempi di tipologie di entità informative
possono essere:
• fascicolo archivistico relativo a una pratica SUAP
• pratica di occupazione suolo pubblico provinciale (OSAP Provinciale)
• pratica Edilizia
• visura di stato di famiglia di un cittadino
• visura catastale di un immobile
• i pagamenti effettuati da un cittadino
DossiER viene interrogato tramite opportune applicazioni di front end (multicanali) a disposizione degli utenti
appartenenti alle varie tipologie viste precedentemente; agendo come proxy applicativo, esso mette a
disposizione delle applicazioni soprastanti un’interfaccia unica e omogenea per la ricerca delle entità
informative condivise dalle fonti.
Le interrogazioni svolte tramite l’applicazione di front end consultano prima il DossiER, poi, eventualmente,
inoltrano la richiesta direttamente alle varie fonti, rese consultabili tramite opportuni servizi di Back End,
Il modello di gestione del DossiER è un modello distribuito, costituito da un ruolo di amministrazione centrale
e da un ruolo di amministrazione locale ad ogni fonte/gruppo di fonti che vengono censite all’interno di
DossiER.
Linee guida per lo sviluppo di servizi di front end
28
7 LINEE GUIDA PER LA REALIZZAZIONE DI SERVIZI DI FRONT END
L’obiettivo di questo capitolo è proporre delle linee guida per la realizzazione dei servizi, focalizzandosi su
alcuni aspetti comuni fra i vari servizi di front end (visure e istanze).
7.1 Servizi di istanza
I servizi di front end di istanza, come ad esempio il Procedimento Unico SUAP o il Cambio di Abitazione,
prevedono la compilazione dei dati necessari all’istanza e l’invio all’ufficio competente per la presa in carico.
Nella realizzazione di un servizio di istanza, si individuano alcune linee guida da seguire relativamente ai
seguenti step di un servizio di istanza:
• Accesso come intermediari
• Pagamento di oneri
• Firma elettronica della pratica
• Invio della pratica all’Ente
7.2 Accesso come intermediari
Frequente è il caso di servizi di istanza utilizzati da utenti intermediari, vale a dire, ad esempio,
professionisti, associazioni di categoria, CAAF, etc… Spesso, infatti, i servizi di front end di istanza
consentono di compilare ed inviare istanze complesse, per le quali, di solito, gli utenti finali (cittadini o
imprese) si affidano appunto a soggetti terzi. Si pensi ad esempio ad una pratica da inviare allo Sportello
Unico delle Attività Produttive (SUAP), per la quale ci si trova a dover compilare una modulistica articolata e
complessa: l’estensore di una pratica SUAP tipicamente è una associazione di categoria, cui l’azienda si
appoggia per attività di questo tipo.
Quanto detto sopra fa sì che, chi si trovi a dover sviluppare un servizio di front end di istanza, si dovrà
preoccupare di rendere possibile l’accesso ad utenti diversi dal titolare della pratica.
Il servizio dovrà gestire internamente la profilazione degli utenti intermediari, o dovrà appoggiarsi ad un
modulo intermediari esterno ai servizi; l’informazione proveniente da Federa dopo l’autenticazione, infatti, è
legata solo all’autenticazione, ma non prevede ancora l’informazione sulla qualifica.
Se il servizio di front end potrà essere acceduto sia da utenti “semplici”, sia da utenti “intermediari”, dovrà
essere possibile, all’ingresso del servizio, scegliere la tipologia di utente con cui procedere.
Linee guida per lo sviluppo di servizi di front end
29
Nel caso di servizi di visualizzazione delle pratiche online, dovrà essere possibile visualizzare le pratiche sia
per l’intermediario che le abbia compilate ed inoltrate, sia per il titolare: su questo aspetto, occorrerà tenere
conto di eventuali problemi di privacy.
7.3 Pagamento di oneri
Nel caso il servizio di istanza prevede il pagamento di oneri all’amministrazione, si propongono le seguenti
linee guida:
• L’utente deve sapere se il pagamento è andato a buon fine o meno e deve poter ritentare in caso di
esito negativo del processo
• Nel caso in cui il pagamento sia di tipo sincrono, cioè nei casi in cui per proseguire con la
compilazione delle pratiche sia necessario pagare anticipatamente degli oneri, occorre gestire il
salvataggio della pratica prima del pagamento, per poter procedere successivamente nel caso il
pagamento non sia andato a buon fine.
• Al termine della compilazione della richiesta, nel caso di pagamento di oneri, deve essere proposto
all’utente un prospetto riepilogativo che contenga la lista degli oneri pagati, l’esito, l’id transazione, il
canale, la commissione applicata). Tale prospetto deve essere compreso nel PDF che viene inviato
all’Ente ed al richiedente.
L’Emilia Romagna si è dotata di una piattaforma di pagamenti regionale, chiamata Payer, che espone
interfacce applicative (API) per l’integrazione con servizi e sistemi che necessitino di funzionalità di
pagamento, mettendo a disposizione diversi payment gateway. L’integrazione con questo servizio
infrastrutturale consente ai servizi di Front end di poter essere arricchiti con le funzionalità di pagamento
online.
Qualora il servizio di front end preveda funzionalità di pagamento e nel caso in cui l’ente abbia aderito a
Payer, il servizio DOVRA’ richiamare i servizi di pagamento esposti dalla piattaforma Payer.
7.4 Firma elettronica della pratica
In questo paragrafo si forniscono delle linee guida sull’utilizzo delle varie tipologie di firma elettronica, in
relazione ai diversi livelli di autenticazione previsti da Federa (cfr. paragrafo 5.3.1).
Il Codice dell’Amministrazione Digitale (CAD) definisce le seguenti tipologie di firma:
• firma elettronica: insieme dei dati in forma elettronica, allegati oppure connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di identificazione informatica;
• firma elettronica avanzata: insieme di dati in forma elettronica allegati oppure connessi a un documento informatico che consentono l'identificazione del firmatario del documento e garantiscono la connessione univoca al firmatario, creati con mezzi sui quali il firmatario può conservare un
Linee guida per lo sviluppo di servizi di front end
30
controllo esclusivo, collegati ai dati ai quali detta firma si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati
• firma elettronica qualificata: un particolare tipo di firma elettronica avanzata che sia basata su un certificato qualificato e realizzata mediante un dispositivo sicuro per la creazione della firma;
• firma digitale: un particolare tipo di firma elettronica avanzata basata su un certificato qualificato e su un sistema di chiavi crittografiche, una pubblica e una privata, correlate tra loro, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l'integrità di un documento informatico o di un insieme di documenti informatici.
I livelli di autenticazione di Federa sono invece mappati sui livelli di affidabilità delle credenziali; l'affidabilità rappresenta il grado di attendibilità delle identità digitale e varia in base alla modalità con cui l'utente è identificato presso il proprio gestore delle Identità. All'interno dell'Identity Provider FedERa, l'affidabilità è distinta in tre livelli:
• Bassa (utenti non identificati): sono gli utenti che si registrano online presso il gestore delle identità. • Media (utenti identificati in maniera debole/indiretta tramite SIM/USIM): sono gli utenti che si
registrano online presso il gestore delle identità, inserendo e confermando il proprio numero di telefono cellulare.
• Alta: o Utenti identificati "de visu" da un operatore del gestore delle identità. o Utenti identificati tramite smart card CIE/CNS. o Utenti identificati tramite invio di documentazione.
Elencate le diverse tipologie di firma elettronica ed i diversi livelli di affidabilità delle credenziali Federa, prendendo a riferimento il CAD ed il successivo DPCM del 22 febbraio 2013, si può affermare che:
• Il livello alto di affidabilità delle credenziali Federa può sostituire la firma elettronica avanzata solo nel caso in cui il servizio di front end sia erogato dallo stesso ente che ha emesso le credenziali. Quindi un utente potrà utilizzare le proprie credenziali Federa di livello alto in luogo della firma elettronica avanzata, per un servizio di front end che ne richieda l’utilizzo, solo nel caso in cui il comune che eroghi il servizio ed il comune che ha emesso le credenziali coincidano.
• L’utilizzo di smart card CIE e CNS può sostituire la firma elettronica avanzata a condizione che l’invio dell’istanza preveda, oltre al documento, anche il token con cui l’utente si è autenticato (in luogo della firma elettronica)
• Per le istanze (ad es. SUAP) che richiedono obbligatoriamente l’utilizzo della firma digitale, l’utilizzo di credenziali Federa anche di livello alto non possono mai sostituire l’utilizzo della firma digitale stessa.
Da un punto di vista tecnologico, i meccanismi di firma elettronica attivabili sono due: firma on line e firma off
line: la differenza tra le due tipologie di firma consiste principalmente nel modo in cui l’utente interagisce con
la procedura di firma e nelle implicazioni tecnologiche che ne scaturiscono.
Linee guida per lo sviluppo di servizi di front end
31
• Firma on line: La firma on line prevede l’attivazione di un’applicazione client (es. applet Java) che viene installata
ed attivata sul computer dell’utente: tramite questa applicazione l’utente visualizza l’anteprima del
documento e procede alla firma dello stesso. Una volta conclusa la firma l’applicazione invia il
documento firmato al server.
L’applicazione di firma on line si interfaccia direttamente con l’hardware di firma (lettori USB,
chiavette USB) e con le smart card, sfruttando delle librerie generiche le quali a loro volta utilizzano
librerie specifiche dei lettori e delle smart card che devono essere presenti sul computer dell’utente.
• Firma off line: La firma off line prevede il download del documento da firmare ed il successivo caricamento del
documento firmato all’interno dell’istanza che si sta compilando. Al momento del download, viene
generato un hash del documento, che sarà successivamente confrontato con l’hash del documento
firmato e caricato.
La verifica del certificato di firma avviene tramite la lettura di un file XML in cui sono censite le regole
di parsing dei certificati stessi.
La firma off line non si interfaccia con nessun tipo di hardware di firma e nemmeno con le smart
card: l’utente firma il documento in autonomia con le stesse modalità con cui firma altre tipologie di
documenti, utilizzando quindi il client di firma che preferisce.
Dal momento che la firma online offre i seguenti vantaggi:
o non richiede nessuna configurazione particolare del client dell’utente
o consente la firma multipla dello stesso documento (necessaria nel caso siano necessarie le
firma di più professionisti, ad esempio)
o non richiede la contestualità di firma del documento rispetto al suo invio finale
o funziona su qualsiasi piattaforma (inclusi sistemi OSX)
si ritiene preferibile, in fase di realizzazione di un servizio di front end di istanza, la firma off-line rispetto alla
firma online.
Linee guida per lo sviluppo di servizi di front end
32
7.5 Invio della pratica all’Ente
Ogni servizio di istanza, al termine dei vari step in cui l’utente inserisce i dati relativi alla pratica, prevede
l’invio dell’istanza all’ente; tale invio può essere un:
• invio legale al protocollo dell’Ente (OBBLIGATORIO)
• invio di servizio al back office (OPZIONALE)
L’invio legale DEVE avvenire secondo una delle due seguenti modalità:
• Invio di una PEC al protocollo dell’Ente: in questo caso, la pratica insieme ai suoi allegati viene
inviata al protocollo del’Ente che deve ricevere la pratica. Per poter essere protocollata
automaticamente, la PEC deve recare le informazioni necessarie alla protocollazione (un esempio è
il file segnatura-cittadino.xml);
• Invio al protocollo dell’Ente tramite cooperazione applicativa: in questo caso, sfruttando il web
service di protocollazione esposto dalla piattaforma documentale Doc/er (cfr. paragrafo 5.4.1), il
servizio di front end invia l’istanza direttamente al protocollo dell’ente.
L’invio legale DEVE, inoltre, prevedere la restituzione di una ricevuta al richiedente, contenente il numero di
protocollo assegnato dall’Ente; la ricevuta PUÒ essere
• inviata tramite PEC al richiedente
• resa disponibile al richiedete in un’area riservata in modo che il richiedente stesso possa scaricarla.
Nel caso di invio di servizio, invece, il servizio di front end deve prevedere l’invocazione del web service
eventualmente esposto dal back office per la ricezione dell’istanza. Una volta ricevuta l’istanza, il back office
tipicamente provvederà a mantenere la stessa in un area di staging, a disposizione dell’utente di back office
per essere eventualmente completata o corretta, prima di essere inserita realmente nel back office.
Sarà possibile anche uno scenario in cui il servizio di front end depositerà l’istanza su di uno spazio
condiviso da più enti: saranno i back office dei vari enti che avranno il compito di andare a recuperare
l’istanza proveniente dal servizio di front end.
Dalle considerazioni sopra esposte, si evince che
• è il servizio di front end, non il back office, che DEVE occuparsi della protocollazione dell’istanza.
• back office PUÒ ricevere l’istanza come invio di servizio: tale integrazione è CONSIGLIATA perché
consente all’operatore di aprire l’istanza all’interno del proprio strumento di lavoro.
Linee guida per lo sviluppo di servizi di front end
33
8 IL CATALOGO DELLE ANAGRAFI CERTIFICANTI E DEI SERVIZI Il Modello di Amministrazione Digitale prevede la creazione di un catalogo di servizi di accesso alle anagrafi
certificate che avrà il compito di:
• creare un unico punto in cui raccogliere tutta la documentazione e le informazioni sui servizi
• consentire la ricerca dei servizi;
• diffondere l’utilizzo dei servizi.
Il catalogo dei servizi si pone quindi l’obiettivo di far conoscere alle Direzioni regionali e agli enti locali della
CNER ed alle altre PA eventualmente interessate, le anagrafi disponibili, i servizi di accesso alle anagrafi e
le modalità con le quali un’amministrazione può utilizzare i servizi.
Il catalogo favorirà il processo di integrazione tramite cooperazione applicativa tra i sistemi delle diverse
amministrazioni mettendo a disposizione in modo certificato ed unificato i metadati e la documentazione
ufficiale dei servizi che nel tempo si renderanno disponibili.
Per quanto riguarda li servizi di front end, DEVE essere compilata la scheda di metadati seguente:
Tipo di metadato richiesto Descrizione Caratteristiche
Nome del servizio * Indicare un nome che
identifichi in modo univoco il
servizio
Descrizione del servizio * Descrivere in modo sintetico
le prestazioni del servizio
Modalità di accesso al servizio *
Indicare quali sono le
modalità con le quali
un’Amministrazione può
richiedere l’accesso al
servizio. In caso di accesso
libero indicare l’URL o i
riferimenti tecnici per potervi
accedere
Canali di accesso al servizio *
Indicare se si tratta di una
web application, di una app o
di altro strumento di front
end
Linee guida per lo sviluppo di servizi di front end
34
Tipo di metadato richiesto Descrizione Caratteristiche
Tipo di servizio *
Indicare il tipo di servizio
selezionando fra uno dei
seguenti valori: visura (fornisce i dati di un entità
dell’anagrafe), istanza
(inoltra un’istanza ad un
sistema di un Ente), calcolo
(facilita il calcolo di un
dovuto ad un utente)
Disponibilità del servizio *
Indicare quale è il livello
minimo di disponibilità del
servizio garantito. E’
necessario indicare quando il
servizio è sicuramente
disponibile (es 24x24 - 7x7
oppure nei giorni feriali dalle
8 alle 20 oppure al meglio
della disponibilità dei sistemi)
Soggetto che ha in carico l’erogazione del servizio *
Indicare chi è il soggetto che
ha in carico l’erogazione del
servizio (Es: Lepida, SIIR,
SIA dell’Unione, CED del
comune di …)
Disponibilità del servizio di help desk *
Indicare se esiste un
servizio di help desk al quale
rivolgersi in caso di
necessità e come fare per
accedervi
Documentazione del servizio *
Indicare quale
documentazione del servizio
è disponibile e dove è
possibile reperirla
Numero di accessi previsti *
Indicare il numero di accessi
al servizio previsti nel corso
di un anno. Si conta un
accesso per ogni volta che
< 100
100 – 1.000
1.000 – 10.000
Linee guida per lo sviluppo di servizi di front end
35
Tipo di metadato richiesto Descrizione Caratteristiche
un utente accede al servizio 10.000 – 100.000
100.000 – 1.000.000
>1.000.000