oscat.rete.toscana.itoscat.rete.toscana.it/docman/view.php/65/1881/MEVARPA... · Web viewL'accesso diretto alle risorse via desktop di portale avviene in base ad alcuni parametri

Progetto MEV-ARPAMigrazione dell’infrastruttura centrale su

architettura openSpecifiche Funzionali nuovo Portal

Redatto da A. Menichetti (TAI), C. Simonelli (TAI)

Rivisto da Francesco Fornasari (TAI)

Approvato da

Versione 1.12

Data emissione 22/12/17

Stato Proposto per approvazione

Storia del documentoVersione Data Descrizione

1.4 24/10/07 Versione di partenza: Progetto_ARPA-Specifiche_Funzionali_1.4.doc

1.5 11/03/11 Modifiche relative al contratto complementare

1.6 13/01/12 Aggiornamento

1.7 27/01/12 Aggiornamento Gestione Errori

1.8 02/05/14 Aggiornamento evoluzione per dispositivi mobili

1.9 03/03/15 Aggiornamento ciclo di vita identità mobile

1.10 07/08/15 Aggiornamento Requisito 20 per non cancellazione utente con deleghe in uscita

1.11 18/05/2016 Introduzione persona giuridica

1.12 22/12/2017 Modifica requisiti per evoluzioni

Migrazione dell’infrastruttura centrale su architettura open

Specifiche funzionali nuovo Portal

1 Generalità..............................................................................................................................51.1 Scopo.............................................................................................................................51.2 Validità...........................................................................................................................51.3 Glossario dei termini......................................................................................................51.4 Riferimenti.....................................................................................................................81.5 Assunzioni e dipendenze................................................................................................9

2 Introduzione........................................................................................................................102.1 Sintesi della soluzione..................................................................................................10

3 ARCHITETTURA LOGICA..............................................................................................173.1 Sottosistemi principali e loro interazioni.....................................................................18

3.1.1 Role Manager.......................................................................................................183.1.2 Portal.....................................................................................................................183.1.3 Generic.................................................................................................................193.1.4 SRTY....................................................................................................................19

3.2 Banche Dati utilizzate..................................................................................................203.3 Definizione delle componenti dei sottosistemi............................................................21

3.3.1 PORTAL...............................................................................................................213.3.2 ROLE MANAGER..............................................................................................223.3.3 SRTY....................................................................................................................223.3.4 GENERIC.............................................................................................................23

3.4 Scenario d’interazioni tra alcune componenti..............................................................233.5 Il Role Manager...........................................................................................................24

3.5.1 Role Administration..............................................................................................26Un ruolo viene definito mediante:..................................................................................26

3.5.2 Role Detection......................................................................................................283.5.3 Adapter.................................................................................................................283.5.4 Notifica delle operazioni sul ruolo verso PORTAL e SRTY................................29

4 Realizzazione della soluzione.............................................................................................304.1 Requisiti non funzionali.................................................................................................304.2 Requisiti funzionali........................................................................................................344.1 Casi d’uso.......................................................................................................................53

4.1.1 Accesso Successivo..............................................................................................534.1.2 Primo Accesso......................................................................................................55

Pag. 3 di 81



4.1.3 Accesso alle risorse SRTY attraverso PORTAL...................................................574.1.4 Accesso diretto alle risorse SRTY........................................................................584.1.5 Accesso diretto (già autenticato) alle risorse SRTY.............................................604.1.6 Accesso alle risorse GENERIC attraverso PORTAL...........................................614.1.7 Accesso diretto alle risorse GENERIC.................................................................624.1.8 Accesso (già autenticato) diretto alle risorse GENERIC......................................644.1.9 Variazione ruoli.....................................................................................................654.1.10 Inserimento, Modifica e Cancellazione di un Ruolo............................................664.1.11 Inserimento, Modifica e Cancellazione di una Risorsa........................................674.1.12 Inserimento, Modifica e Cancellazione di un Criterio.........................................684.1.13 Individuazione e verifica dei ruoli........................................................................684.1.14 Accesso delegato a risorse attraverso PORTAL...................................................694.1.15 SAML Identity Provider.......................................................................................714.1.16 Associazione CNS con applicazione ToscanaID..................................................724.1.17 Inserimento/Modifica/Eliminazione Pin ToscanaID............................................724.1.18 Reset Pin dimenticato o bloccato su ToscanaID...................................................734.1.19 Revoca Associazione CNS con applicazione ToscanaID da portale....................744.1.20 Revoca Associazione CNS con applicazione ToscanaID.....................................744.1.21 Accesso ai servizi da app collegata a ToscanaID.................................................754.1.22 Accesso ai servizi da applicazione nativa.............................................................754.1.23 Accesso ai servizi web di ToscanaID...................................................................76

4.2 Tracciabilità dei requisiti sui sottosistemi individuati....................................................775 PIANO DI SICUREZZA....................................................................................................79

5.1 Sicurezza architetturale...................................................................................................795.2 Politiche di sicurezza delle utenze..................................................................................795.3 Politiche di sicurezza per le applicazioni.......................................................................805.4 Politiche di sicurezza delle aree funzionali....................................................................805.5 Politiche di sicurezza delle componenti applicative.......................................................815.6 Politiche di sicurezza per i sistemi.................................................................................81

Pag. 4 di 81



1 Generalità

Il presente documento descrive i requisiti e le specifiche funzionali previsti per la realizzazione del portale per l’accesso sicuro denominato ARPA. Includendo le evoluzioni per il rilascio del maccanismo di autenticazione via dispositivi mobili (inserire riferimento)

1.1 Scopo

L’obiettivo di questo documento è quello di formalizzare i processi di individuazione e classificazione delle funzionalità del sistema oggetto di analisi e dei relativi requisiti.

1.2 Validità

Il presente documento è valido a partire dalla data di emissione riportata in copertina .

1.3 Glossario dei termini

Adapter Componente software che nasconde ed “adatta” l’interfaccia di un componente mostrandone un’altra all’esterno. Consente di “uniformare” l’interfaccia di accesso alle fonti dati durante il processo di discovery e verifica dei ruoli.

ARPA Autenticazione Ruoli Profili Applicazioni

ARPA Common Libreria software utilizzabile all'interno di applicazioni Web protette SpAgent Java e PhP che permette l'accesso alle informazioni di profilo dell'utente autenticato in Arpa.

Client SDK OpenAM Software Development Kit. Il Client SDK è un framework che permette la verifica e la validazione del token di sessione del portale. Permette inoltre di accedere alla sessione utente e acquisire le informazioni che preventivamente sono state associate al tokenId della sessione (es. CF, PI, ruoli, etc.)

CA Certification Authority. È una entità che rilascia certificati digitali verso terze parti. Aggiorna periodicamente anche le CRL relative ai certificati emessi.

Pag. 5 di 81



CART Infrastruttura di Cooperazione Applicativa di Regione Toscana

Cache Memoria che contiene informazioni temporanee, utilizzata per velocizzare la ricerca e la fruizione delle informazioni, evitando di reperirle direttamente dalle fonti primarie.

Certificatori di ruolo

Entità che rendono disponibili attraverso una o più Fonte Dati, le informazioni (gli attributi) necessari alla verifica (certificazione) del ruolo da parte del modulo Role Manager.

CIE Carte di Identità Elettronica

CNIPA Centro Nazionale per l'Informatica nella Pubblica Amministrazione

CNS Carta Nazionale dei Servizi

Connector Componente software che consente l’interscambio di informazioni con una particolare fonte dati mediante il protocollo richiesto.

Criterio L’insieme di dati che selezionano e valorizzano opportunamente i parametri esposti dagli Adapter, consentendone la specializzazione per il prelievo di opportune informazioni dalle varie fonti dati.

CRL Certificate Revocation List. I certificati revocati o sospesi sono inseriti in CRL firmate dall CA e pubblicate con periodicità prestabilita nel registro dei certificati.

Desktop Ambiente di lavoro erogato agli utenti attraverso il componente Liferay Portal.

Directory Server È il repository dei dati utilizzato dal Portale e dell'OpenAM, costituito dal Directory Server LDAPv3 Sun Java System Directory Server.

Firewall Componente di difesa perimetrale che svolge funzioni di controllo accessi a livello di rete tra due o più sottoreti.

Fonte Dati Repository di informazione necessario al ROLE MANAGER per verificare l’assegnazione dei ruoli agli utenti attraverso specifici Adapter.

GENERIC Applicazioni preesistenti o future che vengono integrate a vario livello nell’infrastruttura. Sono escluse da questa definizione le applicazioni sviluppate con il framework Srty.

Pag. 6 di 81



Integrazione Applicazioni

Una applicazione è da considerarsi integrata nel portale quando:1. è definita come risorsa di un ruolo gestito dal ROLE MANAGER

e quindi, sul desktop di un utente associato a tale ruolo, compare da qualche parte il link ad essa;

2. tramite filtro JEE o PHP (SpAgent o SpAgentPHP) si garantisce la raggiungibilità e la corretta fruibilità del servizio offerto dall'applicazione in modo che sia garantito il Single Sign-On (SSO).

JEE Java Enterprise EditionInsieme di specifiche Sun che definisce un ambiente operativo per le applicazioni accessibili via protocolli Internet (HTTP)

LDAP Lightweight Directory Access ProtocolParticolare tipo di protocollo per la ricerca e la fruizione di informazioni

Load Balancer Componente hardware o software che permette la virtualizzazione di più server su una unica entità e la suddivisione del carico su di essi.

link Collegamento ipertestuale

NAL Nodo Applicativo Locale (parte dell'architettura di cooperazione applicativa)

OpenAM Componente open source che eroga funzionalità di autenticazione, controllo accessi, SSO e federazione.

PDC Personal Digital Certificate

PDK Proxy Development KitInsieme di pacchetti software e di specifiche per la realizzazione di proxy applicativi

Proxy applicativo

Porta applicativa per l’accesso alle funzioni di pubblicazione e sottoscrizione del CART

Risorsa Applicazione fruibile via web e accessibile mediante link

Ruolo Individua gli incarichi, gli obblighi ed privilegi che un utente ha all'interno di un determinato contesto istituzionale e che ne condizionano i profili applicativi all’interno del portale.

SIL Sistema Informativo Locale (parte dell'architettura di cooperazione applicativa)

SAML Security Assertion Markup Language. Linguaggio basato su XML utilizzato per lo scambio di informazioni di autenticazione e autorizzazione tra domini distinti, detti Identity Provider e Service Provider

Pag. 7 di 81



SpAgent Filtro impiantato su applicazioni web JEE che funge da Service Provider (SAML2) per permettere profilazione, gestione accessi e utilizzo ARPA Common all'interno dell'applicazione secondo le politiche attive su OpenAM.

SpAgent PHP Filtro impiantato su applicazioni PHP che funge da Service Provider (SAML2) per permettere profilazione, gestione accessi e utilizzo ARPA Common all'interno dell'applicazione secondo le politiche attive su OpenAM.

SSO Single Sign On

SRTY Framework per lo sviluppo di applicazioni profilate ad accesso sicuro di Regione Toscana.

Web Service Applicazione software le cui funzionalità sono descrivibili, identificabili ed usufruibili tramite linguaggio XML; le interazioni con altre applicazioni vengono effettuate tramite scambio di messaggi basati su XML con l’utilizzo di protocolli Internet (HTTP)

Toscana ID ToscanaID è il sistema di sicurezza che permette di accedere da dispositivi mobili alle App di Regione Toscana che necessitano di identificazione.

App collegata a toscana ID

Applicazione collegata al cirtcuito di fiducia di Arpa e che ha accesso alla sua identità digitale

SPID Sistema Pubblico di Identità Digitale.

1.4 Riferimenti

Sono di seguito elencati i documenti utilizzati nel processo di identificazione delle funzionalità:

(1) Capitolato di Appalto(2) Proposta tecnica rif doc. cod. doc. 05C1204C1ATO rev. 0 – 16/9/2005(3) “MEV-ARPA - Migrazione dell’infrastruttura centrale su architettura open -Offerta

Tecnico-Economica”(4) “MEV-ARPA - Migrazione dell’infrastruttura centrale su architettura open - Specifiche

architetturali nuovo Portal”(5) offerta dispositivi mobili [inserire riferimento]

1.5 Assunzioni e dipendenze

Vengono riportate di seguito le assunzioni e dipendenze nel redigere il documento: RTI (Raggruppamento Temporaneo di Impresa) non sarà ritenuto responsabile dei

problemi di progettazione derivanti dalla mancata presentazione delle informazioni necessarie da parte di Regione Toscana

Pag. 8 di 81



RTI (Raggruppamento Temporaneo di Impresa) valuterà eventuali attività addizionali e/o modifiche alle attività previste nel capitolato riservandosi di richiedere integrazioni contrattuali

Pag. 9 di 81



2 Introduzione

Il progetto ARPA (Autenticazione Ruoli Profili Applicazioni) si colloca nel quadro delle attività volte alla realizzazione di Infrastrutture per l'autenticazione e l'accesso ai servizi ed alle informazioni finalizzate alla diffusione di sistemi sicuri di riconoscimento telematico e alla creazione di modalità attraverso le quali a chi accede in rete sia possibile associare, nel rispetto della legge sulla privacy, i diritti di accesso e visibilità di classi di informazioni e servizi.

L'infrastruttura si compone dei seguenti macro componenti: Sistema di Autenticazione per l’accesso al sistema di persone fisiche sia attraverso

browser web che app mobile; Sistema Autorizzativo utilizzato dai servizi per permettere o negare l’accesso alle

funzionalità; Portale utente con la lista dei servizi disponibili e alcune funzionalità self service; Portale amministrativo, secondo il modello di amministrazione delegata, per la

gestione e controllo del sistema.

L'utilizzo di standard aperti e la capacità di interoperare con altri soggetti esterni secondo il modello di identità federata, consente a Regione l’evoluzione costante dell’infrastruttura. Va interpretata, in questo senso la capacità del portale di accogliere soggetti già autenticati presso altre Amministrazioni offrendo comunque loro servizi basati sulla profilazione per ruolo.

La stessa capacità di operare secondo scenari di identità federata, viene offerta agli utenti profilati sul portale di accesso sicuro che vogliano accedere ai servizi offerti da altre Amministrazioni a fronte dell'autenticazione effettuata sul portale.

2.1 Sintesi della soluzione

Nell’ambito del progetto ARPA vengono erogate una serie di funzionalità, tra queste quelle principali sono:

Dominio Utente – l’accesso al sistema è permesso a persone fisiche, identificate attraverso codice fiscale e client applicativi che possono accedere in delega di utenti fisici.

Dominio Client – I client essenzialmente sono di due tipologie:o Identificano una risorsa, quindi un utente

Accesso al Portale - Gli utenti che si collegano al Portale, o se abilitati, direttamente alle risorse applicative, sono sottoposti ad una fase di autenticazione basata sull'utilizzo di un certificato presente all’interno della Smart Card, oppure SPID o ToscanaID.

o Riguardo l'autenticazione basata su certificato digitale di autenticazione Il modulo di autenticazione acquisisce alcune informazioni dal certificato e ne verifica la validità utilizzando le diverse banche dati a disposizione (Revocation List, Black/White List, ecc.).

o Riguardo l'autenticazione basata su SPID il modulo di autenticazione verifica la validità dell'asserzione di autenticazione proveniente da identity provider appartenenti al circuito di fiducia SPID e con i dati in essa contenuta autentica l'identità.

Pag. 10 di 81



o Riguardo l'autenticazione basata su ToscanaID il modulo di autenticazione verifica la validità del paring del dispositivo basata su un codice di autenticazione (secureToken) generato a seguito della fase di pairing “identità vs Dispositivo” in particolare le verifiche che saranno effettuate sono:

a) che il secure token sia presente nel repository centrale e attivo;b) che il secure token non sia stato invalidato dall'utente o

dall'amministratore;c) che la versione di toscanaID non sia stata invalidata

dall'amministratore.

Primo accesso - Al primo accesso da parte dell'utente, il sistema provvede ad effettuare la verifica sincrona di alcuni dei ruoli esistenti sul sistema. I ruoli che devono essere verificati al primo accesso sono definiti staticamente sul sistema. Dall'istante di primo accesso inizia un'attività asincrona e automatica del sistema di verifica di tutti i ruoli posseduti dall'utente.

Verifica del Ruolo – Per gli utenti fisici l'appartenenza a ciascuno dei ruoli definiti sul sistema sarà verificata in modo automatico ed asincrono dal sistema stesso rispetto alla fase di registrazione. Periodicamente il sistema provvederà inoltre in modo autonomo ad aggiornare la validità delle associazioni tra ruoli ed utenti. L'utente ha la possibilità di richiedere al sistema l'avvio della procedura di aggiornamento stato dei ruoli posseduti. La verifica del ruolo e le funzionalità ad esso correlate sono realizzate attraverso il “Role Manager” che grazie ad una serie di Adapter è in grado di interrogare le diverse Fonti Dati.Il sistema prevede un processo che si attiva ad intervalli regolari (configurabili) ed estrae un insieme di utenti per cui è necessario eseguire un controllo dei ruoli. L'insieme degli utenti è scelto attraverso l'applicazione di una serie di filtri, ciascuno dei quali concorre ad includere od escludere un utente dalla lista. Tali filtri possono essere configurati in modo da essere utilizzati solo in certi orari, o solo dopo un tempo configurabile rispetto all'ultimo controllo eseguito (Trigger Temporale). Segue una tabella che riporta i filtri e le loro funzionalità:

Pag. 11 di 81



Filtro Descrizione Parametri PrecondizioniUtenti con Ruolo Scaduto

Il filtro ritorna la lista degli utenti con ruolo assegnato o non assegnato scaduto

Abilita/DisabilitaTrigger Temporale

Utente non in Pending

Utenti con Ruolo in Errore

Il filtro ritorna la lista degli utenti con almeno un ruolo in errore e con data ultima checkrole + Delta < Now

Abilita/DisabilitaTrigger TemporaleDelta


Utenti Con Assegnati Ruoli Marcati come Eliminati

Il filtro ritorna la lista degli utenti con assegnato un ruolo eliminato

Utenti Con Assegnati Ruoli Marcati come Eliminati


Utenti con Ultima Checkrole Eseguita Prima della Creazione di Un Ruolo

Il filtro ritorna la lista degli utenti con ultima checkrole iniziata prima della creazione di un ruolo e con eventuale ruolo padre assegnato



Utenti con Ultima Checkrole Eseguita Prima della Modifica di Un Ruolo

Il filtro ritorna la lista degli utenti con ultima checkrole iniziata prima della creazione di un ruolo e con il ruolo stesso assegnato



Utenti sulla quale in sistema non ha mai effettuato CheckRole

Il filtro ritorna gli Utenti sulla quale in sistema non ha mai effettuato CheckRole


Utenti orfani di Ruoli

Il filtro ritorna gli Utenti senza ruoli assegnati e con fine ultima checkrole + Delta < Now



Utenti con CheckRole In

Il filtro ritorna gli Utenti in pending


Pag. 12 di 81



Timeout con checkrole iniziata + Delta < Now

Delta

Utenti da Eliminare

Il filtro ritorna gli utenti il cui ultimo accesso 1+ Delta < Now. La checkrole eliminerà l'utente dal sistema



Per ogni utente per cui si esegue il controllo dei ruoli (checkrole) viene applicata la logica descritta dalla seguente tabella per stabilire se un ruolo è o meno assegnato all'utente.Il controllo viene applicato ad ogni ruolo scandito in ordine gerarchico, se non viene assegnato un ruolo non vengono verificati gli eventuali figli:

Stato del Ruolo Controllato Operazione EseguitaAssegnato e scaduto tenta verificaAssegnato e non scaduto assegnaNon assegnato (riverifica scaduta) riverificaNon assegnato (riverifica non scaduta)

nop

In errore (riverifica scaduta) tenta verificaIn errore (riverifica non scaduta) nopNuovo (mai verificato) tenta verifica

Accesso alle risorse - L’utente dopo la fase di autenticazione, selezionando una risorsa contenuta nel proprio desktop di portale, accede alle funzionalità da questa esposte. L'utente avrà inoltre la possibilità, previa autenticazione, di accedere direttamente alle risorse senza passare attraverso il desktop di portale; questa possibilità non esclude il controllo accessi sulla risorsa stessa che viene comunque effettuato. Gli utenti autenticati come soggetti fisici hanno inoltre la possibilità di delegare l’accesso a risorse ad altri soggetti fisici permettendo loro di operare in modalità delegata. L’accesso alle risorse può avvenire diretto oppure mediato da uno o più client:

o per Diretto si intende che è l’utente autenticato che accede direttamente alla risorsa desiderata, esempio la tipica web application;

o per Mediato si in intende che è un client applicativo ad effettuare le invocazioni per conto dell’utente finale, come nel caso di applicazioni mobile oppure Web 2.0.

L'accesso diretto alle risorse via desktop di portale avviene in base ad alcuni parametri riassunti nella seguente Tabella:

1 Per ultimo accesso si intende indifferentemente l'accesso effettuato utilizzando toscana ID ovvero certificato digitale

Pag. 13 di 81



Censito in Cache

Delegato Ha almeno un ruolo che permette l'accesso all'applicazione

Risultato

SI NO NO accesso negatoSI SI (1) NO accesso direttoSI SI (2 o +) NO accesso previa

disambiguazioneSI SI SI accesso previa

disambiguazioneNO NO NO accesso negatoNO SI (1) NO checkrole sinc. + accesso

diretto in delegaNO SI (2 o +) NO accesso previa

disambiguazioneNO SI SI (fra quelli

verificati in sinc)checkrole sinc. + accesso previa disambiguazione

NO SI SI (non fra quelli verificati in sinc)

checkrole sinc. + accesso diretto in delegaL'utente potrà accedere con il proprio ruolo dopo l'esecuzione della checkrole asincrona.

NO NO SI (fra quelli verificati in sinc)

checkrole sinc. + accesso diretto

NO NO SI (non fra quelli verificati in sinc)

checkrole sinc. + accesso negato

Pag. 14 di 81



L'accesso a risorse via Toscana ID avviene in base ad alcuni parametri riassunti nella seguente Tabella:

Censito in Cache Ha almeno un ruolo che permette l'accesso all'applicazione

Risultato

SI NO accesso negatoNO / accesso negatoSI SI accesso consentito

accesso previa disambiguazione (solo web): mostra una pagina dove l'utente può scegliere la modalità d'accesso (delega, quale delega, proprio accesso)

accesso negato: per accesso via browser o toscana ID mostra una pagina con messaggio del tipo: “in questo momento il sistema non ti ha riconosciuto il ruolo utile ad accedere alla risorsa da te selezionata; Il sistema tenterà di verificare i ruoli interessati e potrai vedere il risultato di questo tentativo nel riquadro impostazioni utente in basso”. In caso di accessi via app mobile collegata viene restituito un codice di errore gestibile dall'app collegata

Checkrole sincrona: controllo con attesa perché vengano verificati i ruoli definiti da sistema come da verificare prima della prima autenticazione dell'utente (esempio: cittadino, ruoli per cui vi è un particolare accesso di nuovi utenti)

Checkrole asincrona: controllo con processo in parallelo e relativa attesa per il risultato per verificare tutti i ruoli cui l'utente ha diritto. Nel frattempo l'utente può lavorare con i ruoli risultanti da checkrole sincrona.

Desktop di Portale personalizzato WEB - Dopo l'accesso autenticato al Portale web (indifferentemente se tramite “toscana id” ovvero certificato digitale), agli utenti viene presentato un Desktop personalizzato con l'insieme delle applicazioni (sotto forma di link URL) a cui possono accedere in base ai ruoli posseduti/dichiarati. La generazione del Desktop è dinamica e si basa sulle informazioni provenienti dai diversi sottosistemi che regolano il funzionamento del Portale.

Desktop di Portale personalizzato Su ToscanaID - Dopo l'attivazione dell'identità su Toscana ID, agli utenti viene presentato un Desktop personalizzato con l'insieme delle applicazioni (sotto forma di link URL o APP) a cui possono accedere in base ai ruoli posseduti/dichiarati. La generazione del Desktop è dinamica e si basa sulle informazioni provenienti dai diversi sottosistemi similmente allo scenario per Portale WEB.

Mancato accesso per un determinato periodo - Nel caso in cui un utente non acceda al sistema per un certo periodo di tempo, i dati di ruolo e attributo 2 associati alla sua utenza vengono rimossi. Tali dati potranno anche essere rimossi forzatamente attraverso le funzionalità di amministrazione.

2 Questo caso NON include i dati server side utili all'autenticazione via ToscanaID oppure nel caso di utilizzo della modalità offline

Pag. 15 di 81



Funzionalità di Amministrazione - Consentono all'amministratore l'esecuzione dei compiti di amministrazione nei diversi comparti quali Portale, Role Manager, Gestione utenze Toscana ID. Elemento comune delle funzionalità di Amministrazione sono l'utilizzo di un'interfaccia web, l'accesso attraverso il Portale, la definizione di un particolare ruolo Amministratore nel Portale che consente l'accesso alle funzionalità di Amministrazione dei singoli sottosistemi.

Pag. 16 di 81



3 ARCHITETTURA LOGICA

Il diagramma in Figura 1 Architettura logica illustra l’architettura logica di riferimento della soluzione proposta suddivisa nei suoi sottosistemi principali.

Figura 1 Architettura logica

Pag. 17 di 81



3.1 Sottosistemi principali e loro interazioni

L'architettura logica è composta da quattro aree funzionali principali, corrispondenti ai seguenti sottosistemi:

3.1.1 Role Manager

Descrizione Verifica che gli utenti abbiano diritto ai ruoli che dichiarano di possedere, interrogando, attraverso una serie di Adapter, le diverse fonti dati o Attribute Authority SPID. Consente di gestire ruoli, criteri, risorse e l’associazione tra essi.

Interazione con CART Pubblica sul CART gli eventi collegati alle operazioni d’inserimento, modifica e cancellazione di ruoli, risorse, attributi e criteri.

Interazione con GENERIC Nessuna interazione direttaInterazione con PORTAL Vedi interazione con CART e par. 4.1.2 (Interazione con

R.M.)

3.1.2 Portal

Descrizione Si occupa dell'autenticazione e autorizzazione degli utenti e del controllo degli accessi alle risorse disponibili attraverso il portale. È responsabile della costruzione del desktop per l'utente autenticato e profilato all'interno del portale.

Interazione con CART Legge dal CART gli eventi pubblicati dal ROLE MANAGER.Reagisce agli eventi pubblicati, collegati alle operazioni d’inserimento, modifica e cancellazione di ruoli, risorse, attributi e criteri, modificando dinamicamente la struttura dei ruoli di portale e le policy d’accesso alle risorse così come descritto nel paragrafo dedicato alla definizione dei requisiti.

Interazione con ROLE MANAGER

Contatta il blocco ROLE MANAGER mediante chiamate a servizi da questo esposti (Web Services) per la validazione delle associazioni ruolo/utente e il recupero dei valori degli attributi associati al ruolo in questione.

Interazione con GENERIC

Scambia informazioni con le applicazioni appartenenti al blocco GENERIC per offrire, in vari modi, l’integrazione di queste nel portale fino a garantire raggiungibilità dei servizi, fruibilità e Single Sign-On (SSO).

Pag. 18 di 81



Per la fruibilità del servizio e il Single Sign-On le modalità di azione possono essere diverse a seconda dell’applicazione da integrare: potrebbe essere previsto l’uso di SpAgent JEE o SpAgentPHP.

Interazione con SRTY Centralizza l’autenticazione e l’autorizzazione d’accesso ai servizi offerti.

3.1.3 Generic

GENERICDescrizione Rappresentano le applicazioni preesistenti o di

futuro sviluppo che possono essere integrate e rese fruibili attraverso il PORTAL. Tali applicazioni, non sviluppate mediante il framework SRTY, sono associate ai vari ruoli tramite l’interfaccia d’amministrazione del ROLE MANAGER.

Interazione con PORTAL Tutte le applicazioni appartenenti al blocco GENERIC hanno la necessità di comunicare direttamente con il PORTAL

Interazione con ROLE MANAGER Nessuna interazione direttaInterazione con CART Nessuna interazione direttaInterazione con SRTY Nessuna interazione diretta

3.1.4 SRTY

SRTYDescrizione SRTY è il framework di sviluppo della applicazioni

profilate ad accesso sicuro di Regione Toscana. Nell'ambito del framework SRTY possiamo identificare con SRTY Applications, gli applicativi installati nell'ambiente SRTY e con SRTY Core l'ambiente nel quale vengono installate le applicazione che utilizzano questo framework. Le SRTY Applications si interfacciano con il PORTAL per il reperimento delle credenziali dell’utente e vengono associate ai vari ruoli tramite l’interfaccia di amministrazione del ROLE MANAGER.

Interazione con PORTAL Poiché il PORTAL offre i meccanismi di autenticazione e autorizzazione per SRTY, tale blocco logico ha la necessità di comunicare con il PORTAL.

La comunicazione SRTY->PORTAL avviene su HTTP/s mediante l’uso del framework ARPA

Pag. 19 di 81



Common.Le librerie ARPA Common sono usate dalle

singole applicazioni del blocco SRTY per recuperare alcune informazioni relative all’utente nonchè per recuperare, interpretare ed applicare le politiche di autorizzazione.

La comunicazione PORTAL->SRTY avviene solo su http/s attraverso l'OpenAM che ridirige le connessioni dell'utente verso l'applicazione deployata sotto SRTY.

Interazione con CART SRTY legge dal CART gli eventi pubblicati dal ROLE MANAGER reagendo agli eventi collegati all’inserimento, modifica e cancellazione di un ruolo, come riportato nel paragrafo dedicato alla specifica dei requisiti.

Interazione con ROLE MANAGER Nessuna interazione diretta (lettura attraverso CART)

Interazione con GENERIC Nessuna interazione diretta

3.2 Banche Dati utilizzate

Le diverse aree funzionali descritte in precedenza ed i rispettivi sottosistemi si avvalgono per il loro funzionamento delle informazioni presenti in una o più delle banche dati che seguono.

CRL - Certificate Revocation ListContiene informazioni sulle revoche dei certificati di autenticazione degli utenti. Struttura PDC

Contiene le informazioni relative alle CA riconosciute dal PDC Auth Module; in particolare le CRL aggiornate e le indicazioni necessarie per recuperare il codice fiscale da usare come chiave di autenticazione degli utenti.

Directory ServerContiene le strutture dati necessarie al funzionamento del PORTAL. Memorizza per un

periodo temporaneo definito dall'Amministratore di Sistema, le informazioni relative agli utenti.

RuoliContiene tutti i ruoli definiti dal ROLE MANAGER con le relative caratteristiche.

RisorseElenco delle risorse accessibili attraverso il PORTAL.

CriteriContiene l’insieme di dati che selezionano e valorizzano opportunamente i parametri esposti dagli Adapter consentendone la specializzazione verso una particolare fonte dati.

Fonte DatiContiene le informazioni necessaria al ROLE MANAGER per verificare l’assegnazione dei

ruoli agli utenti attraverso specifici Adapter. Profili Applicativi

Descrivono le operazioni che gli utenti sono autorizzati ad effettuare all'interno degli applicativi SRTY.

Pag. 20 di 81



3.3 Definizione delle componenti dei sottosistemi

In questo paragrafo saranno descritte le componenti funzionali di ciascun sottosistema.

3.3.1 PORTAL Liferay Portal

Costruisce il desktop personalizzato per l'utente in base al suo ruolo. PDC Auth Module

Il Personal Digital Certificate (PDC) Module è la componente che implementa il requisito di autenticazione basata sulla verifica della validità del certificato digitale inviato dall’utente in fase di richiesta di servizio (accesso al portale); tecnicamente è quello che si definisce un modulo di autenticazione del portale.I certificati digitali supportati da tale modulo di autenticazione sono: CNS, CNS-like e CIE. Il concetto di validità di un PDC è affrontato, in questo documento, con maggiore dettaglio, nella sezione dedicata alla specifica dei requisiti funzionali.

Mobile AUTH Module: è la componente che implementa il requisito di autenticazione basata sulla verifica del meccanismo di autentivazione basata su toscanaID

AdministrationFornisce le funzionalità di amministrazione del sistema.

Pim Pollerconsente sia al componente interrupt_out_role che al componente RoleSyncClient di

utilizzare l'Integration Manager per il collegamento al CART Interrupt_out_role

Implementa il web service invocato dal componente Role Manager per invalidare una lista di associazioni utente ruolo

Role Sync ClientLegge / interpreta / gestisce i messaggi inoltrati dal Pim Poller, sincronizzando le

informazioni opportune, relative a ruoli, risorse e attributi, nel Directory Server. OpenAM

Si occupa di fornire le funzionalità di autenticazione e controllo degli accessi.Per ulteriori informazioni sulle funzionalità di questa componente si rimanda al riferimento (3).

External ARPA APIModulo utile all'accesso via sistemi di Backend alle funzionalità esposte dal datamanger

riguardo i dati collegati ad un soggetto.

3.3.2 ROLE MANAGER

Role DetectionSi occupa principalmente di verificare l’appartenenza di un utente, ad un determinato

ruolo. L’utente è identificato in base alla tipologia di soggetto con il quale ha fatto accesso

Il modulo di Role Detection espone due servizi:

1. Check Role

Pag. 21 di 81



Esegue la verifica di cui sopra (veridicità dei ruoli). Per ogni ruolo valido restituisce gli attributi valorizzati per l’accesso alle applicazioni da esso autorizzate.

2. Find RoleRestituisce l'elenco dei ruoli definiti nel sistema.

Il modulo di Role Detection, nel processo di verifica e discovery dei ruoli, può avvalersi di uno o più Adapter in base ai criteri definiti per ciascun attributo.

Proxy_Role (Role Sync Server)Pubblica i messaggi di notifica corrispondenti alla creazione, modifica e cancellazione di

ruoli nel ROLE MANAGER. Role Administration

Consente ad una specifica figura di amministratore, l'Amministratore dei Ruoli, la gestione dei ruoli, delle risorse e dei criteri.

AdapterIl modulo espone dei servizi di base al modulo di Role Detection, con un’interfaccia ben

definita, al fine di consentire l’interrogazione delle fonti dati esposte dai Certificatori di Ruolo. Le modalità di utilizzo di un Adapter rispetto, a quali fonti dati o Attribute Authority contattare, quali credenziali d’accesso utilizzare, quali attributi recuperare sono definite in fase di configurazione dei criteri. Nella stessa fase viene stabilito inoltre come effettuare un mapping dei loro nomi su quelli dei corrispettivi attributi associati ai ruoli. L’Adapter è di tipo Web Services.

3.3.3 SRTY SRTY Application(s)

Gli applicativi installati nell'ambiente SRTY. Role Sync Client

Legge / interpreta / gestisce i messaggi pubblicati dal Proxy Role (Role Sync Server). SRTY Core

Ambiente nel quale vengono installate le applicazioni SRTY. SpAgent

Plug-in software che si avvale delle ARPA Common per controllare che l’utente che richiede il servizio sia in possesso di una sessione valida di portale e per richiedere al blocco PORTAL le politiche di autorizzazione che interpreta ed applica.

3.3.4 GENERIC

Le applicazioni denominate GENERIC rappresentano le applicazioni preesistenti o di futuro sviluppo che possono essere integrate e rese fruibili attraverso il PORTAL.

Tali applicazioni, non sviluppate mediante il framework SRTY, sono associate ai vari ruoli tramite l’interfaccia di amministrazione del ROLE MANAGER. Tutte le applicazione, SRTY o GENERIC, associate ad uno qualunque dei ruoli definiti dal ROLE MANAGER saranno trattate allo stesso modo; l'unica differenza tra le varie applicazioni potrebbe essere la metodologia di integrazione.

Pag. 22 di 81



Tutte le applicazioni da integrare nel portale, non sviluppate con SRTY, sono da considerarsi facenti parte dell'insieme GENERIC.

L'integrazione di queste applicazioni può avvenire in due modi, entrambi in Single Sign-On (SSO):

1. con protezione assicurata da SpAgent per applicazioni JEE2. con protezione assicurata da SpAgentPHP per applicazioni PHP;

3.4 Scenario d’interazioni tra alcune componenti

Ai fini esclusivamente esemplificativi si riporta in Figura 2 Esempio di interazioni nelsistema uno scenario d’interazione tra alcune componenti principali del sistema. Lo scenario in questione fa riferimento ad una parte del processo di self-registration e non ha la pretesa di risolvere tutti i casi possibili che saranno approfonditi successivamente in corso d’opera.

Figura 2 Esempio di interazioni nel sistema

Pag. 23 di 81



3.5 Il Role Manager

Nell’ambito del funzionamento della soluzione proposta il ROLE MANAGER è un elemento di particolare importanza perché ad esso è delegata la fase di verifica dell’associazione ruolo/utente.

Il ruolo è caratterizzato da un insieme di attributi custoditi dai Certificatori di Ruolo che possono essere recuperati interrogando una o più Fonti Dati; attraverso le funzionalità del ROLE MANAGER il PORTAL è in grado quindi di validare l’appartenenza di un utente ad un determinato ruolo e recuperare quindi gli attributi necessari per l’accesso alle applicazioni.

Il ROLE MANAGER offre funzionalità di:

1. interrogazione e verifica del ruolo;2. amministrazione delle entità collegate (ruolo, risorsa, criterio);3. notifica delle operazioni sul ruolo attraverso l’infrastruttura di Cooperazione

Applicativa (CART).

Il ROLE MANAGER è composto principalmente dai moduli di:

1. Role Administration;2. Role Detection;3. Adapter.

Il ROLE MANAGER utilizza il Proxy_Role per l’interoperabilità basata sulla cooperazione applicativa.

La Figura 3 Architettura Logica del ROLE MANAGER evidenzia i moduli logici del ROLE MANAGER e le sue interfacce con le componenti esterne (CART, Fonti Dati, etc.).

Pag. 24 di 81



Figura 3 Architettura Logica del ROLE MANAGER

L’accesso di un utente al PORTALE (cfr REQ02, REQ03) implica la ricerca di tutti i ruoli che l'utente ricopre all'interno del portale.

. La certificazione dell’effettivo possesso di tali ruoli viene effettuata interrogando i

Certificatori di Ruolo, attraverso l’intermediazione del Role Manager.

La verifica della validità del ruolo relativo ad un utente avviene attraverso la componente Role Detection che in base a quanto specificato nei criteri, si collega alle fonti dati, mediante l’opportuno Adapter, per il recupero degli attributi di certificazione della validità del ruolo e degli attributi per l’accesso alle applicazioni.

Il Certificatore di Ruolo da contattare, la Fonte Dati da interrogare, nonché gli attributi da valorizzare, sono tutte informazioni specificate nella tabella dei criteri. La definizione di un criterio e la sua associazione ad un ruolo/attributo viene effettuata dinamicamente in fase di configurazione del ruolo e conservata opportunamente nella banca dati dei ruoli.

3.5.1 Role Administration

Il Role Administration implementa le funzionalità per l’amministrazione dei Ruoli, delle Risorse e dei Criteri.

Un ruolo viene definito mediante:

un nome univoco; una descrizione; un insieme di attributi aggiuntivi.

Pag. 25 di 81



Per ogni ruolo viene definito un certo numero di criteri che consentono la specializzazione degli Adapter per l’accesso a specifiche Fonti Dati per la:

certificazione del ruolo in oggetto; valorizzazione degli eventuali attributi associati.

Un criterio può essere associato ad un ruolo o ad un attributo. Per ogni ruolo sono definite le informazioni su come certificare la coppia ruolo/utente (fonte dati da contattare, Adapter da utilizzare, credenziali di accesso, etc.), mentre per un attributo sono definite le modalità di valorizzazione specificando:

fonte/i dati da contattare; Adapter da utilizzare; eventuali credenziali d’accesso; nome di riferimento con cui l’attributo è associato al ruolo; mapping tra i nomi che tale attributo ha presso ogni fonte dati e quello che ha come

riferimento nell’associazione al ruolo.

Una risorsa è definita con:

un nome univoco; una descrizione; un URL. un URL-mapping

La Figura 4 Corrispondenza informazioni tra ruolo e fonti dati mostra un esempio di corrispondenza delle informazioni del ruolo (certificazione ruolo ed attributi aggiuntivi relativamente ad un ipotetico utente del portale) con le informazioni presenti nelle Fonti Dati messe a disposizione dai Certificatori di Ruolo.

Pag. 26 di 81



Figura 4 Corrispondenza informazioni tra ruolo e fonti dati

Le relazioni tra le varie entità coinvolte nel funzionamento del Role Administration e più genericamente del portale, sono illustrate nel diagramma seguente (Figura 5). L’entità “Attributo-Fonte” è l’entità presente sulla fonte dati che permette la valorizzazione di uno specifico attributo del ruolo, in base al criterio definito per lo stesso attributo.

Figura 5 Relazioni tra le Entità del Role Manager

È possibile definire in modo separato ed in tempi diversi i criteri, i ruoli, gli attributi. In particolare, qualora venga definito un ruolo e non vengano selezionati o definiti immediatamente i relativi criteri di verifica, esso rimane in uno stato intermedio definito “bozza” e non viene reso disponibile agli altri moduli. Tale definizione potrà essere completata successivamente, rendendo il ruolo attivo e disponibile. L’aggiunta di un attributo al ruolo comporta invece l’obbligatoria ed immediata definizione dei relativi criteri.

Ai fini esclusivamente esemplificativi si riporta in Figura 6 un esempio di processo di definizione dei criteri, definizione dei ruoli ed utilizzo dei criteri per la certificazione del ruolo e la valorizzazione degli eventuali attributi.

Pag. 27 di 81



Figura 6 Processo di definizione dei ruoli, attributi e criteri

3.5.2 Role DetectionLa componente Role Detection espone due servizi:

CheckRole FindRole

Il Web Service CheckRole, invocato dal PORTAL (ed eventualmente da altre applicazioni autorizzate) fornendo in input il Codice Fiscale o Partita Iva e il/i ruolo/i per i quali deve essere verificata l’appartenenza di un dato utente, ritorna la conferma o negazione del ruolo in verifica ed eventuali attributi aggiuntivi.

Il Web Service FindRole restituisce l’elenco dei ruoli definiti nel Role Manager.

3.5.3 AdapterPer l’accesso alle Fonti Dati il ROLE MANAGER si avvale del modulo Role Detection che a

sua volta fa uso degli Adapter per l’accesso alle fonti dati.Sarà fornito un Adapter per la comunicazione con le Fonte Dati che espongono Web

Services.

L’architettura del Role Detector consentirà di sviluppare nuovi Adapter. L’eventuale necessità di accedere ai dati messi a disposizione da una Fonte Dati non standard o semplicemente non prevista potrà essere risolta mediante l’implementazione di un opportuno Adapter scritto ad ad-hoc.

Pag. 28 di 81



3.5.4 Notifica delle operazioni sul ruolo verso PORTAL e SRTYLa sincronizzazione delle informazioni relative ai ruoli, risorse e attributi tra il Role

Manager e altri Sistemi/sottosistemi, avviene tramite il Proxy_Role (Role Sync Server) utilizzando l’infrastruttura di Cooperazione Applicativa (CART).

In particolare, si prevede l’utilizzo della modalità di cooperazione applicativa di tipo EDA – Event Driver Architecture o cooperazione ad eventi basata sullo scambio asincrono di messaggi tra i diversi domini, ovvero i partecipanti non devono restare connessi in attesa di una risposta dal destinatario, ma possono limitarsi ad inviare il messaggio affidandolo all'infrastruttura di servizio con il compito di gestirne la consegna in modo affidabile.

La modalità scelta per la cooperazione ad eventi è quella Publish & Subscribe, in cui il Role Manager, attraverso il Proxy_Role implementato sul NAL, pubblicherà gli eventi legati alla variazione (creazione, modifica, cancellazione) di un ruolo e relative informazioni collegate (attributi e risorse) all’interno del repository dei ruoli; i sottoscrittori di tali eventi saranno il PORTAL, che dovrà aggiornare il suo repository e l’SRTY.

Pag. 29 di 81



4 Realizzazione della soluzione

Vengono di seguito elencati e descritti i requisiti non-funzionali e funzionali sui quali si è basata l’analisi e la progettazione.

4.1 Requisiti non funzionali

REQNF01

Nome Amministrazione centralizzata

Descrizione Ogni utente amministratore deve avere un solo punto di accesso per tutte le operazioni di amministrazione relative a ciascun sottosistema.Il sottosistema PORTAL dovrà offrire un desktop per l'utente amministratore (Administrator) da dove poter accedere a tutte le funzionalità di amministrazione (cfr. REQ26).

Use Cases UC11, UC12, UC13, UC14, UC15

REQNF02

Nome Utilizzo del CART

Descrizione È posto come vincolo l'utilizzo del CART per le operazioni di sincronizzazione delle informazioni relative ai ruoli e alle risorse.Il ROLE MANAGER pubblicherà sul CART i dettagli circa le operazioni effettuate da Administrator sui ruoli e sulle risorse; tutti gli altri sottosistemi potranno quindi accedere a tali informazioni per allineare i propri repository


REQNF03

Nome Accesso alle risorse

Descrizione Scopo principale del sistema in oggetto è quello di offrire una infrastruttura di accesso diretto alle risorse disponibili.

Affinché l’accesso diretto sia possibile deve verificarsi una ed una soltanto delle seguenti condizioni:

la risorsa è installata in un container web compatibile con l'installazione di SpAgent (si veda la documentazione relativa indicata nel glossario in 1.3);

Pag. 30 di 81



la risorsa è installata in un container web compatibile con l'installazione di SpAgentPHP (si veda la documentazione relativa indicata nel glossario in 1.3).

Le modalità di accesso che PORTAL ovvero ToscanaID mettono a disposizione per le risorse variano in funzione della natura delle risorse stesse; in particolare:

per SRTY: si prevede di utilizzare SpAgent a livello di framework così da permettere il massimo grado di integrazione possibile;

per GENERIC:✔ se si tratta di applicazioni sviluppate in PHP verrà utilizzato il

componente SpAgentPHP;✔ se si tratta di applicazioni JEE modificabili o da sviluppare, la

soluzione migliore, come per SRTY, rimane l’SpAgent.

In dettaglio, l’SpAgent (sia Java che PHP) ha il compito di verificare che l'utente sia autenticato e che abbia diritto di accedere alle risorse; in caso di esito positivo di tale verifica, le risorse – tramite opportune librerie – possono accedere al codice fiscale, ai ruoli e agli attributi dell'utente.

Use Cases UC4, UC5, UC6, UC7, UC8, UC9

REQNF04

Nome Sicurezza

Descrizione Per i dettagli relativi alla sicurezza si faccia riferimento alla Sezione 5 di questo documento.

Use Cases

REQNF05

Nome Retrocompatibilità di SRTY

Descrizione La versione di SRTY sviluppata per l'integrazione nel presente sistema dovrà essere retrocompatibile con la versione attualmente operativa.In particolare le applicazioni correntemente disponibili all’interno della versione attualmente operativa non necessiteranno di alcuna modifica per funzionare con la nuova versione, eccezion fatta per la sezione relativa ai ruoli ed alla loro associazione con i profili applicativi.

Use Cases

REQNF06

Pag. 31 di 81



Nome Amministrazione di SRTY

Descrizione Dal punto di vista tecnologico, la sezione di amministrazione di SRTY sarà mantenuta uguale a quella attualmente operativa; essa sarà cioè costituita da un’applicazione web a sua volta utilizzante il framework SRTY.Si accederà a tale applicazione in maniera analoga a quella prevista per le altre applicazioni sviluppate col framework SRTY.

Use Cases

REQNF07

Nome Importazione iniziale degli utenti di dominio interno

Descrizione Prima della messa in opera del sistema verranno importati i dati di accesso relativi agli utenti di dominio interno in modo che questi possano trovare assegnati i propri ruoli fin dal primo accesso.

Use Cases

REQNF08

Nome Supporti di autenticazione

Descrizione Il sistema accetta i seguenti supporti di autenticazione (cfr. REQ01) per l’autenticazione degli utenti:

–– certificati digitali di autenticazione la cui CA è accettata

da regione Toscanaall'interno dei quali sia presente il codice fiscale del soggetto in una posizione deducibile da CA e policy del certificato (quali ad esempio CNS, CNS-like, Documento Unificato di prossima emissione)

– meccansimo proprio di Toscana ID– Spid

Per CNS-like si intendono quei supporti di autenticazione con la stessa struttura dei supporti CNS ma emessi da CA non registrate pubblicamente.Per Spid si intende il sistema di identità digitale (vedi schema di D.P.C.M.)

Use Cases

REQNF09

Nome Vincoli prestazionali

Pag. 32 di 81



Descrizione Le prestazioni delle funzionalità di verifica dei ruoli (cfr. REQ05) dipendono in maniera assoluta dai tempi operativi e di risposta delle fonti dati e Attribute Authority.

Use Cases

REQNF11

Nome Livello di sicurezza strumento di autenticazione Toscana ID

Descrizione Toscana ID implementa anche la funzionalità di SOFT CriptoToken 3 su dispositivo utente.

Si attende un sostanziale raggiungimento lato tecnico del Livello 3 così come descritto da

Il processo di rilascio della credenziale avviene tramite autenticazione con strumento di livello 4 (CNS o CNS like) ovvero “riconoscimento de visu (requisito rilassato in fase 1)”

La credenziale ha una durata temporale di X (3?) anni [[verificare con grazia]] passati I quali viene invalidata.

La one timepassord rilasciata al momento della generazione della credenziale per l'utente ha una durata limitata nel tempo configurabile (3gg???) [verificare con Grazia]

La credenziale di TOSCANA ID può essere invalidata-su iniziativa del soggetto titolare sia utilizzando la medesima credenziale sul dispositivo su cui è intallato Toscana ID sia utilizzando via WEB utilizzando gli strumenti previsti dal PDC-tramite funzioni amministrative

Use Cases

REQNF10

Nome Accessibilità

3A cryptographic key that is typically stored on disk, USB stick or some other media. Authentication is accomplished by proving possession and control of the key. The soft token shall be encrypted under a key derived from a password known only to the user, so knowledge of a password is required to activate the token. Each authentication shallrequire entry of the password and the unencrypted copy of the authentication key shall be erased after each authentication

Pag. 33 di 81



Descrizione Le componenti principali del sistema che prevedono un’interazione di tipo web con l’utente (accesso alle risorse e deleghe) saranno realizzate tenendo conto dei requisiti di accessibilità web contenuti nella versione 2.0 delle Web Content Accessibility Guidelines (WCAG 2.0) prodotte dal World Wide Web Consortium, specifiche a cui sta per adeguarsi anche la normativa nel nostro paese

Use Cases

4.2 Requisiti funzionali

REQ01

Nome Accesso autenticato

Descrizione Nel momento in cui un utente, Internet User o Domain User, tenta l'accesso, il sistema deve richiedere un certificato di autenticazione valido (PDC), in subordine tenta la verifica dell'autenticazione secondo I meccanismi previsti da ToscanaID. In assenza di ciò viene presentata all'utente una pagina per l'inizio del processo di autenticazione previsto da Spid.Accesso via Certificato per soggetti fisici:Una volta che l'utente fornisce il certificato richiesto, il sistema verificherà che: sia un certificato valido rilasciato da una CA riconosciuta; non sia scaduto; Il seriale del certificato non compaia nelle liste di revoca (CRL) a

disposizione del sistema. siano soddisfatte le policy associate al certificatoSe tali requisiti sono soddisfatti, il sistema dovrà verificare che:

l'utente non sia in Black ListAccessio Via ToscanaID per soggetti fisiciUna volta che l'utente fornisce il la credenziale richiesta, il sistema verifica che: la credenziale Toscana ID sia tra quelle rilasciate dal sottosistema

ToscanaID la credenziale non sia scaduta.Se tali requisiti sono soddisfatti, il sistema dovrà verificare che:

l'utente non sia in Black ListAccesso attraverso SPID per soggetti fisici e giuridici:

l'utente non sia in Black List l'asserzione sia corretta e provenga da un Identity Provider Spid

appartenenti al circuito di fiducia (sia soggetti fisici che giuridici)Nel caso in cui tutti i requisiti sono soddisfatti, l'utente sarà

Pag. 34 di 81



autorizzato a proseguire e quindi ad accedere al proprio desktop di portale (REQ03).In caso di autenticazione fallita dovuta ad un motivo qualunque collegato ai prerequisiti di cui sopra, il sistema dovrà restituire una pagina d'errore.

Use Cases UC1, UC2

REQ02

Nome Primo Accesso al Portale

Descrizione Per primo accesso si intende la situazione per cui I dati di ruolo e attributo dell'utente non sono presenti nella cache di ARPA, questo può accadere sia perchè si tratta del primo accesso in assoculuto sia perchè l'utente non ha acceduto per 90 giorni (vedi requisto 20)

Nel caso in cui un utente,dotato di un credenziale valida (REQ01), si presenti al sistema per un primo accesso, gli verrà presentato un desktop di portale temporaneo mentre il sistema inizia la procedura di verifica dei soli ruoli definiti per la verifica sincrona al primo accesso.

Contemporaneamente l'utente viene schedulata dal sistema l'attivita' asincrona di verifica di tutti i ruoli definiti: in particolare, per ogni ruolo tale che la coppia utente / ruolo non sia presente nella White List (REQ08), dovrà essere effettuato un controllo presso il ROLE MANAGER al fine di verificare che l'utente possa o meno ricoprire il ruolo in questione (REQ05). Per ogni ruolo valido il ROLE MANAGER dovrà restituire una lista di attributi valorizzati (chiave, valore) che il sistema dovrà provvedere a memorizzare nel repository di PORTAL, compatibilmente con quanto stabilito in REQ21.L’utente potrà accedere ad un desktop temporaneo da cui fruire delle risorse associate ai ruoli sottoposti a verifica sincrona, man mano che questi vengano validati con successo.Il desktop temporaneo potrebbe essere differente a seconda che l’autenticazione sia effettuata da soggetti fisici o giuridici.La necessità di mantenere l’utente in uno stato temporaneo durante la fase di validazione (REQ05) deriva dal fatto che l’operazione in questione non può essere soggetta a vincoli prestazionali (cfr. REQNF09).

Use Cases UC1, UC2

REQ03

Nome Desktop di portale

Descrizione Il sistema dovrà presentare a ciascun utente autenticato il proprio desktop di portale.

Pag. 35 di 81



Il desktop dovrà visualizzare tutte e sole le risorse a cui l'utente può accedere in ragione dei propri ruoli, al livello di autenticazione utilizzato e a seconda se è un soggetto fisico o giuridico.

Use Cases UC1, UC2

REQ03 MOBILE

Nome Desktop di ToscanaID

Descrizione Il sistema ToscanaID deve presentare, a ciascun utente, l'elenco personalizzato sulla base dei ruoli posseduti dei servizi fruibili (sia servizi web che appliazioni native).L'account utente su ToscanaID può creato a seguito di una procedura di associazione ToscanaID oppure mediante l’autenticazione SPID. L'utente può proteggere l'accesso al proprio account su ToscanaID grazie all'inserimento di un pin da immettere ad ogni accesso all'area autenticata delle applicazioni native.Tale funzionalità è disponibile per I soli soggetti fisici.

Use Cases UC21... UC27

REQ04

Nome Gestione delle Liste di Revoca (CRL)

Descrizione Il sistema dovrà mettere a disposizione una funzionalità per la gestione delle liste di revoca dei certificati.

Use Cases UC1, UC2

REQ05

Nome Controllo di appartenenza di un utente ad un ruolo

Descrizione Il sistema dovrà mettere a disposizione di tutti gli altri sottosistemi ed in particolare del sottosistema PORTAL, una funzionalità per verificare se un certo utente, al momento della richiesta, possa essere associato ad un determinato ruolo.La funzionalità in questione, a partire da un Codice Fiscale (CF) oppure Partita Iva (PI) ed un ruolo qualunque, dovrà essere in grado di rispondere, controllando sulle specifiche fonti dati, se l'associazione tra codice fiscale e ruolo sia possibile o meno.In caso affermativo dovrà restituire una lista di attributi valorizzati (chiave, valore) per l’accesso alle applicazioni che il ruolo autorizza.Le informazioni relative agli attributi di accesso alle applicazioni,

Pag. 36 di 81



saranno recuperate dal ROLE MANAGER cercando nelle fonti dati accessibili dall'intero sistema, o altri sistemi federati.

Use Cases UC1, UC2

REQ06

Nome Elenco di tutti i ruoli

Descrizione Il sistema deve mettere a disposizione di tutti gli altri sottosistemi ed in particolare del sottosistema PORTAL, una funzionalità per mostrare tutti i ruoli registrati.

Use Cases UC1, UC2

REQ08

Nome White List

Descrizione La White List è un insieme di associazioni (utente, ruolo). Per ogni coppia di questo tipo, il sistema associerà all'utente il ruolo indicato senza essere sottoposto alle verifiche di cui al REQ05. Le associazioni in White List non sono sottoposte ai vincoli temporali di validità di cui al REQ21.Le verifiche di cui al REQ05 hanno anche la conseguenza di valorizzare gli attributi associati ai ruoli sotto verifica; poiché in caso di White List le verifiche non hanno luogo, è necessario valorizzare gli attributi attraverso le funzionalità di amministrazione (cfr. REQ36 e REQ37).La gestione delle associazioni in White List e la valorizzazione degli attributi associati ai ruoli sarà possibile attraverso l'ambiente di amministrazione (cfr. REQ26, REQ36 e REQ37).

Use Cases

REQ09

Nome Verifica del profilo utente

Descrizione Il sistema dovrà mettere a disposizione degli utenti la funzionalità per la verifica del proprio profilo.In attesa del completamento del processo di validazione l’utente avrà accesso al desktop temporaneo così come previsto per la funzionalità di Self Registration (REQ02),

Use Cases UC10

REQ11

Pag. 37 di 81



Nome Inserimento di un nuovo ruolo

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un nuovo ruolo.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di inserimento di un nuovo ruolo.L'amministratore fornisce per il nuovo ruolo:

nome (obbligatorio); descrizione (opzionale); criteri per certificazione del ruolo, con relativi parametri (opzionale,

selezionati dall’elenco dei criteri disponibili). Fin quando tali criteri non sono forniti, il ruolo rimane in uno stato intermedio (bozza) e non è reso disponibile sul portale (non notificato su CART);

eventuali attributi da associare al ruolo (con relativi criteri, eventuali valori di default e parametri per la valorizzazione);

una lista di risorse da associare al ruolo (una o più risorse prese dalla lista di tutte le risorse presenti);

periodo di validità (obbligatorio) (cfr. REQ21)Il ROLE MANAGER registrerà il ruolo nel suo repository e comunicherà tramite CART l'avvenuta operazione.PORTAL dovrà reagire alla pubblicazione sul CART definendo un nuovo ruolo di portale e definendo le policy di accesso alle risorse in base a quanto specificato per il nuovo ruolo creato.SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al nuovo ruolo.

Use Cases UC11

REQ12

Nome Modifica di un ruolo esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la modifica di un ruolo esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, e quindi scegliere di effettuare l'operazione di modifica di un ruolo esistente.L'amministratore dovrà scegliere il ruolo da modificare tra la lista di tutti quelli presenti, dovrà specificare le modifiche e quindi avviare l'operazione.Il sistema registrerà la modifica nel suo repository e comunicherà tramite CART l'avvenuta operazione.PORTAL dovrà reagire alla pubblicazione sul CART modificando il ruolo

Pag. 38 di 81



di portale corrispondente, rimuovendo la lista degli attributi concernenti le applicazioni associate al ruolo in questione ed eventualmente modificando le policy di accesso alle risorse.Inoltre, il sistema PORTAL, per tutti gli utenti associati a tale ruolo, dovrà forzare la scadenza del ruolo stesso implicando una nuova verifica dell’associazione tra ruolo ed utente.SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al ruolo modificato.

Use Cases UC12

REQ13

Nome Cancellazione di un ruolo esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di un ruolo esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di un ruolo esistente.L'amministratore dovrà scegliere il ruolo da cancellare tra la lista di tutti quelli presenti e quindi avviare l'operazione.Il ROLE MANAGER registrerà la modifica nel suo repository e comunicherà tramite CART l'avvenuta operazione.PORTAL dovrà reagire alla pubblicazione sul CART rimuovendo il ruolo di portale corrispondente, rimuovendo la lista degli attributi concernenti le applicazioni associate al ruolo in questione ed eventualmente modificando le policy di accesso alle risorse.SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al ruolo cancellato.

Use Cases UC13

REQ14

Nome Inserimento di una nuova risorsa

Pag. 39 di 81



Descrizione Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di una nuova risorsa.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di inserimento di una nuova risorsa.L'amministratore fornisce per la nuova risorsa:

nome (obbligatorio); link di riferimento (obbligatorio); descrizione (opzionale); url mapping (obbligatorio).Il ROLE MANAGER registrerà la risorsa nel suo repository e comunicherà tramite CART l'avvenuta operazione.

Use Cases UC14

REQ15

Nome Modifica di una risorsa esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la modifica di una risorsa esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di modifica di una risorsa esistente.L'amministratore dovrà scegliere la risorsa da modificare tra la lista di tutte quelle presenti, dovrà specificare le modifiche e quindi avviare l'operazione.Il ROLE MANAGER modificherà la risorsa nel suo repository e comunicherà tramite CART l'avvenuta operazione.Nel caso in cui la risorsa fosse assegnata ad un ruolo, PORTAL dovrà reagire alla pubblicazione sul CART modificando il ruolo al proprio interno: rimuovendo la lista degli attributi relativi alle applicazioni associate al ruolo e modificando adeguatamente le security policy relative alla risorsa in questione.

Use Cases UC14

REQ16

Nome Cancellazione di una risorsa esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di una risorsa esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il

Pag. 40 di 81



ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di una risorsa esistente.L'amministratore dovrà scegliere la risorsa da cancellare tra la lista di tutte quelle presenti e quindi avviare l'operazione.Il ROLE MANAGER cancellerà la risorsa nel suo repository e comunicherà tramite CART l'avvenuta operazione.Nel caso in cui la risorsa fosse assegnata ad un ruolo, PORTAL dovrà reagire alla pubblicazione sul CART modificando il ruolo al proprio interno: rimuovendo la lista degli attributi relativi alle applicazioni associate al ruolo e modificando adeguatamente le security policy relative alla risorsa in questione.

Use Cases UC14

REQ17

Nome Inserimento di un nuovo criterio

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un nuovo criterio.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di inserimento di un nuovo criterio.L'amministratore fornisce per il nuovo criterio:

nome (obbligatorio); tipo (obbligatorio); descrizione (opzionale). ulteriori campi obbligatori (definizione delle politiche di verifica dei

ruoli, di recupero degli attributi e di mapping dei nomi degli attributi da e verso le fonti dati).

Il ROLE MANAGER registrerà il criterio nel suo repository.

Use Cases UC15

REQ18

Nome Modifica di un criterio esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la modifica di un criterio esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di modifica di un criterio esistente.

Pag. 41 di 81



L'amministratore dovrà scegliere il criterio, definire le modifiche e quindi avviare l'operazione.Il ROLE MANAGER registrerà le modifiche al criterio nel suo repository.

Use Cases UC15

REQ19

Nome Cancellazione di un criterio esistente

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di un criterio esistente.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di un criterio esistente.L'amministratore dovrà scegliere il criterio e quindi avviare l'operazione.Nel caso in cui il criterio in questione sia associato ad un certo ruolo, il sistema deve permettere, in maniera automatica o manuale, di effettuare una operazione per eliminare tale associazione. Solo quando un criterio non sarà associato ad alcun ruolo allora l'operazione di cancellazione può essere portata a termine.Il ROLE MANAGER rimuoverà il criterio nel suo repository.

Use Cases UC15

REQ20

Nome Rimozione automatica utenti

Descrizione Se un utente registrato, sprovvisto di credenziali ToscanaID o deleghe in uscita non acceda al sistema per un periodo superiore a 90 giorni allora il sistema dovrà eliminarne i dati memorizzati, ad eccezione delle eventuali associazioni in White List (cfr.REQ08). L'utente ed i propri dati vengono eliminati anche nel componente Portal

In tal caso, per un eventuale accesso successivo, l'utente rimosso dovrà effettuare una nuova procedura di Primo Accesso (REQ02).

Use Cases

REQ21

Nome Validità dei ruoli

Descrizione L’attribuzione di un ruolo ad un determinato utente ha una validità temporale limitata, definibile in maniera indipendente per ogni ruolo.

Pag. 42 di 81



Il sistema verificherà automaticamente la validità dell’attribuzione dei ruoli agli utenti: allo scadere del periodo di validità – per ogni utente, per ogni ruolo – il sistema provvederà ad effettuare una nuova verifica presso il ROLE MANAGER. In caso di esito positivo, il periodo di validità verrà rinnovato e la lista degli attributi per l’accesso alle applicazioni verrà aggiornato.

Use Cases

REQ22

Nome Accesso ai dati utenti da SRTY

Descrizione SRTY, in assenza di problemi di networking, dovrà poter accedere, tramite ARPA Common, ai dati dell'utente che sta effettuando la richiesta.Tramite opportune funzionalità messe a disposizione si potrà accedere ai dati memorizzati dall'OpenAM subito dopo l'autenticazione dell’utente.L’informazione minima necessaria al corretto funzionamento di SRTY è quella relativa al CF, ai ruoli dell'utente che effettua la richiesta ed agli attributi relativi ad ogni applicazione associata ai ruoli ricoperti dall’utente al momento dell’accesso.

Use Cases UC4, UC5, UC6

REQ23

Nome Sincronizzazione dei ruoli da parte di SRTY

Descrizione Dovrà essere predisposta la funzionalità per mantenere allineate le definizioni dei ruoli di SRTY con quelle relative al ROLE MANAGER.La comunicazione tra ROLE MANAGER e SRTY avverrà tramite CART.


REQ24

Nome Gestione dei profili applicativi per SRTY

Descrizione La gestione dei profili applicativi sarà identica a quella presente nella versione di SRTY attualmente operante.Sarà quindi possibile definire le funzionalità applicative per ogni applicazione sviluppata e raggruppare le funzionalità in opportuni profili applicativi.


Pag. 43 di 81



REQ25

Nome Associazione Ruoli – Profili applicativi

Descrizione Dovrà essere predisposta una funzionalità per mezzo della quale dovrà essere possibile eseguire l’associazione tra i ruoli (definiti dal ROLE MANAGER) ed i profili applicativi definiti all’interno di SRTY.La determinazione dei ruoli relativi all’utente sarà quindi l’unica operazione strettamente necessaria per la corretta definizione della pagine applicative di presentazione.


REQ26

Nome Amministrazione

Descrizione Il sistema dovrà fornire le funzionalità per:

Inserimento, modifica e cancellazione ruoli; Inserimento, modifica e cancellazione risorse; Inserimento, modifica e cancellazione criteri; Inserimento, modifica e cancellazione attributi; Inserimento e rimozione di utenti in Black List; Inserimento e rimozione di utenti in White List; Gestione della struttura PDC; Definizione, modifica e rimozione deleghe; Rimozione forzata degli utenti dal sistema (cfr. REQ20).

In fase di definizione dei criteri dovrà essere possibile specificare: come verificare l’associazione Codice Fiscale (CF), Partita Iva

(PI), ruolo, per ciascun ruolo configurato; come recuperare il valore di ogni attributo associato ad un certo

ruolo; il mapping tra il nome che referenzia un certo attributo

all’interno di un ruolo ed il nome che tale attributo ha su ciascuna fonte dati sulla quale si recupera uno qualunque dei suoi valori (attributi multivalue tipo ASL di appartenenza).

Come specificato in REQNF01, l'interfaccia di amministrazione sarà centralizzata; questo però solo per quanto riguarda la logica di presentazione: le funzionalità dovranno essere dislocate tra i vari sottosistemi in base alle aree di competenza.

In particolare:

SRTY offrirà funzionalità di amministrazione tramite

Pag. 44 di 81



un’applicazione web, in maniera analoga a quella della versione attualmente in uso (REQNF06)

PORTAL e ROLE MANAGER forniranno componenti di amministrazione che saranno rese fruibili attraverso il desktop di portale agli utenti amministratori, in aggiunta alle eventuali risorse che questi utenti visualizzeranno in ragione dei ruoli posseduti.

Verranno inoltre definiti diversi livelli di amministrazione così che sia possibile modulare l’insieme delle funzionalità di amministrazione cui ogni singolo utente è in grado di accedere.


REQ27

Nome Gestione delle deleghe

Descrizione Il sistema dovrà fornire la possibilità ad un qualunque utente autenticato come soggetto fisico di delegarne un altro per l’accesso a determinate risorse; le risorse oggetto di delega possono essere solo quelle per le quali il delegante, ha diritto di accesso in ragione dei ruoli posseduti.Le risorse associate a ruoli amministrativi non sono delegabili.L’utente, opportunamente autenticato ed autorizzato, dovrà avere la possibilità, attraverso una apposita interfaccia integrata nel proprio desktop di portale, di creare “oggetti delega”.Tali oggetti conterranno le seguenti informazioni:

codice fiscale delegante codice fiscale delegato ruolo oppure coppia risorsa / ruolo oggetto della delega attributi relativi al ruolo in oggetto vincoli temporali di validità della delega

Queste informazioni saranno memorizzate all'interno di un ramo separato del repository del blocco logico PORTAL.Ognuno di questi oggetti sarà opportunamente visualizzato sul desktop di portale dell’utente delegato unitamente alle risorse alle quali l'utente in questione ha diritto di accedere.

Use Cases

REQ28

Nome Accesso a risorse delegate

Pag. 45 di 81



Descrizione Se l'utente (detto delegato) accede alle risorse fornendo – oltre al proprio codice fiscale, i propri ruoli ed i propri attributi – anche un altro codice fiscale, un altro ruolo ed altri attributi (ossia quelli del delegante), le risorse dovranno comportarsi come se ad accedere fosse l'utente delegante con il ruolo e gli attributi indicati.Una delega può interessare tutte le risorse di un determinato ruolo o solo un sottoinsieme di queste.

Use Cases UC18

REQ29

Nome Validità delle deleghe

Descrizione La validità di una delega ha dei vincoli temporali specificabili per: data di inizio validità / data di fine validità ora di inizio validità / ora di fine validità periodicità

Use Cases

REQ30

Nome Amministrazione delle deleghe

Descrizione Un utente può delegare un altro utente su ognuna delle risorse e dei ruoli a lui attribuiti.L'amministratore (Administrator) può definire deleghe su qualsiasi coppia di utenti limitatamente ai ruoli posseduti dal delegante.

Use Cases

Pag. 46 di 81



REQ31

Nome Tracciabilità delle deleghe

Descrizione PORTAL terrà traccia degli accessi alle risorse in modalità delegata; il registro di tali accessi conterrà almeno:

data e ora dell’accesso risorsa alla quale si sta accedendo codice fiscale del delegante codice fiscale del delegato

Le operazioni effettuate dagli utenti che accedono in modalità delegata ad una risorsa saranno inoltre registrate dalla risorsa stessa.

Use Cases UC18, UC1

REQ32

Nome SAML Identity Provider

Descrizione Un utente che abbia acceduto al portale e che, in ragione dei propri ruoli, abbia diritto di usufruire dei servizi offerti da un ente esterno federato, deve poterlo fare senza la necessità di autenticarsi nuovamente.All’interno del sottosistema PORTAL sarà necessario configurare la componente Idp che si occuperà di fornire all'ente federato (che svolge il ruolo di SAML Service Provider – SP), le credenziali di accesso ed un insieme di attributi ulteriori relativi all'utente che ha effettuato la richiesta.Nel caso in cui dovessero esistere un SP o un gruppo di SP che richiedono attributi diversi rispetto a quelli previsti di default, sarà necessario sviluppare un software ad-hoc dedicato a soddisfare tale richiesta. Per la realizzazione di tale software non si prevedono meccanismi automatici di generazione e configurazione.Il SAML Identity Provider – IdP fornirà agli SP solo le informazioni che vengono attualmente inviate agli SpAgent e SpAgentPHP. Sarà compito esclusivo degli SP interpretare le informazioni ricevute.

Use Cases UC20

REQ33

Nome Gestione della struttura PDC

Descrizione Il sistema dovrà mettere a disposizione le funzionalità per la gestione della struttura dei dati utilizzati dal PDC Auth Module.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata e selezionare la sezione riguardante

Pag. 47 di 81



l’autenticazione PDC.L'amministratore fornisce per ogni CA che verrà riconosciuta dal PDC Auth Module ai fini dell’autenticazione degli utenti: nome (obbligatorio); descrizione (opzionale); tipologia di accesso alle CRL (obbligatorio); indicazioni necessarie per recuperare il codice fiscale da usare come

chiave di autenticazione degli utenti (obbligatorio). indicazioni sulla policy del certificato

Use Cases

REQ34

Nome Inserimento di un utente in Black List

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un utente in Black List.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la Black List, selezionare un utente tra quelli non presenti in Black List e quindi scegliere di effettuare l'operazione di inserimento in Black List.

Use Cases

REQ35

Nome Rimozione di un utente dalla Black List

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la rimozione di un utente dalla Black List.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la Black List, selezionare un utente tra quelli presenti in Black List e quindi scegliere di effettuare l'operazione di rimozione dalla Black List.

Use Cases

REQ36

Nome Inserimento di un utente in White List

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un utente in White List.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la White List, selezionare un utente ed un ruolo tra quelli definiti nel

Pag. 48 di 81



sistema; infine scegliere di effettuare l'operazione di inserimento in White List.Per ogni utente in White List l’amministratore deve fornire:

utente ruolo da considerare in White List per l’utente selezionato valorizzazione degli eventuali attributi contenuti nella

definizione del ruolo indicato

Use Cases

REQ37

Nome Rimozione di un utente dalla White List

Descrizione Il sistema dovrà mettere a disposizione la funzionalità per la rimozione di un utente dalla White List.L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la White List, selezionare un utente tra quelli presenti in White List e quindi scegliere di effettuare l'operazione di rimozione dalla White List per ognuno dei ruoli per cui è definita.

Use Cases

REQ38

Nome Utilizzo degli attributi Spid (Da IDP)

Descrizione Gi attributi identificativi (nome, cognome e codice fiscale) verranno utilizzati nelle stesse modalità dell'uso di CNS.Gli attributi identificativi (luogo e data di nascita, sesso, ragione e/o denominazione sociale, partita iva, estremi del documento di identità ) insieme all'insieme degli attributi secondari e/o qualificati sono utilizzati per popolare attributi Arpa (attraverso mapping) non soggetti a memorizzazione in cache ma volatili e validi per tutta la sessione utente in Arpa

Use Cases

REQ39

Nome Utilizzo degli attributi Spid (Da Attribute Authority)

Descrizione Gli attributi Spid provenienti da gestori di attributi qualificati saranno

Pag. 49 di 81



fruiti dal sistema Arpa per generare il profilo di sessione (TokenBean)

NOTA: Da capire se usare RM oppure altro, quando saranno pronte le specifiche.

Use Cases

REQ40

Nome Conservazione delle operazioni effettuate con Spid

Descrizione Il sistema deve memorizzare attributi (identificativi e non) di una identità Spid e tracciare le operazioni effettuate sul sistemi tramite Spid. (schema D.P.C.M articolo 13 comma 2)Al momento dell'accesso, dell'inoltro dell'utente ad un service provider Arpa ( o successivi inoltri) deve possibile tracciare attribute e operazione effettuate sui sistemi Arpa. Inoltre viene salvata l'asserzione proveniente da Idp Spid e la medesima asserzione è inoltrata ai service provider Arpa.

Use Cases

REQ41

Nome Rilevamento uso anomalo identità digitale Spid

Descrizione NOTA: occorre che AGID descriva il concetto di uso anomalo. (articolo 13 schema D.P.C.M comma 3)

Il sistema in caso di:

1) Numerosi accessi ravvicinati nel tempo che fanno supporre un uso automatico oppure furto dell'identità

…

attiverà un warning sul sistema di monitoraggio utile a intraprendere le attività previste dal comma stesso.

Use Cases

Pag. 50 di 81



REQ42

Nome Informativa delle Privacy Spid

Descrizione Il sistema prevede che gli utenti siano informati che l'identità digitale e gli attributi qualificati saranno verificati presso I gestori di identità ed attributi.

Use Cases

REQ43

Nome Livelli di sicurezza dell'identità digitale per accesso ai servizi

Descrizione Per ogni servizio Arpa deve essere possibile definire il livello minimo di sicurezza dell'identità digitale necessario all'accesso, in assenza di definizione è assunto il livello massimo.

L'accesso ad un servizio è permesso solo se l'identità digitale possiede un livello di sicurezza pari o superiore a quello definito dal servizio stesso.

La lista dei servizi presenti ordinata per ruolo deve mostrare il livello minimo di autenticazione necessario.

Sp Arpa deve essere in grado di recuperare (per sessione):

• il livello di sicurezza associato all'identità digitale corrente

• il sistema di identità digitale utilizzato; ad oggi Spid, Certificati Digitali Arpa (include CNS), Spid Like.

• L'identificativo dell'identity provider (nel caso Spid, Spid Like)

• La completa asserzione di identità (nel caso Spid, Spid Like)

• Gli attributi associati all'identità digitale (nel caso Spid, Spid Like)

Use Cases

REQ44

Nome Oauth2 Authorization Server

Pag. 51 di 81



Descrizione Un utente che abbia acceduto al portale e che, in ragione dei propri ruoli, abbia diritto di usufruire dei servizi offerti da un ente esterno federato, deve poterlo fare senza la necessità di autenticarsi nuovamente.All’interno del sottosistema PORTAL sarà necessario configurare la componente che si occuperà di fornire all'ente federato (che svolge il ruolo di Resource Server Oauth), le credenziali di accesso ed un insieme di attributi ulteriori relativi all'utente che ha effettuato la richiesta.

Use Cases

4.1 Casi d’uso

Di seguito sono illustrati alcuni scenari d’utilizzo dell'intero sistema. Per gli scenari d’utilizzo di seguito riportati, sono stati individuati i seguenti attori:

Internet userUtenti che accedono al sistema da Internet senza aver eseguito autenticazioni presso

uno degli Identity Provider riconosciuti dal sistema stesso. Domain user

Utenti che accedono al sistema dal dominio interno. Extra-domain user

Utenti che accedono al sistema da Internet dopo l'autenticazione presso uno degli Identity Provider riconosciuti dal sistema stesso.

AdministratorGli utenti che accedono con funzioni amministrative.

Nella descrizione degli scenari ci si è riferiti di volta in volta all’intero blocco logico PORTAL o ad alcune delle sue componenti (OpenAM, Liferay Portal) a seconda della necessità all’interno del contesto di riferimento.

4.1.1 Accesso Successivo

Nome UC1

Priorità Alta

Descrizione Un utente accede al portale con una credenziale valida.Il sistema legge il codice fiscale o parrtita iva, i ruoli assegnati e quelli derivanti dalla presenza in White List; se uno o più dei ruoli assegnati ha terminato il periodo di validità, il sistema provvede a verificarli di nuovo mediante una funzionalità esposta dal ROLE MANAGER.In caso di meccanismi di autenticazione con attributi qualificativi utili a popolare attributi o ruoli Arpa, questi sono inseriti nello

Pag. 52 di 81



userBean di sessione (attraverso apposito mapping).Sulla base di queste informazioni il sistema invia un desktop di portale contenente tutte e sole le risorse alle quali l'utente – in ragione dei propri ruoli – ha diritto di accedere.Alla lista dei ruoli esplicitamente selezionati dall’utente si aggiungono automaticamente

(6) tutti i ruoli antenati (internamente, i ruoli sono rappresentati ad albero);

(7) i ruoli di amministrazione per cui l’utente è in White List.(8) I ruoli di cui ha diritto secondo il mapping degli attributi

legati all'IDP Spid

Attori Internet user, Domain user

Precondizioni L'utente possiede un certificato di accesso valido.L'utente ha già acceduto in precedenza al sistema o i suoi dati sono stati importati inizialmente, nel caso del Domain user.

Eventi di ingresso

L'utente punta il proprio browser web sul punto di accesso al sistema.

Postcondizioni L'utente visualizza l'elenco delle risorse alle quali ha diritto di accedere.Eccezione 1: Se il sistema non riconosce il certificato come valido (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL, certificato scaduto, policy non corretta) invia una pagina di errore.

Pag. 53 di 81



Figura 7 Primo Accesso con CNS

4.1.2 Primo Accesso

Nome UC2

Priorità Alta

Descrizione Un utente accede al portale con un meccanismo di autenticazione valido (vedi req funzionale REQ01).Il sistema verifica che l'utente non abbia mai acceduto prima. Nel caso in cui l’utente sia al primo accesso o, comunque non sia già registrato, il sistema provvede a verificare i ruoli definiti per il controllo sincrono tramite una funzionalità messa a disposizione dal ROLE MANAGER.In caso di meccanismi di autenticazione con attributi qualificativi utili a popolare attributi o ruoli Arpa, questi sono inseriti nello userBean di sessione (attraverso apposito mapping).In attesa dell’esito da parte del ROLE MANAGER, viene presentato all’utente un desktop temporaneo. A mano a mano che la validazione procede, i ruoli validati con successo verranno assegnati all’utente e il desktop si arricchirà dei contenuti relativi a tali ruoli.

Pag. 54 di 81



Al termine della verifica, ad ogni accesso verrà presentato all’utente il proprio desktop di portale con tutte le risorse a cui ha diritto di accedere in ragione dei ruoli realmente posseduti e di quelli per i quali è in White List.

Attori Internet user

Precondizioni L'utente possiede un credenziale di accesso valido.L'utente non ha mai acceduto al sistema.

Eventi di ingresso

L'utente punta il proprio browser web sull'URL corrispondente al punto di accesso al sistema.

Postcondizioni L'utente visualizza l'elenco delle risorse alle quali ha diritto di accedere.Eccezione 1: Se il sistema non riconosce come valido la credenziale di accesso fornita (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL) e propone all'utente una pagina di selezione dell'infrastruttura di autenticazione tra quelle previste..

Pag. 55 di 81



Figura 8 Accesso Successivo con CNS

4.1.3 Accesso alle risorse SRTY attraverso PORTAL

Nome UC4

Priorità Alta

Descrizione L’utente riceve il desktop di portale contenente i collegamenti alle risorse alle quali ha diritto di accedere in ragione dei ruoli posseduti.L'utente sceglie di accedere ad una di queste risorse.Il sistema mette in grado la risorsa di accedere al ruolo utente, al CF /PI e agli attributi necessari per l’accesso e l’espletamento del

Pag. 56 di 81



servizio.A questo punto l’utente continua il colloquio con la risorsa SRTY avendo come punto di accesso il container JEE protetto da SpAgent.

Attori Internet user, Domain user, Extra-domain user

Precondizioni L'utente è stato autenticato.

Eventi di ingresso

L'utente visualizza i collegamenti a risorse presenti sul proprio desktop di portale e sceglie di accedere ad una di queste.

Postcondizioni L'utente accede alla risorsa selezionata.

Figura 9 Accesso alle risorse SRTY attraverso PORTAL

4.1.4 Accesso diretto alle risorse SRTY

Nome UC5

Priorità Alta

Descrizione L'utente tenta di accedere direttamente ad una risorsa.Il sistema intercetta la chiamata e verifica che l’utente non è correntemente autenticato. A questo punto il sistema verifica la

Pag. 57 di 81



validità del certificato e che l'utente sia stato registrato nel sistema; a questo punto ne legge codice fiscale e ruoli assegnati. Se per uno di tali ruoli è stato previsto dal ROLE MANAGER l'accesso alla risorsa in questione, il sistema consente l'accesso.L’utente viene dapprima dirottato su PORTAL (componente OpenAM) per l’autenticazione e poi – in caso di successo – ricondotto alla risorsa alla quale stava originariamente tentando di accedere.A questo punto l’utente accede liberamente e direttamente alla risorsa.

Attori Domain user, Internet user

Precondizioni L'utente non è stato precedentemente autenticato dal sistema.L'utente possiede un certificato di accesso valido.Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli.Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente.

Eventi di ingresso

L'utente punta il proprio browser web sull'URL corrispondente al punto di accesso ad una risorsa.

Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata.Eccezione 1: Se il sistema non riconosce il certificato come valido (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL) invia una pagina di errore.Eccezione 2: Se l'utente non è stato registrato, il sistema registra l'utente.Eccezione 3: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di desktop di portale.

Pag. 58 di 81



Figura 10 Accesso (inizialmente non autenticato) diretto alle risorse SRTY

4.1.5 Accesso diretto (già autenticato) alle risorse SRTY

Nome UC6

Priorità Alta

Descrizione L'utente tenta di accedere direttamente ad una risorsa.Il sistema intercetta la chiamata e verifica che l’utente è correntemente autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli posseduti.A questo punto l’utente accede liberamente e direttamente alla risorsa.

Attori Domain user, Internet user, Extra-domain user

Precondizioni L'utente è stato precedentemente autenticato dal sistema.Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli.Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente.

Pag. 59 di 81



Eventi di ingresso


Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata.Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di errore.

Figura 11 Accesso (già autenticato) diretto alle risorse SRTY

4.1.6 Accesso alle risorse GENERIC attraverso PORTAL

Nome UC7

Priorità Alta

Descrizione L’utente riceve il desktop di portale contenente i collegamenti alle risorse alle quali ha diritto di accedere in ragione dei ruoli posseduti.L'utente sceglie di accedere ad una di queste risorse.Per garantire fruibilità e SSO, il sistema inserisce in sessione informazioni accessibili tramite librerie ARPA Common (si faccia riferimento a UC4).A questo punto l’utente continua il colloquio con la risorsa GENERIC avendo come punto di accesso il container web protetto

Pag. 60 di 81



da SpAgent o SpAgentPHP a seconda del tipo di applicazione.


Precondizioni L'utente è stato autenticato ed ha ricevuto il desktop di portale corrispondente ai propri ruoli.

Eventi di ingresso

L'utente visualizza i collegamenti a risorse presenti sul proprio desktop di portale e sceglie di accedere ad una di queste.

Postcondizioni L'utente accede alla risorsa selezionata.

Figura 12 Accesso alle risorse GENERIC attraverso PORTAL

4.1.7 Accesso diretto alle risorse GENERIC

Nome UC8

Priorità Alta

Descrizione L'utente tenta di accedere direttamente ad una risorsa.Il sistema intercetta la chiamata e verifica che l’utente non è correntemente autenticato. A questo punto il sistema autentica l’utente con uno dei metodi supportati e genera un profilo utente aggiornato. Se per uno di tali ruoli è stato previsto dal ROLE

Pag. 61 di 81



MANAGER l'accesso alla risorsa in questione, il sistema consente l'accesso.L’utente viene dapprima dirottato su PORTAL (componente OpenAM) per l’autenticazione e poi – in caso di successo – ricondotto alla risorsa alla quale stava originariamente tentando di accedere.A questo punto l’utente accede liberamente e direttamente alla risorsa.Nota: durante la fase di verifica di autenticazione dell’utente (interazione tra SpAgent e OpenAM) è possibile inserire meccanismi adatti – da implementare caso per caso – per mettere a disposizione della risorsa GENERIC le informazioni di cui ha bisogno per autorizzare l’accesso dell’utente o per altri scopi.

Attori Domain user, Internet user

Precondizioni L'utente non è stato precedentemente autenticato dal sistema.L'utente possiede un certificato o credenziale di accesso valida.Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli.Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente.

Eventi di ingresso


Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata.Eccezione 1: Se il sistema non riconosce il certificato come valido (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL) invia una pagina di errore.Eccezione 2: Se l'utente non è stato registrato, il sistema invia una pagina di errore.Eccezione 3: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di errore.

Pag. 62 di 81



Figura 13 Accesso (inizialmente non autenticato) diretto alle risorse GENERIC

4.1.8 Accesso (già autenticato) diretto alle risorse GENERIC

Nome UC9

Priorità Alta

Descrizione L'utente tenta di accedere direttamente ad una risorsa.Il sistema intercetta la chiamata e verifica che l’utente è correntemente autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli posseduti.A questo punto l’utente accede liberamente e direttamente alla risorsa.Nota: durante la fase di verifica di autenticazione dell’utente (interazione tra SpAgent e OpenAM) è possibile inserire meccanismi adatti – da implementare caso per caso – per mettere a disposizione della risorsa GENERIC le informazioni di cui ha bisogno per autorizzare l’accesso dell’utente o per altri scopi.

Attori Domain user, Internet user, Extra-domain user

Precondizioni L'utente è stato precedentemente autenticato dal sistema.Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli.Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa

Pag. 63 di 81



selezionata dall'utente.

Eventi di ingresso


Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata.Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di errore.

Figure 14 Accesso (già autenticato) diretto alle risorse GENERIC

4.1.9 Variazione ruoli

Nome UC10

Priorità Alta

Descrizione L’utente, all’interno di una sessione valida di utilizzo del sistema, decide di voler richiedere al sistema la verifica dell’elenco dei ruoli in suo possesso.Il sistema verifica che ne abbia diritto mediante una funzionalità esposta dal ROLE MANAGER.In attesa di un responso, ad ogni nuovo accesso, l’utente potrà accedere solo sul desktop temporaneo.In funzione dell'andamento della verifica, il sistema, per gli accessi

Pag. 64 di 81



successivi, invierà un nuovo desktop di portale contenente le risorse alle quali l'utente – in ragione dei ruoli assegnati – ha diritto di accedere.

Attori Internet user, Domain user

Precondizioni L'utente è stato autenticato dal sistema.

Eventi di ingresso

L'utente accede alla funzionalità di variazione ruoli.

Postcondizioni L'utente visualizza l'elenco delle risorse alle quali ha diritto di accedere in ragione dei ruoli che ha appena selezionato.

4.1.10 Inserimento, Modifica e Cancellazione di un Ruolo

Nome UC11

Priorità Alta

Descrizione L'utente aggiunge un nuovo ruolo attraverso l'interfaccia di amministrazione (Role Administration) del Role Manager, l'evento viene notificato attraverso il CART a PORTAL e SRTY.

Attori Administrator

Precondizioni L'utente accede all'interfaccia di amministrazione, quindi alla sezione ROLE MANAGER e seleziona la funzionalità. L’utente può indicare se il nuovo ruolo è primario (non ha padri) oppure se è derivato da un particolare ruolo già esistente.

Eventi di ingresso

L'utente fornisce per il nuovo ruolo le informazioni previste (cfr. REQ11), quindi seleziona una o più risorse dall’elenco delle risorse disponibili presentato.

Postcondizioni L'evento viene notificato attraverso il CART a PORTAL e SRTY che provvedono ad allineare le proprie informazioni sul ruolo aggiunto e provvedono al controllo di coerenza dei dati.

Nome UC12

Priorità Alta

Descrizione L'utente modifica un nuovo ruolo attraverso l'interfaccia di amministrazione (Role Administration) del Role Manager, l'evento viene notificato attraverso il CART a PORTAL e SRTY.

Pag. 65 di 81




Precondizioni L'utente accede all'interfaccia di amministrazione, quindi alla sezione ROLE MANAGER e seleziona la funzionalità. L’utente può modificare le informazioni, ma non può spostarlo nella gerarchia.

Eventi di ingresso

L'utente può modificare: Criterio di verifica; Descrizione; Attributi aggiuntivi; Parametri dei criteri per la valorizzazione degli attributi; Le risorse associate.

Postcondizioni L'evento viene notificato attraverso il CART a PORTAL e SRTY che provvedono ad allineare le proprie informazioni sul ruolo aggiunto e provvedono al controllo di coerenza dei dati.

Nome UC13

Priorità Alta

Descrizione L'utente cancella un ruolo attraverso l'interfaccia di amministrazione (Role Administration) del Role Manager, l'evento viene notificato attraverso il CART a PORTAL e SRTY.


Precondizioni L'utente accede all'interfaccia di amministrazione, quindi alla sezione ROLE MANAGER e seleziona la funzionalitàIl ruolo non può essere cancellato se da esso dipendono (nella gerarchia) altri ruoli.

Eventi di ingresso

L'utente seleziona il ruolo per la cancellazione.

Postcondizioni L'evento viene notificato attraverso il CART a PORTAL e SRTY che provvedono ad allineare le proprie informazioni sul ruolo e provvedono al controllo di coerenza dei dati.

4.1.11 Inserimento, Modifica e Cancellazione di una Risorsa

Nome UC14

Priorità Alta

Descrizione L'utente, attraverso l'interfaccia di amministrazione del ROLE MANAGER, effettua le operazioni di inserimento, modifica e

Pag. 66 di 81



cancellazione di una risorsa.


Precondizioni L'utente accede all'interfaccia di amministrazione, quindi alla sezione ROLE MANAGER e seleziona la funzionalità.La risorsa deve essere definita coerentemente con le URL di applicazioni esposte da SRTY / GENERIC.

Eventi di ingresso

L’utente individua l'operazione, inserisce i dati richiesti e conferma l'operazione.

Postcondizioni L'evento viene notificato attraverso il CART a PORTAL che provvede ad allineare le proprie informazioni sulla risorsa e provvedono al controllo di coerenza dei dati.

4.1.12 Inserimento, Modifica e Cancellazione di un Criterio

Nome UC15

Priorità Alta

Descrizione L'utente, attraverso l'interfaccia di amministrazione del ROLE MANAGER, effettua le operazioni di inserimento, modifica e cancellazione di un criterio.


Precondizioni L'utente accede all'interfaccia di amministrazione, quindi alla sezione ROLE MANAGER e seleziona la funzionalità.

Eventi di ingresso

L’utente individua l'operazione, inserisce i dati richiesti e conferma l'operazione.

Postcondizioni Le informazioni relative al criterio oggetto dell'operazione vengono registrate nella banca dati del ROLE MANAGER, per essere disponibili per la successiva associazione ai ruoli/attributi.

4.1.13 Individuazione e verifica dei ruoli

Nome UC16

Priorità Alta

Descrizione Viene richiesta la verifica di una lista di ruoli e i la valorizzazione degli attributi corrispondenti.

Pag. 67 di 81



Attori Portal

Precondizioni La richiesta è fatta in opportuno formato XML/SOAP basato sul WSDL fornito.

Eventi di ingresso

Il Portale invia una richiesta di reperimento attributi dei ruoli fornendo:- il Codice Fiscale dell’utente;- la lista dei ruoli di cui reperire gli attributi.

Postcondizioni Viene innescato il processo di discovery al termine del quale viene restituita una Risposta SOAP/XML, basata sul WSDL fornito, contenente le seguenti informazioni:Una lista di coppie <Ruolo, {TRUE, FALSE}>Nel caso di TRUE la lista degli attributi del corrispondente ruolo.Un codice di errore nel caso in cui il “provider” non sia “raggiungibile”, etc.

Nome UC17

Priorità Alta

Descrizione Viene richiesto l’elenco di tutti i ruoli.

Attori Portal

Precondizioni La richiesta è fatta in opportuno formato XML/SOAP basato sul WSDL fornito.

Eventi di ingresso

Il Portale invia una richiesta di reperimento dei ruoli.

Postcondizioni Viene restituita una Risposta SOAP/XML, basata sul WSDL fornito, contenente l’albero gerarchico dei ruoli presenti.

4.1.14 Accesso delegato a risorse attraverso PORTAL

Nome UC18

Priorità Alta

Descrizione L'utente accede ad una risorsa attraverso l’oggetto delega rappresentato sul proprio desktop di portale.Il sistema, prima di ridirigere l'utente verso la risorsa selezionata, provvede a rendere reperibili via ARPA Common le informazioni richieste dalla delega e a tenere traccia dell’accesso in modalità delegata che si sta effettuando.

Pag. 68 di 81




Precondizioni L’utente è stato autenticato ed ha ricevuto il desktop di portale corrispondente ai propri ruoliL’utente è stato delegato e per questo visualizza sul proprio desktop di portale almeno un oggetto delega

Eventi di ingresso

L'utente visualizza i collegamenti a risorse presenti sul proprio desktop di portale.

Postcondizioni L'utente accede alla risorsa selezionata in modalità delegata.Il sistema tiene traccia dell’accesso in modalità delegata.

Figura 15 Accesso delegato a risorse attraverso PORTAL

4.1.15 SAML Identity Provider

Nome UC20

Priorità Alta

Pag. 69 di 81



Descrizione L'utente, dal proprio desktop di portale, richiede l'accesso ad un servizio esterno offerto da un ente federato (SP).


Precondizioni L'utente è stato autenticato ed ha ricevuto il desktop di portale corrispondente ai propri ruoliL'utente, in ragione dei propri ruoli, ha diritto di accedere al servizio richiesto

Eventi di ingresso

L'utente richiede il servizio in questione a partire da un collegamento presente sul proprio desktop di portale

Postcondizioni L'utente accede al servizio richiesto

Figura 16 Accesso ad un servizio esposto da un ente federato (SP)

4.1.16 Associazione CNS con applicazione ToscanaID

Nome UC21

Priorità Alta

Pag. 70 di 81



Descrizione L'utente vuole usufruire dei servizi da dispositivi non dotati di lettore Smart Card. Il processo di associazione permette all'utente dotato di CNS di abilitare il proprio utente all'interno di una specifica istallazione di ToscanaID. L'associazione prevede l'inserimento di una one time password sull'applicazione ToscanaId generata attraverso un'apposita funzionalità di Arpa Desktop. Opzionalmente l'utente può inserire un Pin come descritto dallo UC22.


Precondizioni L'utente è stato autenticato con carta CNS ed ha ricevuto il desktop di portale corrispondente ai propri ruoliL'utente è in possesso dell'applicazione ToscanaIDL'utente non è associato a ToscanaID

Eventi di ingresso

L'utente richiede il servizio in questione a partire da un collegamento presente sul proprio desktop di portale

Postcondizioni L'utente viene riconosciuto sulla suddetta istallazione di ToscanaID

Figura 17 Associazione CNS con applicazione ToscanaID

4.1.17 Inserimento/Modifica/Eliminazione Pin ToscanaID

Nome UC22

Priorità Normale

Pag. 71 di 81



Descrizione L'utente desidera proteggere l'accesso ai servizi offerti da ToscanaID attraverso l'inserimento di un Pin numerico che viene richiesto per ogni nuova tipologia di sessione di servizio a cui l'utente tenta di accedere. In caso di modifica/elimina del Pin l'utente deve preventivamente inserire quello attualmente in uso

Attori App User

Precondizioni L'utente è associato o si sta associando in ToscanaID

Eventi di ingresso

L'utente seleziona l'apposita funzionalità presente in ToscanaID

Postcondizioni In caso di Inserimento/Modifica dal successivo accesso l'utente dovrà utilizzare il nuovo Pin.In caso di Eliminazione al successivo accesso l'utente non dovrà inserire alcun Pin.

4.1.18 Reset Pin dimenticato o bloccato su ToscanaID

Nome UC23

Priorità Alta

Descrizione L'utente non ricorda il Pin configurato sulla specifica installazione di ToscanaID ed avvia la procedura di reset del Pin. La procedura prevedere interrazione con il portale (quindi utilizzando I meccanismi di autenticazione previsti fa postazioni desktop )ed è equivalente a quello descritto nello UC21, UC22

Attori App User

Precondizioni L'utente è associato in ToscanaID ed ha configurato un Pin.L'utente ha superato il numero di tentativi massimi per la richiesta del Pin oppure non si ricorda il Pin.

Eventi di ingresso

L'utente accede all'apposita funzione disponibile in ToscanaID.

Postcondizioni Vedi UC21, UC22

4.1.19 Revoca Associazione CNS con applicazione ToscanaID da portale

Pag. 72 di 81



Nome UC24

Priorità Alta

Descrizione L'utente desidera revocare il permesso ad una determinata istallazione di ToscanaID di accedere ai servizi utente


Precondizioni L'utente è autenticato ed ha ricevuto il desktop di portale corrispondente ai propri ruoli.L'utente ha almento una associazione CNS - ToscanaID

Eventi di ingresso

L'utente seleziona l'apposita funzionalità presente sul portale

Postcondizioni L'associazione non è più visibile sul portale.Dopo un lasso di tempo limitato (se collegato alla rete) l'associazione viene rimossa anche dall'installazione di ToscanaID, impedendo quindi l'accesso ai servizi.

4.1.20 Revoca Associazione CNS con applicazione ToscanaID

Nome UC25

Priorità Alta

Descrizione L'utente desidera revocare il permesso all'istallazione di ToscanaID su cui sta operando

Attori App User

Precondizioni L'utente è autenticato su ToscanaID (eventuale Pin richiesto)

Eventi di ingresso

L'utente seleziona l'apposita funzionalità presente su ToscanaID

Postcondizioni L'associazione non è più visibile su ToscanaID.Salvo problemi di connessione l'associazione non è più visibile da portale.

4.1.21 Accesso ai servizi da app collegata a ToscanaID

Pag. 73 di 81



Nome UC26

Priorità Alta

Descrizione L'utente tenta l'accesso ad una applicazione nativa presente nel circuito di fiducia di Arpa e disponibile per il profilo dell'utente collegato

Attori App User

Precondizioni Applicazione ToscanaID installata e associata (e non revocato) all'utente.Applicazione Nativa presente nel circuito Arpa.Applicazione Nativa disponibile per il profilo utente collegato.Applicazione Nativa correttamente configurata.Dispositivo in modalità online

Eventi di ingresso

L'utente naviga all'interno dell'applicazione nativa.

Postcondizioni Le funzionalità autenticate mostrano dati specifici dell'utente. Se l'utente ha impostato il Pin, questo viene richiesto almeno al primo accesso.

4.1.22 Accesso ai servizi da applicazione nativa

Nome UC27

Priorità Alta

Descrizione L'utente tenta l'accesso ad una applicazione nativa presente nel circuito di fiducia di Arpa e disponibile per il profilo dell'utente collegato

Attori App User

Precondizioni Applicazione ToscanaID installata e associata (e non revocato) all'utente.Applicazione Nativa presente nel circuito Arpa.Applicazione Nativa disponibile per il profilo utente collegato.Applicazione Nativa correttamente configurata.Dispositivo in modalità online

Pag. 74 di 81



Eventi di ingresso

L'utente naviga all'interno dell'applicazione nativa.

Postcondizioni Le funzionalità autenticate mostrano dati specifici dell'utente. Se l'utente ha impostato il Pin, questo potrà essere richiesto almeno al primo accesso. Se sono presenti più utenti in ToscanaID è necessario prima selezionare quello corretto.

4.1.23 Accesso ai servizi web di ToscanaID

Nome UC28

Priorità Normale

Descrizione L'utente visualizza una serie di applicazioni fruibili da dispositivo mobile e in base al proprio profilo utente.

Attori User

Precondizioni Applicazione ToscanaID installata e associata (e non revocato) all'utente.Dispositivo in modalità onlineUtente correttamente profilato in Arpa

Eventi di ingresso

L'utente accede all'apposita funzione all'interno di ToscanaID

Postcondizioni L'utente accede alla risorsa web. Se l'utente ha impostato il Pin, questo sarà richiesto almeno al primo accesso. Se sono presenti più utenti in ToscanaID è necessario prima selezionare quello corretto.

4.2 Tracciabilità dei requisiti sui sottosistemi individuati

In questo paragrafo verranno suddivisi i requisiti funzionali e non funzionali in base alle loro aree di competenza.

Viene fatta eccezione del requisito sulla sicurezza (REQNF04) e del requisito sull'amministrazione (REQ26) che saranno considerati comuni a tutte le aree funzionali.

PORTAL REQNF01

REQNF03

REQ01

Pag. 75 di 81



REQ02

REQ03

REQ04

REQ08

REQ09

REQ27

REQ28

REQ29

REQ30

REQ31

REQ32

REQ33

REQ34

REQ35

REQ36

REQ37

ROLE MANAGER REQNF02

REQ05

REQ06

REQ11

REQ13

REQ14

REQ150

REQ16

REQ17

REQ18

REQ19

SRTY REQ22

Pag. 76 di 81



REQ23

REQ24

REQ25

REQ28

REQ31

Pag. 77 di 81



5 PIANO DI SICUREZZA

Il seguente piano definisce le linee guida che dovranno essere seguite dal fornitore che Regione Toscana sceglierà per l’infrastruttura IT che ospiterà il progetto ARPA. Tale piano contempla la sicurezza di sistema e la sicurezza applicativa.

Va notato che nessuna funzionalità di sicurezza di rete viene descritta poiché al di fuori del dominio di competenza.

Il piano di sicurezza si occupa della sicurezza architetturale, dei firewall di bordo su ogni sistema, di mezzi di trasporto sicuri per l'amministrazione applicativa e dell'hardening di ogni singolo sistema. L’obiettivo finale è quello di raggiungere un livello di sicurezza assoluto elevato attraverso la messa in sicurezza dei sistemi, degli applicativi, dei dati e del loro trasporto.

5.1 Sicurezza architetturale

I flussi generati dagli utenti del sistema (Domain User, Extra Domain User, Internet User, Administrator e System Administrator) sono descritti sopra, nella sezione relativa agli scenari applicativi.

È compito del piano di sicurezza impedire che gli utenti non raggiungano e/o accedano ad aree non autorizzate e mantenere separati i flussi informativi, anche se i sistemi interessati possono essere gli stessi.

Dall’analisi dei flussi si nota che l'utente Administrator avrà accesso alle funzioni di amministrazione a livello applicativo di tutte le aree funzionali.

5.2 Politiche di sicurezza delle utenze

In questo paragrafo verranno descritte ed elencate le politiche di sicurezza per tutti gli utenti dell'infrastruttura. Tali politiche dettano, concedono e restringono le attività degli utenti.

System Administrator✔ La sua funzione è la mera amministrazione dei sistemi lato sistema

operativo✔ Il system administrator accede ai sistemi tramite il protocollo sicuro✔ Il system administrator accede a tutte le console di sistema operativo dei

sistemi installati✔ Il system administrator accede e controlla le politiche di backup dei sistemi✔ Il system administrator deve poter svolgere tutte le comuni funzioni di

amministrazione di sistema come creazione utenti, log ecc. Administrator

✔ La sua funzione è l’amministrazione di tutti gli applicativi dell'infrastruttura✔ L'administrator accede solo tramite protocollo sicuro HTTPS secondo le

modalità di autenticazione previste al REQ01 con i supporti previsti dal REQNF08

✔ L'administrator accede a tutte le console degli applicativi installati✔ L'administrator crea/modifica/cancella ruoli, utenze, log ecc.

Internet User

Pag. 78 di 81



✔ L'internet user accede a tutti i servizi erogati dall'infrastruttura solo attraverso la rete Internet

✔ L'internet user accede solo tramite protocollo sicuro HTTPS secondo le modalità di autenticazione previste al REQ01 con i supporti previsti dal REQNF08

Domain User✔ Il domain user accede a tutti i servizi erogati dall'infrastruttura sia attraverso

la rete Internet sia attraverso la rete interna✔ Il domain user accede solo tramite protocollo sicuro HTTPS secondo le


Extra-domain User✔ L'extra-domain user accede a tutti i servizi erogati dall'infrastruttura solo

attraverso la rete internet✔ L'extra-domain user accede solo tramite protocollo sicuro HTTPS secondo le


✔ L'extra-domain user viene autenticato tramite il principio della federazione gestito dall'OpenAM

✔ L'autenticazione gestita dalla federazione utilizza il protocollo di trasporto HTTPS

5.3 Politiche di sicurezza per le applicazioni

In questo paragrafo vengono descritte le politiche di sicurezza degli applicativi e delle relative comunicazioni; viene inoltre affrontata la sicurezza delle applicazioni scritte e/o sviluppate ad-hoc. Per maggiore chiarezza vengono riportati i piani di sicurezza sia delle aree funzionali sia delle componenti applicative.

5.4 Politiche di sicurezza delle aree funzionali

Il piano di sicurezza ha impatto su tutte le aree funzionali dell'architettura PORTAL

✔ Gli utenti accedono a PORTAL tramite protocollo sicuro HTTPS secondo le modalità di autenticazione previste al REQ01 con i supporti previsti dal REQNF08

✔ Tutti gli utenti interni possono accedere alle risorse protette da SpAgent e SpAgentPHP

✔ Accede a ROLE MANAGER tramite web service su protocollo sicuro✔ Accede alle notifiche di gestione ruoli pubblicate dal ROLE MANAGER con

protocollo dedicato (Role Sync Client) ROLE MANAGER

✔ Verifica che i ruoli forniti dagli utenti in fase di self-registration siano validi✔ Per effettuare le verifiche accede a basi di dati esterne✔ La natura delle verifiche implica che i protocolli di trasmissione utilizzati dal

ROLE MANAGER non possono essere determinati a priori✔ Pubblica le notifiche di gestione ruoli per le altre aree funzionali (Role Sync

Server) SRTY

✔ Fornisce l'accesso a risorse di varia natura✔ Alle risorse si accede tramite protocollo sicuro HTTPS

Pag. 79 di 81



✔ Accede alle notifiche di gestione ruoli pubblicate dal ROLE MANAGER con protocollo dedicato (Role Sync Client)

5.5 Politiche di sicurezza delle componenti applicative

PDC Auth Module✔ Ha lo stesso livello di sicurezza di OpenAM✔ Modulo scritto ad-hoc seguendo le best practices di sviluppo software

OpenAM✔ Tutte le comunicazioni da e verso OpenAM avvengono tramite protocollo sicuro

HTTPS Desktop Provider

✔ L'elenco delle risorse da mostrare all'utente è ricavato tramite accesso in HTTPS ad un apposito web service esposto dal ROLE MANAGER

Client SDK✔ Il protocollo utilizzato è l'HTTPS

SpAgent e SpAgentPHP✔ Eseguono una redirezione su OpenAM utilizzando il protocollo sicuro HTTPS

5.6 Politiche di sicurezza per i sistemi

Questa sezione descrive le funzionalità di sicurezza da implementare a livello di sistema operativo: firewall di bordo ed hardening.

Il firewall di bordo viene attivato con lo scopo di aumentare il livello di sicurezza anche a livello di host: in questo modo la comunicazione avviene solo con sistemi conosciuti a priori.

L'hardening dei sistemi verrà effettuato per aumentare ulteriormente il livello di sicurezza; a questo scopo vengono disabilitati tutti i servizi di sistema operativo attivi di default ma non necessari.

Firewall di sistemaSi tratta di applicare a livello locale lo stesso principio di filtering applicato all’intera

infrastruttura a livello perimetrale. Questa tecnica fa sì che l'eventuale security policy possa essere implementata puntualmente sui sistemi e per i servizi offerti dagli stessi. Il firewall di bordo aumenta intrinsecamente il livello di sicurezza perché limita il management dei sistemi solo da postazioni e da sottoreti censite a priori.

HardeningI sistemi operativi moderni sono configurati per default con una serie di servizi che

possono essere utili in certi contesti ma molto rischiosi in altri.L'hardening di un sistema operativo consiste nel disabilitare in maniera selettiva i

servizi offerti in modo tale da non influenzarne la gestione e l'erogazione, minimizzando i rischi.

Le modifiche da implementare sui sistemi riguardano le seguenti aree:– Autenticazione/autorizzazione utenti

Minimizzazione servizi di rete erogati– Tuning dello stack TCP/IP e disabilitazione del forwarding– Tuning del Kernel– logging centralizzato degli eventi di sistema– Sincronizzazione di data ed ora ad una sorgente univoca predefinita

Pag. 80 di 81



– Banner di accesso ai sistemi.

Non è suggerita la minimizzazione dei sistemi per motivi di supportabilità dei medesimi.

È anche cura della metodologia dell'hardening stabilire le politiche sulle password; ad esempio:

– periodo minimo di validità delle password– periodo massimo di validità delle password– periodo di preavviso scadenza delle password– lunghezza minima delle password– Password History – impossibilità di riutilizzare password già utilizzate– Password Dictionary – controllo della password immessa su un dizionario di

password frequentemente utilizzate o di facile discernimento

Pag. 81 di 81

Documents

oscat.rete.toscana.itoscat.rete.toscana.it/docman/view.php/65/1881/MEVARPA... · Web viewL'accesso diretto alle risorse via desktop di portale avviene in base ad alcuni parametri