Linee guida Servizi Front End v1.0 - Home | lepida.itlepida.it/sites/default/files/u8/MAD/Linee...

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


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


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


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


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)


7

2 Mappa dei documenti del MAD

Le linee guida si collocano all’interno della gerarchia dei documenti del Modello di Amministrazione Digitale.


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, ….


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.


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…)


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.


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)


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.


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.


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”.


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


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.


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;


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


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


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…).


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...).


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;


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.


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.


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.


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.


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.


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


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.


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.


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.


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


34


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


35


un utente accede al servizio 10.000 – 100.000

100.000 – 1.000.000

>1.000.000

Linee guida Servizi Front End v1.0 - Home | lepida.itlepida.it/sites/default/files/u8/MAD/Linee...

Documents

Transcript of Linee guida Servizi Front End v1.0 - Home | lepida.itlepida.it/sites/default/files/u8/MAD/Linee...