1

Progetto Eli_ComUni “Elisa Comunicazione Unica”

CAPITOLATO TECNICO

2

ART.1 – OGGETTO DELL’APPALTO L’appalto ha per oggetto la Fornitura di attività e servizi relativi alla realizzazione di quanto previsto nel progetto Eli_ComUni “Elisa Comunicazione Unica” , per quanto riguarda le attività di pertinenza della Provincia di Pescara. La realizzazione delle necessarie attività verrà meglio descritta negli articoli successivi.

ART.2 – CONTESTO

Il progetto “Eli_ComUni - Elisa Comunicazione Unica”, promosso da un partenariato di Enti Pubblici Abruzzesi e non, con capofila la Provincia di Pescara, si inserisce nel più ampio scenario nazionale della progettualità di e-government. Il progetto Eli_ComUni ha come obiettivo di contribuire a determinare una completa “de-certificazione” del rapporto tra la Pubblica Amministrazione ed il cittadino. Sembra essere un intento forte di semplificazione dell’azione amministrativa usufruendo delle possibilità che offrono Internet e le applicazioni telematiche per semplificare la vita ai cittadini e per un uso importante dell’ICT nel rapporto diretto tra i diversi livelli della P.A. . Infatti, l’eliminazione dei certificati richiesti dal cittadino ai Comuni per fornire i dati anagrafici ad un’altra amministrazione pubblica rappresenta in se una piccola rivoluzione rispetto a pratiche cartacee secolari. Il progetto Eli_ComUni cerca di soddisfare due bisogni fondamentali: da una parte, produrre e dispiegare nuovi servizi per via telematica per i cittadini e le imprese che riguardano l’anagrafe comunale, tenendo presente comunque i limiti dell’attuale normativa; dall’altra, facilitare la cooperazione applicativa e lo scambio di informazioni tra le diverse amministrazioni pubbliche per consolidare il processo di de-certificazione, risolvendo per via telematica il controllo delle “autocertificazioni” da parte dei cittadini presso l’amministrazione pubblica (la cui crescita è ormai esponenziale); Per questo motivo, oltre al pacchetto di servizi per i cittadini e le imprese , Eli_ComUni propone agli enti locali la cosiddetta “porta di dominio dei Comuni” per veicolare lo scambio di informazioni tra le diverse amministrazioni locali e con gli enti centrali e regionali. Per ciò che riguarda le attività assegnate alla Provincia di Pescara nell’ambito del progetto Eli_ComUni, queste riguardano l’attivazione di un centro servizi pilota, per dispiegare i suddetti servizi (descritti nel dettaglio negli allegati 1 e 2) in ambito provinciale, presso due comuni pilota.

ART.3 – DESCRIZIONE DELLA FORNITURA

Il progetto consterà nella realizzazione delle seguenti componenti:

infrastruttura di base per la Interoperabilità e la Cooperazione Applicativa interregionale secondo lo standard SPCoop (specifiche SPCoop Ver. 1.1 e successive) adottato nel progetto ICAR della Regione Abruzzo;

3

strumenti di Service Level Agreement a livello interregionale, tracciatura e monitoraggio dei servizi;

sistema di sicurezza della Cooperazione Applicativa: a) sistema Federato Interregionale di Autenticazione; b) infrastruttura di Sicurezza Intranet;

interoperabilità e cooperazione a livello applicativo secondo quanto previsto dai task di progetto.

ART.3.1 – COMPONENTE “PORTA DI DOMINIO” L’elemento tecnologico centrale per la cooperazione applicativa è rappresentato dalla Porta di Dominio. Da un punto di vista fisico, essa può essere considerata un componente infrastrutturale della Rete, un “proxy” per l’accesso alle risorse applicative. Dal punto di vista dell’architettura applicativa, la Porta di Dominio può essere vista come un adattatore che consente a sistemi informatici esistenti, o comunque realizzati in base alle esigenze del dominio specifico, di affacciarsi sulla rete e partecipare all’interscambio telematico delle informazioni. Nella figura successiva si evidenzia il modello di cooperazione applicativa, dove il termine “sistema informativo” deve essere inteso nella sua accezione più ampia.

In particolare, può trattarsi di: - un sistema monolitico o comunque operante su un singolo nodo presso una struttura di piccole dimensioni; - un sistema distribuito su più nodi collegati in rete locale presso una struttura di dimensioni maggiori; - una rete di area, alla quale sono collegati i sistemi informatici di strutture anche diverse, o di una singola struttura. Risulta, quindi, chiaro che le porte di dominio, come componenti software di adattamento, possono essere chiamate a svolgere funzioni di integrazione diverse, a seconda del contesto nel quale si trovano ad operare. In particolare possiamo distinguere: - la Porta Applicativa che è la Porta di Dominio atta all’erogazione dei servizi. Ogni dominio esportante, in grado cioè di erogare servizi, lo fa attraverso la Porta Applicativa. La Porta Applicativa ha un riferimento sull’Indice dei Servizi in corrispondenza di tutti i servizi che esporta

4

sia in modo diretto che indiretto. La Porta Applicativa è sempre in ascolto per accogliere le richieste fatte al dominio. Attraverso opportuni moduli denominati Wrapper, la Porta Applicativa interfaccia i sistemi informatici che sono alla base dell’erogazione di uno specifico servizio. - la Porta Delegata che e la Porta di Dominio attraverso cui si richiedono servizi o si notificano eventi ad un altro Dominio. La Porta Delegata è attivata dai Sistemi Informatici e sfrutta i servizi di Rete per realizzare la collaborazione. Le collaborazioni principali prevedono l’adozione di modalità sincrone e asincrone di scambio dei messaggi. E’ bene notare che le modalità sincrona e asincrona sono intese relativamente allo scambio di una coppia di messaggi, uno in andata e l’altro in ritorno. Il sincronismo è visto dal punto di vista della porta delegata. In uno scambio sincrono, la porta delegata, a seguito dell’invio del messaggio di andata, rimane in attesa del messaggio di ritorno. Viceversa, in uno scambio asincrono, i due messaggi di andata e di ritorno vengono scambiati senza che una delle due parti rimanga in attesa. La scelta della modalità sincrona o asincrona può anche dipendere da aspetti legati alla latenza amministrativa delle procedure amministrative (es.: la necessita di intervento umano, ad esempio per l’apposizione della firma digitale di un pubblico ufficiale). Tuttavia, in linea di principio, tale scelta può dipendere anche da scelte di carattere esclusivamente tecnologico, come dimostra l’ampia diffusione: - Collaborazione Sincrona: è quella più semplice e, tipicamente, è la modalità prevista per le richieste di informazioni. Presso il dominio richiedente, il messaggio è formato dal sistema informativo per poi essere trasmesso dalla porta delegata. La porta delegata rimane in attesa del messaggio di ritorno. Presso il dominio erogatore del servizio viene ricevuto ed immediatamente elaborato con la formazione e trasmissione del messaggio di ritorno. La collaborazione sincrona, una volta adottata, è da considerarsi come obbligatoria per le parti coinvolte. In altri termini, la porta applicativa deve restituire un messaggio di eccezione se l’elaborazione sincrona non è possibile, per esempio a causa di problemi tecnici temporanei. - Collaborazione Asincrona: una forma lievemente più complessa di collaborazione è quella basata sulla modalità sincrona con possibilità di transizione ad una modalità asincrona. La prima fase di collaborazione e sostanzialmente eguale a quella descritta nel caso precedente (collaborazione sincrona), con la formazione e la trasmissione di un messaggio presso il dominio richiedente. Anche in questo caso la porta delegata rimane in attesa del messaggio di ritorno. La differenza consiste nel fatto che il sistema esportante può eventualmente passare alla modalità asincrona, ad esempio per fare fronte a situazioni di carico eccessivo e/o di concomitanza con altre situazioni straordinarie. In caso di passaggio alla modalità asincrona, la porta applicativa si limita a restituire un messaggio di ritorno che conferma la ricezione del messaggio e attesta la presa in carico della richiesta in esso contenuta. In un tempo differito, successivo, la porta delegata, trasmette un messaggio con l’identificatore della richiesta e rimane in attesa del messaggio di ritorno. Se il sistema esportante ha la risposta, la restituisce e conclude la collaborazione, altrimenti risponde con un nulla di fatto e la transazione dovrà essere ripetuta. In generale, il servizio rappresenta la modalità più diretta di collaborazione tra due sistemi. Una richiesta, sottoposta da un sistema ad un altro, scatena in quest’ultimo l’esecuzione di un processo applicativo il cui risultato viene restituito sotto forma di risposta. Il servizio è tipicamente un tipo

5

di collaborazione sincrona ma è scomposto in due fasi differite nel tempo: sottomissione della richiesta e ricezione della risposta, può realizzare anche una collaborazione asincrona. Nei due casi, però, l’approccio dei sistemi informatici coinvolti nella collaborazione cambia sostanzialmente. Nel caso asincrono, chi effettua la richiesta deve essere in grado di iterare più volte il processo di richiesta, mentre il sistema che eroga il servizio deve essere in grado di gestire il sistema di code di richieste e di risposte. Caratteristica peculiare della Porta di Dominio (ICAR) da utilizzare è il rispetto delle specifiche SPCoop Ver. 1.1 a cui si aggiungono le funzionalità di: · tracciamento; · sicurezza. Di seguito sono illustrate le funzionalità sopra citate. ART.3.1.1 – FUNZIONI DI “TRACCIAMENTO” La Porta di Dominio SPCoop tiene traccia delle Buste e-Gov inviate e delle Buste e-Gov ricevute in transito.

Il tracciamento realizzato nell’Implementazione di riferimento si attiene a quanto definito nel documento “Sistema pubblico di cooperazione: Porta di Dominio” del CNIPA-DigitPA. Viene quindi tracciato solo l’header e-Gov insieme alle seguenti informazioni: · ora di registrazione · identificativo della porta di dominio · tipo di Messaggio (Richiesta/Risposta) ART.3.1.2 – FUNZIONI DI “SICUREZZA” La Porta di Dominio SPCoop implementa funzionalità di “firewall” in quanto è in grado di bloccare tutto il traffico in ingresso che non rispetta determinate regole.

6

Le regole del firewall avranno come oggetto l’header delle buste di e-Gov. Qualora una busta di e-Gov non rispetti le regole stabilite, la Porta di Dominio SPCoop ne terrà traccia. La Porta di Dominio SPCoop, come da specifica SPCoop, identifica tutti i soggetti infrastrutturali e applicativi in gioco tramite certificati X.509 rilasciati da PKI riconosciute e l’uso di WS-Security tramite X509 Token Profile e SAML 2.0, compatibilità con SAML 1.1, per la gestione di autenticazione e autorizzazione da parte delle Porte di Dominio. ART.3.2 – SERVICE LEVEL AGREEMENT E SISTEMA DI “TRACCIATURA E MONITORAGGIO” Le raccomandazioni reperibili dalla documentazione ICAR per quel che riguarda i componenti architetturali di pertinenza della “Gestione di Strumenti di Service Level Agreement a livello interregionale SPECIFICHE TECNICHE DEL SISTEMA (INF2_SPE)” si articolano lungo le seguenti tre linee di intervento: · specifica dei livelli di servizio negli accordi di servizio; · sistema di tracciatura; · sistema di monitoraggio. Il compito legato alla prima linea di intervento è, dunque, limitato all’individuazione del formalismo da utilizzare nella dichiarazione dei parametri SLA associati ai servizi applicativi cooperanti. La reference implementation prodotta come deliverable del progetto dovrà comprendere esempi di tracciatura e monitoraggio di parametri SLA. Questi esempi, elaborati anche secondo le indicazioni raccolte in ambito progettuale, dovranno prevedere parametri derivanti da metriche di risorsa “di base”, utili, cioè, a fondare un sistema di gestione SLA semplice ma significativo ed in grado di evolvere verso forme di monitoraggio più sofisticate a seconda delle necessità che si creeranno. ART.3.2.1 – SPECIFICA DEI LIVELLI DI SERVIZIO Tra i framework nati per gestire in modo formalizzato vari processi assimilabili allo SLA management sono stati oggetto di accurata indagine il WS-Agreement ed il WSLA – Web Services Level Agreement, entrambi in forma di “proposte” e dunque soggetti a evoluzione. Il framework in prima istanza scelto è stato WSLA. Alcune importanti caratteristiche lo rendevano preferibile: maggiore accuratezza nella definizione dei parametri SLA e i loro algoritmi di calcolo, assenza di strutture e interfacce dedicate alla contrattazione e alla stipula on-line degli accordi tra le parti, maggiore semplicita. Il CNIPA-DigitPA ha scelto di WS-Agreement come formalismo di definizione e di monitoraggio dei parametri SLA. Per quanto riguarda la definizione dei parametri SLA, sarà obiettivo del progetto non specificare dettagli delle metriche associate ai parametri stessi come, per esempio, dove e in che modo misurarle. La validità dei parametri SLA (“GuaranteeTerm”) è definita da asserzioni (“ServiceLevelObjective”) basate sulle metriche di riferimento. La definizione del formalismo di tali asserzioni è esplicitamente definita come estranea al framework, tuttavia è possibile utilizzare sia formalismi personalizzati (struttura “CustomServiceLevel”) sia metriche composte basate su metriche di risorsa personalizzate (struttura “KPITarget”).

7

<wsag:GuaranteeTerm Obligated=”wsag:ServiceRoleType”>

<wsag:ServiceScope ServiceName=”xs:string”>

xs:any

</wsag:ServiceScope>*

<wsag:QualifyingCondition>...</wsag:QualifyingCondition>?

<wsag:ServiceLevelObjective>...</wsag:ServiceLevelObjective>

<wsag:BusinessValueList>...</wsag:BusinessValueList>

</wsag:GuaranteeTerm>

... <wsag:ServiceLevelObjective>

<wsag:KPITarget> </wsag:KPITarget> |

<wsag:CustomServiceLevel> ... </wsag:CustomServiceLevel>

</wsag:ServiceLevelObjective> Il framework WSLA è molto più orientato alla specifica formale degli algoritmi che, partendo da metriche elementari, portano alla composizione di metriche composte e SLO; si può ipotizzare l’innesto di alcune parti ad esso ispirate all’interno del formalismo WS-Agreement. WS-Agreement prevede la negoziazione e la conclusione di accordi on-line. Una rilevante parte del formalismo XML proposto è dedicato alla definizione dell’elemento a struttura complessa “AgreementTemplate”. I soggetti che intendono usufruire di un servizio valuteranno le caratteristiche offerte all’interno di tale struttura e, eventualmente, sarà creato un elemento “Agreement” a immagine del template esaminato. Questa parte di formalismo non è utile agli scopi progettuali, dunque tutti gli elementi afferenti all’”AgreementTemplate” non saranno utilizzati. Un procedimento del genere è autorizzato dal framework, che prevede esplicitamente l’utilizzo indipendente di parti diverse della specifica e la creazione di accordi al di fuori dei meccanismi di negoziazione proposti. WS-Agreement non è solo una specifica di linguaggio XML, ma definisce anche protocolli, basati su interfacce astratte, per la creazione di accordi ed il monitoraggio degli stessi on-line. I web service di interrogazione delle metriche registrate e di verifica dei parametri SLA saranno disegnati rifacendosi alla logica del port type “wsag:AgreementState”, definito dal framework per l’indagine standardizzata degli stati di accordi, servizi e singolo parametro SLA. Nella definizione dei ServiceLevelObjective, l’approccio basato sui CustomServiceLevel consentirà massima liberta nell’utilizzo di costrutti logici e nel riferimento a variabili esterne. L’approccio KPI, a fronte di una maggiore schematizzazione, rende meno agile la costruzione di condizioni logiche complesse, a causa della presenza di “wsag:Target”, valore di soglia. La soddisfazione di una condizione, dunque, risulta sempre legata al raggiungimento, al superamento o al mancato superamento di tale valore. Pur essendo “wsag:Target” di tipo non definito, quindi utilizzabile a sua volta anche per accogliere espressioni complesse, la struttura di questo approccio risulta in ultima analisi un po’ troppo rigida per il particolare dominio di applicazione della porta di dominio. Sarà, quindi, definito un namespace esterno alla specifica “wsag” (“ICAR”), contenente i soli elementi di un linguaggio di asserzioni in grado di comporre elaborazioni aritmetiche e condizioni logiche complesse a valore booleano. Il contenuto degli elementi “wsag:CustomServiceLevel” sarà un’espressione complessa a valore booleano basata su predicati logici facenti riferimento a metriche composte e valori di soglia. Le metriche composte conterranno operatori definiti nel linguaggio e operandi, a loro volta eventualmente complessi, ma corrispondenti in ultima analisi a metriche di risorsa elementari. Queste ultime saranno identificate univocamente da un nome in linguaggio naturale, possibilmente esplicativo. Tale nome coinciderà con la relativa parte di chiave nel sistema di

8

tracciatura, permettendo di identificare una singola traccia all’interno del repository. Quando l’espressione complessa contenuta in un elemento “wsag:CustomServiceLevel” assumerà valore “true” il parametro SLA relativo sarà da considerare rispettato (“Fulfilled”). La definizione di parametri SLA relativi ad un servizio applicativo avverrà, dunque, a partire dall’individuazione di metriche di risorsa aventi attinenza col servizio applicativo medesimo e di algoritmi in grado di costruire, basandosi su tali metriche elementari, il valore complessivo del parametro, di conseguenza la rispondenza con quanto pattuito. Il completamento di questo processo logico di individuazione dei parametri SLA avrà una duplice ricaduta sulle attività a carico degli erogatori dei servizi applicativi: · le metriche di risorsa dovranno essere dichiarate come operandi terminali nella struttura dei “wsag:CustomServiceLevel” e costituiscono parte di chiave nel sistema di tracciatura; · gli algoritmi dovranno essere esplicitati, utilizzando il linguaggio di asserzioni, nella struttura interna ai “wsag:CustomServiceLevel” e, in tale modo, guidano la realizzazione ed il funzionamento dei web services previsti nel sistema di monitoraggio. Nell’elaborare un linguaggio adatto all’ambito applicativo della cooperazione applicativa, si è partiti dal sottoinsieme WSLA di cui sopra, mantenendo alcuni costrutti originali ma approdando, però, ad una specifica formale del tutto autonoma. Una delle modifiche più significative consiste nell’introduzione di un nuovo elemento “BasicMetric”, destinato a rappresentare le metriche di risorsa. In WSLA gli elementi relativi a metriche di base contenevano generalmente un identificativo URI mediante il quale interrogare le misure residenti presso i domini cooperanti. Invece, le misurazioni delle metriche di risorsa vengono man mano depositate nel repository di tracciatura, e dunque e sufficiente dotare le metriche di risorsa solo di identificativo univoco per reperirle in fase di monitoraggio nel repository stesso. ART.3.2.2 – SISTEMA DI “TRACCIATURA” Nella prima iterazione del progetto solo i servizi applicativi erogatori tracceranno le metriche relative ai parametri SLA da loro stessi dichiarati nell’accordo di servizio. Al termine di tale prima iterazione progettuale si valuteranno i responsi forniti secondo questo approccio, con la possibilità di ampliare le funzionalità di tracciatura, estendendole ai servizi fruitori ed eventualmente integrandole con le tracciature delle PdD. La realizzazione del repository delle tracciature applicative costituirà parte integrante della reference implementation prevista, con particolare riferimento a: · interfaccia di scrittura delle metriche di risorsa; · identificazione univoca delle tracce memorizzate; · interfaccia di monitoraggio dei parametri SLA. Individuata la natura dei dati oggetto di memorizzazione, occorrerà stabilire le caratteristiche del sistema di tracciatura che provvederà alla loro registrazione, la dislocazione ed il tracciato del repository ad essi dedicato e le caratteristiche del sistema di monitoraggio dei parametri SLA dichiarati negli accordi di servizio. Il progetto del repository delle tracciature dovrà tenere conto di due esigenze primarie: · l’individuazione dell’episodio di cooperazione applicativa cui si riferisce la misura da registrare · l’identificazione della misura medesima.

9

La singola tracciatura memorizzata dovrà contenere riferimenti a: · parte specifica dell’accordo di servizio (che contiene riferimento alla parte comune); · fruitore ed erogatore del servizio; · servizio; · singola interazione fruitore-erogatore (per correlare metriche di risorsa diverse relative al medesimo episodio). Sarà di tipo “data e ora dell’inizio elaborazione”, in modo da poter definire eventuali finestre temporali; · misura di metrica di risorsa elementare. Gli identificativi di queste misure corrisponderanno a quanto specificato, a seconda dell’approccio scelto, nella definizione di /wsag:KPITarget o nell’espressione complessa riportata in /wsag:ServiceLevelObjective/wsag:CustomServiceLevel. Entrambe queste tipologie di definizione non fanno parte della specifica WS-Agreement. La metrica di risorsa rilevata associata all’identificativo complesso, individuato sulla base delle indicazioni di cui sopra, costituirà il dato elementare da utilizzare secondo le regole di composizione di espressione complessa (approccio KPI) o l’espressione assertiva (approccio CustomServiceLevel) specificate nell’accordo di servizio. Le interfacce che dovranno essere messe a disposizione dal sistema di tracciatura consentiranno la registrazione delle singole misure di ogni metrica di risorsa prevista nell’accordo di servizio, fornendo la chiave necessaria per l’univoca identificazione dell’episodio di cooperazione applicativa di riferimento e della misura medesima. ART.3.2.3 – SISTEMA DI “MONITORAGGIO” Questo sistema sarà costituito da un’interfaccia esposta come repertorio di web services compatibili SPCoop, dunque a regime sarà dotato, a sua volta, di Accordo di Servizio per il monitoraggio dei parametri SLA basati sulle tracciature depositate nel repository di cui sopra. Come già osservato, WS-Agreement definisce anche protocolli, basati su interfacce astratte, per il monitoraggio on-line degli accordi di servizio. In particolare, l’implementazione dell’interfaccia di monitoraggio sarà realizzata ispirandosi alla medesima logica definita dal port type “wsag:AgreementState” fornite nel framework. Tale port type, mediante la definizione di una struttura basata su “Resource Properties”, consente l’interrogazione dello stato degli elementi “Agreement”, “ServiceTerm” e “GuaranteeTerm”. Le verifiche sugli “Agreement” (accordo nel suo complesso) sono di scarso interesse a causa della stipula off-line degli accordi stessi. Dunque un’interrogazione sui parametri che corrispondono a quanto WS-Agreement definisce come “resource property wsag:AgreementState” potrebbe solo restituire invariabilmente il valore “Observed”, corrispondente al significato di accordo siglato ed in funzione. Il monitoraggio sui parametri che corrispondono a quanto WS-Agreement definisce “ServiceTerm” (nella nostra accezione si tratta di un servizio) e “GuaranteeTerm” (singolo parametro SLA) realizza invece lo scopo del nostro intervento e sarà in grado di restituire i seguenti valori:

- per i servizi (“ServiceTerm”): · Not ready – servizio non utilizzabile; · Ready – servizio pronto per l’esecuzione; · Processing – servizio in esecuzione che sta processando una richiesta;

10

· Idle – servizio in esecuzione e in attesa; · Completed – esecuzione terminata e non più utilizzabile;

- per i parametri SLA (“GuaranteeTerm”): · Fulfilled – parametro SLA soddisfatto; · Violated – parametro SLA violato; · NotDetermined – l’attività effettuata non consente di valutare il parametro SLA.

ART.3.3 – SISTEMA DI SICUREZZA DELLA COOPERAZIONE APPLICATIVA Il tema della sicurezza in un‘architettura di cooperazione applicativa, ancora più che in architetture applicative classiche, costituirà un elemento caratterizzante, trattando transazioni che attraversano domini applicativi afferenti a differenti Amministrazioni. Un tale ambiente esporrà i limiti e la fragilità della sicurezza delle infrastrutture cooperanti. D’altro canto, la cooperazione applicativa e, in generale, l’approccio a servizi, tenderà a risolvere l’esigenza di flessibilità e veloce riconfigurabilità in seguito al cambiamento di organizzazioni, regolamenti e normative. Sarà necessario, quindi, realizzare un sistema di sicurezza dell‘infrastruttura di cooperazione al quale dovrà essere demandata la fornitura di servizi di sicurezza, evitando, quindi, che ogni singola applicazione debba gestire anche soltanto una parte di una catena di sicurezza. In una tale tipologia di architettura, i servizi di sicurezza che sarà necessario fornire sono: · la propagazione, trasformazione (mapping) e gestione (provisioning) delle identità; · l’autorizzazione all’accesso alle applicazioni. Nel seguito si descrivono, quindi, le componenti che compongono tale sistema dei servizi di sicurezza. ART.3.3.1 – SISTEMA DI GESTIONE DELLE IDENTITA’ FEDERATE Sarà necessario affiancare all‘infrastruttura di cooperazione anche una infrastruttura per la gestione della propagazione delle identità attraverso i differenti servizi. A tale complessità, si dovrà tenere in considerazione che tale sistema federato di autenticazione si baserà su standard sulla propagazione delle asserzioni di identità che sono ancora in via di maturazione. Di seguito si effettuerà una puntuale disanima dei vari aspetti che portano al posizionamento di tale sistema in architettura. In estrema sintesi, nella figura seguente sarà descritta la relazione di trust che si viene a stabilire tra le amministrazioni cooperanti e la trasformazione delle asserzioni di identità all’interno di un dominio amministrativo in token SAML 2.0. Il passaggio attraverso il token SAML determinerà la necessità della presenza, all’interno di ogni Amministrazione cooperante, di un modulo che generi tale token di sicurezza (nel caso di richiesta del servizio) o lo controlli (nel caso di erogazione del servizio richiesto).

11

Nel caso di generazione del token il flusso sarà quello riportato nella figura seguente, dove sarà possibile apprezzare anche il meccanismo di propagazione e mapping dell’identità.

Il servizio di gestione dei token di sicurezza si completerà nel sistema federato di autenticazione anche in base ad accordi di servizio tra gli attori in gioco. Il modello concettuale di riferimento del sistema federato interregionale di autenticazione potrà essere riassunto in uno scenario tipico di una community network (per esempio una rete regionale) cui afferiscono più domini in grado di offrire diversi servizi applicativi agli utenti finali. I servizi appartenenti ad un dominio potranno essere resi disponibili ad altri domini grazie ad opportuni meccanismi di supporto alla federazione. Fattore abilitante per lo scenario descritto sarà la disponibilità di un sistema federato di autenticazione che supporti le politiche di sicurezza relative all’invocazione e alla fruizione dei servizi applicativi. Riassumendo brevemente i principali contributi alla definizione del sistema federato di autenticazione, si può iniziare ricordando la definizione del concetto di dominio informatico e la sua declinazione nelle diverse tipologie di domini riconoscibili in uno scenario di interazione a livello di community network: un dominio rappresenta il sistema informativo di un’Amministrazione, intesa in senso lato, e in particolare definisce il perimetro di sicurezza

12

informatica di responsabilità di tale Amministrazione. Il modello concettuale prevede quattro tipi distinti di domini: · di profilazione: è il dominio in cui è stata eseguita la procedura di riconoscimento iniziale di un determinato utente, durante la quale gli è stato richiesto di fornire alcune informazioni (attributi) che vengono poi memorizzate e archiviate in un’apposita struttura dati (il profilo utente); · fruitore: è il dominio in cui ha origine la richiesta che da luogo a un’interazione di accesso a un servizio offerto da un fornitore di servizi; · erogatore: è il dominio in cui è presente il fornitore del servizio a cui l’utente intende accedere; · certificatore: è il dominio in cui sono presenti uno o più soggetti (detti authority) in grado di certificare l’identità dell’utente cosi come il valore di uno o più attributi contenuti nel profilo utente. In particolare, il modello concettuale prevede i seguenti tipi di certificatori:

· Certification Authority: è l’entità abilitata a certificare l’identità di un utente. Il Certificatore di identità deve essere in grado di identificare l’utente e, come tale, deve gestire un database degli utenti e riconoscere le informazioni necessarie alla loro autenticazione. E’ possibile che un soggetto funga da Certificatore di identità per gli utenti che ha in carico. Molto più spesso il Certificatore di identità è un’entità specifica indipendente che possiamo vedere associata ad una CA. Un caso particolare è l’autoasserzione di identità, in questo caso l’utente è Certificatore di se stesso; · Attribute Authority: è l’entità abilitata a certificare alcuni degli attributi contenuti nel profilo utente. La definizione di Certificatore di attributo è estremamente flessibile. Un Certificatore di attributo associa delle informazioni, attributi per l’appunto, ad un’identità. Un Certificatore di attributo è abilitato a certificare solo gli attributi previsti dall’asserzione di Certificatore rilasciata dal CDC (Coordinatore del Dominio di Cooperazione); · Profile Authority: è l’entità incaricata della gestione dei profili utente presenti nei domini di profilazione. Di massima il Certificatore di autorizzazione è interno al DSA (Dominio dei Servizi Applicativi). Questo perchè la gestione dei diritti d’acceso ai servizi è di norma un aspetto interno. Può, pero, sussistere il caso in cui il Certificatore di autorizzazione sia esterno al DSA nel qual caso varranno per lui le stesse indicazioni previste per il Certificatore di attributo.

Oltre ai certificatori, nei domini possono agire altre entità, anzitutto gli utenti stessi che accedono ai servizi, che nella realtà sono, però, sempre mediati, quindi rappresentati da opportuni dispositivi chiamati User Agent (per esempio un comune browser web). Inoltre, per rendere possibile l’interazione di accesso ai servizi sono ovviamente necessari i fornitori di tali servizi, detti Service Provider. E’ da notare che, poichè anche i Service Provider possono comportarsi da fruitori di servizi quando interagiscono con altri provider in cooperazione applicativa, essi possono essere globalmente considerati dei Service Requestor, categoria a cui appartengono di diritto anche gli utenti con i loro User Agent. A supporto del sistema federato sono poi state introdotte e modellate altre entità quali l’Access Manager (o Local Proxy), che ha il compito di accedere alle varie authority o di mettere in contatto l’utente con esse per ottenere certificazioni di identità o di attributo, ed il Gestore delle Politiche di Autorizzazione, incaricato di verificare che gli attributi certificati e ottenuti dal Local Proxy rispondano ai requisiti di accesso imposti dal fornitore del servizio (e opportunamente memorizzati in un profilo del servizio) per consentire o negare l’accesso all’utente. Ciascuna delle entità elencate finora offre o richiede agli altri elementi del modello opportune interfacce che rendano possibile l’interazione e ne caratterizzino la natura e le funzionalità di base.

13

A valle di tale analisi è possibile procedere alla descrizione e alla definizione dei due principali scenari di riferimento per il sistema federato di autenticazione, vale a dire: · accesso di un utente a un servizio tramite web browser; · cooperazione applicativa tra servizi nell’ambito dell’erogazione di un servizio ad un utente. La descrizione di questi due ha comportato la necessità di descrivere ad alto livello il modello dei dati a supporto della gestione federata delle identità degli utenti (per esempio il profilo utente e le asserzioni). Come si evince da questo pur sintetico richiamo, nella modellazione concettuale si è considerato un contesto il più possibile esaustivo e rappresentativo di un sistema federato di autenticazione. La modellazione architetturale si dovrà occupare in particolare di: · consolidare l’architettura di alto livello del sistema federato di autenticazione; · definire l’architettura delle entità cardine del sistema federato di autenticazione, cioè il Local Proxy, la Profile Authority e l’Authority Registry; · definire il modello dei dati adottato dalle entità descritte al punto precedente ed i protocolli di comunicazione adoperati nelle interazioni con gli altri componenti del sistema, in particolare:

· le tipologie di asserzioni scambiate (che includono statement di identità e di attributo) e i relativi protocolli di richiesta e risposta; · le modalità di interazione tra il Service Provider ed il Local Proxy; · la struttura del profilo utente gestito dalla Profile Authority; · il protocollo di interrogazione della Profile Authority; · il protocollo di interrogazione dell’Authority Registry.

· descrivere in dettaglio le interazioni nei seguenti scenari di riferimento, già identificati nel documento di modellazione concettuale:

· accesso dell’utente via web browser ad un servizio offerto da un Service Provider; · fruizione in cooperazione applicativa da parte di un Service Provider di un servizio offerto da un altro Service Provider appartenente a un dominio differente, a seguito di una richiesta utente.

14

Di seguito saranno illustrate alcune delle tecnologie che si ritengono più utili per supportare la realizzazione degli scenari individuati, nell’ambito del sistema federato di autenticazione e autorizzazione. Astraendo, come detto, dai dettagli tecnologici alla base della comunicazione a basso livello tra interfacce quali le porte di dominio, ci si concentra sullo scambio dei token di sicurezza, ovvero delle asserzioni di autenticazione, attributo e autorizzazione, necessarie per abilitare gli utenti alla fruizione dei servizi nei vari domini a disposizione. Come già menzionato nelle sezioni precedenti, verrà utilizzato il linguaggio SAML ver. 2.0 per la codifica e il trasferimento delle asserzioni. Si farà ricorso invece allo standard XACML ver. 3.0 per formalizzare le policy di autorizzazione adottate presso i vari SP. ART.3.3.2 – SAML La notazione SAML, creata nel 2002 dall’ente di standardizzazione OASIS, consiste in un framework basato su XML e indipendente dai vendor, per lo scambio di informazioni di sicurezza, dette “asserzioni”, tra business partner via Internet. SAML è stato pensato per consentire molta di quella interoperabilità che si è dimostrata assolutamente necessaria tra i prodotti di sicurezza e i sistemi di gestione degli accessi sicuri ai siti Web. Lo scopo di SAML è realizzare un framework unificato che sia in grado di trasmettere le informazioni di sicurezza dell'utente che interagisce con un sistema, in modo da realizzare una lingua franca delle credenziali di sicurezza che permetta di scambiare informazioni senza modificare i sistemi di sicurezza esistenti. SAML è stato progettato per funzionare sui meccanismi di trasporto più comuni, come HTTP, SMTP, FTP e alcuni framework XML, come SOAP ed ebXML. Fornisce un metodo standard per definire l'autenticazione dell'utente, le autorizzazioni e gli attributi all'interno di un documento XML. Gli attori previsti dalla specifica della notazione sono entità che emettono asserzioni, dette “asserting party” e altre entità che le richiedono e ne fanno uso per gli scopi di autenticazione e autorizzazione, dette “relying party”, di fatto, gli asserting party coincidono con i certificatori di identità e attributo, mentre i relying party sono le entità che li interrogano, come il Local Proxy dello scenario di riferimento. Le componenti principali della notazione SAML sono le seguenti: · Asserzioni: Presenti in tre tipi diversi, sono dichiarazioni di fatti riguardanti l'utente, sia esso una persona fisica o un sistema hardware/software. Le asserzioni di autenticazione richiedono che un utente provi la propria identità. Le asserzioni di attributo (attribute assertion) contengono i dettagli specifici dell'utente, come il ruolo assunto in un’organizzazione. I permessi (authorization decision statements) identificano, invece, quali operazioni un utente può compiere (per esempio l’accesso ad una data pagina di un servizio). · Protocolli: Definiscono come si richiedono e ricevono le asserzioni contattando un asserting party; sono costituiti da successioni di SAML request e SAML response, a loro volta in formato di messaggi XML. Le request comprendono dati sui soggetti dei quali viene richiesta una asserzione, mentre nelle response sono presenti le asserzioni richieste. · Binding: Forniscono i dettagli esatti su come i vari protocolli definiti possono essere mappati nei protocolli di trasporto, come SOAP su HTTP. · Profili: Corrispondono ad un certo numero di scenari d’uso, nei quali è definito come le asserzioni, i protocolli e i binding vengono utilizzati in modo combinato per raggiungere gli scopi

15

per i quali tali scenari sono stati pensati. Esempi di profili sono quello per effettuare il single sign-on tra vari servizi cross-dominio, quello per identificare l’asserting party usato da un certo soggetto e uno per formulare query di asserzioni utilizzando un binding sincrono come SOAP. La notazione SAML, in se, non autentica o autorizza gli utenti. Essa è il mezzo con il quale le varie entità citate, chiamate anche authentication/authorization server, rilasciano attestati comprovanti certe caratteristiche di taluni soggetti. In questo senso, i certificatori esterni all’infrastruttura e con essa interagenti mediante cooperazione applicativa vengono ad essere degli authorization server, in quanto ricevono richieste di asserzioni di attributo ove gli attributi in questione corrispondono ai ruoli degli utenti, che devono essere certificati. Uno schema d’uso di SAML per il sistema di autorizzazione e autenticazione federata in cui vengono descritte le entità coinvolte per la certificazione delle credenziali è il seguente:

ART.3.3.3 – XACML

Lo standard XACML (eXtensible Access Control Markup Language) è uno standard, basato su XML, definito dal consorzio OASIS, avente lo scopo di definire la sintassi e la semantica di un linguaggio per esprimere e valutare politiche di controllo di accesso. Tra i principali linguaggi esistenti per la definizione di politiche di controllo di accesso, XACML si distingue per il fatto di essere stato definito come standard, versatile all’impiego in svariati campi applicativi e non è invece legato, come spesso accade per altre soluzioni, ad uno specifico contesto. Il linguaggio XACML definisce, come SAML, un protocollo di richiesta/risposta, ove le richieste indicano la volontà di accedere a particolari risorse (es. servizi). Le risposte comunicano la decisione presa, che può essere di permesso, diniego o rimanere indeterminata. Gli elementi costituenti del linguaggio XACML sono i seguenti: · Policy: sono le politiche di accesso viste come insiemi di regole (rule) e algoritmi per la combinazione di regole. Lo scopo di questi ultimi discende dal fatto che, dal momento che una politica potrebbe contenere più regole, le quali potrebbero sortire decisioni diverse e contrastanti, è necessario riconciliare queste differenze nei risultati e produrre un’unica decisione finale.

16

Esempi di algoritmi sono quello per cui se esiste nella politica anche soltanto una regola che vieta l’accesso, allora la decisione globale è di divieto. · Target: è un insieme di condizioni su alcuni elementi, quali il soggetto a cui si applica la policy di cui il target è parte, la risorsa richiesta ed un’azione richiesta su tale risorsa, da parte del soggetto indicato. Tali condizioni servono per consentire di stabilire un legame tra una certa politica e una data richiesta di accesso. Se tutte le condizioni di un certo target sono soddisfatte, allora viene applicata la rispettiva regola che decide sull’accesso alla risorsa. · Rule: sono le regole elementari contenute nelle politiche, definite come insieme di un target, un effetto (o decisione) e una condizione. Se la condizione è soddisfatta, viene restituita la decisione (permesso o divieto) di accesso alla risorsa indicata. · Policy set: è un insieme di politiche unitamente a un algoritmo di combinazione delle decisioni prodotte dalle politiche. Ad un livello superiore viene ripetuto ciò che accade per le regole all’interno di una policy. L’algoritmo di combinazione serve per conciliare differenti risultati di diverse politiche di accesso relative alla stessa risorsa. Oltre a tali concetti, XACML fa uso di mattoni elementari per effettuare le sue valutazioni sulle politiche, che sono attributi e valori in cui memorizzare i dati relativi ai soggetti richiedenti, alle risorse ecc., oltre ad alcune funzioni di calcolo e combinazione. Tutti gli elementi sopraindicati concorrono alla definizione delle politiche di accesso secondo una sintassi XML definita mediante opportuni schemi nell’ambito dello standard. La specifica XACML definisce inoltre alcuni ruoli standard, nel processo di enforcement delle politiche di accesso, necessari per l’attuazione dello stesso: i principali sono il “Policy Enforcement Point” (PEP) e il “Policy Decision Point” (PDP). Il primo riceve le richieste di accesso alle risorse protette e si preoccupa anzitutto di recuperare tutte le informazioni relative agli attributi e ruoli dei soggetti che richiedono l’accesso. Queste ultime informazioni possono essere trasferite direttamente come asserzioni SAML utilizzando uno dei profili definiti per tale standard. Lo scenario di autorizzazione, sulla base delle politiche definite in XACML, è descritto dal diagramma di collaborazione UML sottostante.

Una volta che il PEP è in possesso della richiesta e dell’insieme di asserzioni (portafoglio) utile a prendere una decisione sui diritti di accesso del richiedente, eventualmente accedendo anche ad altri tipi di informazioni addizionali, esso passa il controllo al PDP che si incarica di prendere tale decisione. Il PDP accede alla definizione delle politiche di controllo di accesso relative alla risorsa

17

richiesta e le valuta rispetto alle asserzioni pervenute. Infine informa il PEP della decisione presa, in modo tale che quest’ultimo consenta o neghi l’accesso al richiedente. Si intuisce come la collettività dei soggetti che operano nell’ambito del Dominio di Cooperazione vanno a costituire una Comunità di soggetti con specifici ruoli e responsabilità. La comunità si struttura in domini di responsabilità che coincidono di fatto con Enti ed Amministrazioni. All’interno di questi domini è possibile distinguere diverse attività e processi che richiedono un modello organizzativo di riferimento. L’accreditamento di un utente, di un dominio, di un Certificatore sono i processi che richiedono una precisa regolamentazione. Il presupposto di questo modello organizzativo è che l’utente non sia noto al dominio erogatore del servizio, questi valuterà le proprie politiche d’accesso sulla base delle attestazioni di identità e di attributo fornite dall’utente. Le attestazioni in oggetto avranno la validità conferitagli dal loro sottoscrittore. Tutto il “circle of trust” si sostiene sul certificato del Coordinatore del Dominio di Cooperazione (CDC). Ciò che è sottoscritto con questo certificato ha per tutti gli aderenti alla comunità validità certa. Al pari del CDC possono essere considerate le Certification Authority (CA) qualificate ma, al momento, solo per le asserzioni di identità la partecipazione alla comunità (come dominio erogatore o fruitore) così come la qualifica di dominio Certificatore, con la tipologia di attributi asseribili, può essere attestata esclusivamente dal CDC. Per altro un dominio può partecipare a più comunità contemporaneamente riconoscendo i rispettivi CDC. Di fatto il modello organizzativo del Sistema Federato di Autenticazione copre molti degli aspetti trattati da SPCoop e definisce specifici soggetti, ruoli, servizi, processi e funzioni per i quali deve essere trovata una corretta collocazione. Riprendendo i principi generali da SPCoop: · il modello di cooperazione applicativa supporta una modalità di erogazione del servizio organizzata per adempimenti e procedimenti che derivano da dettati normativi o da compiti istituzionali; · il modello di cooperazione applicativa è paritetico fra tutti i soggetti cooperanti; · il modello di cooperazione è indipendente dagli assetti organizzativi dei soggetti cooperanti; · ciascun soggetto cooperante ha la responsabilità dei servizi erogati e dei dati forniti; · ciascun soggetto è autonomo nella gestione dei propri sistemi e nella definizione ed attuazione delle politiche di sicurezza del proprio sistema informativo; · ciascun soggetto è responsabile delle autorizzazioni per l’accesso ai propri dati e/o servizi; · ciascun soggetto risponde della mancata applicazione degli accordi di servizio stipulati. Il modello di funzionamento organizzativo del SFA (Sistema Federato di Autenticazione) ha per oggetto gli stessi concetti del SPCoop ed in particolare: · Servizi

· servizi applicativi e accordi di servizio · Soggetti

· Pubbliche Amministrazioni · Imprese singole o in forma associata · Soggetti Privati

· Processi · Monitoraggio e Controllo:

· Controllo del rispetto delle regole, inclusa la verifica dei livelli di servizio · Gestione reclami e controversie

18

· Gestione Dominio Servizi Applicativi (DSA): · Definizione e predisposizione componenti di base del DSA · Registrazione/Aggiornamento/chiusura del DSA (comprende la qualificazione dei soggetti)

· Gestione Dominio di Cooperazione (DC): · Costituzione del DC (definizione dell’accordo istitutivo, della tipologia di amministrazione che possono/devono partecipare al dominio e dei procedimenti coinvolti) · Definizione dell’accordo di cooperazione (inclusa la scelta del fornitore dei servizi o in alternativa predisposizione dei servizi per il Dominio di Cooperazione) · Registrazione del DC e dei servizi erogati · Adesione ad DC

· Erogazione dei servizi applicativi: · Erogazione dei servizi applicativi · Gestione delle autorizzazioni individuali e delle politiche di accesso ai servizi · Verifica dell’autorizzazione all’erogazione di servizi applicativi

· Fruizione dei servizi applicativi · Certificazione dell’identità:

· Gestione degli utenti · Gestione credenziali · Riconoscimento dell’utente · Rilascio asserzione d’identità per l’utente

· Certificazione degli attributi: · Gestione degli utenti · Gestione attributi dell’utente · Identificazione del richiedente · Rilascio asserzioni di attributo per l’utente

· Autorizzazione: · Registrazione dei servizi · Gestione delle politiche di accesso · Identificazione del richiedente · Rilascio asserzioni di autorizzazione

Il modello organizzativo ha, inoltre, come oggetto gli obiettivi descritti nei successivi paragrafi e relativi alla sicurezza, alla privacy ed alle asserzioni afferenti al modello descritto. ART.3.3.3.1 – SICUREZZA E PRIVACY Il Coordinatore del Dominio di Cooperazione (CDC), relativamente alla sicurezza, svolge il compito di amministratore e gestore dei meccanismi primari. Quella del CDC è ad esempio l’unica credenziale che deve essere riconosciuta da tutti i sistemi. Sarà del CDC la firma sull’asserzione di porta che abilita il soggetto ad interfacciarsi al resto della comunità. Sempre del CDC sarà la firma delle asserzioni dei certificatori che abilita i certificatori al rilascio delle rispettive asserzioni. Il responsabile del DC deciderà la validità temporale di queste asserzioni e avrà il compito di generare via via le nuove in tempo utile per la sostituzione. La diffusione di queste asserzioni dovrà essere garantita attraverso un Directory Server pubblicamente accessibile.

19

Il sistema così come è stato concepito consente la massima apertura e coinvolgimento di soggetti specialmente in qualità di semplici fruitori. Qui è, però, necessario un distinguo tra il Dominio fruitore ed il fruitore inteso come singolo individuo. Mentre il soggetto Dominio fruitore deve poter acclarare il suo diritto a partecipare al Dominio di Cooperazione, il singolo individuo deve semplicemente essere in grado di acclarare la sua identità attraverso le credenziali rilasciate da un Certificatore riconosciuto valido all’interno del Dominio di cooperazione stesso. Il responsabile di un Dominio di Erogazione risponderà del servizio offerto dal suo dominio. In questo rientra il rispetto degli accordi di servizio e la responsabilità dei processi interni al dominio alla base dell’erogazione dei singoli servizi. La responsabilità dello specifico servizio può invece essere assunta da un soggetto diverso (ad esempio il responsabile di uno specifico settore amministrativo) attraverso meccanismi che sono, però, propri del livello applicativo.

ART.3.3.3.2 – ASSERZIONE DI DOMINIO

L’asserzione di dominio abilita il Dominio a far parte del Dominio di Cooperazione. Questa Asserzione viene rilasciata dal CDC al termine dell’iter di accettazione e verifica della richiesta di adesione. Il CDC fissa la validità temporale di queste asserzioni e provvede alla loro riemissione in tempo utile per la loro distribuzione. La distribuzione avviene attraverso pubblicazione su un directory server accessibile a tutti i soggetti della comunità. Tutte la asserzioni hanno una data di emissione ed una data di scadenza. Alcune asserzioni devono essere messe a disposizione di tutta la comunità e per questo dovranno essere pubblicate su un directory server gestito dal CDC. ART.3.3.3.3 – ASSERZIONE DI CERTIFICATORE Questo è un particolare tipo di asserzione d’attributo. Ad ogni soggetto Certificatore abilitato il CDC rilascia un’Asserzione firmata con un range temporale di validità. Questa Asserzione, attraverso il certificato di firma, legittima il Certificatore nei confronti degli altri soggetti per il rilascio di Asserzioni. Ogni Asserzione di Certificatore deve contenere anche la tipologia di Certificatore. Uno stesso soggetto può assumere più ruoli di Certificatore. L’Asserzione di Certificatore rilasciata ai Certificatori di Attributo reca anche l’elenco degli attributi “asseribili”. Questa Asserzione viene rilasciata dal CDC al termine dell’iter di accettazione e verifica della richiesta di adesione. Il CDC fissa la validità temporale di queste asserzioni e provvede alla loro riemissione in tempo utile per la loro distribuzione. La distribuzione avviene attraverso pubblicazione su un directory server accessibile a tutti i soggetti della comunità. ART.3.3.3.4 – ASSERZIONE DI IDENTITA’ L’asserzione di identità può essere rilasciata dal Certificatore d’identità: questi deve essere in grado di identificare l’utente in modo da certificarne il codice identificativo personale (CF) e la modalità di autenticazione utilizzata. Queste informazioni costituiscono il contenuto del Certificato

20

di identità sottoscritto dal Certificatore. Questa Asserzione viene rilasciata dal CDC al termine dell’iter di accettazione e verifica della richiesta di adesione. L’asserzione di identità è l’asserzione senza dubbio più importante. A partire infatti dall’asserzione di identità vengono poi rilasciate le asserzioni di attributo e, soprattutto, viene identificato univocamente il richiedente. Mentre, per le altre asserzioni, la validità è un concetto molto semplice e legato alla validità del contenuto stesso dell’asserzione, per l’asserzione di identità non è proprio cosi. L’asserzione di identità testimonia che in un dato momento il richiedente è stato riconosciuto, informazione, questa, spendibile solo se legata ad un’altra richiesta. Dunque l’asserzione di identità ha senso solo se legata in modo indissolubile, attraverso una firma digitale di porta, ad una richiesta di servizio. ART.3.3.3.5 – ASSERZIONE DI ATTRIBUTO L’asserzione di attributo può essere rilasciata dal Certificatore d’attributo, questi deve essere in grado di associare all’identificazione dell’utente (Asserzione di identità) una serie di attributi di sua pertinenza. Queste informazioni costituiscono il contenuto del Certificato di attributo sottoscritto dal Certificatore. Saranno considerati validi i soli attributi dell’Asserzione (di attributo) che compaiono anche nell’Asserzione di Certificatore. Questa Asserzione viene rilasciata dal CDC al termine dell’iter di accettazione e verifica della richiesta di adesione. La scadenza di una asserzione di attributo può variare, per motivi di sicurezza è bene che non superi le 24 o 48 ore, a meno che non debba venir utilizzata in procedimenti che hanno una vita temporale maggiore. Il Certificatore stabilirà nei vari casi il limite massimo di validità temporale. ART.3.3.3.6 – ASSERZIONE DI AUTORIZZAZIONE L’asserzione di autorizzazione è rilasciata a fronte di una richiesta d’accesso ad un servizio. Viene rilasciata dal Certificatore di Autorizzazione dopo aver verificato le politiche di accesso al servizio nei confronti di tutte le Asserzioni presenti nel Portafoglio delle Asserzioni al momento della richiesta. Questa Asserzione viene rilasciata dal CDC al termine dell’iter di accettazione e verifica della richiesta di adesione. I vincoli di validità temporale per un’asserzione di autorizzazione non sono in genere critici. Una stessa autorizzazione può essere riutilizzata anche più volte se i parametri d’accesso al servizio lo consentono. Per quel che riguarda le procedure di qualificazione dei vari soggetti facenti parte della Comunità di Cooperazione, queste possono essere riassunte in: · Procedura di qualificazione dei soggetti erogatori/fruitori di servizi applicativi:

· Procedura di qualificazione/revoca dei soggetti pubblici · Procedura di qualificazione/revoca dei soggetti privati · Verifica e qualificazione del Dominio

· Procedura di qualificazione dei soggetti fruitori di servizi applicativi che operano attraverso il DSA di un altro soggetto:

· Procedura di qualificazione/revoca dei soggetti pubblici · Procedura di qualificazione/revoca dei soggetti privati

21

· Procedura di qualificazione dei soggetti certificatori: · Procedura di qualificazione/revoca dei soggetti certificatori · Verifica e qualificazione dei sistemi di certificazione

A questo proposito, la Regione Abruzzo intenderà porsi come fornitore del servizio di gestione dei token ed in generale del Sistema Federato di Autenticazione per gli Enti che non intendano dotarsi di tale infrastruttura. Si richiede, quindi, che tale sistema, presenti le seguenti caratteristiche: · presenza di un modulo nativo (facilmente configurabile) per la creazione e consumazione di token SAML 2.0 che risulti compatibile con il rilascio ed il riconoscimento di token SAML 1.1; · interfacciamento con il Service Consumer secondo le specifiche WS-TRUST 1.3; · presenza di un modulo nativo (facilmente configurabile) in grado di produrre autorizzazioni secondo il protocollo XACML 3.0. ART.3.4 – INTEROPERABILITA’ APPLICATIVA L’interoperabilità e cooperazione a livello applicativo previsto dai task del progetto richiedono la realizzazione/riuso, l’installazione e la configurazione di diverse componenti software aderenti agli standard SOA (Services Oriented Architecture) su cui si fonda il sistema SPCoop e la struttura a “Porte di Dominio”. Tali componenti software possono essere così riassunti:

a) realizzazione di web services per l’erogazione dei servizi di interrogazione/notifica variazione anagrafica con sistema di tracciatura integrato;

b) configurazione degli opportuni accordi di servizio fruiti/erogati dalla Porta di Dominio comunale

c) personalizzazione dei sistemi di pagamento già forniti dal Comune ed eventuale realizzazione di web services “ad hoc”

d) eventuale realizzazione di un web service per la pubblicazione dei servizi erogati, quale Indice dei Servizi erogati localmente dall’Amministrazione comunale

e) eventuale disposizione di un Identity Provider locale addetto all’identificazione degli utenti (Cittadini ed Enti) presenti all’interno dell’anagrafica comunale.

Per tutti i dettagli relativi alle suddette componenti software si rimanda agli allegati 1 e 2. ART.4 – DESCRIZIONE ANALITICA DEI SERVIZI DA IMPLEMENTARE I servizi che il proponente dovrà realizzare sono :

22

I servizi di base associati alla fornitura dei moduli applicativi personalizzati costituiscono un elemento imprescindibile che deve essere integrato all’interno del Progetto Tecnico per consentire la piena fruibilità di quanto richiesto. L’impresa concorrente, per la corretta definizione del Progetto Tecnico e delle modalità esecutive, dovrà effettuare tutti gli accertamenti necessari per l’elaborazione dello stesso e per la successiva esecuzione delle attività e la definizione del prezzo offerto. L’impresa concorrente, pertanto, non potrà richiedere variazioni di prezzo, giustificate da difficoltà nella esecuzione delle attività dovute ad elementi che avrebbero potuto essere riscontrati nell’ambito dei sopralluoghi e dei rilievi in parola. ART.4.1 – SERVIZIO DI ANALISI PRELIMINARE Di seguito sono riportati i servizi di analisi preliminare per definire e contestualizzare le attività da realizzare secondo gli obiettivi progettuali. ART.4.1.1 – SERVIZIO DI ANALISI PRELIMINARE DELL’INFRASTRUTTURA ELABORATIVA ESISTENTE Nella fase iniziale del progetto e preliminarmente all’inizio delle attività di sviluppo e di implementazione, dovrà essere realizzata un’analisi dell’infrastruttura elaborativa e di comunicazione esistente situata presso il CED del Comune destinata ad ospitare gli applicativi software e le personalizzazioni collegate all’intervento. Il servizio di analisi dell’infrastruttura elaborativa necessaria per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti dell’impresa esecutrice ha come punto di partenza le indicazioni contenute nella documentazione di gara e darà origine ad un documento nel quale dovranno essere riportati gli eventuali adeguamenti necessari a rendere idonee le infrastrutture elaborative del CED comunale alla piena e completa messa in esercizio del sistema. La proposta di progetto dovrà contenere, quindi, tutte le indicazioni dettagliate, sia a livello di schema che di elementi dell’infrastruttura elaborativa necessaria per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti dall’impresa esecutrice e le modalità di esecuzione del servizio di analisi preliminare. ART.4.1.2 – SERVIZIO DI ANALISI PRELIMINARE DEI SERVIZI APPLICATIVI ESISTENTI Nella fase iniziale del progetto e preliminarmente all’inizio delle attività di sviluppo, dovrà essere realizzata un’analisi preliminare dei servizi applicativi offerti dalla Regione Abruzzo e dal CTTL, successivamente di quelli che possono essere esposti dal singolo Ente Locale o da “piattaforme” integrate sovra comunali che saranno d’interesse per la realizzazione dei task di progetto. Il servizio di analisi necessario per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti dal soggetto esecutore avrà come punto di partenza le indicazioni contenute nella Documentazione Progettuale e darà origine ad un documento nel quale dovranno essere riportati gli eventuali adeguamenti necessari a rendere idonea l’infrastruttura applicativa del CED comunale alla piena e completa messa in esercizio del sistema. Il servizio di analisi preliminare dei servizi applicativi in uso presso la Regione Abruzzo ed il CTTL includerà un insieme di attività tra loro collegate.

23

Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato. Resta inteso che ogni azione di analisi, sviluppo o di verifica preliminare necessarie all'integrazione degli applicativi rientrano all'interno del dimensionamento a corpo dell'attività e non potrà essere richiesto, ne addebitato alcun costo aggiuntivo per il completamento della stessa. ART.4.2 – SERVIZIO DI CONSEGNA ED INSTALLAZIONE Il servizio di consegna ed installazione includerà in modo omnicomprensivo tutti gli oneri relativi alla produzione di supporti (CD – DVD, ecc.), materiale accessorio (documentazione, ecc.), consegna, installazione, verifica funzionalità e qualsiasi attività ad esse strumentale. La verifica di funzionalità in questa fase sarà intesa unicamente come la presenza dei moduli software comprensivi di tutto il materiale accessorio (supporti, documentazione, ecc.) e della collocazione di tali moduli software all’interno dell’infrastruttura elaborativa. La proposta di progetto dovrà contenere, tra le altre cose, i termini di consegna e d’installazione sull’intera realizzazione prevista nel progetto. Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato. La proposta di progetto dovrà contenere, tra le altre cose, i termini di consegna ed installazione sull’intera realizzazione prevista nel progetto. Questa tipologia di servizio dovrà essere inclusa in modo forfetario, espressa in termini di personale con i relativi profili e relativi impegni temporali, e non dovrà comportare nessun altro onere aggiuntivo per il Committente. ART.4.3 – SERVIZIO DI INTEGRAZIONE I servizi di integrazione riferiti ai sistemi in essere presso l’Amministrazione comunale, la Regione Abruzzo e l’ARIT include un insieme di attività tra loro collegate. Considerata l’importanza dell’integrazione delle componenti software del progetto all’interno delle infrastrutture esistenti, dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione delle attività con il personale interessato. Nell’Offerta Tecnica dovrà essere inclusa la descrizione del processo di analisi delle infrastrutture per la determinazione delle soluzioni di interoperabilità che il soggetto esecutore intende utilizzare nell’esecuzione dei servizi richiesti in modo da consentire di implementare e testare, in particolare, l’interoperabilità secondo quanto previsto dai task di progetto. Dovrà, di conseguenza, essere indicato in dettaglio l’insieme degli strumenti applicativi utilizzati ed il ciclo completo di determinazione delle problematiche, dello stato dell’arte e delle soluzioni prospettate. L’analisi dell’integrazione dell’infrastruttura con i servizi applicativi già presenti dovrà essere inteso in senso generale e non strettamente collegato alla singola implementazione locale, pertanto lo schema di riferimento generale da produrre dovrà prevedere un quadro complessivo per la realizzazione di applicativi ed interfacce di accesso che facciano uso degli standard di riferimento precedentemente descritti nel documento. In sede operativa dovranno essere concordate con il Committente le priorità d’intervento delle attività di integrazione e relative tempistiche. Resta inteso che le attività di integrazione potranno avere corso solo dopo esplicita approvazione del piano operativo da parte del Committente.

24

Questa tipologia di servizio dovrà essere inclusa a corpo e non dovrà comportare nessun altro onere aggiuntivo per il Committente. ART.4.4 – SERVIZIO DI TEST DELL’INTEROPERABILITA’ APPLICATIVA Il servizio di test dell’interoperabilità applicativa dovrà confarsi alle normative emanate in merito dal CNIPA-DigitPA per i progetti ICAR regionali. Considerata l’architettura del progetto, che si pone l’obiettivo di creare un’infrastruttura in grado di erogare servizi in cooperazione applicativa, sarà necessario prevedere test di cooperazione applicativa tra le Porte di Dominio degli Enti coinvolti nel progetto. Le attività di test saranno validate dalla Stazione Appaltante in considerazione del documento comprendente il dettaglio delle metodologie e dei test case che il soggetto esecutore dovrà produrre. Questa tipologia di servizio dovrà essere inclusa in modo forfetario, espressa in termini di personale con i relativi profili e relativi impegni temporali, e non dovrà comportare nessun altro onere aggiuntivo per il Committente. ART.4.5 – SERVIZIO DI CONFIGURAZIONE E MESSA IN ESERCIZIO Il servizio di configurazione e messa in esercizio include un insieme di attività tra loro collegate. La proposta di progetto dovrà contenere i termini anche temporali di configurazione e messa in esercizio per l’intera realizzazione prevista nel progetto (software di base, moduli applicativi, ecc…), per l’installazione, la configurazione e l’attivazione degli applicativi. Il servizio di configurazione e messa in esercizio includerà in modo omnicomprensivo tutti gli oneri relativi alla definizione delle configurazioni (definizione profili, indirizzamenti, policy, ecc.) per la piena e completa messa in esercizio di quanto realizzato. Lo schema delle configurazioni riportato in un documento sarà validato dalla Direzione di Progetto della Stazione Appaltante preliminarmente all’esecuzione operativa delle attività. Per l’insieme complessivo dei prodotti software forniti e di quanto altro realizzato dovrà essere prodotta una documentazione che illustri complessivamente tutte le configurazioni. Le operazioni di verifica in questa fase prevedono test di riscontro sul funzionamento inteso quale controllo delle configurazioni e delle politiche implementate. La proposta di progetto dovrà contenere, tra l’altro, i termini temporali di configurazione e messa in esercizio sull’intera realizzazione prevista nel progetto. Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato. Questa tipologia di servizio dovrà essere inclusa in modo forfetario, espressa in termini di personale con i relativi profili e relativi impegni temporali, e non dovrà comportare nessun altro onere aggiuntivo per il Committente. ART.4.6 – SERVIZIO DI START-UP

25

Dopo la messa in servizio del sistema dovrà essere previsto un periodo di affiancamento del personale preposto alla gestione al fine di supportarlo nella delicata fase di avviamento del sistema e di tuning. L’assistenza di gestione operativa dovrà riferirsi ad attività connesse all’affiancamento del personale che utilizza il sistema, in modo da facilitarne le operazioni di gestione e monitoraggio e consentire una completa ed efficace fruizione della stesso. Altre attività riguardano attività di servizio particolari come ad esempio quelle connesse alla verifica di situazioni anomale o la realizzazione di operazioni di controllo a campione. Nell’Offerta Tecnica dovrà essere riportato un prospetto riepilogativo che indichi per ogni profilo professionale tutti i servizi di Start-up offerti mediante risorse professionali. Le attività richieste dovranno, inoltre, essere erogate con continuità secondo le modalità di esecuzione previste a partire dalla data di firma del contratto di aggiudicazione. La proposta di progetto dovrà contenere un insieme di servizi specificamente orientati allo Start-up del sistema che sarà esplicato in un insieme di attività di servizio da un “pool” di risorse umane qualificato con esperienze lavorative in progetti di analoga dimensione quantitativa e che utilizzino le tecnologie di riferimento precedentemente indicate. Per la definizione del pool di risorse l’azienda concorrente dovrà includere nell’offerta tecnica secondo le indicazioni dei paragrafi successivi tutti i curriculum vitae del personale competente nell’area interessata al progetto, descritte nel paragrafo successivo. ART.4.6.1 – I PROFILI PROFESSIONALI Il “pool” di risorse umane da utilizzare per l’esecuzione del supporto specialistico informatico è particolarmente vario e differenziato. Di seguito sono elencate le figure professionali con gli specifici requisiti richiesti in termini di professionalità ed esperienza per l’esecuzione della fornitura dei servizi specialistici oggetto della soluzione progettuale. Per tutti i curriculum vitae senior collegati ai profili professionali è propedeutica ed obbligatoria la laurea vecchio ordinamento oppure la laurea specialistica del nuovo ordinamento sempre in discipline scientifiche. La laurea vecchio ordinamento e quella specialistica possono essere mutuate con cinque anni di esperienza lavorativa negli specifici segmenti di seguito indicati. Un laureato di primo livello con due anni di esperienza lavorativa negli specifici segmenti di seguito indicati viene considerato come un laureato con specialistica (laurea II livello). ART.4.6.1.1 – SPECIALISTA AREA SVILUPPO APPLICATIVO Uno specialista in area di sviluppo applicativo è colui che: · Ha maturato un’approfondita esperienza e conoscenza dei principali moduli applicativi Microsoft: IIS, Exchange, SQL Server e in moduli applicativi Open Source: Apache, Firebird, SendMail, MySQL, Tomcat e JBOSS e nelle operazioni di gestione, tuning e configurazioni avanzate. · Ha esperienza nello sviluppo in ambiente middleware distribuito, in particolare conosce i maggiori framework applicativi in ambito ICT con i relativi sistemi operativi (Linux/Unix, Windows, Solaris, ecc.)

26

· Ha esperienza nello sviluppo Jsp/Servlet/Ejb e più in generale dell’ambiente J2EE, buona conoscenza della programmazione e dei paradigmi OO. Ha, inoltre, esperienza nello sviluppo .Net C# e SQL Server. Ha conoscenza approfondita del web 2.0 ed in particolar modo degli standard definiti dal W3C. Conosce i linguaggi e la sintassi XML, XSL e XHTML. · Ha esperienza nello sviluppo di applicazioni web oriented, ed ha esperienza in ambito SOA e nello sviluppo di web services. · Ha esperienza nella installazione e configurazione di Porte di Dominio in standard SPCoop per la fruizione ed erogazione di servizi secondo accordi di servizio condivisi tra gli Enti della Pubblica Amministrazione coinvolti. · Ha esperienza nella integrazione di applicativi tramite l’uso di protocolli di comunicazione (messaggi) i quali sono stati sviluppati con diversi linguaggi di programmazione e vengono eseguiti su diversi sistemi e piattaforme · Ha esperienza in ambito RDBMS, PL/SQL e IDE di programmazione e sullo sviluppo di applicativi front-office e back-office. ART.4.6.1.2 – SPECIALISTA AREA INFRASTRUTTURE ELABORATIVE ED APPLICATIVE Uno specialista in area di infrastrutture elaborative ed applicative è colui che: · Ha esperienza nella progettazione di infrastrutture elaborative integrate in ambiente eterogeneo, in particolare conosce le problematiche generali organizzative della P.A. regionale, e in grado di redigere analisi, raccolta di requisiti, e progetti in linea con le più recenti tecnologie di settore. · Ha maturato un’approfondita esperienza nella configurazione e tuning a livello avanzato di infrastrutture elaborative in ambiente eterogeneo (Server, Server Blade, Server Virtuali, SAN, ecc.). · Ha maturato un’approfondita esperienza e conoscenza dei principali Sistemi Operativi a livello Server ed in particolare VMWare ESX, Windows2000/2003, Linux e Solaris e nelle operazioni di gestione, tuning e configurazioni avanzate. · Ha maturato un’approfondita esperienza e conoscenza dei principali moduli applicativi Microsoft: IIS, Exchange, SQL Server e in moduli applicativi Open Source: Apache, Firebird, SendMail, MySQL, Tomcat e JBOSS e nelle operazioni di gestione, tuning e configurazioni avanzate. · Ha maturato un’approfondita esperienza e conoscenza nel segmento della security infrastrutturale ed applicativa ed in particolare nei moduli applicativi di reverse proxy e Proxy Server. · Ha maturato un’esperienza lavorativa di cinque anni nella funzione e nel coordinamento ed assistenza in attività di progetti relativi a infrastrutture elaborative di dimensione medio-alta. · Ha esperienza nella implementazione e gestione di infrastrutture che supportano servizi ed applicativi Web Services in ambiente SOA. · Ha esperienza nei sistemi Single Sign On, Identity Manager, Policy Manager per stabilire i meccanismi di Identità Federata. ART.4.7 – SERVIZIO DI FORMAZIONE ED ADDESTRAMENTO

27

La proposta di progetto dovrà contenere un insieme di servizi specificamente orientati alla formazione e all’addestramento del personale tecnico secondo le indicazioni della Stazione Appaltante in riferimento alla realizzazione dei servizi. Dovrà essere previsto il necessario affiancamento operativo ai predetti operatori nella fase di start-up ed avviamento del sistema. Il modello organizzativo e di servizio ipotizzato dovrà essere inteso come formazione in training on the job di un primo nucleo in grado di replicare poi la formazione in termini esaustivi. Inoltre l’offerta dovrà contenere modalità alternative ai classici corsi in aula così da favorire la formazione dell’utenza presso le diversi sedi degli Enti coinvolti dal progetto. I docenti dovranno essere d’elevato profilo ed esperienza professionale ed in possesso delle certificazioni inerenti le tematiche dei corsi da essi tenuti. Tutti i corsi dovranno essere pianificati in modo da concludersi in coincidenza del rilascio definitivo del sistema oggetto dell’infrastruttura determinata dal progetto e dovranno essere corredati di materiale didattico documentale ed illustrativo in formato elettronico e cartaceo. Le attività dovranno essere dettagliate e descritte in un apposito documento riportante il piano complessivo di formazione, includendo le tempistiche, le modalità di effettuazione ed i contenuti dei corsi. In particolare dovranno essere previsti corsi di formazione riguardanti i moduli applicativi introdotti dal progetto oltre a coprire i vari aspetti tecnologici trattati. La formazione dovrà incentrarsi sulle tematiche di Human Computer Interaction per la progettazione e lo sviluppo di sistemi interattivi in ambito di interoperabilità applicativa. Si dovranno, inoltre, prevedere corsi incentrati sull’infrastruttura definita dal progetto e sulle attività di integrazione dei servizi locali, prendendo in considerazione l’attuale infrastruttura esistente con le relative applicazioni presenti e quella definita dal progetto. La ditta aggiudicataria dovrà implementare e rendere operativi i sopra-elencati servizi, secondo quanto specificato nel presente capitolo. ART.5 – DESCRIZIONE DELLE INFRASTRUTTURE Il progetto non prevede la realizzazione di infrastrutture tecnologiche da parte di Pescara Innova. Tutti i servizi utilizzeranno le infrastrutture già realizzate dalla Regione Abruzzo (Centri Tecnici dell’Aquila e di Tortoreto; rete regionale a banda larga, ove disponibile). Nel caso si presentino necessità di procedere all’acquisto di tecnologie hardware funzionali al progetto, la consistenza delle medesime sarà celermente posta a conoscenza dell’azienda aggiudicataria. ART.6 – ATTIVITA’ DA REALIZZARE L’avviamento del progetto si realizzerà con lo svolgimento delle attività così come descritto agli articoli 3 e 4 coerentemente a quanto espresso documenti contrassegnati quali “ALLEGATO 1” e “ALLEGATO 2”. Esse ricomprendono i servizi di cui all’articolo precedente, con relative attività previste.

28

L’insieme delle attività collegate alla fornitura di un supporto specialistico informatico connesso alla realizzazione dei servizi sarà realizzato secondo le indicazioni e con le limitazioni e le modalità operative di seguito riportate. Tali modalità di esecuzione potranno essere congiuntamente riviste anche su proposta dell’impresa aggiudicataria e potranno essere concordate opportune semplificazioni o variazioni in funzione delle specificità riscontrate. ART.6.1 – IL PIANO DELLE ATTIVITA’ La realizzazione del progetto implica l’esecuzione di una serie di attività eterogenee con l’impiego di personale qualificato e richiede per il raggiungimento degli obiettivi un esecuzione coordinata, efficace e con controlli e verifiche puntuali. L’esecuzione delle attività d’implementazione del progetto (analisi, realizzazione, progetto tecnico, test, installazione e successiva manutenzione) collegate alla realizzazione ed alla completa messa in funzione di quanto previsto dal progetto saranno interamente a carico dell’azienda aggiudicataria, come anche quelle di coordinamento tecnico dei singoli sottoprogetti, di progettazione, realizzazione, messa in opera, gestione e manutenzione delle necessarie infrastrutture applicative software e di tutto quanto altro necessario alla messa in esercizio del progetto. Il soggetto esecutore dovrà prevedere un Capo Progetto unico a coordinamento di tutte le attività erogate, che sia responsabile dei rapporti con la Stazione Appaltante e dell’attuazione, per le attività di competenza. Tale figura non è esplicitata nelle richieste quantitative e nei profili in quanto, l’indicazione della quota di partecipazione del Capo Progetto, nella composizione dei team relativi alle attività di sviluppo e manutenzione, da esplicitarsi nei servizi di Project Management è di specifica competenza dell‘azienda offerente. ART.6.2 – LA DOCUMENTAZIONE DI PROGETTO Le attività definite all’interno del progetto richiedono, in funzione della loro tipologia, la produzione di documentazione differenziata che consenta la piena comprensione e la completa conoscenza delle situazioni realizzative. Lo schema documentale a corredo delle attività operative deve consentire alla Stazione Appaltante di conservare il pieno controllo del Progetto e la messa in atto di tutte le attività di controllo per il rispetto dei piani di qualità al fine di garantire l’assoluta eccellenza delle realizzazioni. Per tutte le attività è richiesta la documentazione progettuale organizzativa e pianificatoria (diagrammi di GANTT, piani di allocazione delle risorse con i relativi profili professionali, lista degli obiettivi da raggiungere, ecc…) e quella di accettazione e validazione (verbali di accettazione, stato di consistenza, report di configurazione, piani di test, ecc.) il cui dettaglio sarà definito nella fase di pianificazione iniziale del progetto. Dovrà essere predisposta, inoltre, tutta la documentazione relativa all’installazione, al test ed alla gestione degli applicativi, oltre che una relazione che illustri le modalità di funzionamento e faciliti le attività formative ed il trasferimento applicativo al personale addetto.

29

Tutta la documentazione progettuale dovrà essere prodotta sia in forma cartacea che in forma elettronica anche editabile su supporti CD/DVD. ART.6.3 – IL GRUPPO DI LAVORO Il gruppo di lavoro sarà caratterizzato da diversi ruoli e responsabilità, da continuità operativa e da obiettivi condivisi. La Stazione Appaltante avrà la facoltà di verificare con propri mezzi, anche mediante colloqui tecnici, che le persone incaricate di svolgere le attività abbiano le capacita e le esperienze professionali corrispondenti a quanto descritto nei curricula. Il personale impiegato verrà formato, mediante apposite sessioni tenute da tecnici specialisti deputati dalla Stazione Appaltante, in merito ad aspetti specifici e tematiche peculiari del contesto di sviluppo e alle infrastrutture di riferimento per i servizi applicativi oggetto di erogazione. Il costo giornaliero delle risorse appartenenti all‘impresa aggiudicataria impegnate nelle sessioni di addestramento iniziale, sarà a carico dell’impresa stessa. L’azienda aggiudicataria dovrà assicurare il costante aggiornamento del personale del gruppo di lavoro in base all’evoluzione tecnologica ed applicativa prevista dal progetto. La Stazione Appaltante si riserverà di verificare periodicamente l’adeguatezza del livello di competenze del gruppo di lavoro. ART.6.3.1 – IL PROJECT MANAGEMENT L’azienda aggiudicataria dovrà gestire in modo efficiente tutte le attività relative al Contratto. A tal fine dovrà designare un Project Manager che sarà responsabile della gestione e dell’esecuzione del lavoro richiesto, del coordinamento del lavoro del team di Progetto e delle relazioni con l’Amministrazione. Il Project Manager sarà l’unico punto di Contatto ufficiale dell’Amministrazione. In particolare, oltre all’azione organizzativa dovranno essere descritti gli schemi atti a garantire un livello qualitativo di eccellenza coniugato al rispetto delle tempistiche definite congiuntamente in fase di esecuzione delle attività. L’azienda dovrà fornire al Kick-Off (inizio lavori) il Piano di Gestione del progetto con le seguenti informazioni: · descrizione delle attività; · strategia del progetto; · aspetti critici; · organizzazione e Gestione o Struttura del Raggruppamento o Team di Progetto (Organizzazione, Responsabilità, Persone chiave); · gestione dei sottocontraenti (in caso di RTI); · pianificazione di Progetto (GANTT); · riunioni di progetto e rapporti; · responsabile della qualità. Le attività dovranno essere gestite secondo la pianificazione proposta dall’impresa aggiudicataria ed approvata dall’Amministrazione. La pianificazione presentata in Offerta costituisce la “Baseline” contrattuale, salvo modifiche al contratto stesso. L’azienda sarà responsabile dell’aggiornamento

30

della pianificazione del Progetto e dovrà fornire eventuali aggiornamenti della pianificazione. In ogni caso la pianificazione aggiornata dovrà riportare il riferimento alla “Baseline” contrattuale. Variazioni alla pianificazione saranno valide ed impegnative per l’Amministrazione solo se approvate e sottoscritte. Nella relazione tecnica dovrà essere inclusa la specifica descrizione dei servizi di project management offerti. In particolare, oltre all’azione organizzativa andranno descritti gli schemi adottati per garantire un livello qualitativo di assoluta eccellenza coniugato al rispetto delle tempistiche definite. Il livello qualitativo/quantitativo del project management dovrà essere adeguato al volume complessivo di attività ed ovviamente dovrà fare riferimento al corrispettivo complessivo al netto di IVA, richiesto in modo omnicomprensivo, per le prestazioni oggetto della gara, che deve essere indicato unicamente nell’Offerta Economica. Non sarà, quindi, richiesto un corrispettivo unitario per la figura professionale collegata a tale servizio. In sintesi :

SERVIZIO : PIANO DI DISPIEGAMENTO E ISTALLAZIONE

Entro il 06 maggio 2015

SERVIZIO: FASE DI TEST E STARTUP

Dal 7 maggio 2015 al 27 maggio 2015

Collaudo definitivo entro la fine di maggio 2015

ART. 7 - STATI DI AVANZAMENTO E COMPLETAMENTO DELLA FORNITURA La fornitura sarà suddivisa in n. 3 SAL (Stati di Avanzamento Lavori), come di seguito riportato :

SAL n. 1 : AL COMPLETAMENTO DEL 40 % DELLE ATTIVITA’ PREVISTE SAL n. 2 : AL COMPLETAMENTO DEL 80 % DELLE ATTIVITA’ PREVISTE SAL n. 3 : AL COMPLETAMENTO DEL 100 % DELLE ATTIVITA’ PREVISTE

La fornitura si intenderà compiuta al completamento del SAL n. 3.

31

Il completamento di ogni attività sarà accertata attraverso apposite verifiche che saranno concordate tra la Stazione Appaltante ed il fornitore. A tal proposito sarà definita apposita modulistica che sarà cura del fornitore redigere e compilare. ART. 8 PENALITA’ Qualora le tempistiche di realizzazione del progetto siano superiori a quelle previste nel crono-programma temporale incluso negli allegati 1 e 2 , saranno applicate penali secondo la formula seguente:

- 2% per ogni settimana di ritardo rispetto alla data prevista per ciascuna attività. Resta inteso che la somma delle penali su base annua non potrà comunque superare il 10% del valore del contratto di fornitura.