Regione Toscana. GeRTIC Documento di progetto

Transcript

1 Regione Toscana GeRTIC Documento di progetto Progetto: GeRTIC. Titolo: Documentazione di progetto. Autore: Gabriele Mannocci. Stato: Bozza Ultima versione: 0.1 Ultimo Aggiornamento: 24/10/2014 Pag. 1

2 1. Revisioni AUTORE DATA VERSIONE Mannocci Gabriele 24/10/ Allegati NOME FILE Pag. 2

3 SOMMARIO Contesto di riferimento... 4 Architettura... 5 Flussi di lavoro... 9 Specifiche Tecniche Pag. 3

4 Contesto di riferimento Lo scopo del presente documento è quello di descrivere il contesto di riferimento nel quale si inserisce l applicazione GeRTIC, sia da un punto di vista architetturale che tecnico, e va ad integrare Manuale Utente ed Allegato tecnico d offerta nella definizione dei documenti che descrivono Analisi, Design ed Implementazione di progetto. Regione Toscana dispone di una applicazione web denominata AuthServTel realizzata per centralizzare le richieste di autorizzazione all'erogazione dei servizi al personale non dipendente che accede a vario titolo alle Sedi Regionali e necessita di servizi e risorse varie, di tipo informatico e non. Esempi di servizi che gli utenti possono richiedere sono: postazioni di lavoro, tesserino badge di riconoscimento/timbratura, accesso alla mensa, autorizzazione al parcheggio, posta elettronica, etc. GeRTIC nasce in seguito alla volontà espressa da Regione Toscana di effettuare la revisione (refactoring) di AuthServTel per renderla più flessibile e generica ed integrarla con il sistema di gestione delle identità (NetIQ Identity Manager) semplificando così la gestione, l abilitazione e la disabilitazione dei servizi. GeRTIC consente quindi di gestire richieste telematiche durante tutto il loro ciclo di vita: dalla definizione all attuazione, passando per fasi che prevedono anche flussi approvativi pensati in accordo con la profilazione utente. Pag. 4

5 Architettura L'applicazione GeRTIC è stata pensata per essere completamente integrabile con l'applicazione web di interfaccia del sistema NetIQ IDM, comunemente detta User Application, e per essere erogata attraverso l'infrastruttura ARPA (Autenticazione, Ruoli e Profili Applicativi) dei servizi sicuri di Regione Toscana, della quale sono utilizzati i seguenti servizi: Pubblicazione dell'applicazione attraverso sistemi ad accesso sicuro Autenticazione Reperimento della profilazione applicativa e delle logiche di delega La seguente immagine testimonia come i due sistemi ARPA e IDM siano connessi all interno del disegno architetturale entro il quale si colloca GeRTIC. Pag. 5

6 GeRTIC è un applicazione web three-tier, ovvero strutturata in tre strati: interfaccia utente (front-end), logica funzionale (back-end) e persistenza dei dati. La realizzazione dei primi due moduli è stata fatta mediante l utilizzo di GWT (Google Web Toolkit) un framework che consente lo sviluppo di Rich Internet Application (RIA). La tecnologia Ajax messa a disposizione da GWT permette di costruire interfacce grafiche accattivanti mantenendo contenuti gli oneri computazionali grazie al minor scambio di informazioni tra browser e web server. Tutte le componenti sono gestite dal tool di build automation Apache Maven. La componente server è stata progettata in modo tale da permettere il disaccoppiamento delle proprie componenti. Questo consente di poter eseguire il deploy dei moduli di business logic su più di un application server. Per quanto riguarda il lato persistenza dei data GeRTIC utilizza un database Postgres 9.1. L utilizzo del pattern DAO (Data Access Object) per l accesso ai dati consente di astrarre dalla tecnologia sottostante, lasciando quindi aperta la possibilità di porting verso un altra tecnologia in modo trasparente. L applicativo GeRTIC viene costruito come archivio EAR (Enterprise Archive) contenente al proprio interno: L archivio web gertic.war relativo alla parte di frontend Pag. 6

7 L archivio java gerticejb.jar, relativo alla parte di backend La directory lib, contenente librerie utilizzate dall applicazione La directory META-INF, contenente il file MANIFEST e il file di configurazione application.xml, mostrato di seguito: <?xml version="1.0" encoding="utf-8"?> <application xmlns:xsi=" xmlns=" xmlns:application=" xsi:schemalocation=" id="application_id" version="5"> <display-name>gertic</display-name> <module> <ejb>gerticejb.jar</ejb> </module> <module> <web> <web-uri>gertic.war</web-uri> <context-root>gertic</context-root> </web> </module> </application> La NetIQ User Application espone dei SOAP endpoint in modo da permettere l integrazione con software di terze parti. Tra gli endpoint disponibili c è il Directory Abstraction Layer WS e il Provisioning WS, entrambi utilizzati all interno di GeRTIC. Il Provisioning web service offre un interfaccia che permette la gestione dei processi di business aziendali (workflow). Tali processi, una volta definiti attraverso il Designer, possono essere gestiti in maniera autonoma, dando così la possibilità all utente di customizzare il proprio flusso di lavoro a seconda delle necessità. Questo è quanto fatto all interno di GeRTIC, definendo tre tipologie di flussi (analizzati più avanti) che modellano il dominio nel quale l applicazione opera. All interno GeRTIC si può accedere, qualora in possesso dei diritti di amministratore, alla sezione di gestione dei workflow come riportato nella seguente figura: Pag. 7

8 In questa maschera sono presenti tutti i workflow utilizzati dall applicazione. La procedura di importazione dei workflow, acceduta facendo click sul pulsante Importa, prevede la lettura dei flussi definiti in Identity Vault sotto una certa unità organizzativa. Una volta importato un workflow occorre configurarne il suo utilizzo all interno di GeRTIC selezionandolo dalla lista ed entrando in modifica. La seguente immagine mostra come avviene la configurazione, che di fatto si traduce nella corretta definizione dei campi dei workflow (visibilità, ordinamento, etichette), attraverso i quali vengono veicolate le informazioni durante il tutto il ciclo di vita del flusso e tra le varie approvazioni. Pag. 8

9 Flussi di lavoro Di seguito verranno analizzati i flussi di lavoro presenti in GeRTIC. Essi sono divisi in tre tipologie: flusso per gestione richieste da connettore Gertic-Soap flusso per richiesta di titoli per il personale interno/esterno flusso per richiesta di risorse per il personale interno/esterno Richieste da connettore GerticSoap Il connettore GerticSoap si attiva al momento che viene effettuata una variazione su rtorgstatus su un utente nel Vault, repository centralizzato usato da IDM. Il connettore accetta solo eventi di add e modify ovvero quando su un utente viene aggiunto o modificato l attributo rtorgstatus. Dopodichè viene effettuato un controllo e se il valore dell attributo precedentemente citato cambia in valore 1 vuol dire che l utente è passato nello stato attivo. A questo punto viene effettuato un altro controllo ovvero se già precedentemente è partita una richiesta per il tesserino oppure per la mail controllando gli attributi rtbadgestatus e rtzimbrastatus allora l evento viene bloccato. Se così non fosse viene creato l opportuno XML per fare partire le richieste di mail e/o tesserino inviate all applicazione Gertic tramite un web service esposto dall applicazione stessa la cui signature è la public String data); Il parametro di tipo DataResourceService rappresente un oggetto che incapsula un XML opportunamente formattato che, successivamente ad un processo di parsing, permette la costruzione di richieste per approvvigionamento di risorse ed il relativo inoltro. Un esempio di XML utilizzato dal driver è il seguente: Pag. 9

10 <?xml version="1.0" encoding="utf-8"?> <request-def> <resource id='4'> <params> <key>cognome_badge</key> <value>rossi</value> <key>nome_badge</key> <value>mario</value> <key>matricola</key> <value>00001</value> <key>data_attivazione</key> <value>01/01/2011</value> <key>data_fine_attivazione</key> <value>01/31/2011</value> <key>versione</key> <value>1</value> <key>commento</key> <value></value> <key>rtgerticbadgestruttura</key> <value>cn=settore ORGANICO-04473,ou=Strutture,o=Regione Toscana,c=IT</value> <key>rtgerticbadgederoga</key> <value>false</value> </params> </resource> </request-def> Si noti che l attributo id nel tag resource rappresente l id della risorsa all interno del database di GeRTIC. La seguente figura mostra le regole definite sul driver necessarie per la creazione del suddetto XML. Pag. 10

11 Richieste di titoli per personale interno/esterno Ogni Titolo definito all interno dell applicazione ha un insieme di risorse associate. Il meccanismo di gestione delle richieste di GeRTIC prevede che una volta approvata la richiesta, e quindi terminato il workflow legato al titolo, debbano essere avviati tutti i workflow relativi alle risorse del titolo. L associazione di risorse ai titoli avviene in fase di configurazione e può essere cambiata del relativo pannello nell applicazione in ogni momento. Le risorse non associate ai titoli possono comunque essere richieste come risorse in deroga, sovrascrivendo quindi la configurazione standard tra titoli e risorse. I workflow relativi alla richiesta per un titolo sono due. Strumenti giuridici, Strumenti giuridici interni. Questi due workflow differiscono nella loro esecuzione a seconda che il destinatario della richiesta sia un dipendente interno di Regione Toscana oppure un esterno. Nel caso di richiesta per utenti esterni è previsto uno step approvativo in più svolto da personale del Settore di Assistenza normativa. La seguente figura mostra lo schema delle approvazioni previste. Si noti come la presenza di risorse in deroga possa dar luogo ad un percorso diverso all interno del flussi che porta all approvazione da parte del Direttore Generale richiedente. Si riportano anche le immagini relative ai suddetti workflow come avviene all interno del Novell Designer IDM utilizzato per la loro definizione. Pag. 11

12 Pag. 12

13 Richieste di risorse per personale interno/esterno Flusso Gestione Badge Il flusso gestione badge viene fatto partire da gertic in seguito a una richiesta di risorsa badge richiesta da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: Nome dell utente del Badge Cognome dell utente del badge Matricola del badge Verisone Badge Un Commento Un valore che indica se la risorsa badge è in deroga La struttura dell utente su cui è stato richiesto il badge Inizialmente viene testato se la richiesta di badge è Non in deroga se così fosse il flusso passa direttamente a Gestione Badge per essere approvato. Se la risorsa badge invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvtivo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine a gestione badge. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta del badge e notificato il gertic della chiusura del flusso. Flusso Gertic Il flusso gertic viene fatto partire da gertic in seguito a una richiesta di casella di posta fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: Nome dell utente proprietario della mail Cognome dell utente proprietario della mail Matricola dell utente proprietario della mail Un valore che indica se la risorsa mail è in deroga La struttura dell utente su cui è stata richiesta la mail Pag. 13

14 Inizialmente viene testato se la richiesta di mail è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticmail che approva o meno la richiesta. Se la risorsa mail invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvtivo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo gerticmail. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta della mail che tramite il connettore Zimbra farà provisioning sul sistema target. Inoltre viene notificata l applicazione gertic che il flusso singolo è stato concluso. Flusso GerticPDL Il flusso gerticpdl (PostazioneDiLavoro) viene fatto partire da gertic in seguito a una richiesta di postazione di lavoro fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la PDL Expiration della PDL DN della PDL Se la richiesta della PDL è in deroga La struttura dell utente che richiede la PDL Note riguardanti il flusso Un commento Inizialmente viene testato se la richiesta di Stanza è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticpdl che approva o meno la richiesta. Se la risorsa gerticpdl invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvativo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo gerticpdl. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta stanza. Inoltre viene notificata l applicazione gertic che il flusso singolo è stato concluso. Pag. 14

15 Flusso GerticParcheggio Il flusso gerticparcheggio viene fatto partire da gertic in seguito a una richiesta di parcheggio fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la il parcheggio Expiration del parcheggio DN della risorsa parcheggio Se la richiesta del parcheggio è in deroga La struttura dell utente che richiede il parcheggio Note riguardanti il flusso Inizialmente viene testato se la richiesta di parcheggio è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticparcheggio che approva o meno la richiesta. Se la risorsa parcheggio invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvativo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo geticparcheggio. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta parcheggio. Inoltre viene notificata l applicazione gertic che il flusso singolo è stato concluso. Flusso GerticMobile Il flusso gerticmobile viene fatto partire da gertic in seguito a una richiesta di mobile fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la risorsa mobile Expiration della risorse mobile Se la richiesta del mobile è in deroga La struttura dell utente che richiede la risorsa mobile Se è richiesto Fonia Se è richiesto Dati Se è richiesto Cellulare Se è richiesto la Internet Key Pag. 15

16 Inizialmente viene testato se la richiesta di mobile è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticmobile che approva o meno la richiesta. Se la risorsa mobile invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvativo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo gerticmobile. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta mobile tra cui se è stato richiesto oltre alla fonia mobile anche i dati, il cellulare o la internet key. Inoltre viene notificata l applicazione gertic che il flusso singolo è stato concluso. Flusso GerticFoniaFissa Il flusso gerticfoniafissa viene fatto partire da gertic in seguito a una richiesta di fonia fissa fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la risorsa fonia Expiration della risorse fonia Se la richiesta della fonia è in deroga La struttura dell utente che richiede la risorsa fonia Se è richiesto fax Inizialmente viene testato se la richiesta di mobile è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticphone che approva o meno la richiesta. Se la risorsa mobile invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvativo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo gerticphone. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta di fonia e viene notificata alll applicazione gertic che il flusso singolo è stato concluso. Pag. 16

17 Flusso GerticRegToscFS (File Server) Il flusso gerticregtoscfs viene fatto partire da gertic in seguito a una richiesta di file server fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la risorsa FS Expiration della risorsa FS Se la richiesta del FS è in deroga La struttura dell utente che richiede la risorsa FS Come primo step viene testato se l utente richeidente è un utente esterno oppure no. Se l utente è un utente interno viene assegnata la risorsa senza approvazioni viene notifica l applicazione gertic e il flusso finisce. Se l utente è esterno invece viene testato se la richiesta di FS è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticfs che approva o meno la richiesta. Se la risorsa FS invece è in deroga vengono testate altre condizioni per inserire oppure no altre approvazioni. Se il dirigente è anche il direttore generale dell utente viene inserita un altra approvazione in carico al dirigente. Se così non fosse allora viene inserito lo step approvativo del DG Erogante dopodichè l approvazione passa al Dirigente e alla fine in Programmazione al gruppo gerticfs. Dopo tutte le approvazioni viene creato un oggetto nel vault con i dati della richiesta FS. Inoltre viene notificata l applicazione gertic che il flusso singolo è stato concluso. Pag. 17

18 Specifiche Tecniche Applicazione three-layer sviluppata in linguaggio Java EE Application server Jboss 5.1 Persistenza su database PostgreSQL attraverso ORM Hibernate Accesso al directory vault del prodotto NetIQ IDM attraverso il protocollo LDAP Integrazione con NetIQ IDM tramite webservices SOAP standard di prodotto Gestione della stampa dei tesserini su stampante specifica tramite CUPS Completa integrazione nell'architettura ARPA Aderenza agli standard tecnologici di Regione Toscana Pag. 18