Progetto ARPA-Specifiche Funzionali 1.4

Contratto: ARPA Rif.
repertorio n 6788 raccolta n 2778 firmato il 7/4/2006

Codice Documento: Progetto_ARPA-Specifiche_Funzionali
Sistema: ARPA
Nota: Ad esclusivo uso interno della Regione Toscana Settore ITSAE.
Versione documento: 1.4
Stato del documento DRAFT
SPECIFICHE FUNZIONALI
DOCUMENTO DI DETTAGLIO RELATIVO AI
REQUISITI DI SISTEMA
Progetto ARPA
CONTIENE D01.1
Livelli di approvazione Funzione Nome Data Firma

RTI
Redazione GdL ARPA RTI 08-08-2006
Integrazione GdL ARPA RTI 20-10-2007
Revisione Architect RTI Ovidiu 20-10-2007
Constantin
Approvazione/Emissione PM RTI Marco Coppi 20-10-2007
Livelli di approvazione Funzione Nome Data Firma

Cliente
Verifica
Approvazione
Approvazione
LISTA DI DISTRIBUZIONE
Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Pagina 1 di 65
REVISIONI
Paragrafo/revisione Modifica effettuata Data Approvaz./Autorizz.

Accorpati i due documento 0.16a e 0.16b.
Aggiunti flussi applicativi su architettura
1.0 7/8/06
logica. Descrizione componenti e loro
interazione.
Estensione del Req 26, aggiunta
spiegazione su Req 06, Aggiunta
1.1 spiegazione su come gestire le CA del PDC 6/10/06
auth module nel REQ26, Modifica REQ10,
REQ32
Aggiornamento Figura 1, par. 1.3 e 4.3 con
SRA Gateway; Aggiornamento 4.2;
Estensione 4.3.4; Estensione del REQ10;
Estensione del REQNF03; Estensione del
1.2 REQNF08; Estensione del REQ26; 12/10/06
Riscrittura e accorpamento dei precedenti
REQ34, REQ35 e REQ36 nel nuovo
REQ34; Revisione UC; Aggiornamento 5.4;
Aggiornamento e allineamento capitolo 6
1.3 Allineamento con il TestPlan 20/06/07
REQNF09: tolto requisito di accessibilit
sull'amministrazione
REQ01: l'accesso non viene inibito se ci
sono ruoli scaduti.
REQ02: gestione dichiarazioni mendaci +
black list
REQ02: specifica del desktop temporaneo
REQ09: durante la modifica del profilo
utente non viene forzato un logout
REQ10: recupero informazioni utente (ruoli
e attributi)
1.4 REQ14: le categorie non sono specificate 24/10/07
attraverso role manager
REQ26: aggiunta funzionalit mancanti
REQ33: il certificato digitale della CA non
serve caricarlo dall'interfaccia di
amiinistrazione (tale certificato va importato
a mano sul db del rproxy e sul db del
webserver)
UC3: recupero informazioni utente (ruoli e
attributi)
UC10: durante la modifica del profilo utente
non viene forzato un logout

Pagina 2 di 65
SOMMARIO
1 GENERALIT ..................................................................................................................................5
1.1 SCOPO ........................................................................................................................................5
1.2 VALIDIT ......................................................................................................................................5
1.3 GLOSSARIO DEI TERMINI .............................................................................................................5
1.4 RIFERIMENTI................................................................................................................................8
2 ASSUNZIONI E DIPENDENZE ......................................................................................................9
3 INTRODUZIONE........................................................................................................................... 10
3.1 SINTESI DELLA SOLUZIONE....................................................................................................... 10
4 ARCHITETTURA LOGICA .......................................................................................................... 12
4.1 SOTTOSISTEMI PRINCIPALI E LORO INTERAZIONI ...................................................................... 13
4.1.1 Role Manager .........................................................................................................................13
4.1.2 Portal......................................................................................................................................13
4.1.3 Generic...................................................................................................................................14
4.1.4 SRTY.....................................................................................................................................14
4.2 BANCHE DATI UTILIZZATE ......................................................................................................... 15
4.3 DEFINIZIONE DELLE COMPONENTI DEI SOTTOSISTEMI .............................................................. 15
4.3.1 PORTAL................................................................................................................................ 15
4.3.2 ROLE MANAGER ................................................................................................................16
4.3.3 SRTY.....................................................................................................................................16
4.3.4 GENERIC .............................................................................................................................. 17
4.4 SCENARIO DINTERAZIONI TRA ALCUNE COMPONENTI .............................................................. 17
4.5 IL ROLE MANAGER ................................................................................................................... 19
4.5.1 Role Administration ...............................................................................................................20
Un ruolo viene definito mediante: ...................................................................................................20
4.5.2 Role Detection........................................................................................................................22
4.5.3 Adapter ..................................................................................................................................22
4.5.4 Notifica delle operazioni sul ruolo verso PORTAL e SRTY....................................................22
5 REALIZZAZIONE DELLA SOLUZIONE .................................................................................... 24
5.1 REQUISITI NON FUNZIONALI...................................................................................................... 24
5.2 REQUISITI FUNZIONALI ............................................................................................................. 27
5.3 CASI D 'USO............................................................................................................................... 42
5.3.1 Accesso senza self-registration ...............................................................................................42
5.3.2 Accesso con self-registration ..................................................................................................43
5.3.3 Accesso da un dominio esterno ...............................................................................................45
5.3.4 Accesso alle risorse SRTY attraverso PORTAL......................................................................46
5.3.5 Accesso diretto alle risorse SRTY...........................................................................................47
5.3.6 Accesso alle risorse GENERIC attraverso PORTAL ...............................................................49
5.3.7 Accesso diretto alle risorse GENERIC ....................................................................................50
5.3.8 Variazione ruoli......................................................................................................................54
5.3.9 Inserimento, Modifica e Cancellazione di un Ruolo ................................................................ 56
5.3.10 Inserimento, Modifica e Cancellazione di una Risorsa.............................................................57
5.3.11 Inserimento, Modifica e Cancellazione di un Criterio.............................................................. 57
5.3.12 Individuazione e verifica dei ruoli...........................................................................................57
5.3.13 Accesso delegato a risorse attraverso PORTAL ......................................................................59
5.3.14 SAML Identity Provider .........................................................................................................60
5.4 TRACCIABILIT DEI REQUISITI SUI SOTTOSISTEMI INDIVIDUATI ................................................. 61
6 PIANO DI SICUREZZA ................................................................................................................ 63
6.1 SICUREZZA ARCHITETTURALE .................................................................................................. 63
6.2 POLITICHE DI SICUREZZA DELLE UTENZE ................................................................................. 63
6.3 POLITICHE DI SICUREZZA PER LE APPLICAZIONI ....................................................................... 64
Pagina 3 di 65
6.4 POLITICHE DI SICUREZZA DELLE AREE FUNZIONALI .................................................................. 64
6.5 POLITICHE DI SICUREZZA DELLE COMPONENTI APPLICATIVE.................................................... 64
6.6 POLITICHE DI SICUREZZA PER I SISTEMI ................................................................................... 64

Pagina 4 di 65
1 GENERALIT
Il presente documento descrive i requisiti e le specifiche funzionali previsti per la
realizzazione del portale per laccesso sicuro denominato ARPA.
1.1 Scopo
Lobiettivo 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
Access Manager Componente della suite Sun Java System (SJS) che eroga funzionalit di
autenticazione e controllo accessi.
http://docs.sun.com/app/docs/doc/819-6188/6n87ih3o2?a=view
Adapter Componente software che nasconde ed adatta linterfaccia di un

componente mostrandone unaltra allesterno. Consente di uniformare
linterfaccia di accesso alle fonti dati durante il processo di discovery e
verifica dei ruoli.
ARPA Autenticazione Ruoli Profili Applicazioni
AM Policy Agent Componente plug-in che agisce in cooperazione con Access Manager ed
effettua il controllo delle credenziali consentendo la gestione della
autenticazione ed il controllo degli accessi centralizzato.
Richiede, interpreta e applica le politiche di autorizzazione daccesso alle
risorse.
http://docs.sun.com/app/docs/coll/1322.1
http://docs.sun.com/app/docs/doc/819-2143
AM SDK Access Manager Software Development Kit. L'AMSDK 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,
ruoli, etc.)
CA Certification Authority. una entit che rilascia certificati digitali verso terze
parti. Aggiorna periodicamente anche le CRL relative ai certificati emessi.
CART Infrastruttura di Cooperazione Applicativa di Regione Toscana
Cache Memoria che contiene informazioni temporanee, utilizzata per velocizzare la

Pagina 5 di 65
ricerca e la fruizione delle informazioni, evitando di reperirle direttamente
dalle fonti primarie.
Certificatori di Entit che rendono disponibili attraverso una o pi Fonte Dati, le informazioni
ruolo (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 linterscambio di informazioni con una
particolare fonte dati mediante il protocollo richiesto.
Criterio Linsieme 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 la componente SJS Portal
Server utilizzata nell'ambito del PORTAL.
Directory Server il repository dei dati utilizzato dal Portale e dell'Access Manager, costituito
dal Directory Server LDAPv3 Sun Java System Directory Server.
http://docs.sun.com/app/docs/coll/1316.1
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

lassegnazione dei ruoli agli utenti attraverso specifici Adapter.
GENERIC Applicazioni preesistenti o future che vengono integrate a vario livello
nellinfrastruttura. Sono escluse da questa definizione le applicazioni
sviluppate con il framework Srty.
Integrazione Una applicazione da considerarsi integrata nel portale quando:
Applicazioni 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;
tramite un modulo del Portal Server (SRA Gateway) si garantisce la
raggiungibilit e la corretta fruibilit del servizio offerto
dall'applicazione;
per un pi alto livello di integrazione, sia garantito il Single Sign-On
(SSO).
I tre punti precedenti definiscono livelli di integrazione diversi da un livello
base in cui si ha il solo link sul desktop ad un livello maggiore in cui viene
garantito il Single Sign-On. In questo documento, il livello di integrazione
inteso sar sempre quello massimo in cui verr garantito: presentazione sul
desktop, raggiungibilit e fruibilit del servizio e SSO.
J2EE Java 2 Enterprise Edition

Insieme di specifiche Sun che definisce un ambiente operativo per le

Pagina 6 di 65
applicazioni accessibili via protocolli Internet (HTTP)
LDAP Lightweight Directory Access Protocol

Particolare 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)
PDC Personal Digital Certificate
PDK Proxy Development Kit

Insieme di pacchetti software e di specifiche per la realizzazione di proxy
applicativi
Proxy applicativo Porta applicativa per laccesso 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
allinterno 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
SRA Gateway Componente della suite Sun Java System (SJS) che eroga funzionalit di
sicurezza per laccesso.
SSO Single Sign On
SRTY Framework per lo sviluppo di applicazioni profilate ad accesso sicuro di

Regione Toscana.
SJS Sun Java System. Famiglia di prodotti software di Sun Microsystems
Web Proxy Componente SJS con funzionalit di reverse proxy.

Server http://docs.sun.com/app/docs/coll/1311.1
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 lutilizzo
di protocolli Internet (HTTP)

Pagina 7 di 65
1.4 Riferimenti
Sono di seguito elencati i documenti utilizzati nel processo di identificazione delle funzionalit:
Capitolato di Appalto
Proposta tecnica rif doc. cod. doc. 05C1204C1ATO rev. 0 16/9/2005

Pagina 8 di 65
2 ASSUNZIONI E DIPENDENZE
Vengono riportate di seguito le assunzioni e dipendenze nel redigere il documento:
1. 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
2. RTI (Raggruppamento Temporaneo di Impresa) valuter eventuali attivit addizionali e/o

modifiche alle attivit previste nel capitolato riservandosi di richiedere integrazioni contrattuali

Pagina 9 di 65
3 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 (certificati digitali) 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.
Il progetto prevede la realizzazione di uninfrastruttura di Autenticazione ed Accesso Sicuro ai servizi

di Regione Toscana (E.Toscana), ottenuta dallintegrazione della piattaforma di Access Management,
Sun Java System Access Manager con i servizi offerti dal framework SRTY e la piattaforma di
Cooperazione Applicativa di Regione Toscana (CART).
L'infrastruttura di Autenticazione ed Accesso Sicuro realizzata utilizzando le funzionalit di

Autenticazione, Autorizzazione ed Accesso di Sun Java System Access Manager insieme alle
funzionalit di Aggregazione e Profilazione basata su ruoli di Sun Java System Portal Server.
Il risultato la costruzione di un portale per l'accesso sicuro alle risorse applicative di Regione
Toscana che consente di centralizzare l'accesso degli utenti, rafforzandolo di strumenti di
autenticazione sicuri quali le smart card, offrendo all'utente un desktop personalizzato sulla base del
proprio ruolo. L'interazione tra il portale ed il modulo di gestione dei ruoli consente di disaccoppiare il
controllo accessi basato sui ruoli dalla gestione delle banche dati utilizzate per la validazione dei ruoli
stessi.
Elemento chiave dell'infrastruttura proposta la capacit di interoperare con altre amministrazioni

secondo il modello di identit federata, basato cio su un rapporto di fiducia legato all'identit
dell'utente. 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.
L'utilizzo di standard aperti, la possibilit di utilizzare i servizi della piattaforma di autenticazione ed

autorizzazione sia attraverso il portale che richiamandoli direttamente dalle applicazioni consentono a
Regione Toscana di far evolvere le proprie applicazioni utilizzando l'infrastruttura di autenticazione ed
autorizzazione del portale.
3.1 Sintesi della soluzione

Nellambito del progetto ARPA vengono erogate una serie di funzionalit, tra queste quelle principali
sono:
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 una
SmartCard e di un certificato. Il modulo di autenticazione acquisisce alcune informazioni
dal certificato e ne verifica la validit utilizzando le diverse banche dati a disposizione
(Revocation Listi, Black/White List, ecc.). Gli utenti che si collegano al Portale provenienti
da Domini Esterni sono invece autenticati alla fonte ed il Portale utilizza meccanismi di
identit federata (SAML) per concedergli l'accesso.
Self Registration - Al primo accesso il sistema richiede allutente di effettuare una

procedura di registrazione: sar richiesto all'utente di specificare, da una lista di ruoli
possibili, quelli con i quali si intende accedere ai servizi offerti dal sistema. L'utente avr, in
ogni momento, la possibilit di variare l'insieme dei ruoli selezionati (modifica del profilo
utente). A valle della selezione, viene attivata la fase di Verifica del Ruolo che attraverso i
Certificatori di Ruolo e le Fonti Dati verifica il reale possesso del ruolo da parte dell'utente.
Verifica del Ruolo - La veridicit dei dati forniti dallutente (il ruolo) sar verificata dal
Pagina 10 di 65
sistema in modo asincrono rispetto alla fase di registrazione o di modifica del profilo
utente. Periodicamente il sistema provveder inoltre in modo autonomo a verificare la
validit delle associazioni tra ruoli ed utenti. 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.
Accesso alle risorse - Lutente dopo la fase di autenticazione, selezionando una risorsa
contenuta nel proprio desktop di portale, accede alle funzionalit da questa esposte. I soli
utenti interni di Regione Toscana avranno 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.
Desktop di Portale personalizzato - Dopo l'accesso autenticato al Portale, 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 (SJS
Access Manager, Role Manager, Banche Dati) che regolano il funzionamento del Portale.
Mancato accesso per un determinato periodo - Nel caso in cui un utente non acceda al
sistema per un certo periodo di tempo, i dati associati alla sua utenza vengono rimossi.
Tali dati potranno anche essere rimossi forzatamente attraverso le funzionalit di
amministrazione.
Funzionalit di Amministrazione - Consentono all'amministratore l'esecuzione dei

compiti di amministrazione nei diversi comparti quali Portale, Role Manager, SRTY.
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.

Pagina 11 di 65
4 ARCHITETTURA LOGICA
Il diagramma in Figura 1 Architettura logica illustra larchitettura logica di riferimento della soluzione
proposta suddivisa nei suoi sottosistemi principali.
Figura 1 Architettura logica

Pagina 12 di 65
4.1 Sottosistemi principali e loro interazioni
L'architettura logica composta da quattro aree funzionali principali, corrispondenti ai seguenti
sottosistemi:
4.1.1 Role Manager
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. Consente di gestire ruoli, criteri, risorse e
lassociazione tra essi.
Interazione con CART Pubblica sul CART gli eventi collegati alle operazioni
dinserimento, modifica e cancellazione di ruoli, risorse,
attributi e criteri.
Interazione con GENERIC Nessuna interazione diretta
Interazione con SRTY Nessuna interazione diretta (pubblicazione attraverso CART)
Interazione con PORTAL Vedi interazione con CART e par. 4.1.2 (Interazione con R.M.)
4.1.2 Portal
PORTAL
Descrizione Si occupa dell'autenticazione degli utenti e del controllo degli
accessi alle risorse disponibili attraverso il portale. E'
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
dinserimento, modifica e cancellazione di ruoli, risorse,
attributi e criteri, modificando dinamicamente la struttura dei
ruoli di portale e le policy daccesso 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, lintegrazione di
queste nel portale fino a garantire raggiungibilit dei servizi,
fruibilit e Single Sign-On (SSO).
Per ogni applicazione integrata nel portale, la raggiungibilit
del sevizio viene offerta mediante unazione di reverse proxy
offerta dal blocco PORTAL.
Per la fruibilit del servizio e il Single Sign-On le modalit di
azione possono essere diverse a seconda dellapplicazione da
integrare: potrebbero essere previsto linvio di informazioni su
HTTP Header, linterazione con meccanismi di Form
Authentication piuttosto che Basic o Digest o altro
meccanismo custom, luso di AM SDK o AM Policy Agent ed
altro ancora.
Interazione con SRTY Mediante un meccanismo di reverse proxy offre la
raggiungibilit, dallesterno, del servizio pubblicato su SRTY.
Pagina 13 di 65
Inoltre, centralizza lautenticazione e lautorizzazione
daccesso ai servizi offerti.
4.1.3 Generic
GENERIC
Descrizione 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
linterfaccia damministrazione del ROLE MANAGER.
Interazione con PORTAL Alcune applicazioni appartenenti al blocco GENERIC
potrebbero avere la necessit di comunicare direttamente con
il PORTAL; ad esempio applicazioni che fanno uso di AM SDK
o AM Policy Agent.
Interazione con ROLE MANAGER Nessuna interazione diretta
Interazione con CART Nessuna interazione diretta
Interazione con SRTY Nessuna interazione diretta
4.1.4 SRTY
SRTY
Descrizione 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 dellutente e vengono associate ai vari ruoli tramite
linterfaccia 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 luso del framework AM SDK.
LAM SDK usato dalle singole applicazioni del blocco SRTY
per recuperare alcune informazioni relative allutente e dallAM
Policy Agent per recuperare, interpretare ed applicare le
politiche di autorizzazione.
La comunicazione PORTAL->SRTY avviene solo su http/s
attraverso il gateway (dal blocco di portale) 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 allinserimento,
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

Pagina 14 di 65
4.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 List

Contiene 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 Server
Contiene le strutture dati necessarie al funzionamento del PORTAL. Memorizza per un
periodo temporaneo definito dall'Amministratore di Sistema, le informazioni relative agli
utenti.
Ruoli
Contiene tutti i ruoli definiti dal ROLE MANAGER con le relative caratteristiche.
Risorse
Elenco delle risorse accessibili attraverso il PORTAL.
Criteri
Contiene linsieme di dati che selezionano e valorizzano opportunamente i parametri
esposti dagli Adapter consentendone la specializzazione verso una particolare fonte dati.
Fonte Dati
Contiene le informazioni necessaria al ROLE MANAGER per verificare lassegnazione dei
ruoli agli utenti attraverso specifici Adapter.
Profili Applicativi
Descrivono le operazioni che gli utenti sono autorizzati ad effettuare all'interno degli
applicativi SRTY.
4.3 Definizione delle componenti dei sottosistemi

In questo paragrafo saranno descritte le componenti funzionali di ciascun sottosistema.
4.3.1 PORTAL
Desktop Provider
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 dallutente 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.
SAML Auth Module
la componente che implementa il requisito di autenticazione basata sulla verifica di
asserzioni SAML (Security Assertion Markup Language). Garantisce la possibilit di offrire
il servizio in SSO ad utenti gi autenticati su domini con i quali sussiste un rapporto di
fiducia reciproca.
necessario sottolineare che tale componente si occupa di autenticazione e non ha nulla
a che vedere con funzionalit di tipo Attribute Provider; lunico scopo quello di fornire i
meccanismi per permettere al blocco PORTAL di funzionare come Service Provider.
Administration
Fornisce le funzionalit di amministrazione del sistema.

Pagina 15 di 65
Role Sync Client
Legge / interpreta / gestisce i messaggi pubblicati dal Role Sync Server sincronizzando le
informazioni opportune, relative a ruoli, risorse e attributi, nel Directory Server.
Access Manager
Si occupa di fornire le funzionalit di autenticazione e controllo degli accessi.
Per ulteriori informazioni sulle funzionalit di questa componente si rimanda all'offerta
tecnica (par. 5.2.1.1 Sviluppo e Gestione) e/o alla documentazione ufficiale di Sun
Microsystems (vedi URL nel par. 1.3 Glossario dei Termini).
SRA Gateway
La componente che in grado di fornire la protezione in termini di sicurezza di accesso a
tutte le altre.
tecnica (par. 5.2.1.1 Sviluppo e Gestione) e/o alla documentazione ufficiale di Sun
4.3.2 ROLE MANAGER
Role Detection
Si occupa principalmente di verificare lappartenenza di un utente, ad un determinato
ruolo. Lutente identificato attraverso il proprio Codice Fiscale.
Il modulo di Role Detection espone due servizi:
o Check Role
Esegue la verifica di cui sopra (veridicit dei ruoli). Per ogni ruolo valido restituisce
gli attributi valorizzati per laccesso alle applicazioni da esso autorizzate.
o Find Role
Restituisce l'elenco dei ruoli definiti nel sistema.
Il modulo di Role Detection, nella 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.
Adapter
Il modulo espone dei servizi di base al modulo di Role Detection, con uninterfaccia ben
definita, al fine di consentire linterrogazione delle fonti dati esposte dai Certificatori di
Ruolo. Le modalit di utilizzo di un Adapter rispetto, a quali fonti dati contattare, quali
credenziali daccesso 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. LAdapter di
tipo Web Services.
4.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.
Pagina 16 di 65
AM SDK
Framework utilizzato per recuperare ed interpretare le informazioni associate alla sessione
del portale (sessione relativa al blocco PORTAL).
tecnica (par. 11.2.6 Sviluppo e Gestione) e/o alla documentazione ufficiale di Sun
AM Policy Agent
Plug-in software che si avvale dellAM SDK per controllare che lutente che richiede il
servizio sia in possesso di una sessione valida di portale e per richiede al blocco PORTAL
le politiche di autorizzazione che interpreta ed applica.
Per ulteriori informazioni sulle funzionalit di questa componente si rimanda alla
documentazione ufficiale di Sun Microsystems (vedi URL in 1.3 Glossario dei termini).
4.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
linterfaccia 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.
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 a vari livelli:
a seconda delle modalit d'accesso alle applicazioni potrebbe essere prevista, o meno, la
possibilit di effettuare Single Sign-On (SSO);
potrebbero essere previsti meccanismi particolari per l'invio di informazioni sull'Header HTTP
necessari al corretto funzionamento dell'applicazione;
potrebbero essere previste modalit di integrazione in SSO per particolari processi di
autenticazione, quali Form Authentication, Basic Authentication o, pi in generale, qualunque
altro meccanismo custom di autenticazione.
Qualora possibile e non sconveniente, per l'integrazione nel portale, di una qualunque applicazione,
si tender a prediligere l'uso di strumenti quali AMSDK e AM Policy Agent.
Affinch agli utenti sia consentito laccesso diretto alle risorse (cfr. UC5, UC6, UC8 e UC9) risulta
assolutamente necessario che si verifichi una ed una soltanto delle seguenti condizioni:
1. la risorsa installata in un container web compatibile con l'installazione di AM Policy Agent (si
veda la documentazione relativa indicata nel glossario in 1.3);
2. la risorsa viene resa raggiungibile esclusivamente attraverso un container web, che faccia da
reverse proxy, all'interno del quale installabile AM Policy Agent (ad esempio Sun Web Proxy
Server).
Il soddisfacimento di una delle condizioni di cui sopra si rende necessario proprio perch si vuole che
laccesso alla risorsa sia contemporaneamente diretto ossia non mediato da PORTAL
(componente SRA Gateway) e protetto cio sottoposto ai controlli di sicurezza e ai meccanismi
di accesso basati su ruolo, come di seguito specificato nel documento.
4.4 Scenario dinterazioni tra alcune componenti

Ai fini esclusivamente esemplificativi si riporta in Figura 2 Esempio di interazioni nel sistema uno
scenario dinterazione tra alcune componenti principali del sistema. Lo scenario in questione fa
Pagina 17 di 65
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 dopera.
Figura 2 Esempio di interazioni nel sistema

Pagina 18 di 65
4.5 Il Role Manager
Nellambito del funzionamento della soluzione proposta il ROLE MANAGER un elemento di
particolare importanza perch ad esso delegata la fase di verifica dellassociazione 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 lappartenenza di un utente ad un determinato ruolo e
recuperare quindi gli attributi necessari per laccesso alle applicazioni.
Il ROLE MANAGER offre funzionalit di:
interrogazione e verifica del ruolo;

amministrazione delle entit collegate (ruolo, risorsa, criterio);
notifica delle operazioni sul ruolo attraverso linfrastruttura di Cooperazione Applicativa
(CART).
Il ROLE MANAGER composto principalmente dai moduli di:
Role Administration;
Role Detection;
Adapter.
Il ROLE MANAGER utilizza il Proxy_Role per linteroperabilit 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.).
Figura 3 Architettura Logica del ROLE MANAGER
Laccesso di un utente al PORTALE (cfr REQ02, REQ03) prevede che l'utente specifichi i ruoli che
intende ricoprire allinterno del portale. La certificazione delleffettivo possesso di tali ruoli viene
effettuata interrogando i Certificatori di Ruolo, attraverso lintermediazione del Role Manager.
La verifica della validit del ruolo relativo ad un utente (identificato attraverso il suo Codice Fiscale)
avviene attraverso la componente Role Detection che in base a quanto specificato nei criteri, si

Pagina 19 di 65
collega alle fonti dati, mediante lopportuno Adapter, per il recupero degli attributi di certificazione
della validit del ruolo e degli attributi per laccesso 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.
4.5.1 Role Administration
Il Role Administration implementa le funzionalit per lamministrazione dei Ruoli, delle Risorse e dei
Criteri.
Un ruolo viene definito mediante:
un nome univoco;
una descrizione;
un insieme di attributi aggiuntivi.
Per ogni ruolo viene definito un certo numero di criteri che consentono la specializzazione degli
Adapter per laccesso 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 daccesso;
nome di riferimento con cui lattributo associato al ruolo;
mapping tra i nomi che tale attributo ha presso ogni fonte dati e quello che ha come
riferimento nellassociazione al ruolo.
Una risorsa definita con:
un nome univoco;
una descrizione;
un URL.
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.

Pagina 20 di 65
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). Lentit Attributo-
Fonte lentit presente sulla fonte dati che permette la valorizzazione di uno specifico attributo del
ruolo, in base al criterio definito per lo stesso attributo.
Role Manager
Internet user <<Interroga>>

Portal Role Detector 1..n Fonte Dati
/Domain user
1..n 1..n
1 <<Comunica>>
Adapter 1
Ruolo
<<Autocertifica>>
1..n
1
1..n
<<Usa>> <<include>>
1..n
Criterio Connector
1..n
Attributo Attributo-Fonte
1..n 1..n
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. Laggiunta di un attributo al ruolo comporta invece lobbligatoria ed immediata definizione
dei relativi criteri.
Pagina 21 di 65
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.
Figura 6 Processo di definizione dei ruoli, attributi e criteri
4.5.2 Role Detection

La 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 e il/i ruolo/i per i quali deve essere verificata lappartenenza di un
dato utente, ritorna la conferma o negazione del ruolo in verifica ed eventuali attributi aggiuntivi.
Il Web Service FindRole restituisce lelenco dei ruoli definiti nel Role Manager.
4.5.3 Adapter
Per laccesso alle Fonti Dati il ROLE MANAGER si avvale del modulo Role Detection che a sua volta
fa uso degli Adapter per laccesso alle fonti dati.
Sar fornito un Adapter per la comunicazione con le Fonte Dati che espongono Web Services.
Larchitettura del Role Detector consentir di sviluppare nuovi Adapter. Leventuale necessit di
accedere ai dati messi a disposizione da una Fonte Dati non standard o semplicemente non prevista
potr essere risolta mediante limplementazione di un opportuno Adapter scritto ad ad-hoc.
4.5.4 Notifica delle operazioni sul ruolo verso PORTAL e SRTY

La 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 linfrastruttura di
Cooperazione Applicativa (CART).
In particolare, si prevede lutilizzo della modalit di cooperazione applicativa di tipo EDA Event
Driver Architecture o cooperazione ad eventi basata sullo scambio asincrono di messaggi tra i diversi
Pagina 22 di 65
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)
allinterno del repository dei ruoli; i sottoscrittori di tali eventi saranno il PORTALE, che dovr
aggiornare il suo repository e lSRTY.

Pagina 23 di 65
5 REALIZZAZIONE DELLA SOLUZIONE
Vengono di seguito elencati e descritti i requisiti non-funzionali e funzionali sui quali si basata
lanalisi e la progettazione.
5.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 alle risorse disponibili, sia mediato attraverso PORTAL (componente SRA
Gateway) sia diretto.
Affinch laccesso diretto sia possibile deve verificarsi una ed una soltanto delle
seguenti condizioni:
1. la risorsa installata in un container web compatibile con l'installazione di
AM Policy Agent (si veda la documentazione relativa indicata nel glossario
in 1.3);
2. la risorsa viene resa raggiungibile esclusivamente attraverso un container
web, che faccia da reverse proxy, all'interno del quale installabile AM
Policy Agent (ad esempio Sun Web Proxy Server).
Le modalit di accesso che PORTAL mette a disposizione per le risorse variano in

funzione della natura delle risorse stesse; in particolare:
per SRTY: si prevede di utilizzare congiuntamente AM Policy Agent e
AMSDK a livello di framework cos da permettere il massimo grado di
integrazione possibile;

Pagina 24 di 65
per GENERIC:
o se si tratta di applicazioni esistenti e non sviluppate in tecnologia
J2EE o comunque non modificabili, occorrer utilizzare soluzioni ad
hoc (passaggio di parametri tramite header HTTP, uso di reverse-
proxy, );
o se si tratta di applicazioni J2EE modificabili o da sviluppare, la
soluzione migliore, come per SRTY, rimane laccoppiata AM Policy
Agent / AMSDK.
In dettaglio, lAM Policy Agent 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 AMSDK 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 6 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 allinterno 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
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
unapplicazione 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

Pagina 25 di 65
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 evitare la fase di self
registration (REQ02).
Use Cases
REQNF08
Nome Supporti di autenticazione
Descrizione Il sistema accetter esclusivamente i seguenti supporti di autenticazione (cfr.

REQ01) per lautenticazione degli utenti:
1. CNS
2. CNS-like
3. CIE
Per CNS-like si intendono quei supporti di autenticazione con la stessa struttura
dei supporti CNS ma emessi da CA non registrate pubblicamente.
Use Cases
REQNF09
Nome Vincoli prestazionali
Descrizione Le prestazioni delle funzionalit di verifica dei ruoli (cfr. REQ05) dipendono in
maniera assoluta dai tempi operativi e di risposta delle fonti dati.
Use Cases
REQNF10
Nome Accessibilit
Descrizione Tutte le componenti di sistema che prevedono uninterazione di tipo web con
lutente (come ad esempio il desktop di portale) dovranno essere sviluppate in
modo da soddisfare i requisiti di accessibilit web espressi dal CNIPA per i sistemi
di e-government.
Use Cases

Pagina 26 di 65
5.2 Requisiti funzionali
REQ01
Nome Accesso autenticato tramite PDC
Descrizione Nel momento in cui un utente, Internet User o Domain User, tenta l'accesso, il
sistema dovr richiedergli un certificato di autenticazione valido (PDC).
Una volta che l'utente fornisce il certificato richiesto, il sistema verificher che:
1. sia un certificato valido rilasciato da una CA riconosciuta;
2. non sia scaduto;
3. Il seriale del certificato non compaia nelle liste di revoca (CRL) a
disposizione del sistema.
Se tali requisiti sono soddisfatti, il sistema dovr verificare che:
l'utente non sia in Black List (REQ07).
Nel caso in cui tutti i requisiti sono soddisfatti, l'utente sar autorizzato a
proseguire e quindi ad accedere al proprio desktop di portale (REQ03).
Nel caso in cui l'utente sia al primo accesso, prima di controllare la sua presenza in
Black List e di poter accedere al proprio desktop, dovr effettuare un'operazione di
Self Provisioning (REQ02).
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 Self Provisioning
Descrizione Nel caso in cui un utente, Internet User o Domain User, dotato di un certificato
valido (REQ01), si presenti al sistema per un primo accesso, verr presentata una
procedura che gli permetter di registrarsi nel sistema. Con questa procedura
l'utente dovr specificare alcuni suoi dati anagrafici ed i ruoli che possiede al
momento.
La scelta dei ruoli deve avvenire a partire da una lista fornita dal ROLE MANAGER
(REQ06).
Le informazioni inserite dall'utente dovranno essere verificate dal sistema: 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.
Nellattesa che tutti i suoi dati vengano verificati, lutente avr accesso solo ad un
desktop temporaneo in cui non saranno presentate le risorse associate ad i ruoli
specificati. Un volta terminato il processo di validazione, lutente, in caso di
dichiarazione veritiera, potr accedere alle risorse visualizzate in ragione dei ruoli
dichiarati.

Pagina 27 di 65
Nel caso in cui l'utente abbia effettuato una dichiarazione mendace relativamente
all'appartenenza ad uno o pi ruoli, il sistema dovr chiedergli conferma di tale
scelta avvertendolo del problema riscontrato. L'utente, al momento di un nuovo
login o a partire da una funzionalit di modifica del proprio profilo, potr quindi
rivedere la propria posizione oppure confermare la scelta. In questultimo caso, se
la condizione di invalidit della scelta continua a sussistere, il sistema inserir
l'utente nella Black List notificandogli l'avvenuto mediante una messaggio d'errore.
Terminato il processo di registrazione, lutente potr accedere ad un desktop
temporaneo da cui fruire delle risorse associate ai ruoli dichiarati, man mano che
questi vengano validati con successo.
In caso di inserimento dellutente in Black List, lutente non potr pi accedere
neanche al desktop temporaneo.
La necessit di mantenere lutente in uno stato temporaneo durante la fase di
validazione (REQ05) deriva dal fatto che loperazione 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.
Il desktop dovr visualizzare tutte e sole le risorse a cui l'utente pu accedere in
ragione dei propri ruoli.
Sar possibile organizzare la visualizzazione delle risorse sia in base ai ruoli
dellutente sia in base alle categorie di appartenenza delle risorse stesse (cfr.
REQ14).
Use Cases UC1, UC2
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 ROLE MANAGER 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 certo ruolo.
La funzionalit in questione, a partire da un Codice Fiscale (CF) 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.

Pagina 28 di 65
In caso affermativo dovr restituire una lista di attributi valorizzati (chiave, valore)
per laccesso alle applicazioni che il ruolo autorizza.
Le informazioni relative agli attributi di accesso alle applicazioni, saranno
recuperate dal ROLE MANAGER cercando nelle fonti dati accessibili dall'intero
sistema.
Use Cases UC1, UC2
REQ06
Nome Elenco di tutti i ruoli
Descrizione Il ROLE MANAGER 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
REQ07
Nome Black List
Descrizione In fase di Self Provisioning o di modifica del proprio profilo, in caso di dichiarazione
non verificata di appartenenza ad un certo ruolo, il sistema dovr inserire l'utente in
una lista che impedir a questo di accedere ai servizi di portale e a tutte le altre
risorse.
Dovr essere prevista, in ambiente di amministrazione, una funzionalit per la
gestione della Black List (cfr. REQ26, REQ34 e REQ35).
Use Cases UC2, UC10
REQ08
Nome White List
Descrizione La White List un insieme di associazioni (utente, ruolo). Per ogni coppia di
questo tipo, il sistema permetter all'utente di selezionare il ruolo indicato - in fase
di Self Provisioning (REQ02) o di modifica del profilo (REQ09) 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

Pagina 29 di 65
Nome Modifica del profilo utente
Descrizione Il sistema dovr mettere a disposizione degli utenti la funzionalit per la modifica
del proprio profilo.
L'assegnazione di ogni ruolo verr sempre validata come per la funzionalit di Self
Provisioning (REQ02). In caso di dichiarazione mendace, l'utente sar avvertito del
problema e gli sar richiesta una modifica o un nuova conferma. In caso di una
seconda conferma mendace, l'utente sar inserito in Black List.
In attesa del completamento del processo di validazione lutente avr accesso al
desktop temporaneo cos come previsto per la funzionalit di Self Registration
(REQ02),
Use Cases UC10
REQ10
Nome Accesso da un dominio esterno
Descrizione Un utente, Extra-Domain User, autenticato presso un dominio esterno con il quale
sussiste un rapporto di trust, tenta l'accesso al sistema.
Il sistema recuperer dalle asserzioni i ruoli e gli attributi (tra cui il codice fiscale)
che l'utente in questione possiede presso il dominio esterno. Sulla base di queste
informazioni invier un desktop di portale contenente le risorse alle quali l'utente, in
ragione dei ruoli assegnati, ha diritto di accedere.
Nel caso in cui il sistema non sia in grado di reperire le informazioni di cui ha
bisogno per la definizione del desktop di portale, dovr restituire una pagina
d'errore.
Il sistema viene configurato come SAML Service Provider (SP); lidentificazione del
SAML Identity Provider (IdP) remoto avverr sulla base del dominio Internet.
Si intende implementare i meccanismo basandosi sulle specifiche SAML 1.1 con
Browser / POST profile.
Allinterno del sistema, il componente software che verr deputato alla
responsabilit del presente requisito il SAML Auth Module che specializza per
SAML le funzionalit di controllo daccesso di Access Manager.
Use Cases UC3
REQ11
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);

Pagina 30 di 65
criteri per certificazione del ruolo, con relativi parametri (opzionale,
selezionati dallelenco 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.
MANAGER 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 ROLE MANAGER registrer la modifica nel suo repository e comunicher tramite
PORTAL dovr reagire alla pubblicazione sul CART modificando 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.
Inoltre, il sistema PORTAL, per tutti gli utenti associati a tale ruolo, dovr forzare la
scadenza del ruolo stesso implicando una nuova verifica dellassociazione tra
ruolo ed utente.
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

Pagina 31 di 65
ruolo esistente.
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
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.
con le informazioni relative al ruolo cancellato.
Use Cases UC13
REQ14
Nome Inserimento di una nuova risorsa
Descrizione Il sistema dovr mettere a disposizione la funzionalit per l'inserimento di una

nuova risorsa.
MANAGER e quindi scegliere di effettuare l'operazione di inserimento di una
nuova risorsa.
L'amministratore fornisce per la nuova risorsa:
link di riferimento (obbligatorio);
descrizione (opzionale).
Il ROLE MANAGER registrer la risorsa nel suo repository e comunicher tramite
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.
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

Pagina 32 di 65
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.
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
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.
MANAGER e quindi scegliere di effettuare l'operazione di inserimento di un nuovo
criterio.
L'amministratore fornisce per il nuovo criterio:
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

Pagina 33 di 65
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.
MANAGER e quindi scegliere di effettuare l'operazione di modifica di un criterio
esistente.
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.
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 Qualora un utente registrato 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).
In tal caso, per un eventuale accesso successivo, l'utente rimosso dovr effettuare
una nuova procedura di Self Provisioning (REQ02).

Pagina 34 di 65
Use Cases
REQ21
Nome Validit dei ruoli
Descrizione Lattribuzione di un ruolo ad un determinato utente ha una validit temporale

limitata, definibile in maniera indipendente per ogni ruolo.
Il sistema verificher automaticamente la validit dellattribuzione 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 laccesso alle applicazioni verr aggiornato; viceversa, l'utente ricever un
messaggio d'errore al successivo accesso al sistema e dovr forzatamente
eseguire una modifica del proprio profilo (cfr. REQ09).
Use Cases
REQ22
Nome Accesso ai dati utenti da SRTY
Descrizione SRTY, in assenza di problemi di networking, dovr poter accedere, tramite

AMSDK, ai dati dell'utente che sta effettuando la richiesta.
Tramite opportune funzionalit messe a disposizione si potr accedere ai dati
memorizzati dall'Access Manager subito dopo l'autenticazione dellutente.
Linformazione 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 dallutente al momento dellaccesso.
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.

Pagina 35 di 65
REQ25
Nome Associazione Ruoli Profili applicativi
Descrizione Dovr essere predisposta una funzionalit per mezzo della quale dovr essere
possibile eseguire lassociazione tra i ruoli (definiti dal ROLE MANAGER) ed i
profili applicativi definiti allinterno di SRTY.
La determinazione dei ruoli relativi allutente sar quindi lunica 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;
Inserimento e cancellazione categorie;
Associazione di risorse a categorie;
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 lassociazione Codice Fiscale (CF) 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 allinterno 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 unapplicazione 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

Pagina 36 di 65
possibile modulare linsieme 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 di delegarne un altro

per laccesso 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.
Lutente, 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
dellutente delegato unitamente alle risorse alle quali l'utente in questione ha diritto
di accedere.
Use Cases
REQ28
Nome Accesso a risorse delegate
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, Errore. L'origine riferimento non stata trovata.
REQ29
Nome Validit delle deleghe

Pagina 37 di 65
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

Pagina 38 di 65
REQ31
Nome Tracciabilit delle deleghe
Descrizione PORTAL terr traccia degli accessi alle risorse in modalit delegata; il registro di
tali accessi conterr almeno:
1. data e ora dellaccesso
2. risorsa alla quale si sta accedendo
3. codice fiscale del delegante
4. codice fiscale del delegato
5. ruolo delegato (e relativi attributi) in ragione del quale lutente delegato
autorizzato ad accedere alla risorsa
Le operazioni effettuate dagli utenti che accedono in modalit delegata ad una
risorsa saranno inoltre registrate dalla risorsa stessa.
Use Cases UC18, Errore. L'origine riferimento non stata trovata.
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.
Allinterno del sottosistema PORTAL sar necessario configurare la componente
Access Manager 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 (Access Manager) fornir ai SP solo le informazioni
di cui dispone, senza alcuna rielaborazione o interpretazione. Sar compito
esclusivo dei SP interpretare le informazioni ricevute.
Si intende implementare i meccanismo basandosi sulle specifiche SAML 1.1 con

Browser / POST profile.
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.
amministrazione centralizzata e selezionare la sezione riguardante lautenticazione

Pagina 39 di 65
PDC.
L'amministratore fornisce per ogni CA che verr riconosciuta dal PDC Auth Module
ai fini dellautenticazione degli utenti:
descrizione (opzionale);
tipologia di accesso alle CRL (obbligatorio);
indicazioni necessarie per recuperare il codice fiscale da usare come
chiave di autenticazione degli utenti (obbligatorio).
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.
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.
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.
amministrazione centralizzata, selezionare la sezione riguardante la White List,
selezionare un utente ed un ruolo tra quelli definiti nel sistema; infine scegliere di
effettuare l'operazione di inserimento in White List.
Per ogni utente in White List lamministratore deve fornire:
utente
Pagina 40 di 65
ruolo da considerare in White List per lutente 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.
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

Pagina 41 di 65
5.3 Casi d'uso
Di seguito sono illustrati alcuni scenari dutilizzo dell'intero sistema. Per gli scenari dutilizzo di seguito
riportati, sono stati individuati i seguenti attori:
Internet user
Utenti 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.
Administrator
Gli utenti che accedono con funzioni amministrative.
Nella descrizione degli scenari ci si riferiti di volta in volta allintero blocco logico PORTAL o ad
alcune delle sue componenti (Access Manager, Desktop Provider, SRA Gateway) a seconda della
necessit allinterno del contesto di riferimento.
5.3.1 Accesso senza self-registration
Nome UC1
Priorit Alta
Descrizione Un utente accede al portale con un certificato valido.

Il sistema legge il codice fiscale, 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.
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 dallutente si aggiungono
automaticamente
tutti i ruoli antenati (internamente, i ruoli sono rappresentati ad
albero);
i ruoli di amministrazione per cui lutente in White List.
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) invia una pagina di errore.
Eccezione 2: Se l'utente non ha diritto a uno o pi dei ruoli che ha
selezionato, il sistema invia una pagina di conferma contenente i ruoli
selezionali ed un messaggio di errore. In caso di ulteriore fallimento della

Pagina 42 di 65
verifica dei ruoli, il sistema inserisce lutente in Black List ed invia una
pagina di errore.
Figura 7 Accesso senza self-registration
5.3.2 Accesso con self-registration
Nome UC2
Priorit Alta
Descrizione Un utente accede al portale con un certificato valido.

Il sistema verifica che l'utente non abbia mai acceduto prima. Nel caso in cui
lutente sia al primo accesso o, comunque non sia gi registrato, il sistema
propone all'utente di selezionare uno o pi ruoli tra quelli definiti dal ROLE
MANAGER. Da questo elenco di ruoli sono esclusi quelli per i quali lutente
in White List.
Una volta che l'utente ha selezionato i propri ruoli, il sistema verifica che
l'utente ne abbia diritto, tramite una funzionalit messa a disposizione dal
ROLE MANAGER.
In attesa dellesito viene presentato allutente un desktop temporaneo. A
mano a mano che la validazione procede, i ruoli validati con successo
verranno assegnati allutente e il desktop si arricchir dei contenuti relativi a
tali ruoli.
Alla lista dei ruoli esplicitamente selezionati dallutente verranno aggiunti
automaticamente
tutti i ruoli antenati (internamente, i ruoli sono rappresentati ad
albero);

Pagina 43 di 65
i ruoli di amministrazione per cui lutente in White List.
Al termine della verifica, in caso di dichiarazione veritiera, ad ogni accesso

verr presentato allutente il proprio desktop di portale con tutte le risorse a
cui ha diritto di accedere in ragione dei ruoli dichiarati e di quelli per i quali
in White List.
Precondizioni L'utente possiede un certificato 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.
formato, presenza in CRL) invia una pagina di errore.
Eccezione 2: Se l'utente non ha diritto a uno o pi dei ruoli che ha
selezionato, al successivo accesso, il sistema chieder conferma allutente
delle scelte effettuate. In caso di ulteriore fallimento della verifica dei ruoli, il
sistema inserisce lutente in Black List impedendogli quindi accessi futuri
anche al desktop temporaneo.

Pagina 44 di 65
Figura 8 Accesso con self-registration
5.3.3 Accesso da un dominio esterno
Nome UC3
Priorit Alta
Descrizione Un utente, autenticato presso un dominio esterno con il quale sussiste un

rapporto di trust, tenta l'accesso al sistema.
Il sistema recuperer dalle asserzioni il codice fiscale ed i ruoli che l'utente
in questione possiede presso il dominio trusted; sulla base di questi e di
quelli per i quali lutente in White List, invia un desktop di portale
contenente le risorse alle quali l'utente ha diritto di accedere.
Attori Extra-domain user
Precondizioni Sussiste un rapporto di trust tra il dominio esterno ed il sistema.

L'utente stato autenticato dal dominio esterno.

Pagina 45 di 65
accesso al sistema.
Eccezione: Se il sistema non riesce a recuperare dal dominio esterno le
informazioni necessarie sull'utente, invia una pagina di errore.
Figura 9 Accesso da un dominio esterno
5.3.4 Accesso alle risorse SRTY attraverso PORTAL
Nome UC4
Priorit Alta
Descrizione Lutente 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 fiscale
e agli attributi necessari per laccesso e lespletamento del servizio.
A questo punto lutente continua il colloquio con la risorsa SRTY avendo
come punto di accesso la componente SRA Gateway di PORTAL.
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

Pagina 46 di 65
portale e sceglie di accedere ad una di queste.
Postcondizioni L'utente accede alla risorsa selezionata.
Figura 10 Accesso alle risorse SRTY attraverso PORTAL
5.3.5 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 lutente non correntemente
autenticato. A questo punto il sistema verifica la 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.
Lutente viene dapprima dirottato su PORTAL (componente Access
Manager) per lautenticazione e poi in caso di successo ricondotto alla
risorsa alla quale stava originariamente tentando di accedere.
A questo punto lutente 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
Pagina 47 di 65
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.
accesso ad una risorsa.
Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata.

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.
Figura 11 Accesso (inizialmente non autenticato) diretto alle risorse SRTY
Nome UC6
Priorit Alta

Il sistema intercetta la chiamata e verifica che lutente correntemente
autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli
posseduti.
Pagina 48 di 65
Attori Domain user, Internet user, Extra-domain user
Precondizioni L'utente stato precedentemente autenticato dal sistema.

dall'utente.
Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata.

Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione,
Figura 12 Accesso (gi autenticato) diretto alle risorse SRTY
5.3.6 Accesso alle risorse GENERIC attraverso PORTAL
Nome UC7
Priorit Alta
Descrizione Lutente 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.
In base al tipo di applicazione il sistema effettua una serie di operazioni per
garantire fruibilit e SSO. Alcune di queste potrebbero essere, ad esempio:
Inserimento in sessione di informazioni necessarie al funzionamento,
accessibili tramite AM SDK;
Processo automatico di Form Authentication (piuttosto che Basic,
Digest e altro);
Inserimento nella struttura dell'HTTP Header delle informazioni
necessarie al funzionamento.
Se in particolare la risorsa GENERIC in questione unapplicazione in
grado di utilizzare lAMSDK, si faccia riferimento a UC4.

Pagina 49 di 65
A questo punto lutente continua il colloquio con la risorsa GENERIC avendo
come punto di accesso la componente SRA Gateway di PORTAL.
Precondizioni L'utente stato autenticato ed ha ricevuto il desktop di portale

corrispondente ai propri ruoli.
portale e sceglie di accedere ad una di queste.
Postcondizioni L'utente accede alla risorsa selezionata.
Figura 13 Accesso alle risorse GENERIC attraverso PORTAL
5.3.7 Accesso diretto alle risorse GENERIC
Nome UC8
Priorit Alta

Il sistema intercetta la chiamata e verifica che lutente non correntemente
autenticato. A questo punto il sistema verifica la 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.
Lutente viene dapprima dirottato su PORTAL (componente Access
Manager) per lautenticazione e poi in caso di successo ricondotto alla
risorsa alla quale stava originariamente tentando di accedere.

Pagina 50 di 65
Nota: durante la fase di verifica di autenticazione dellutente (interazione tra
AM Policy Agent e Access Manager) possibile inserire meccanismi adatti
da implementare caso per caso per mettere a disposizione della risorsa
GENERIC le informazioni di cui ha bisogno per autorizzare laccesso
dellutente o per altri scopi.
Attori Domain user, Internet user
Precondizioni L'utente non stato precedentemente autenticato dal sistema.

L'utente possiede un certificato di accesso valido.
dall'utente.
Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata.

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,

Pagina 51 di 65
Figura 14 Accesso (inizialmente non autenticato) diretto alle risorse GENERIC

Pagina 52 di 65
Nome UC9
Priorit Alta

Il sistema intercetta la chiamata e verifica che lutente correntemente
autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli
posseduti.
Nota: durante la fase di verifica di autenticazione dellutente (interazione tra
AM Policy Agent e Access Manager) possibile inserire meccanismi adatti
da implementare caso per caso per mettere a disposizione della risorsa
GENERIC le informazioni di cui ha bisogno per autorizzare laccesso
dellutente o per altri scopi.
Attori Domain user, Internet user, Extra-domain user
Precondizioni L'utente stato precedentemente autenticato dal sistema.

dall'utente.
Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata.

Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione,
Figure 15 Accesso (gi autenticato) diretto alle risorse GENERIC

Pagina 53 di 65
5.3.8 Variazione ruoli
Nome UC10
Priorit Alta
Descrizione Lutente, allinterno di una sessione valida di utilizzo del sistema, decide di
voler variare lelenco dei ruoli in suo possesso.
Una volta che l'utente ha selezionato i propri ruoli, il sistema verifica che ne
abbia diritto mediante una funzionalit esposta dal ROLE MANAGER.
In attesa di un responso, ad ogni nuovo accesso, lutente potr accedere
solo sul desktop temporaneo.
Se la verifica ha esito positivo, il sistema, per gli accessi successivi, invier
un nuovo desktop di portale contenente le risorse alle quali l'utente in
ragione dei ruoli assegnati ha diritto di accedere.
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.
Eccezione: Se l'utente non ha diritto a uno o pi dei ruoli che ha selezionato,
il sistema, al prossimo accesso, invier una pagina di conferma contenente i
ruoli selezionali ed un messaggio di errore. In caso di ulteriore fallimento
della verifica dei ruoli, il sistema inserisce lutente in Black List impedendogli
laccesso anche al desktop temporaneo.

Pagina 54 di 65
Figura 16 Variazione ruoli

Pagina 55 di 65
5.3.9 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. Lutente pu indicare se il nuovo
ruolo e 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 dallelenco 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
MANAGER e seleziona la funzionalit. Lutente 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.

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
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.
provvedono ad allineare le proprie informazioni sul ruolo e provvedono al
controllo di coerenza dei dati.
5.3.10 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 cancellazione di una risorsa.

MANAGER e seleziona la funzionalit.
La risorsa deve essere definita coerentemente con le URL di applicazioni
esposte da SRTY / GENERIC.
Eventi di ingresso Lutente 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.
5.3.11 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.

MANAGER e seleziona la funzionalit.
Eventi di ingresso Lutente 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.
5.3.12 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.
Attori Portale
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 dellutente;
- 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 lelenco di tutti i ruoli.
Attori Portale
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 lalbero gerarchico dei ruoli presenti.
5.3.13 Accesso delegato a risorse attraverso PORTAL
Nome UC18
Priorit Alta
Descrizione L'utente accede ad una risorsa attraverso loggetto delega rappresentato sul
proprio desktop di portale.
Il sistema, prima di ridirigere l'utente verso la risorsa selezionata, provvede
a rendere reperibili via AMSDK le informazioni richieste dalla delega e a
tenere traccia dellaccesso in modalit delegata che si sta effettuando.
Precondizioni Lutente stato autenticato ed ha ricevuto il desktop di portale

corrispondente ai propri ruoli
Lutente stato delegato e per questo visualizza sul proprio desktop di
portale almeno un oggetto delega
portale.
Postcondizioni L'utente accede alla risorsa selezionata in modalit delegata.

Il sistema tiene traccia dellaccesso in modalit delegata.
Figura 17 Accesso delegato a risorse attraverso PORTAL

5.3.14 SAML Identity Provider
Nome UC20
Priorit Alta
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 ruoli
L'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 18 Accesso ad un servizio esposto da un ente federato (SP)

5.4 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
REQ02
REQ03
REQ04
REQ07
REQ08
REQ09
REQ10
REQ27
REQ28
REQ29
REQ30
REQ31
REQ32
REQ33
REQ34
REQ35
REQ36
REQ37
ROLE MANAGER REQNF02

REQ05
REQ06
REQ10
REQ11
REQ13
REQ14
REQ150
REQ16
REQ17
REQ18
REQ19
SRTY REQ22
REQ23
REQ24
REQ25
REQ28
REQ31
6 PIANO DI SICUREZZA
Il seguente piano definisce le linee guida che dovranno essere seguite dal fornitore che Regione
Toscana sceglier per linfrastruttura 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.
Lobiettivo 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.
6.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.
Dallanalisi dei flussi si nota che l'utente Administrator avr accesso alle funzioni di amministrazione a
livello applicativo di tutte le aree funzionali.
6.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
o La sua funzione la mera amministrazione dei sistemi lato sistema operativo
o Il system administrator accede ai sistemi tramite il protocollo sicuro
o Il system administrator accede a tutte le console di sistema operativo dei sistemi
installati
o Il system administrator accede e controlla le politiche di backup dei sistemi
o Il system administrator deve poter svolgere tutte le comuni funzioni di amministrazione
di sistema come creazione utenti, log ecc.
Administrator
o La sua funzione lamministrazione di tutti gli applicativi dell'infrastruttura
o L'administrator accede solo tramite protocollo sicuro HTTPS secondo le modalit di
autenticazione previste al REQ01 con i supporti previsti dal REQNF08
o L'administrator accede a tutte le console degli applicativi installati
o L'administrator crea/modifica/cancella ruoli, utenze, log ecc.
Internet User
o L'internet user accede a tutti i servizi erogati dall'infrastruttura solo attraverso la rete
Internet
o L'internet user accede solo tramite protocollo sicuro HTTPS secondo le modalit di
Domain User
o Il domain user accede a tutti i servizi erogati dall'infrastruttura sia attraverso la rete
Internet sia attraverso la rete interna
o Il domain user accede solo tramite protocollo sicuro HTTPS secondo le modalit di
Extra-domain User
o L'extra-domain user accede a tutti i servizi erogati dall'infrastruttura solo attraverso la
rete internet
o L'extra-domain user accede solo tramite protocollo sicuro HTTPS secondo le modalit
di autenticazione previste al REQ01 con i supporti previsti dal REQNF08
o L'extra-domain user viene autenticato tramite il principio della federazione gestito
dall'Access Manager
o L'autenticazione gestita dalla federazione utilizza il protocollo di trasporto HTTPS
6.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.
6.4 Politiche di sicurezza delle aree funzionali

Il piano di sicurezza ha impatto su tutte le aree funzionali dell'architettura
PORTAL
o Gli utenti accedono a PORTAL tramite protocollo sicuro HTTPS secondo le modalit di
o Tutti gli utenti interni possono accedere alle risorse proette da AM Policy Agent
o Accede a ROLE MANAGER tramite web service su protocollo sicuro
o Accede alle notifiche di gestione ruoli pubblicate dal ROLE MANAGER con protocollo
dedicato (Role Sync Client)
ROLE MANAGER
o Verifica che i ruoli forniti dagli utenti in fase di self-registration siano validi
o Per effettuare le verifiche accede a basi di dati esterne
o La natura delle verifiche implica che i protocolli di trasmissione utilizzati dal ROLE
MANAGER non possono essere determinati a priori
o Pubblica le notifiche di gestione ruoli per le altre aree funzionali (Role Sync Server)
SRTY
o Fornisce l'accesso a risorse di varia natura
o Alle risorse si accede tramite protocollo sicuro HTTPS
o Accede alle notifiche di gestione ruoli pubblicate dal ROLE MANAGER con protocollo
dedicato (Role Sync Client)
6.5 Politiche di sicurezza delle componenti applicative

PDC Auth Module
o Ha lo stesso livello di sicurezza di Access Manager
o Modulo scritto ad-hoc seguendo le best practices di sviluppo software
SAML Auth Module
o Ha lo stesso livello di sicurezza di Access Manager
o Modulo gi integrato in Access Manager
Access Manager
o Tutte le comunicazioni da e verso Access Manager avvengono tramite protocollo
sicuro HTTPS
Desktop Provider
o L'elenco delle risorse da mostrare all'utente ricavato tramite accesso in HTTPS ad un
apposito web service esposto dal ROLE MANAGER
AMSDK
o Il protocollo utilizzato l'HTTPS
AM Policy Agent
o Esegue una redirezione su Access Manager utilizzando il protocollo sicuro HTTPS
6.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 sistema
Si tratta di applicare a livello locale lo stesso principio di filtering applicato allintera 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.
Hardening
I 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. Anche Sun Solaris
che comunque un sistema operativo general-purpose sebbene gi sufficientemente sicuro,
necessita di alcune operazioni atte a massimizzarne la sicurezza.
Si suggerisce di effettuare l'hardening dei sistemi utilizzando la metodologia delle blueprints con
l'ausilio del tool JASS.
Le modifiche da implementare sui sistemi riguardano le seguenti aree:

1. Autenticazione/autorizzazione utenti
2. Minimizzazione servizi di rete erogati
3. Tuning dello stack TCP/IP e disabilitazione del forwarding
4. Tuning del Kernel
5. logging centralizzato degli eventi di sistema
6. Sincronizzazione di data ed ora ad una sorgente univoca predefinita
7. Banner di accesso ai sistemi.
Non suggerita la minimizzazione dei sistemi per motivi di supportabilit dei medesimi.
Scendendo nel dettaglio, le operazioni di hardening da effettuare con l'ausilio del tool JASS verranno
implementate principalmente tramite l'esecuzione di una serie di script che si preoccuperanno di
svolgere o meno (a seconda di diversi fattori tra cui ad esempio la versione del sistema operativo o la
presenza o meno di certi package sul sistema) disabilitazioni di servizi.
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

Progetto ARPA-Specifiche Funzionali 1.4

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Progetto ARPA-Specifiche Funzionali 1.4

Caricato da

Copyright:

Formati disponibili

Contratto: ARPA Rif.

repertorio n 6788 raccolta n 2778 firmato il 7/4/2006

Livelli di approvazione Funzione Nome Data Firma

Livelli di approvazione Funzione Nome Data Firma

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Paragrafo/revisione Modifica effettuata Data Approvaz./Autorizz.

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Lobiettivo di questo documento quello di formalizzare i processi di individuazione e classificazione

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 linterfaccia di un

ARPA Autenticazione Ruoli Profili Applicazioni

AM SDK Access Manager Software Development Kit. L'AMSDK un framework che

CART Infrastruttura di Cooperazione Applicativa di Regione Toscana

Cache Memoria che contiene informazioni temporanee, utilizzata per velocizzare la

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

CIE Carte di Identit Elettronica

Criterio Linsieme di dati che selezionano e valorizzano opportunamente i parametri

Firewall Componente di difesa perimetrale che svolge funzioni di controllo accessi a

Fonte Dati Repository di informazione necessario al ROLE MANAGER per verificare

J2EE Java 2 Enterprise Edition

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

LDAP Lightweight Directory Access Protocol

Load Balancer Componente hardware o software che permette la virtualizzazione di pi

link Collegamento ipertestuale

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

PDC Personal Digital Certificate

PDK Proxy Development Kit

Risorsa Applicazione fruibile via web e accessibile mediante link

SIL Sistema Informativo Locale (parte dell'architettura di cooperazione

SAML Security Assertion Markup Language. Linguaggio basato su XML utilizzato

SSO Single Sign On

SRTY Framework per lo sviluppo di applicazioni profilate ad accesso sicuro di

SJS Sun Java System. Famiglia di prodotti software di Sun Microsystems

Web Proxy Componente SJS con funzionalit di reverse proxy.

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

2. RTI (Raggruppamento Temporaneo di Impresa) valuter eventuali attivit addizionali e/o

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Il progetto prevede la realizzazione di uninfrastruttura di Autenticazione ed Accesso Sicuro ai servizi

L'infrastruttura di Autenticazione ed Accesso Sicuro realizzata utilizzando le funzionalit di

Elemento chiave dell'infrastruttura proposta la capacit di interoperare con altre amministrazioni

L'utilizzo di standard aperti, la possibilit di utilizzare i servizi della piattaforma di autenticazione ed

3.1 Sintesi della soluzione

Self Registration - Al primo accesso il sistema richiede allutente di effettuare una

Desktop di Portale personalizzato - Dopo l'accesso autenticato al Portale, agli utenti

Funzionalit di Amministrazione - Consentono all'amministratore l'esecuzione dei

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

Figura 1 Architettura logica

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

4.1.1 Role Manager

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

CRL - Certificate Revocation List

4.3 Definizione delle componenti dei sottosistemi

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA

4.3.2 ROLE MANAGER

Il modulo di Role Detection espone due servizi:

Proxy_Role (Role Sync Server)

Le applicazioni denominate GENERIC rappresentano le applicazioni preesistenti o di futuro sviluppo

L'integrazione di queste applicazioni pu avvenire a vari livelli:

4.4 Scenario dinterazioni tra alcune componenti

Figura 2 Esempio di interazioni nel sistema

Commessa: 05C1204 Specifiche Funzionali PROGETTO ARPA