REGIONE TOSCANA GERTIC Documentazione di progetto Viale Montegrappa 278/E 59100 Prato (Italy) Telefono +39.0574.514180 Fax +39.0574.551195 www.netstudio.it
INFORMAZIONI DOCUMENTO PROGETTO GeRTIC Gestione Richieste Telematiche IDM Compliant TITOLO Documentazione di progetto COMMITTENTE Regione Toscana AUTORE Net Studio s.r.l. FILE RT - GeRTIC - Documentazione di progetto.docx STATO Bozza ULTIMA VERSIONE 0.1 ULTIMO AGGIORNAMENTO PAGINE AVVERTENZE Le informazioni contenute in questo documento rappresentano l attuale punto di vista di NetStudio S.r.l. sulla modalità di implementazione di una soluzione relativamente all oggetto del Progetto descritto e sono basate sulla combinazione di informazioni presenti sulla documentazione ufficiale di prodotto e l esperienza e la competenza di NetStudio S.r.l. sui temi trattati. Il contenuto e le raccomandazioni contenute nel presente documento non costituiscono ne devono essere interpretate come un impegno da parte di NetStudio S.r.l. L accuratezza delle informazioni presenti non è garantita dopo la data della pubblicazione. DIRITTI Il presente documento è di proprietà di NetStudio S.r.l. La diffusione del presente documento è limitata al personale del Cliente che verrà autorizzato ed agli eventuali soggetti coinvolti nell attività per conto o in collaborazione del Cliente, nell ambito del progetto in oggetto. Nessuna porzione di questo documento può essere riprodotta, fotocopiata, archiviata in un sistema di ricerca/memorizzazione documentale, o trasmessa senza l espresso consenso scritto di NetStudio S.r.l. a norma delle leggi vigenti. RT - GeRTIC - Documentazione di progetto.docx Pagina 2 di 19
REVISIONI Versione Data Autore Commenti 0.1 5 febbraio 2013 Gabriele Mannocci Prima versione rilasciata ALLEGATI Versione Data Autore Titolo RT - GeRTIC - Documentazione di progetto.docx Pagina 3 di 19
SOMMARIO Contesto di riferimento... 5 Architettura... 6 RT - GeRTIC - Documentazione di progetto.docx Pagina 4 di 19
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. RT - GeRTIC - Documentazione di progetto.docx Pagina 5 di 19
Architettura L'applicazione GeRTIC è stata pensata per essere completamente integrata 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 collaca GeRTIC. GeRTIC è un applicazione web three-tier, ovvero strutturata in tre strati: interfaccia utente (frontend), 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. RT - GeRTIC - Documentazione di progetto.docx Pagina 6 di 19
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 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: RT - GeRTIC - Documentazione di progetto.docx Pagina 7 di 19
<?xml version="1.0" encoding="utf-8"?> <application xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemalocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" 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 si 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: RT - GeRTIC - Documentazione di progetto.docx Pagina 8 di 19
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. RT - GeRTIC - Documentazione di progetto.docx Pagina 9 di 19
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 risorse per il personale interno/esterno flusso per richiesta di titoli 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 seguente: @WebMethod(operationName="ResourceService") public String ResourceService( @WebParam(name="request")DataResourceService 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: RT - GeRTIC - Documentazione di progetto.docx Pagina 10 di 19
<?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. RT - GeRTIC - Documentazione di progetto.docx Pagina 11 di 19
FLUSSI RELATIVI ALLE RISORSE RT - GeRTIC - Documentazione di progetto.docx Pagina 12 di 19
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 GerticEmail Il flusso gerticemail 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 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. RT - GeRTIC - Documentazione di progetto.docx Pagina 13 di 19
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 GerticStanza Il flusso gerticstanza viene fatto partire da gertic in seguito a una richiesta di stanza fatta partire da strumenti giuridici o strumenti giuridici interni. Esso prevede come input: DN dell utente che ha richiesto la stanza Expiration della stanza DN della stanza Se la richeista della stanza è in deroga La struttura dell utente che richiede la stanza Note riguardanti il flusso Inizialmente viene testato se la richiesta di Stanza è Non in deroga se così fosse il flusso passa direttamente in Programmazione ovvero ad un Gruppo gerticstanza che approva o meno la richiesta. Se la risorsa gerticstanza 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 gerticstanza. 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. 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 RT - GeRTIC - Documentazione di progetto.docx Pagina 14 di 19
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. 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. RT - GeRTIC - Documentazione di progetto.docx Pagina 15 di 19
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 - (boolean) - Se è richiesto Dati - (boolean) - Se è richiesto Cellulare - (boolean) - Se è richiesto la Internet Key- (boolean) 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 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. RT - GeRTIC - Documentazione di progetto.docx Pagina 16 di 19
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. 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. RT - GeRTIC - Documentazione di progetto.docx Pagina 17 di 19
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. La presenza di risorse in deroga può dar luogo a percorso diversi all interno dei flussi come mostrato in figura. RT - GeRTIC - Documentazione di progetto.docx Pagina 18 di 19
Richieste di Titoli per personale Interno o Esterno Si tratta del flusso principale presente all interno dell applicazione e fa riferimento ai Titoli, dove un Titolo rappresenta il motivo di esecuzione della richiesta e la contestualizza in un area specifica, ad esempio quella del personale interno o di una ditta esterna. Ognuna di queste aree fa riferimento a due tipologie di personale: interno o esterno. Per poterle gestire entrambe in modo autonomo sono stati creati due workflow che hanno un iter approvativo diverso. Il flusso strumenti giuridici riceve in input fino ad un massimo di 15 risorse e per ognuna di essa viene specificato se si tratta di una risorsa in deroga oppure no. Questo flusso come i successivi vengono fatti partire dall applicazione GeRTIC. Una volta fatto partire il flusso esso verifica se è presente almeno una risorsa in deroga, se così fosse viene inserito uno step approvativo ulteriore diretto verso il DG Richiedente. Se invece non vi è alcuna risorsa in deroga allora il workflow entra nello stato di attuazione e effettua una chiamata attraverso un integration Activity al webservice di Gertic tramite il metodo WFEnd passandogli i commenti, le risorse e le eventuali deroghe relative. Dopodiché GeRTIC farà partire un flusso approvativo per ogni risorsa ricevuta. 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. La presenza di risorse in deroga può dar luogo a percorso diversi all interno dei flussi come mostrato in figura. Questo flusso principale opera in modo diverso a seconda che la richiesta venga fatta per utenti interni (dipendenti Regione Toscana) oppure su esterni (borsisti, stagisti, consulenti) RT - GeRTIC - Documentazione di progetto.docx Pagina 19 di 19