LINEE GUIDA PER L INTEGRAZIONE DI APPLICAZIONI Progetto ARPA CONTIENE D17.7

Transcript

1 Modulo: Guidelines Sistema: ARPA Versione documento: 1.5 LINEE GUIDA PER L INTEGRAZIONE DI APPLICAZIONI Progetto ARPA CONTIENE D17.7 Livelli di approvazione Cliente Verifica Approvazione Approvazione Funzione Nome Data Firma LISTA DI DISTRIBUZIONE Pagina 1 di 27

2 SOMMARIO 1 GENERALITÀ SCOPO VALIDITÀ DIZIONARIO DEI NOMI...4 INTRODUZIONE L'INFRASTRUTTURA ARPA (OVERVIEW) I servizi offerti dall'infrastruttura ARPA Ruoli e attribuiti Certificatori di ruolo e attributi COSA SI INTENDE PER RISORSE COSA SI INTENDE PER RISORSE INTEGRATE IN ARPA RISORSE INTEGRABILI TECNOLOGIE A DISPOSIZIONE PER L INTEGRAZIONE Utilizzo del Dispatcher Utilizzo di meccanismi di reverse proxying basati su SRA Gateway Utilizzo dell AM Policy Agent Libreria wrapper AMSDK Framework SRTY Federazione SAML SVILUPPARE UNA NUOVA RISORSA PER ARPA LINEE GUIDA PER LO SVILUPPO DI APPLICAZIONI J2EE Autenticazione e autorizzazione Raggiungibilità del servizio Sviluppo di applicazioni SRTY LINEE GUIDA PER LO SVILUPPO DI APPLICAZIONI NON J2EE Autenticazione e autorizzazione Raggiungibilità del servizio REFERENCE PER IL SYSTEM ADMINISTRATOR: COME INTEGRARE UNA RISORSA PREREQUISITI Passi d integrazione comuni per ogni tipo di applicazione web INDIVIDUARE I METODI DI INTEGRAZIONE DA ADOTTARE LINEE GUIDA PER L INTEGRAZIONE DI APPLICAZIONI CHE FANNO USO DELLA LIBRERIA WRAPPER AMSDK Deploy Retrieve informazioni utente Configurazione risorsa Applicazioni SRTY INTEGRAZIONE DI APPLICAZIONI CHE RICHIEDONO FORM AUTHENTICATION Deploy Retrieve informazioni utente Configurazione risorsa INTEGRAZIONE DI APPLICAZIONI CHE RICHIEDONO PARAMETRI IN HTTP HEADER Deploy Retrieve informazioni utente Configurazione risorsa...23 Pagina 2 di 27

3 6.6 APPLICAZIONI NON PROFILATE Deploy Retrieve informazioni utente Configurazione risorsa FEDERAZIONE Regione Toscana come IdP Regione Toscana come SP...27 Pagina 3 di 27

4 1 GENERALITÀ Il presente documento descrive le modalità di integrazione delle applicazioni GENERIC ed SRTY nel sistema ARPA. 2 SCOPO L obiettivo di questo documento è la descrizione di alcuni degli scenari di integrazione allo scopo di dare le prime linee guida agli specialisti di sistema. Nel caso di sviluppo di nuove applicazioni per Regione Toscana verrà fatto uso del framework SRTY per applicazioni profilate o fare uso delle librerie ArpaCommon. Le restanti strategie di integrazione devono essere utilizzate solo se preventivamente concordate con Regione Toscana 3 VALIDITÀ Il presente documento è valido a partire dalla data di emissione riportata in copertina. 4 DIZIONARIO DEI NOMI Di seguito una tabella dei nomi utilizzati, aggiornata in data: 22/11/2007 Tale tabella viene riportata a solo scopo illustrativo. I corretti riferimenti ai sistemi di produzione verrà comunicato ai fornitori di RT al momento della definizione dei piani di lavoro. portal url gateway url portal_instance Nome Traduzione portal1.cart.tix.it Pagina 4 di 27

5 INTRODUZIONE Il modello architetturale su cui si dispiega il sistema è costituito da tre Aree: l area Portale, che fornisce l accesso agli utenti garantendo i servizi di autenticazione, e controllo accessi; l area Role Manager che garantisce l autorizzazione ossia la corretta associazione utente/ruoli; l area Servizi che è costituita dai servizi disponibili che saranno in grado di fornire il corretto profilo applicativo all utente sulla base delle sue credenziali così come fornite dall area Portale e valorizzate dall Area Role Manager. L accesso alle applicazioni integrate in ARPA (AREA SERVIZI) è vincolato dall appartenenza dell utente che vi accede a uno o più ruoli. I ruoli e l associazione ruoli/applicazioni vengono gestite tramite l interfaccia di amministrazione del componente denominato ROLE MANAGER. L accesso effettivo di un utente ad una applicazione viene controllato dalla componente Portal mediante policy dinamiche, ovvero policy basate sul controllo dinamico delle URL che compongono l applicazione e che vengono richieste dall utente. Il presente documento tratta nel dettaglio le modalità di integrazione di applicazione nell area SERVIZI. Nella terminologia di progetto le applicazioni vengono classificate in due macro categorie : GENERIC SRTY. Le applicazioni SRTY sono applicazioni J2EE che sono sviluppate nel framework SRTY e nativamente integrate in ARPA. Le applicazioni GENERIC sono tutte quelle applicazioni non sviluppate nel framework SRTY. 4.1 L'infrastruttura ARPA (overview) 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). Pagina 5 di 27

6 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. 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. Il diagramma in figura (Figura 1 Architettura logica) illustra l architettura logica di riferimento. Figura 1 Architettura logica Pagina 6 di 27

7 4.1.1 I servizi offerti dall'infrastruttura ARPA 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 della P.A. Toscana che consente di: centralizzare l'accesso degli utenti (meccanismi di Single Sign On - SSO); raggiungere e fruire, da internet, di applicazioni web non raggiungibili in assenza del sistema ARPA (applicazioni relegate alla intranet aziendale); favorire e diffondere l utilizzo di strumenti di autenticazione sicuri quali le smart card e CNS; offrire all'utente un desktop personalizzato sulla base del proprio ruolo; disaccoppiare il controllo accessi basato sui ruoli dalla gestione delle banche dati utilizzate per la validazione dei ruoli stessi; interoperare con altre amministrazioni secondo il modello di identità federata, basato cioè su un rapporto di fiducia legato all'identità dell'utente Ruoli e attribuiti Gli utenti sono associati ad uno o più ruoli: Il ruolo individua gli incarichi, gli obblighi e privilegi che un utente ha all'interno di un determinato contesto istituzionale e che ne condizionano i profili applicativi all interno del portale. Gli utenti in ARPA sono caratterizzati da: un insieme di attributi inseriti dall utente in fase di registrazione (esempio: ); un insieme di attributi recuperati dinamicamente dal sistema dalle credenziali di autenticazione dell utente (certificato digitale personale) quali, ad esempio: nome, cognome, codice fiscale, uno o più ruoli richiesti dall utente in fase di registrazione e confermati successivamente dal sistema ARPA previa verifica su delle fonti dati esterne (esempio: albo dei medici o degli avvocati); l insieme degli attributi caratteristici dei ruoli posseduti recuperati dinamicamente dal sistema dalle fonti dati esterne Certificatori di ruolo e attributi I certificatori di ruolo e attributi sono entità che rendono disponibili, attraverso una o più fonte dati, le informazioni (attributi) necessari alla verifica (certificazione) del ruolo da parte del modulo Role Manager. La definizione e/o l utilizzo di ruoli da parte delle nuove applicazioni deve essere concordata in modo esplicito con Regione Toscana, nella fase di progettazione della nuova applicazione. Pertanto qualora i ruoli e/o attributi definiti sul sistema ARPA non fossero sufficienti per Pagina 7 di 27

8 l applicazione in progettazione, eventuali variazioni e/o integrazione dovranno essere concordati con i responsabili della infrastruttura ARPA. 4.2 Cosa si intende per risorse In terminologia ARPA, una risorsa non è altro che un applicazione web. Le risorse integrabili in ARPA sono di due tipi: SRTY e GENERIC. Le risorse SRTY sono applicazioni J2EE sviluppate nel framework SRTY e che, per essere integrate nel sistema ARPA, dovranno far uso di AMSDK. Le risorse GENERIC sono tutte quelle applicazioni non sviluppate nel framework SRTY che possono essere suddivise in diverse categorie in base alla tecnologia in cui sono state sviluppate, ai meccanismi di autenticazione, ai dati necessari per l autorizzazione, alla modalità in cui essi vengono trasmessi all applicazione, ecc. 4.3 Cosa si intende per risorse integrate in ARPA Una risorsa è perfettamente integrata in ARPA quando può usufruire di tutti i servizi messi a disposizione da ARPA stessa (paragrafo 7). 4.4 Risorse integrabili In figura Figura 2 Tipologie di risorse viene mostrata una possibile visione di insieme di tutte le applicazioni web. Ovviamente questa non è l unica in quanto sarebbe possibile individuare molti più insiemi e sottoinsiemi prendendo in considerazione un numero molto vasto di parametri di discriminazione. Tuttavia, tale raggruppamento è più che sufficiente per individuare e classificare tutte le risorse integrabili in ARPA. Tutte le applicazioni web (cerchiate in giallo) comprendono applicazioni sviluppate con tecnologia J2EE (cerchiate in blu) e applicazioni sviluppate con altra tecnologia. Tra le applicazioni sviluppate in J2EE ci sono quelle che fanno uso di libreria wrapper AMSDK (cerchiate in rosso). Inoltre, tra tutte le applicazioni, J2EE e non, è possibile distinguere tra applicazioni profilate, che forniscono servizi diversi ad utenti diversi, e non profilate che forniscono gli stessi servizi a tutti gli utenti autenticati senza fare distinzione sulle identità (cerchiate in viola), e ancora, tra applicazioni che fanno uso di form authentication o passaggio di parametri in http header (cerchiate in verde) e applicazioni che prevedono altre modalità d autenticazione proprie. Le applicazioni integrabili in ARPA sonno: Applicazioni che fanno uso di libreria wrapper AMSDK (arancione cerchiato di rosso); Applicazioni non profilate (viola); Applicazioni che fanno uso di Form Authentication (verde); Applicazioni che fanno uso di passaggio di parametric in http header (verde). Pagina 8 di 27

9 Tutte le applicazioni che non rientrano in queste tipologie devono essere migrate cosi come mostrato in figura con l ausilio delle frecce. Le applicazioni J2EE possono essere migrate verso applicazioni che utilizzano la libreria wrapper AMSD o verso applicazioni non profilate o verso applicazioni che fanno uso di form authentication o passaggio di parametric in http header. Le applicazioni non J2EE possono essere migrate verso applicazioni non profilate o verso applicazioni che che fanno uso di form authentication o passaggio di parametric in http header. L integrazione di ogni singola applicazione viene discussa in dettaglio nel capito 6. Figura 2 Tipologie di risorse 4.5 Tecnologie a disposizione per l integrazione Esistono diverse modalità/meccanismi di integrazione. La scelta dipende spesso dal tipo di applicazione che si intende integrare, dalla sua dislocazione nella rete e dai meccanismi di SSO che possono essere messi in campo. Pagina 9 di 27

10 Tra le tecnologie a nostra disposizione, per integrare una qualunque applicazione, abbiamo: Dispatcher; SRA Gateway; AM Policy Agent; Libreria wrapper AMSDK Framework SRTY; Federazione SAML. Data l estrema variabilità delle tipologie di applicazioni e architetture che si possono incontrare, il presente documento si propone di indicare delle strade da seguire che guidino verso la scelta più opportuna nella maggioranza dei casi Utilizzo del Dispatcher Tale strumento è utilizzato per vari scopi, molti dei quali esulano dal contesto del presente documento. Il principale scopo del dispatcher è quello di garantire gli accessi in delega Utilizzo di meccanismi di reverse proxying basati su SRA Gateway Il modulo di portale, SRA Gateway, mette a disposizione dell utente buoni meccanismi di reverse proxy e, soprattutto, un potente modulo di riscrittura delle URL. E solitamente la soluzione preferibile nel caso in cui sia necessario rendere raggiungibili e fruibili risorse tramite meccanismi di reverse proxy. L utilizzo dello SRA Gateway è una scelta obbligata nel caso in cui la risorsa da integrare richieda un autenticazione basata su form authentication o passaggio di parametri in http header. Nel caso in cui si utilizzi il gateway l URL di accesso alla risorsa sarà della forma risorsa> Questa tecnica come indicato nella sezione scopo del documento è da utilizzarsi solo in casi eccezionali e in accordo con i responsabili della infrastruttura Utilizzo dell AM Policy Agent Gli ambienti di produzione di Regione Toscana fanno uso di questa componente, pertanto la presenza del componente è trasparente per gli sviluppatori. Nel caso in cui un applicazione sia modificabile o non preveda un meccanismo di autenticazione proprio, potrebbe essere tentato per essa un approccio basato su policy agent (sempre che esista una versione disponibile per il container dell'applicazione) e/o Pagina 10 di 27

11 AMSDK (se l'applicazione è J2EE). Non vi sono dipendenze dirette tra l utilizzo del policy agent e quello dell AMSDK. Il policy agent si occupa di controllare gli accessi verificando la presenza e la validità del token di sessione ed effetuando policy evaluation. Il funzionamento del policy agent può essere riprodotto sviluppando opportunamente un modulo di autenticazione che faccia uso di AMSDK Libreria wrapper AMSDK La libreria è presente come libreria condivisa negli ambienti di produzione di regione Toscana. Per lo sviluppo in locale presso i fornitori sarà messo a disposizione una libreria di emulazione indipendente dalle componenti ARPA. Affinché una risorsa J2EE in sviluppo sia destinata ad essere integrata nel sistema ARPA, si consiglia l utilizzo della libreria wrapper AMSDK, arpa-common.jar. Tramite i metodi messi a disposizione dalle classi fornite con la libreria, è possibile accedere ai dati dell utente, ai suoi ruoli e ai suoi attributi, nonché alle informazioni di delega per le applicazioni in grado di gestirle (applicazioni delegabili) Framework SRTY Il framework dipende dalla libreria wrapper amsdk per lo sviluppo in locale presso i fornitori sarà messo a disposizione una libreria di emulazione indipendente dalle componenti ARPA. Le applicazioni sviluppate nel framework SRTY sono applicazioni J2EE e quindi dovranno far uso del wrapper AMSDK (Libreria wrapper AMSDK). Inoltre, tali applicazioni saranno protette tramite policy agent per il controllo dell autorizzazione all accesso. Il wrapper dovrà essere utilizzato principalmente per accedere ai dati dell utente (ruoli e attributi) e per recuperare le modalità operative d accesso (deleghe) Federazione SAML Questa modalità dovrà essere utilizzata prevalentemente per integrare domini applicativi e di identità,non in generale per integrare singole risorse. Per l integrazione di servizi offerti da enti esterni, o per offrire servizi ad utenti provenienti da enti esterni e non in possesso di un certificato di autenticazione valido, la federazione è, solitamente, la scelta migliore. In uno scenario federato, ARPA è in grado di giocare il ruolo di Identità Provider (IdP) e di Service Provider (SP). Nel caso in cui si desidera offrire, ad utenti di un certo ente esterno, i servizi ARPA, allora sarà necessario configurare tale ente come IdP per ARPA che in questo caso giocherà il ruolo di SP. Nel caso in cui si desideri offrire, ad un utente di ARPA, i servizi messi a disposizione da Pagina 11 di 27

12 un certo ente esterno, allora sarà necessario configurare l ente come SP per ARPA che in questo caso giocherà il ruolo di IdP. Quando ARPA funge da IdP per un certo SP, invierà in modalità POST Profile, nell asserzione SAML di autenticazione, tutti i ruoli e tutti gli attributi dell utente connesso. Viceversa, quando ARPA è SP, si aspetterà di ricevere dall IdP, nell asserzione di autenticazione, i ruoli e gli attributi che l utente che intende accedere ai servizi ARPA, ha presso di esso. Pagina 12 di 27

13 5 SVILUPPARE UNA NUOVA RISORSA PER ARPA In questo capitolo vengono fornite le linee guida per lo sviluppo di nuove risorse destinate ad essere integrate nel sistema ARPA. In questo particolare caso, la bontà di una risorsa dipende dalla sua facilità d integrazione: tanto più una risorsa è facilmente integrabile, tanto più è da considerarsi una buona risorsa per ARPA. 5.1 Linee guida per lo sviluppo di applicazioni J2EE Come già detto nei paragrafi precedenti, per lo sviluppo di nuove applicazioni J2EE destinate ad essere integrate in ARPA, si consiglia l utilizzo della libreria wrapper AMSDK (arpa-common.jar). Utilizzando i metodi messi a disposizione in tale libreria sarà possibile accedere ai dati sempre aggiornati dell utente connesso (ruoli e attributi) ma anche ai dati relativi alla modalità operativa con cui l utente accede: in caso di delega sarà possibile attenere le informazioni, relative a ruoli ed attributi, ereditate dal delegante. In generale, le applicazioni dovranno effettuare i seguenti passi: Istanziare la classe ArpaSSOProxy Accedere alle informazioni dell utente (nome, cognome, codice fiscale, ) Accedere alle informazioni dell eventuale delegante (nome, cognome, codice fiscale, ) Accedere ai ruoli operativi (ruoli delegati in caso di accesso per delega) Accedere agli attributi operativi (attributi relativi ai ruoli operativi individuati) Implementare le funzionalità applicative. Pur ritenendo sufficienti le informazioni ottenute nei punti precedenti, vengono fornite ulteriori funzionalità per l accesso alle informazioni associate ai ruoli e agli attributi: Possibilità di accedere a tutti i ruolo posseduti dall utente; Possibilità di cercare un ruolo a partire dal nome; Possibilità di accedere a tutti gli attributi di un utente; Possibilità di accedere a tutti gli attributi locali ad un certo ruolo; Possibilità di cercare un attributo locale ad un certo ruolo a partire dal nome; Possibilità di cercare un attributo tra tutti i ruoli dell utente a partire dal nome. Per i dettagli sui metodi implementati si rimanda al javadoc associato alla libreria. In allegato viene fornito un documento per lo sviluppo di applicazioni J2EE che fanno uso della libreria wrapper AMSDK Autenticazione e autorizzazione Le applicazioni J2EE sviluppate non dovranno prevedere alcun meccanismo proprio di autenticazione ed autorizzazione. Pagina 13 di 27

14 Tali funzionalità saranno offerte direttamente dal sistema ARPA Raggiungibilità del servizio Gli scenari di deploy delle applicazioni sono essenzialmente due e fanno riferimento alla modalità di raggiungimento e utilizzo del servizio offerto. Le risorse potrebbero essere fruite direttamente da internet o necessitare di meccanismi di reverse proxying perché situate in un rete protetta da regole di firewalling piuttosto stringenti. La raggiungibilità del servizio non è l unico elemento a determinare lo scenario di deploy delle applicazioni: la possibilità d installare un am policy agent sul container che ospita l applicazione gioca un ruolo fondamentale in questa scelta. Nel caso in cui, in presenza di regole di networking che non permettono l accesso diretto da internet ai servizi offerti, la raggiungibilità dovrebbe essere garantita mediante SRA Gateway. Nel caso in cui l applicazione sia raggiungibile direttamente, si consiglia di configurare il web container affinché permetta l accesso solo in https con client authentication. Tramite un metodo messo a disposizione dalla lebreria wrapper sarà possibile intercettare un eventuale cambio di certificato ssl associato alla sessione corrente. A tale evento sarà possibile reagire distruggendo la sessione corrente per motivi di sicurezza. Nel caso in cui sia previsto un accesso diretto ai servizi, cioè non mediato da alcun meccanismo di reverse proxying, sarà necessario integrare l applicazione in ARPA mediante l ausilio di un AM Policy Agent. Sarà quindi opportuno prevedere il deploy di tali applicazioni su un web container per il quale esista una versione di AM Policy Agent supportata. Il policy agent dovrà essere configurato così come previsto negli allegati al fine di poter usufruire dei servizi di autenticazione, autorizzazione, SSO e delega, messi a disposizione da ARPA. In allegato viene fornita la documentazione per la configurazione di un policy agent in ambiente ARPA (documento D17.7c) Sviluppo di applicazioni SRTY Le applicazioni sviluppate nel framework SRTY sono applicazioni J2EE e come tali si rimanda a quanto già specificato nei paragrafi precedenti. Per maggiori dettagli si rimanda l utente all allegato relativo allo sviluppo, configurazione e deploy di applicazioni SRTY (documenti D17.7d e D17.7e). Pagina 14 di 27

15 5.2 Linee guida per lo sviluppo di applicazioni non J2EE Le applicazioni non J2EE dovranno essere sviluppate nell ottica di essere integrate in ARPA mediante l ausilio di SRA Gateway o AM Policy Agent. L utilizzo del solo policy agent potrebbe richiedere che l applicazione, non essendo J2EE, sia non profilata e raggiungibile da internet direttamente. L utilizzo del gateway implica la necessità di dover riscrivere URL presenti in pagine XML/HTML e codice JavaScript. Il modulo del gateway che si occupa della riscrittura va configurato adeguatamente attraverso la console di amministrazione offerta dal prodotto (<portal url>/psconsole). Identificare tutte le regole di riscrittura necessarie per fruire dei servizi da integrare, risulta essere a volte molto complicato. Per semplificare tale attività è necessario tener presente, in fase di sviluppo, le seguenti indicazioni. Non utilizzare ActiveX; Minimizzare l uso di javascript tenendo traccia delle variabili e delle funzioni che specificano o gestiscono url; Definire un meccanismo di autenticazione proprio basato su form authentication; Non definire meccanismi di autorizzazione propri dell applicazione; Le URL, ovunque specificate, devono essere ben formate e rispettare gli standard; I cambi di contesto devono essere limitati: è buona norma mantenere sempre lo stesso root context per la stessa applicazione; E preferibile che l applicazione sia concentrata tutta sullo stesso dominio e che non contenga riferimenti domini esterni (a meno che non siano domini pubblici); Utilizzare cookie per tracciare le sessioni utente. Tenendo sempre presenti i punti di cui sopra, si raccomanda di sviluppare applicazioni non J2EE che ricadano in uno dei seguenti insiemi, discussi nel paragrafo 4.4: applicazioni non profilate; applicazioni che fanno uso di Form Authentication; applicazioni che richiedono il passaggio di parametri in http header. N.B. i limiti imposti sono per facilitare il processo d integrazione; le potenzialità degli strumenti a disposizione sono molto maggiori. A tal proposito si rimanda alla documentazione presente all URL Autenticazione e autorizzazione Nel caso in cui si intenda sviluppare applicazioni dotate di un proprio modulo di autenticazione si ricorda che tale modulo deve essere una form authentication oppure qualcosa che si aspetta parametri in http header. Per poter lavorare in modalità delegata, l applicazione dovrà inoltre creare una propria Pagina 15 di 27

16 sessione di lavoro per ciascun utente autenticato. I meccanismi di SSO e autorizzazione saranno offerti dal sistema ARPA Raggiungibilità del servizio Per usufruire dei meccanismi di autorizzazione, SSO e delega, offerti da ARPA, l applicazione deve essere fruita esclusivamente attraverso SRA Gateway oppure deve essere un applicazione non profilata, protetta da policy agent e con possibilità d accesso dioretto da internet. Pagina 16 di 27

17 6 REFERENCE PER IL SYSTEM ADMINISTRATOR: COME INTEGRARE UNA RISORSA Questo capitolo è rivolto ad integratori di sistema e viene presentato a completezza delle informazioni. E di particolare interesse per l integrazione di risorse preesistenti. Per lo sviluppo di nuove applicazioni si ricorda quanto affermato nel capitolo 2 scopo. Nel caso di nuove applicazioni, sviluppate ad-hoc per ARPA, il processo d integrazione risulta essere semplice è veloce. Per le altre applicazioni, magari già esistenti prima di ARPA, il processo d integrazione potrebbe risultare molto più complesso e si potrebbe parlare più di migrazione che d integrazione. Possiamo distinguere tra: Deploy (integrazione di applicazioni in ARPA senza alcuna modifica al codice sorgente) Migrazione (integrazione di applicazioni in ARPA previa modifica del codice sorgente). In questo capitolo saranno date alcune linee guida allo scopo di semplificare, e standardizzare I processi di deploy e migrazione. 6.1 Prerequisiti Questa sezione 6.1 viene riportata per completezza, ma riguarda prerequisiti di attività cche verranno svolte all interno di RT ed esulano dalle competenze richieste agli sviluppatori. L integrazione di qualunque applicazione in ARPA inizia con l analisi delle peculiarità della medesima al fine di poter individuare il meccanismo di integrazione migliore. Pertanto, l analisi delle applicazioni da integrare potrebbero richiedere certe competenze tecnologiche che elenchiamo di seguito: 1. Competenze sistemistiche su SO Unix e stack TCP/IP; 2. Conoscenza dell infrastruttura del sistema ARPA; 3. Competenze su JAVA e altri linguaggi di programmazione usati per scrivere le applicazioni da integrare; 4. Competenze su tecnologie Internet (DNS, Proxy, Web, Application server, cookies etc.); 5. Competenze su Sun Java Portal e Access Manager. Inoltre, l attività di integrazione potrà richiedere: 1. Accessibilità al codice sorgente della applicazione da integrare 2. Possibilità di modificare il sorgente per le applicazioni che richiedono un intervento sul codice. Affinché agli utenti sia consentito l accesso diretto alle risorse risulta assolutamente Pagina 17 di 27

18 necessario che si verifichi almeno una delle seguenti condizioni: 1. La risorsa è installata in un container web compatibile con l'installazione di AM Policy Agent 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) Passi d integrazione comuni per ogni tipo di applicazione web E' possibile definire alcuni passi comuni necessari all'integrazione di un'applicazione nel sistema ARPA: 1. Concordare i requisiti di SSO 2. Verificare la compatibilità dei requisiti con le caratteristiche tecnologiche 3. Decidere il livello di integrazione (con SSO, senza SSO) 1 4. Verificare la dislocazione della risorsa nella rete e quindi la sua raggiungibilità 5. Configuare, eventualmente, una o più componenti tecnologiche a disposizione per accedere alla risorsa (gateway, reverse proxy, policy agent e dispatcher) 6. Associare tramite Role Manager la risorsa ad un ruolo, specificandone le URL di accesso e le regole per la generazione di policy dinamiche. Va evidenziato che, durante la definizione degli URL Mapping, i mapping verso una certa directory vengono considerati uguali con o senza slash (/) alla fine. Ad esempio, i primi due mapping di quanto specificato di seguito sono da considerrarsi come se fossero la specifica di un medesimo mapping La definizione di due url mapping uguali, per la stessa risorsa, potrebbe rendere imprevedibile il comportamento del modulo di controllo delle policy d accesso (AM Policy Agent). Per correttezza, è importante evitare di inserire mapping come riportato in esempio. In questi casi, un comportamento corretto potrebbe essere quello di specificare le regole di mapping come di seguito riportato. E inoltre importante sottolineare che a parità di risorsa da integrare, l URL di accesso e i mapping da specificare, possono cambiare nel caso in cui per l accesso si utilizzi il dispatcher, il gateway o il proxy. 1 N.B. a volte si potrebbe essere costretti ad una scelta obbligata per motivi tecnici Pagina 18 di 27

19 6.2 Individuare i metodi di integrazione da adottare Prima di integrare una qualsiasi applicazione nel sistema ARPA è necessario fare un analisi preventiva al fine di capire: Quale tecnologia è stata utilizzata per fornire il servizio; Quali meccanismi di autenticazione sono utilizzati; Quali e quante sono le pagine che compongono il servizio; Quali sono i domini e i contesti coinvolti nella fornitura del servizio; Quali sono i meccanismi utilizzati per la gestione delle sessioni. A valle dell analisi sarà possibile proseguire con l'integrazione dell'applicazione scegliendo opportunamente la tecnologia messa a disposizione per ARPA. In particolare si suggeriscono le seguenti tecnologie nei casi indicati: le applicazioni che fanno uso di form authentication siano accessibili solo attraverso SRA Gateway e siano integrate mediante SRA Gateway; le applicazioni che richiedono passaggi di parametri nell header http siano accessibili solo attraverso SRA Gateway e siano integrate mediante SRA Gateway; le applicazioni J2EE che fanno uso della libreria wrapper AMSDK siano accessibili direttamente da internet e siano integrate mediante l ausilio di AM Policy Agent; le applicazioni SRTY siano integrate mediante l ausilio di AM Policy Agent e libreria wrapper AMSDK; le applicazioni non profilate siano rese accessibili solo attraverso SRA Gateway e integrate tramite SRA Gateway oppure siano rese accessibili da internet e integrate mediante l ausilio di AM Policy Agent. Le applicazioni che non rientrano nelle categorie di cui sopra, dovranno essere migrate così come descritto nel paragrafo Linee guida per l integrazione di applicazioni che fanno uso della libreria wrapper AMSDK In questo paragrafo saranno indicati i passi da effettuare per integrare un'applicazione J2EE sviluppata utilizzando la libreria wrapper AMSDK, di cui al paragrafo 4.5.4; Deploy Un applicazione J2EE che faccia uso della libreria wrapper AMSDK può essere integrata o mediante l ausilio di un policy agent oppure tramite gateway. Se l applicazione deve essere raggiunta direttamente da internet si raccomanda l utilizzo del AM Policy Agent 2.2 compatibile con il container web dell applicazione. Se tale policy Pagina 19 di 27

20 agent compatibile non dovesse esistere si raccomanda di cambiare web container qualora possibile o rendere accessibile l applicazione solo tramite SRA Gateway evitando così di utilizzare un policy agent. Se l applicazione non è direttamente raggiungibile da internet si raccomanda l integrazione mediante l ausilio dello SRA Gateway Retrieve informazioni utente Un applicazione J2EE che faccia uso della libreria wrapper AMSDK deve recuperare le informazioni utente utilizzando i metodi messi a disposizione dalla libreria stessa. Per i dettagli si rimanda alla lettura dell allegato relativo alla libreria wrapper AMSD (documento D17.7a) Configurazione risorsa Per semplicità si prenderà come esempio l'applicazione Arpa Test applicazione SampleSite e si supporrà di volerla integrare come risorsa offerta dal portale. L applicazione fa uso della libreria wrapper AMSDK (4.5.4) ed è installata su un container Tomcat, acceduta tramite mod_jk da un server Apache di front-end, compatibile con l installazione di una versione di AM Policy Agent 2.2. I passi di configurazione sono i seguenti: 1. Configurare i container (tomcat e apache) e l applicazione, così come descritto nell allegato relativo alla configurazione di un ambiente integrato con AM Policy Agent (documento 17.7c). 2. Creare la risorsa Arpa Test applicazione SampleSite a partire dalla console del Role Manager. Per tale risorsa è necessario definire: Nome nome del link sul desktop di portale Descrizione title del link di cui sopra URL URL d accesso al servizio URL Mapping Mapping per la definizione dalla policy d accesso Arpa Test applicazione SampleSite Arpa Test applicazione SampleSite mplesite.jsp Una volta associata la risorsa ad un ruolo qualunque (sempre tramite console di amministrazione del Role Manager), essa sarà fruibile da tutti gli utenti in possesso di tale ruolo Applicazioni SRTY Le applicazioni SRTY rientrano nella categoria relativa alle applicazioni J2EE che fanno uso della libreria wrapper AMSDK e come tali seguono le modalità d integrazione specificata nel paragrafo relativo alle applicazioni web J2EE che fanno uso di libreria Pagina 20 di 27

21 wrapper AMSDK (6.3). Per maggiori dettagli si rimanda l utente all allegato relativo allo sviluppo, configurazione e deploy di applicazioni SRTY (documenti D17.7d e D17.7e). 6.4 Integrazione di applicazioni che richiedono Form Authentication In questo paragrafo saranno indicati i passi da effettuare per integrare un'applicazione web che presenta un autenticazione basata su form authentication Deploy Le applicazioni web che richiedono form authentication devono essere rese fruibili solo attraverso SRA Gateway. Tali applicazioni devono essere integrate mediante l ausilio del gateway Retrieve informazioni utente Le informazioni dell utente, nonché le informazioni di delega, vengono recuperate dalla POST relativa alla form authentication. ARPA mette a disposizione un meccanismo per specificare più parametri da inviare in POST Configurazione risorsa Per semplicità si prenderà come esempio l'applicazione Guida Monaci e si supporrà di volerla integrare come risorsa offerta dal portale. Tale applicazione fa uso di form authentication. Di seguito sono elencati i passi standard d integrazione necessari per effettuare SSO in presenza di form authentication: 1. Modifica del file formauth.xml. Il file da modificare è: /opt/arpa/service/rproxy/xml/formauth.xml ed è presente sugli host di gateway. Tale file va modificato aggiungendo, tra le entry definite, quelle per l'applicazione in questione. Aggiunta del pattern per identificare l applicazione e i parametri da inviare in POST <!-- START PATTERNS SPECIFICATION --> <entry key="patterns">...*/ guidamonaci,.. </entry> <!-- END PATTERNS SPECIFICATION --> Specifica dei parametri e relativa valorizzazione <!-- START GUIDA MONACI --> <entry key="guidamonaci.parameters">login, password</entry> <entry key="guidamonaci.login">regione</entry> Pagina 21 di 27

22 <entry key="guidamonaci.password">toscana</entry> <!-- END GUIDA MONACI --> Per maggiori dettagli sulla configurazione del dispatcher si rimanda all allegato (documento D17.7b). 2. Creare la risorsa Guida Monaci a partire dalla console del Role Manager (per l utilizzo della console del RM consultare il manuale di amministrazione ARPA). Per tale risorsa è necessario definire: Nome nome del link sul desktop di portale Descrizione title del link di cui sopra URL URL d accesso al servizio URL Mapping Mapping per la definizione dalla policy d accesso Guida Monaci Accesso alla Guida Monaci <gateway_url>/ gin.jsp * 3. Associare la risorsa creata ad un ruolo di test (per comodità potrebbe essere un ruolo di amministrazione poiché non è visibile in fase di self provisioninig) 4. Accedere alla console di portale (psconsole) all'url: <host url>/psconsole 5. Cliccare sul tab Secure Remote Access e successivamente, nel sottotab Profile, scegliere il profilo default 6. Accedere al sottotab deployment e aggiungere alla voce Proxies for Domains and Subdomains il dominio dell'applicazione: guidamonaci.com 2 7. Accedere al sottotab Rewriter e aggiungere alla voce Map URIs to RuleSets il mapping del dominio sulle regole di riscrittura *:// --> arpa_ruleset 8. Aggiungere le regole di riscrittura per l'applicazione modificando opportunamente arpa_ruleset : - tornare all home (psconsole); - accedere al sottotab Rewriter ruleset ; - effettuare un download delle regole arpa_ruleset ; - rimuovere arpa_ruleset (N.B. controllare prima che il download sia avvenuto correttamente); - modificare il file scaricato come segue: <Variable name="sez_titolo" type="dhtml"/> <Variable name="sez_corpo_testo" type="dhtml"/> <Variable name="sez_menu_context" type="dhtml"/> <Function name="vai" parampatterns="y" type="url"/> 2 Al fine di ottenere una riscrittura dell'intero dominio guidamonaci.com Pagina 22 di 27

23 - effetuare upload di tale file. 9. Effettuare un restart del modulo gateway e del modulo di riscrittura lanciando i seguenti comandi dalla macchina su cui è installato lo SRA Gateway. N.B. è importante rispettare l ordine indicato di seguito. /opt/arpa/service/rproxy/rproxy stop /opt/sunwportal/bin/psadmin stop-sra-instance -u amadmin -f /root/pass -N default -t gateway /opt/sunwportal/bin/psadmin start-sra-instance -u amadmin -f /root/pass -N default -t gateway /opt/arpa/service/rproxy/rproxy start 6.5 Integrazione di applicazioni che richiedono parametri in http header In questo paragrafo sono indicati i passi da effettuare per integrare un'applicazione che richiede parametri in HTTP Header Deploy L applicazione web dovrà essere fruibile solo e soltanto attraverso SRA Gateway. Tale strumento è l unico da utilizzare per integrare questo tipo di applicazioni Retrieve informazioni utente Le informazioni utente, nonché le informazioni di delega, dovranno essere recuperate sull http header Configurazione risorsa Per semplicità si prenderà come esempio l'applicazione Pasti Fruiti e si supporrà di volerla integrare come risorsa offerta dal portale. Tale applicazione richiede un parametro in http header: CLIENT_CERT_SUBJECT_CN valorizzato con il cf dell utente. Di seguito sono elencati i passi standard relativi all integrazione delle applicazioni che hanno necessità di attributi in http header. 1. Modifica del file header.xml. Il file da modificare è: /opt/arpa/service/rproxy/xml/header.xml ed è presente sugli host del gateway. Tale file va modificato aggiungendo la proprietà seguente. Per maggiori dettagli sulla configurazione del file service.xml si rimanda all allegato (documento D17.7b). Aggiunta del pattern per identificare l applicazione e i parametri da inviare in header <entry key="patterns">..*/ipo1.regione.toscana.it/.*pasti.* ipo1pasti,. </entry> Specifica dei parametri e relativa valorizzazione <entry key="ipo1pasti.bean_parameters"> cf CLIENT_CERT_SUBJECT_CN Pagina 23 di 27

24 </entry> 2. Creare la risorsa Pasti Fruiti a partire dalla console del Role Manager (per l utilizzo della console del RM consultare il manuale di amministrazione ARPA). Per tale risorsa è necessario definire: Nome nome del link sul desktop di portale Descrizione title del link di cui sopra URL URL d accesso al servizio URL Mapping Mapping per la definizione dalla policy d accesso Pasti Fruiti Pasti Fruiti <gateway url>/ * * * * 3. Associare la risorsa creata ad un ruolo di test (per comodità potrebbe essere un ruolo di amministrazione poiché non sia visibile in fase di self provisioninig) 4. Cliccare sul tab Secure Remote Access e successivamente, nel sottotab Profile, scegliere il profilo default 5. Accedere al sottotab deployment e aggiungere alla voce Proxies for Domains and Subdomains il dominio dell'applicazione: regione.toscana.it. 6. Accedere al sottotab Rewriter e aggiungere alla voce Map URIs to RuleSets il mapping del dominio sulle regole di riscrittura *://ipo1.regione.toscana.it/* --> arpa_ruleset 7. Aggiungere le regole di riscrittura per l'applicazione modificando opportunamente arpa_ruleset : - tornare all home (psconsole); - accedere al sottotab Rewriter ruleset ; - effettuare un download delle regole arpa_ruleset ; - rimuovere arpa_ruleset (N.B. controllare prima che il download sia avvenuto correttamente); - modificare il file scaricato come segue: <Variable name="url*" type="url"/> <Variable name="riga*" type="dhtml"/> <Variable name="where_you_are*" type="dhtml"/> - effetuare upload di tale file. 8. Effettuare un restart del modulo gateway e del modulo di riscrittura lanciando i seguenti comandi dalla macchina su cui è installato lo SRA Gateway /opt/arpa/service/rproxy/rproxy stop /opt/sunwportal/bin/psadmin stop-sra-instance -u amadmin -f /root/pass -N default -t gateway /opt/sunwportal/bin/psadmin start-sra-instance -u amadmin -f /root/pass -N default -t gateway /opt/arpa/service/rproxy/rproxy start Pagina 24 di 27

25 6.6 Applicazioni non profilate In questo paragrafo sono indicati i passi da effettuare per integrare un'applicazione non profilata Deploy L applicazione web dovrà essere fruibile solo attraverso SRA Gateway oppure esposta su internet e protetta da AM Policy Agent 2.2. Se l applicazione deve essere raggiunta direttamente da internet si raccomanda l utilizzo del AM Policy Agent 2.2 compatibile con il container web dell applicazione. Se tale policy agent compatibile non dovesse esistere si raccomanda di cambiare web container qualora possibile o rendere accessibile l applicazione solo tramite SRA Gateway evitando così di utilizzare un policy agent Retrieve informazioni utente Un applicazione non profilata non ha bisogno di accedere alle informazioni dell utente Configurazione risorsa La configurazione della risorsa segue quanto già detto per le applicazioni J2EE che utilizzano la libreria wrapper AMSDK. N.B. nel caso in cui si integri l applicazione mediante SRA Gateway si raccomanda di seguire le indicazioni riportate nel paragrafo 6.5, relativo all integrazione di applicazioni che richiedono parametri in http header. In questo caso non sarà però necessario modificare il file service.xml. 6.7 Federazione In un contesto di federazione, Regione Toscana può svolgere il compito di Identità Provider (IdP); Service Provider (SP). Un SP fornisce servizi ad utenti esterni, autenticati presso un IdP. Il rapporto di fiducia tra due enti sta proprio nel fatto che chi gioca il ruolo di SP si fida delle asserzioni provenienti da un certo IdP. Regione Toscana può essere configurata per fidarsi di più IdP così come può essere configurata per fare da IdP per diversi SP. Se si desidera fornire dei servizi esterni ad utenti del proprio dominio, deve essere configurato come SP l ente che fornirà i servizi. Su questo, deve essere configurata Regione Toscana come IdP. Viceversa, nel caso in cui si desideri fornire servizi ad utenti esterni al proprio dominio è necessario configurare come IdP l ente fruitore e, su questo, Regione Toscana come SP. Pagina 25 di 27

26 Regione Toscanca agisce in POST Profile per lo scambio di asserzioni: durante l asserzione di autenticazione prodotta come IdP o ricevuta in caso di SP, devono essere inviate le informazioni relative a ruoli ed attributi, oltre quelle relative ai dati anagrafici dell utente (CF, Nome, Cognome). Come IdP Regione Toscana invia i seguenti attributi: Nome; Cognome; CodiceFiscale; ; DataNascita; CodiceComuneNascita; Ruoli (insieme di tutti i ruoli posseduti dall utente); per ogni ruolo, di cui al punto precedente, invia tanti attributi della forma <ruolo>.<attributo di ruolo> per ciascun attributo del ruolo. Come SP Regione Toscana si aspetta di ricevere i seguenti attributi: Nome; Cognome; CodiceFiscale; Ruoli (insieme di tutti i ruoli posseduti dall utente); per ogni ruolo, di cui al punto precedente, invia tanti attributi della forma <ruolo>.<attributo di ruolo> per ciascun attributo del ruolo. Per configurare Regione Toscana come IdP o SP è necessario: accedere alla console dell Access Manager all URL (N.B. per accedere alla console è necessario possedere il certificato idoneo); cliccare sul tab Federation ; selezionare il sottotab SAML ; Da qui è possibile inserire i Trusted partners cliccando su new : nel caso in cui si desideri configurare un SP per RT che gioca il ruolo di IdP è necessario selezionare POST come Destination ; nel caso in cui si desideri configurare un IdP per RT che gioca il ruolo di SP è necessario specificare POST come Source. Una volta scelto il profilo si prosegue configurando come di seguito riportato Regione Toscana come IdP Di seguito vengono indicati i parametri da indicare per configurare Regione Toscana come IdP. SourceID identificativo di chi emette l asserzione (è possibile utilizzare sempre 8mPtB0zy8TjRp3jQtbju6S9FRk8= per ogni conf). Target - nome host, dominio e porta del sito target (sito SP). Pagina 26 di 27

27 PostURL SP SAML consumer siteattributemapper classe di attribute mapper (it.toscana.regione.arpa.portal.saml.idp.arpasiteattributemapper inserisce attributi nell asserzione di autenticazione così come decritto sopra). Per comodità supponiamo che si desideri configurare Regione Toscana come IdP del sito che offre servizi all url SourceID: 8mPtB0zy8TjRp3jQtbju6S9FRk8= target: tportal.inps.it:443 posturl: siteattributemapper: it.toscana.regione.arpa.portal.saml.idp.arpasiteattributemapper version: 1.1 Authorized TARGET: Regione Toscana come SP Di seguito vengono indicati i parametri da indicare per configurare Regione Toscana come SP. SourceID Il source ID viene recuperato sulla macchina di portale mediante il comando: java -classpath /opt/sunwam/lib/amclientsdk.jar com.sun.identity.saml.common.samlsiteid Issuer protocollo, host, dominio e porta dell IdP. AccountMapper classe di account mapper (la classe it.toscana.regione.arpa.portal.saml.sp.arpapartneraccountmapper si coccupa di ricevere gli attributi utente inviati cosi come descritto sopra). Per comodità supponiamo che si desideri configurare Regione Toscana come SP del sito che offre servizi all URL SourceID: XeF2/gIN0UkedbwFBUWHR+NQyz8= Issuer: AccountMapper: it.toscana.regione.arpa.portal.saml.sp.arpapartneraccountmapper Pagina 27 di 27