SPECIFICHE FUNZIONALI DOCUMENTO DI DETTAGLIO RELATIVO AI REQUISITI DI SISTEMA Progetto ARPA CONTIENE D01.1

Transcript

1 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 Data Firma RTI Redazione GdL ARPA RTI Integrazione GdL ARPA RTI Revisione Architect RTI Ovidiu Constantin Approvazione/Emissione PM RTI Marco Coppi Livelli di approvazione Cliente Verifica Approvazione Approvazione Funzione Data Firma LISTA DI DISTRIBUZIONE Pagina 1 di 65

2 REVISIONI Paragrafo/revisione Modifica effettuata Data Approvaz./Autorizz. 1.0 Accorpati i due documento 0.16a e 0.16b. Aggiunti flussi applicativi su architettura logica. componenti e loro 7/8/06 interazione. 1.1 Estensione del Req 26, aggiunta spiegazione su Req 06, Aggiunta spiegazione su come gestire le CA del PDC 6/10/06 auth module nel REQ26, Modifica REQ10, REQ 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 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 Allineamento con il TestPlan 20/06/ 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) REQ14: le categorie non sono specificate 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 24/10/07 Pagina 2 di 65

3 SOMMARIO 1 GENERALITÀ SCOPO VALIDITÀ GLOSSARIO DEI TERMINI RIFERIMENTI ASSUNZIONI E DIPENDENZE INTRODUZIONE SINTESI DELLA SOLUZIONE ARCHITETTURA LOGICA SOTTOSISTEMI PRINCIPALI E LORO INTERAZIONI Role Manager Portal Generic SRTY BANCHE DATI UTILIZZATE DEFINIZIONE DELLE COMPONENTI DEI SOTTOSISTEMI PORTAL ROLE MANAGER SRTY GENERIC SCENARIO D INTERAZIONI TRA ALCUNE COMPONENTI IL ROLE MANAGER Role Administration...20 Un ruolo viene definito mediante: Role Detection Adapter Notifica delle operazioni sul ruolo verso PORTAL e SRTY REALIZZAZIONE DELLA SOLUZIONE REQUISITI NON FUNZIONALI REQUISITI FUNZIONALI CASI D'USO Accesso senza self-registration Accesso con self-registration Accesso da un dominio esterno Accesso alle risorse SRTY attraverso PORTAL Accesso diretto alle risorse SRTY Accesso alle risorse GENERIC attraverso PORTAL Accesso diretto alle risorse GENERIC Variazione ruoli Inserimento, Modifica e Cancellazione di un Ruolo Inserimento, Modifica e Cancellazione di una Risorsa Inserimento, Modifica e Cancellazione di un Criterio Individuazione e verifica dei ruoli Accesso delegato a risorse attraverso PORTAL SAML Identity Provider TRACCIABILITÀ DEI REQUISITI SUI SOTTOSISTEMI INDIVIDUATI PIANO DI SICUREZZA SICUREZZA ARCHITETTURALE POLITICHE DI SICUREZZA DELLE UTENZE POLITICHE DI SICUREZZA PER LE APPLICAZIONI Pagina 3 di 65

4 6.4 POLITICHE DI SICUREZZA DELLE AREE FUNZIONALI POLITICHE DI SICUREZZA DELLE COMPONENTI APPLICATIVE POLITICHE DI SICUREZZA PER I SISTEMI Pagina 4 di 65

5 1 GENERALITÀ Il presente documento descrive i requisiti e le specifiche funzionali previsti per la realizzazione del portale per l accesso sicuro denominato ARPA. 1.1 Scopo L obiettivo di questo documento è quello di formalizzare i processi di individuazione e classificazione delle funzionalità del sistema oggetto di analisi e dei relativi requisiti. 1.2 Validità Il presente documento è valido a partire dalla data di emissione riportata in copertina. 1.3 Glossario dei termini Access Manager Adapter ARPA AM Policy Agent AM SDK CA CART Cache Componente della suite Sun Java System (SJS) che eroga funzionalità di autenticazione e controllo accessi. Componente software che nasconde ed adatta l interfaccia di un componente mostrandone un altra all esterno. Consente di uniformare l interfaccia di accesso alle fonti dati durante il processo di discovery e verifica dei ruoli. Autenticazione Ruoli Profili Applicazioni 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 d accesso alle risorse. 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.) Certification Authority. È una entità che rilascia certificati digitali verso terze parti. Aggiorna periodicamente anche le CRL relative ai certificati emessi. Infrastruttura di Cooperazione Applicativa di Regione Toscana Memoria che contiene informazioni temporanee, utilizzata per velocizzare la Pagina 5 di 65

6 ricerca e la fruizione delle informazioni, evitando di reperirle direttamente dalle fonti primarie. Certificatori di ruolo CIE CNIPA CNS Connector Criterio CRL Desktop Directory Server Firewall Fonte Dati GENERIC Integrazione Applicazioni Entità che rendono disponibili attraverso una o più Fonte Dati, le informazioni (gli attributi) necessari alla verifica (certificazione) del ruolo da parte del modulo Role Manager. Carte di Identità Elettronica Centro Nazionale per l'informatica nella Pubblica Amministrazione Carta Nazionale dei Servizi Componente software che consente l interscambio di informazioni con una particolare fonte dati mediante il protocollo richiesto. L insieme di dati che selezionano e valorizzano opportunamente i parametri esposti dagli Adapter, consentendone la specializzazione per il prelievo di opportune informazioni dalle varie fonti dati. Certificate Revocation List. I certificati revocati o sospesi sono inseriti in CRL firmate dall CA e pubblicate con periodicità prestabilita nel registro dei certificati. Ambiente di lavoro erogato agli utenti attraverso la componente SJS Portal Server utilizzata nell'ambito del PORTAL. È il repository dei dati utilizzato dal Portale e dell'access Manager, costituito dal Directory Server LDAPv3 Sun Java System Directory Server. Componente di difesa perimetrale che svolge funzioni di controllo accessi a livello di rete tra due o più sottoreti. Repository di informazione necessario al ROLE MANAGER per verificare l assegnazione dei ruoli agli utenti attraverso specifici Adapter. Applicazioni preesistenti o future che vengono integrate a vario livello nell infrastruttura. Sono escluse da questa definizione le applicazioni sviluppate con il framework Srty. Una applicazione è da considerarsi integrata nel portale quando: è 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

7 applicazioni accessibili via protocolli Internet (HTTP) LDAP Load Balancer link NAL PDC PDK Lightweight Directory Access Protocol Particolare tipo di protocollo per la ricerca e la fruizione di informazioni Componente hardware o software che permette la virtualizzazione di più server su una unica entità e la suddivisione del carico su di essi. Collegamento ipertestuale Nodo Applicativo Locale (parte dell'architettura di cooperazione applicativa) Personal Digital Certificate Proxy Development Kit Insieme di pacchetti software e di specifiche per la realizzazione di proxy applicativi Proxy applicativo Porta applicativa per l accesso alle funzioni di pubblicazione e sottoscrizione del CART Risorsa Ruolo SIL SAML SRA Gateway SSO SRTY SJS Web Proxy Server Web Service Applicazione fruibile via web e accessibile mediante link Individua gli incarichi, gli obblighi ed privilegi che un utente ha all'interno di un determinato contesto istituzionale e che ne condizionano i profili applicativi all interno del portale. Sistema Informativo Locale (parte dell'architettura di cooperazione applicativa) 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 Componente della suite Sun Java System (SJS) che eroga funzionalità di sicurezza per l accesso. Single Sign On Framework per lo sviluppo di applicazioni profilate ad accesso sicuro di Regione Toscana. Sun Java System. Famiglia di prodotti software di Sun Microsystems Componente SJS con funzionalità di reverse proxy. Applicazione software le cui funzionalità sono descrivibili, identificabili ed usufruibili tramite linguaggio XML; le interazioni con altre applicazioni vengono effettuate tramite scambio di messaggi basati su XML con l utilizzo di protocolli Internet (HTTP) Pagina 7 di 65

8 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

9 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

10 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 un infrastruttura di Autenticazione ed Accesso Sicuro ai servizi di Regione Toscana (E.Toscana), ottenuta dall integrazione 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 Nell ambito 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 all utente 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 dall utente (il ruolo) sarà verificata dal Pagina 10 di 65

11 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 - L utente 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

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

13 4.1 Sottosistemi principali e loro interazioni L'architettura logica è composta da quattro aree funzionali principali, corrispondenti ai seguenti sottosistemi: Role Manager Interazione con CART Interazione con GENERIC Interazione con SRTY Interazione con PORTAL ROLE MANAGER 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 l associazione tra essi. Pubblica sul CART gli eventi collegati alle operazioni d inserimento, modifica e cancellazione di ruoli, risorse, attributi e criteri. Nessuna interazione diretta Nessuna interazione diretta (pubblicazione attraverso CART) Vedi interazione con CART e par (Interazione con R.M.) Portal Interazione con CART Interazione con ROLE MANAGER Interazione con GENERIC Interazione con SRTY PORTAL 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. Legge dal CART gli eventi pubblicati dal ROLE MANAGER. Reagisce agli eventi pubblicati, collegati alle operazioni d inserimento, modifica e cancellazione di ruoli, risorse, attributi e criteri, modificando dinamicamente la struttura dei ruoli di portale e le policy d accesso alle risorse così come descritto nel paragrafo dedicato alla definizione dei requisiti. 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. Scambia informazioni con le applicazioni appartenenti al blocco GENERIC per offrire, in vari modi, l integrazione di queste nel portale fino a garantire raggiungibilità dei servizi, fruibilità e Single Sign-On (SSO). Per ogni applicazione integrata nel portale, la raggiungibilità del sevizio viene offerta mediante un azione 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 dell applicazione da integrare: potrebbero essere previsto l invio di informazioni su HTTP Header, l interazione con meccanismi di Form Authentication piuttosto che Basic o Digest o altro meccanismo custom, l uso di AM SDK o AM Policy Agent ed altro ancora. Mediante un meccanismo di reverse proxy offre la raggiungibilità, dall esterno, del servizio pubblicato su SRTY. Pagina 13 di 65

14 Inoltre, centralizza l autenticazione e l autorizzazione d accesso ai servizi offerti Generic GENERIC Rappresentano le applicazioni preesistenti o di futuro sviluppo che possono essere integrate e rese fruibili attraverso il PORTAL. Tali applicazioni, non sviluppate mediante il framework SRTY, sono associate ai vari ruoli tramite l interfaccia d amministrazione 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 SRTY Interazione con PORTAL Interazione con CART Interazione con ROLE MANAGER Interazione con GENERIC SRTY SRTY è il framework di sviluppo della applicazioni profilate ad accesso sicuro di Regione Toscana. Nell'ambito del framework SRTY possiamo identificare con SRTY Applications, gli applicativi installati nell'ambiente SRTY e con SRTY Core l'ambiente nel quale vengono installate le applicazione che utilizzano questo framework. Le SRTY Applications si interfacciano con il PORTAL per il reperimento delle credenziali dell utente e vengono associate ai vari ruoli tramite l interfaccia di amministrazione del ROLE MANAGER. Poiché il PORTAL offre i meccanismi di autenticazione e autorizzazione per SRTY, tale blocco logico ha la necessità di comunicare con il PORTAL. La comunicazione SRTY->PORTAL avviene su HTTP/s mediante l uso del framework AM SDK. L AM SDK è usato dalle singole applicazioni del blocco SRTY per recuperare alcune informazioni relative all utente e dall AM 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. SRTY legge dal CART gli eventi pubblicati dal ROLE MANAGER reagendo agli eventi collegati all inserimento, modifica e cancellazione di un ruolo, come riportato nel paragrafo dedicato alla specifica dei requisiti. Nessuna interazione diretta (lettura attraverso CART) Nessuna interazione diretta Pagina 14 di 65

15 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 l insieme 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 l assegnazione dei ruoli agli utenti attraverso specifici Adapter. Profili Applicativi Descrivono le operazioni che gli utenti sono autorizzati ad effettuare all'interno degli applicativi SRTY. 4.3 Definizione delle componenti dei sottosistemi In questo paragrafo saranno descritte le componenti funzionali di ciascun sottosistema 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 dall utente in fase di richiesta di servizio (accesso al portale); tecnicamente è quello che si definisce un modulo di autenticazione del portale. I certificati digitali supportati da tale modulo di autenticazione sono: CNS, CNS-like e CIE. Il concetto di validità di un PDC è affrontato, in questo documento, con maggiore dettaglio, nella sezione dedicata alla specifica dei requisiti funzionali. 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 ; l unico 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

16 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 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. Per ulteriori informazioni sulle funzionalità di questa componente si rimanda all'offerta tecnica (par Sviluppo e Gestione) e/o alla documentazione ufficiale di Sun Microsystems (vedi URL nel par. 1.3 Glossario dei Termini) ROLE MANAGER Role Detection Si occupa principalmente di verificare l appartenenza di un utente, ad un determinato ruolo. L utente è 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 l accesso 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 un interfaccia ben definita, al fine di consentire l interrogazione delle fonti dati esposte dai Certificatori di Ruolo. Le modalità di utilizzo di un Adapter rispetto, a quali fonti dati contattare, quali credenziali d accesso utilizzare, quali attributi recuperare sono definite in fase di configurazione dei criteri. Nella stessa fase viene stabilito inoltre come effettuare un mapping dei loro nomi su quelli dei corrispettivi attributi associati ai ruoli. L Adapter è di tipo Web Services 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

17 AM SDK Framework utilizzato per recuperare ed interpretare le informazioni associate alla sessione del portale (sessione relativa al blocco PORTAL). Per ulteriori informazioni sulle funzionalità di questa componente si rimanda all'offerta tecnica (par Sviluppo e Gestione) e/o alla documentazione ufficiale di Sun Microsystems (vedi URL nel par. 1.3 Glossario dei Termini). AM Policy Agent Plug-in software che si avvale dell AM SDK per controllare che l utente 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) GENERIC Le applicazioni denominate GENERIC rappresentano le applicazioni preesistenti o di futuro sviluppo che possono essere integrate e rese fruibili attraverso il PORTAL. Tali applicazioni, non sviluppate mediante il framework SRTY, sono associate ai vari ruoli tramite l interfaccia di amministrazione del ROLE MANAGER. Tutte le applicazione, SRTY o GENERIC, associate ad uno qualunque dei ruoli definiti dal ROLE MANAGER saranno trattate allo stesso modo; l'unica differenza tra le varie applicazioni potrebbe essere la metodologia di integrazione. 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 l accesso 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 l accesso 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 d interazioni tra alcune componenti Ai fini esclusivamente esemplificativi si riporta in Figura 2 Esempio di interazioni nel sistema uno scenario d interazione tra alcune componenti principali del sistema. Lo scenario in questione fa Pagina 17 di 65

18 riferimento ad una parte del processo di self-registration e non ha la pretesa di risolvere tutti i casi possibili che saranno approfonditi successivamente in corso d opera. Figura 2 Esempio di interazioni nel sistema Pagina 18 di 65

19 4.5 Il Role Manager Nell ambito del funzionamento della soluzione proposta il ROLE MANAGER è un elemento di particolare importanza perché ad esso è delegata la fase di verifica dell associazione ruolo/utente. Il ruolo è caratterizzato da un insieme di attributi custoditi dai Certificatori di Ruolo che possono essere recuperati interrogando una o più Fonti Dati; attraverso le funzionalità del ROLE MANAGER il PORTAL è in grado quindi di validare l appartenenza di un utente ad un determinato ruolo e recuperare quindi gli attributi necessari per l accesso alle applicazioni. Il ROLE MANAGER offre funzionalità di: interrogazione e verifica del ruolo; amministrazione delle entità collegate (ruolo, risorsa, criterio); notifica delle operazioni sul ruolo attraverso l infrastruttura 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 l interoperabilità basata sulla cooperazione applicativa. La Figura 3 Architettura Logica del ROLE MANAGER evidenzia i moduli logici del ROLE MANAGER e le sue interfacce con le componenti esterne (CART, Fonti Dati, etc.). Figura 3 Architettura Logica del ROLE MANAGER L accesso di un utente al PORTALE (cfr REQ02, REQ03) prevede che l'utente specifichi i ruoli che intende ricoprire all interno del portale. La certificazione dell effettivo possesso di tali ruoli viene effettuata interrogando i Certificatori di Ruolo, attraverso l intermediazione del Role Manager. La verifica della validità del ruolo relativo ad un utente (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

20 collega alle fonti dati, mediante l opportuno Adapter, per il recupero degli attributi di certificazione della validità del ruolo e degli attributi per l accesso alle applicazioni. Il Certificatore di Ruolo da contattare, la Fonte Dati da interrogare, nonché gli attributi da valorizzare, sono tutte informazioni specificate nella tabella dei criteri. La definizione di un criterio e la sua associazione ad un ruolo/attributo viene effettuata dinamicamente in fase di configurazione del ruolo e conservata opportunamente nella banca dati dei ruoli Role Administration Il Role Administration implementa le funzionalità per l amministrazione dei Ruoli, delle Risorse e dei Criteri. Un ruolo viene definito mediante: un nome univoco; una descrizione; un insieme di attributi aggiuntivi. Per ogni ruolo viene definito un certo numero di criteri che consentono la specializzazione degli Adapter per l accesso a specifiche Fonti Dati per la: certificazione del ruolo in oggetto; valorizzazione degli eventuali attributi associati. Un criterio può essere associato ad un ruolo o ad un attributo. Per ogni ruolo sono definite le informazioni su come certificare la coppia ruolo/utente (fonte dati da contattare, Adapter da utilizzare, credenziali di accesso, etc.), mentre per un attributo sono definite le modalità di valorizzazione specificando: fonte/i dati da contattare; Adapter da utilizzare; eventuali credenziali d accesso; nome di riferimento con cui l attributo è associato al ruolo; mapping tra i nomi che tale attributo ha presso ogni fonte dati e quello che ha come riferimento nell associazione al ruolo. Una risorsa è definita con: un nome univoco; una descrizione; un URL. 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

21 Figura 4 Corrispondenza informazioni tra ruolo e fonti dati Le relazioni tra le varie entità coinvolte nel funzionamento del Role Administration e più genericamente del portale, sono illustrate nel diagramma seguente (Figura 5). L entità Attributo- Fonte è l entità presente sulla fonte dati che permette la valorizzazione di uno specifico attributo del ruolo, in base al criterio definito per lo stesso attributo. Role Manager Internet user /Domain user Portal Role Detector <<Interroga>> 1..n Fonte Dati 1 <<Comunica>> 1..n 1..n <<Autocertifica>> 1..n Ruolo 1..n <<Usa>> Adapter 1 1 <<include>> Criterio 1..n Connector 1..n Attributo 1..n 1..n Attributo-Fonte Figura 5 Relazioni tra le Entità del Role Manager È possibile definire in modo separato ed in tempi diversi i criteri, i ruoli, gli attributi. In particolare, qualora venga definito un ruolo e non vengano selezionati o definiti immediatamente i relativi criteri di verifica, esso rimane in uno stato intermedio definito bozza e non viene reso disponibile agli altri moduli. Tale definizione potrà essere completata successivamente, rendendo il ruolo attivo e disponibile. L aggiunta di un attributo al ruolo comporta invece l obbligatoria ed immediata definizione dei relativi criteri. Pagina 21 di 65

22 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 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 l appartenenza di un dato utente, ritorna la conferma o negazione del ruolo in verifica ed eventuali attributi aggiuntivi. Il Web Service FindRole restituisce l elenco dei ruoli definiti nel Role Manager Adapter Per l accesso alle Fonti Dati il ROLE MANAGER si avvale del modulo Role Detection che a sua volta fa uso degli Adapter per l accesso alle fonti dati. Sarà fornito un Adapter per la comunicazione con le Fonte Dati che espongono Web Services. L architettura del Role Detector consentirà di sviluppare nuovi Adapter. L eventuale necessità di accedere ai dati messi a disposizione da una Fonte Dati non standard o semplicemente non prevista potrà essere risolta mediante l implementazione di un opportuno Adapter scritto ad ad-hoc 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 l infrastruttura di Cooperazione Applicativa (CART). In particolare, si prevede l utilizzo della modalità di cooperazione applicativa di tipo EDA Event Driver Architecture o cooperazione ad eventi basata sullo scambio asincrono di messaggi tra i diversi Pagina 22 di 65

23 domini, ovvero i partecipanti non devono restare connessi in attesa di una risposta dal destinatario, ma possono limitarsi ad inviare il messaggio affidandolo all'infrastruttura di servizio con il compito di gestirne la consegna in modo affidabile. La modalità scelta per la cooperazione ad eventi è quella Publish & Subscribe, in cui il Role Manager, attraverso il Proxy_Role implementato sul NAL, pubblicherà gli eventi legati alla variazione (creazione, modifica, cancellazione) di un ruolo e relative informazioni collegate (attributi e risorse) all interno del repository dei ruoli; i sottoscrittori di tali eventi saranno il PORTALE, che dovrà aggiornare il suo repository e l SRTY. Pagina 23 di 65

24 5 REALIZZAZIONE DELLA SOLUZIONE Vengono di seguito elencati e descritti i requisiti non-funzionali e funzionali sui quali si è basata l analisi e la progettazione. 5.1 Requisiti non funzionali REQNF01 Amministrazione centralizzata 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). UC11, UC12, UC13, UC14, UC15 REQNF02 Utilizzo del CART È 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 UC11, UC12, UC13, UC14, UC15 REQNF03 Accesso alle risorse 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é l accesso 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

25 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 reverseproxy, ); o se si tratta di applicazioni J2EE modificabili o da sviluppare, la soluzione migliore, come per SRTY, rimane l accoppiata AM Policy Agent / AMSDK. In dettaglio, l AM 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. UC4, UC5, UC6, UC7, UC8, UC9 REQNF04 Sicurezza Per i dettagli relativi alla sicurezza si faccia riferimento alla Sezione 6 di questo documento. REQNF05 Retrocompatibilità di SRTY La versione di SRTY sviluppata per l'integrazione nel presente sistema dovrà essere retrocompatibile con la versione attualmente operativa. In particolare le applicazioni correntemente disponibili all interno della versione attualmente operativa non necessiteranno di alcuna modifica per funzionare con la nuova versione, eccezion fatta per la sezione relativa ai ruoli ed alla loro associazione con i profili applicativi. REQNF06 Amministrazione di SRTY Dal punto di vista tecnologico, la sezione di amministrazione di SRTY sarà mantenuta uguale a quella attualmente operativa; essa sarà cioè costituita da un applicazione web a sua volta utilizzante il framework SRTY. Si accederà a tale applicazione in maniera analoga a quella prevista per le altre applicazioni sviluppate col framework SRTY. REQNF07 Pagina 25 di 65

26 Importazione iniziale degli utenti di dominio interno 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). REQNF08 Supporti di autenticazione Il sistema accetterà esclusivamente i seguenti supporti di autenticazione (cfr. REQ01) per l autenticazione 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. REQNF09 Vincoli prestazionali Le prestazioni delle funzionalità di verifica dei ruoli (cfr. REQ05) dipendono in maniera assoluta dai tempi operativi e di risposta delle fonti dati. REQNF10 Accessibilità Tutte le componenti di sistema che prevedono un interazione di tipo web con l utente (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. Pagina 26 di 65

27 5.2 Requisiti funzionali REQ01 Accesso autenticato tramite PDC 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. UC1, UC2 REQ02 Self Provisioning 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. Nell attesa che tutti i suoi dati vengano verificati, l utente 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, l utente, in caso di dichiarazione veritiera, potrà accedere alle risorse visualizzate in ragione dei ruoli dichiarati. Pagina 27 di 65

28 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 quest ultimo 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, l utente 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 dell utente in Black List, l utente non potrà più accedere neanche al desktop temporaneo. La necessità di mantenere l utente in uno stato temporaneo durante la fase di validazione (REQ05) deriva dal fatto che l operazione in questione non può essere soggetta a vincoli prestazionali (cfr. REQNF09). UC1, UC2 REQ03 Desktop di portale 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 dell utente sia in base alle categorie di appartenenza delle risorse stesse (cfr. REQ14). UC1, UC2 REQ04 Gestione delle Liste di Revoca (CRL) Il sistema dovrà mettere a disposizione una funzionalità per la gestione delle liste di revoca dei certificati. UC1, UC2 REQ05 Controllo di appartenenza di un utente ad un ruolo 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

29 In caso affermativo dovrà restituire una lista di attributi valorizzati (chiave, valore) per l accesso alle applicazioni che il ruolo autorizza. Le informazioni relative agli attributi di accesso alle applicazioni, saranno recuperate dal ROLE MANAGER cercando nelle fonti dati accessibili dall'intero sistema. UC1, UC2 REQ06 Elenco di tutti i ruoli 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. UC1, UC2 REQ07 Black List 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). UC2, UC10 REQ08 White List 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). REQ09 Pagina 29 di 65

30 Modifica del profilo utente 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 l utente avrà accesso al desktop temporaneo così come previsto per la funzionalità di Self Registration (REQ02), UC10 REQ10 Accesso da un dominio esterno 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); l identificazione 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. All interno 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 d accesso di Access Manager. UC3 REQ11 Inserimento di un nuovo ruolo 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

31 criteri per certificazione del ruolo, con relativi parametri (opzionale, selezionati dall elenco dei criteri disponibili). Fin quando tali criteri non sono forniti, il ruolo rimane in uno stato intermedio (bozza) e non è reso disponibile sul portale (non notificato su CART); eventuali attributi da associare al ruolo (con relativi criteri, eventuali valori di default e parametri per la valorizzazione); una lista di risorse da associare al ruolo (una o più risorse prese dalla lista di tutte le risorse presenti); periodo di validità (obbligatorio) (cfr. REQ21) Il ROLE MANAGER registrerà il ruolo nel suo repository e comunicherà tramite CART l'avvenuta operazione. PORTAL dovrà reagire alla pubblicazione sul CART definendo un nuovo ruolo di portale e definendo le policy di accesso alle risorse in base a quanto specificato per il nuovo ruolo creato. SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al nuovo ruolo. UC11 REQ12 Modifica di un ruolo esistente Il sistema dovrà mettere a disposizione la funzionalità per la modifica di un ruolo esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE 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 CART l'avvenuta operazione. 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 dell associazione tra ruolo ed utente. SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al ruolo modificato. UC12 REQ13 Cancellazione di un ruolo esistente Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di un Pagina 31 di 65

32 ruolo esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di un ruolo esistente. L'amministratore dovrà scegliere il ruolo da cancellare tra la lista di tutti quelli presenti e quindi avviare l'operazione. Il ROLE MANAGER registrerà la modifica nel suo repository e comunicherà tramite CART l'avvenuta operazione. PORTAL dovrà reagire alla pubblicazione sul CART rimuovendo il ruolo di portale corrispondente, rimuovendo la lista degli attributi concernenti le applicazioni associate al ruolo in questione ed eventualmente modificando le policy di accesso alle risorse. SRTY dovrà reagire alla pubblicazione sul CART allineando le proprie banche dati con le informazioni relative al ruolo cancellato. UC13 REQ14 Inserimento di una nuova risorsa Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di una nuova risorsa. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di inserimento di una nuova risorsa. L'amministratore fornisce per la nuova risorsa: nome (obbligatorio); link di riferimento (obbligatorio); descrizione (opzionale). Il ROLE MANAGER registrerà la risorsa nel suo repository e comunicherà tramite CART l'avvenuta operazione. UC14 REQ15 Modifica di una risorsa esistente Il sistema dovrà mettere a disposizione la funzionalità per la modifica di una risorsa esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di modifica di una risorsa esistente. L'amministratore dovrà scegliere la risorsa da modificare tra la lista di tutte quelle Pagina 32 di 65

33 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. UC14 REQ16 Cancellazione di una risorsa esistente Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di una risorsa esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di una risorsa esistente. L'amministratore dovrà scegliere la risorsa da cancellare tra la lista di tutte quelle presenti e quindi avviare l'operazione. Il ROLE MANAGER cancellerà la risorsa nel suo repository e comunicherà tramite CART l'avvenuta operazione. Nel caso in cui la risorsa fosse assegnata ad un ruolo, PORTAL dovrà reagire alla pubblicazione sul CART modificando il ruolo al proprio interno: rimuovendo la lista degli attributi relativi alle applicazioni associate al ruolo e modificando adeguatamente le security policy relative alla risorsa in questione. UC14 REQ17 Inserimento di un nuovo criterio Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un nuovo criterio. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di inserimento di un nuovo criterio. L'amministratore fornisce per il nuovo criterio: nome (obbligatorio); tipo (obbligatorio); descrizione (opzionale). ulteriori campi obbligatori (definizione delle politiche di verifica dei ruoli, di recupero degli attributi e di mapping dei nomi degli attributi da e verso le fonti Pagina 33 di 65

34 dati). Il ROLE MANAGER registrerà il criterio nel suo repository. UC15 REQ18 Modifica di un criterio esistente Il sistema dovrà mettere a disposizione la funzionalità per la modifica di un criterio esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di modifica di un criterio esistente. 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. UC15 REQ19 Cancellazione di un criterio esistente Il sistema dovrà mettere a disposizione la funzionalità per la cancellazione di un criterio esistente. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante il ROLE MANAGER e quindi scegliere di effettuare l'operazione di cancellazione di un criterio esistente. L'amministratore dovrà scegliere il criterio e quindi avviare l'operazione. Nel caso in cui il criterio in questione sia associato ad un certo ruolo, il sistema deve permettere, in maniera automatica o manuale, di effettuare una operazione per eliminare tale associazione. Solo quando un criterio non sarà associato ad alcun ruolo allora l'operazione di cancellazione può essere portata a termine. Il ROLE MANAGER rimuoverà il criterio nel suo repository. UC15 REQ20 Rimozione automatica utenti 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

35 REQ21 Validità dei ruoli L attribuzione 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à dell attribuzione dei ruoli agli utenti: allo scadere del periodo di validità per ogni utente, per ogni ruolo il sistema provvederà ad effettuare una nuova verifica presso il ROLE MANAGER. In caso di esito positivo, il periodo di validità verrà rinnovato e la lista degli attributi per l accesso alle applicazioni verrà aggiornato; viceversa, l'utente riceverà un messaggio d'errore al successivo accesso al sistema e dovrà forzatamente eseguire una modifica del proprio profilo (cfr. REQ09). REQ22 Accesso ai dati utenti da SRTY 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 dell utente. L informazione minima necessaria al corretto funzionamento di SRTY è quella relativa al CF, ai ruoli dell'utente che effettua la richiesta ed agli attributi relativi ad ogni applicazione associata ai ruoli ricoperti dall utente al momento dell accesso. UC4, UC5, UC6 REQ23 Sincronizzazione dei ruoli da parte di SRTY 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. UC4, UC5, UC6 REQ24 Gestione dei profili applicativi per SRTY 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. UC4, UC5, UC6 Pagina 35 di 65

36 REQ25 Associazione Ruoli Profili applicativi Dovrà essere predisposta una funzionalità per mezzo della quale dovrà essere possibile eseguire l associazione tra i ruoli (definiti dal ROLE MANAGER) ed i profili applicativi definiti all interno di SRTY. La determinazione dei ruoli relativi all utente sarà quindi l unica operazione strettamente necessaria per la corretta definizione della pagine applicative di presentazione. UC4, UC5, UC6 REQ26 Amministrazione 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 l associazione 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 all interno di un ruolo ed il nome che tale attributo ha su ciascuna fonte dati sulla quale si recupera uno qualunque dei suoi valori (attributi multivalue tipo ASL di appartenenza). Come specificato in REQNF01, l'interfaccia di amministrazione sarà centralizzata; questo però solo per quanto riguarda la logica di presentazione: le funzionalità dovranno essere dislocate tra i vari sottosistemi in base alle aree di competenza. In particolare: SRTY offrirà funzionalità di amministrazione tramite un applicazione web, in maniera analoga a quella della versione attualmente in uso (REQNF06) PORTAL e ROLE MANAGER forniranno componenti di amministrazione che saranno rese fruibili attraverso il desktop di portale agli utenti amministratori, in aggiunta alle eventuali risorse che questi utenti visualizzeranno in ragione dei ruoli posseduti. Verranno inoltre definiti diversi livelli di amministrazione così che sia Pagina 36 di 65

37 possibile modulare l insieme delle funzionalità di amministrazione cui ogni singolo utente è in grado di accedere. UC11, UC12, UC13, UC14, UC15 REQ27 Gestione delle deleghe Il sistema dovrà fornire la possibilità ad un qualunque utente di delegarne un altro per l accesso a determinate risorse; le risorse oggetto di delega possono essere solo quelle per le quali il delegante, ha diritto di accesso in ragione dei ruoli posseduti. L utente, opportunamente autenticato ed autorizzato, dovrà avere la possibilità, attraverso una apposita interfaccia integrata nel proprio desktop di portale, di creare oggetti delega. Tali oggetti conterranno le seguenti informazioni: codice fiscale delegante codice fiscale delegato ruolo oppure coppia risorsa / ruolo oggetto della delega attributi relativi al ruolo in oggetto vincoli temporali di validità della delega Queste informazioni saranno memorizzate all'interno di un ramo separato del repository del blocco logico PORTAL. Ognuno di questi oggetti sarà opportunamente visualizzato sul desktop di portale dell utente delegato unitamente alle risorse alle quali l'utente in questione ha diritto di accedere. REQ28 Accesso a risorse delegate 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. UC18, Errore. L'origine riferimento non è stata trovata. REQ29 Validità delle deleghe Pagina 37 di 65

38 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à REQ30 Amministrazione delle deleghe 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. Pagina 38 di 65

39 REQ31 Tracciabilità delle deleghe PORTAL terrà traccia degli accessi alle risorse in modalità delegata; il registro di tali accessi conterrà almeno: 1. data e ora dell accesso 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 l utente 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. UC18, Errore. L'origine riferimento non è stata trovata. REQ32 SAML Identity Provider Un utente che abbia acceduto al portale e che, in ragione dei propri ruoli, abbia diritto di usufruire dei servizi offerti da un ente esterno federato, deve poterlo fare senza la necessità di autenticarsi nuovamente. All interno del sottosistema PORTAL sarà necessario configurare la componente 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. UC20 REQ33 Gestione della struttura PDC Il sistema dovrà mettere a disposizione le funzionalità per la gestione della struttura dei dati utilizzati dal PDC Auth Module. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata e selezionare la sezione riguardante l autenticazione Pagina 39 di 65

40 PDC. L'amministratore fornisce per ogni CA che verrà riconosciuta dal PDC Auth Module ai fini dell autenticazione degli utenti: nome (obbligatorio); descrizione (opzionale); tipologia di accesso alle CRL (obbligatorio); indicazioni necessarie per recuperare il codice fiscale da usare come chiave di autenticazione degli utenti (obbligatorio). REQ34 Inserimento di un utente in Black List Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un utente in Black List. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la Black List, selezionare un utente tra quelli non presenti in Black List e quindi scegliere di effettuare l'operazione di inserimento in Black List. REQ35 Rimozione di un utente dalla Black List Il sistema dovrà mettere a disposizione la funzionalità per la rimozione di un utente dalla Black List. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la Black List, selezionare un utente tra quelli presenti in Black List e quindi scegliere di effettuare l'operazione di rimozione dalla Black List. REQ36 Inserimento di un utente in White List Il sistema dovrà mettere a disposizione la funzionalità per l'inserimento di un utente in White List. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la White List, selezionare un utente ed un ruolo tra quelli definiti nel sistema; infine scegliere di effettuare l'operazione di inserimento in White List. Per ogni utente in White List l amministratore deve fornire: utente Pagina 40 di 65

41 ruolo da considerare in White List per l utente selezionato valorizzazione degli eventuali attributi contenuti nella definizione del ruolo indicato REQ37 Rimozione di un utente dalla White List Il sistema dovrà mettere a disposizione la funzionalità per la rimozione di un utente dalla White List. L'amministratore (Administrator) dovrà poter accedere all'interfaccia di amministrazione centralizzata, selezionare la sezione riguardante la White List, selezionare un utente tra quelli presenti in White List e quindi scegliere di effettuare l'operazione di rimozione dalla White List per ognuno dei ruoli per cui è definita. Pagina 41 di 65

42 5.3 Casi d'uso Di seguito sono illustrati alcuni scenari d utilizzo dell'intero sistema. Per gli scenari d utilizzo di seguito riportati, sono stati individuati i seguenti attori: Internet 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 all intero blocco logico PORTAL o ad alcune delle sue componenti (Access Manager, Desktop Provider, SRA Gateway) a seconda della necessità all interno del contesto di riferimento Accesso senza self-registration Priorità Attori Precondizioni UC1 Alta 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 dall utente si aggiungono automaticamente tutti i ruoli antenati (internamente, i ruoli sono rappresentati ad albero); i ruoli di amministrazione per cui l utente è in White List. Internet user, Domain user 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

43 verifica dei ruoli, il sistema inserisce l utente in Black List ed invia una pagina di errore. Figura 7 Accesso senza self-registration Accesso con self-registration Priorità UC2 Alta Un utente accede al portale con un certificato valido. Il sistema verifica che l'utente non abbia mai acceduto prima. Nel caso in cui l utente sia al primo accesso o, comunque non sia già registrato, il sistema 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 l utente è 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 dell esito viene presentato all utente un desktop temporaneo. A mano a mano che la validazione procede, i ruoli validati con successo verranno assegnati all utente e il desktop si arricchirà dei contenuti relativi a tali ruoli. Alla lista dei ruoli esplicitamente selezionati dall utente verranno aggiunti automaticamente tutti i ruoli antenati (internamente, i ruoli sono rappresentati ad albero); Pagina 43 di 65

44 i ruoli di amministrazione per cui l utente è in White List. Al termine della verifica, in caso di dichiarazione veritiera, ad ogni accesso verrà presentato all utente il proprio desktop di portale con tutte le risorse a cui ha diritto di accedere in ragione dei ruoli dichiarati e di quelli per i quali è in White List. Attori Precondizioni Internet user, Domain user 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. 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) 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 all utente delle scelte effettuate. In caso di ulteriore fallimento della verifica dei ruoli, il sistema inserisce l utente in Black List impedendogli quindi accessi futuri anche al desktop temporaneo. Pagina 44 di 65

45 Figura 8 Accesso con self-registration Accesso da un dominio esterno Priorità Attori Precondizioni UC3 Alta 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 l utente è in White List, invia un desktop di portale contenente le risorse alle quali l'utente ha diritto di accedere. Extra-domain user Sussiste un rapporto di trust tra il dominio esterno ed il sistema. L'utente è stato autenticato dal dominio esterno. Eventi di ingresso L'utente punta il proprio browser web sull'url corrispondente al punto di Pagina 45 di 65

46 accesso al sistema. Postcondizioni L'utente visualizza l'elenco delle risorse alle quali ha diritto di accedere. 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 Accesso alle risorse SRTY attraverso PORTAL Priorità Attori Precondizioni UC4 Alta L utente riceve il desktop di portale contenente i collegamenti alle risorse alle quali ha diritto di accedere in ragione dei ruoli posseduti. L'utente sceglie di accedere ad una di queste risorse. Il sistema mette in grado la risorsa di accedere al ruolo utente, al CF fiscale e agli attributi necessari per l accesso e l espletamento del servizio. A questo punto l utente continua il colloquio con la risorsa SRTY avendo come punto di accesso la componente SRA Gateway di PORTAL. Internet user, Domain user, Extra-domain user L'utente è stato autenticato. Eventi di ingresso L'utente visualizza i collegamenti a risorse presenti sul proprio desktop di Pagina 46 di 65

47 portale e sceglie di accedere ad una di queste. Postcondizioni L'utente accede alla risorsa selezionata. Figura 10 Accesso alle risorse SRTY attraverso PORTAL Accesso diretto alle risorse SRTY Priorità Attori Precondizioni UC5 Alta L'utente tenta di accedere direttamente ad una risorsa. Il sistema intercetta la chiamata e verifica che l utente non è correntemente autenticato. A questo punto il sistema verifica la validità del certificato e che l'utente sia stato registrato nel sistema; a questo punto ne legge codice fiscale e ruoli assegnati. Se per uno di tali ruoli è stato previsto dal ROLE MANAGER l'accesso alla risorsa in questione, il sistema consente l'accesso. L utente viene dapprima dirottato su PORTAL (componente Access Manager) per l autenticazione e poi in caso di successo ricondotto alla risorsa alla quale stava originariamente tentando di accedere. A questo punto l utente accede liberamente e direttamente alla risorsa. Domain user, Internet user 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

48 sistema; in particolare gli sono stati assegnati uno o più ruoli. Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente. Eventi di ingresso L'utente punta il proprio browser web sull'url corrispondente al punto di accesso ad una risorsa. Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata. Eccezione 1: Se il sistema non riconosce il certificato come valido (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL) invia una pagina di errore. Eccezione 2: Se l'utente non è stato registrato, il sistema 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 Priorità UC6 Alta L'utente tenta di accedere direttamente ad una risorsa. Il sistema intercetta la chiamata e verifica che l utente è correntemente autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli posseduti. Pagina 48 di 65

49 A questo punto l utente accede liberamente e direttamente alla risorsa. Attori Precondizioni Domain user, Internet user, Extra-domain user L'utente è stato precedentemente autenticato dal sistema. Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli. Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente. Eventi di ingresso L'utente punta il proprio browser web sull'url corrispondente al punto di accesso ad una risorsa. Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata. Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di errore. Figura 12 Accesso (già autenticato) diretto alle risorse SRTY Accesso alle risorse GENERIC attraverso PORTAL Priorità UC7 Alta L utente riceve il desktop di portale contenente i collegamenti alle risorse alle quali ha diritto di accedere in ragione dei ruoli posseduti. L'utente sceglie di accedere ad una di queste risorse. 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 è un applicazione in grado di utilizzare l AMSDK, si faccia riferimento a UC4. Pagina 49 di 65

50 A questo punto l utente continua il colloquio con la risorsa GENERIC avendo come punto di accesso la componente SRA Gateway di PORTAL. Attori Precondizioni Internet user, Domain user, Extra-domain user L'utente è stato autenticato ed ha ricevuto il desktop di portale corrispondente ai propri ruoli. Eventi di ingresso L'utente visualizza i collegamenti a risorse presenti sul proprio desktop di portale e sceglie di accedere ad una di queste. Postcondizioni L'utente accede alla risorsa selezionata. Figura 13 Accesso alle risorse GENERIC attraverso PORTAL Accesso diretto alle risorse GENERIC Priorità UC8 Alta L'utente tenta di accedere direttamente ad una risorsa. Il sistema intercetta la chiamata e verifica che l utente non è correntemente autenticato. A questo punto il sistema verifica la validità del certificato e che l'utente sia stato registrato nel sistema; a questo punto ne legge codice fiscale e ruoli assegnati. Se per uno di tali ruoli è stato previsto dal ROLE MANAGER l'accesso alla risorsa in questione, il sistema consente l'accesso. L utente viene dapprima dirottato su PORTAL (componente Access Manager) per l autenticazione e poi in caso di successo ricondotto alla risorsa alla quale stava originariamente tentando di accedere. Pagina 50 di 65

51 A questo punto l utente accede liberamente e direttamente alla risorsa. Nota: durante la fase di verifica di autenticazione dell utente (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 l accesso dell utente o per altri scopi. Attori Precondizioni Domain user, Internet user L'utente non è stato precedentemente autenticato dal sistema. L'utente possiede un certificato di accesso valido. Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli. Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente. Eventi di ingresso L'utente punta il proprio browser web sull'url corrispondente al punto di accesso ad una risorsa. Postcondizioni L'utente accede direttamente e liberamente alla risorsa selezionata. Eccezione 1: Se il sistema non riconosce il certificato come valido (ciò è possibile per diversi motivi: ad esempio issuer sconosciuto, errore nel formato, presenza in CRL) invia una pagina di errore. Eccezione 2: Se l'utente non è stato registrato, il sistema 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. Pagina 51 di 65

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

53 Priorità Attori Precondizioni UC9 Alta L'utente tenta di accedere direttamente ad una risorsa. Il sistema intercetta la chiamata e verifica che l utente è correntemente autenticato e autorizzato ad accedere alla risorsa in ragione dei ruoli posseduti. A questo punto l utente accede liberamente e direttamente alla risorsa. Nota: durante la fase di verifica di autenticazione dell utente (interazione tra 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 l accesso dell utente o per altri scopi. Domain user, Internet user, Extra-domain user L'utente è stato precedentemente autenticato dal sistema. Le informazioni circa l'utente sono state memorizzate in precedenza nel sistema; in particolare gli sono stati assegnati uno o più ruoli. Uno dei ruoli assegnato all'utente prevede l'accesso alla risorsa selezionata dall'utente. Eventi di ingresso L'utente punta il proprio browser web sull'url corrispondente al punto di accesso ad una risorsa. Postcondizioni L'utente accede liberamente e direttamente alla risorsa selezionata. Eccezione: Se l'utente non ha diritto di accesso alla risorsa in questione, viene inviata una pagina di errore. Figure 15 Accesso (già autenticato) diretto alle risorse GENERIC Pagina 53 di 65