LINEE GUIDA PER L INTEGRAZIONE E LO SVILUPPO DI APPLICAZIONI Progetto ARPA

Transcript

1 Modulo: Linee guida ridotte Sistema: ARPA Versione documento: 1.5 LINEE GUIDA PER L INTEGRAZIONE E LO SVILUPPO DI APPLICAZIONI Progetto ARPA Livelli di approvazione Cliente Verifica Approvazione Approvazione Funzione Nome Data Firma Responsabile tecnico Responsabile Progetto Grazia Ugolini Laura Castellani LISTA DI DISTRIBUZIONE Pagina 1 di 17

2 REVISIONI Paragrafo/Revisione Modifica effettuata Data 1.0 Prima versione 22/06/ Aggiornamenti 27/07/ Aggiornamenti 27/08/ rev Revisione RT 30/08/ a 1.5b 1.5c 1.5d 1.5e Revisione RTI 20/10/2007 Pagina 2 di 17

3 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...16 Pagina 3 di 17

4 1 GENERALITÀ Il presente documento descrive le modalità per lo sviluppo e/o l integrazione di applicazioni nel sistema ARPA. Nel documento sono presenti commenti con il presente formato inseriti per facilitare la lettura del docuemnto a chi deve sviluppare sistemi che devono essere integrati con l infrastruttura per l autenticazione e l accesso ARPA di Regione Toscana. 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 17

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 17

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 17

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. Pagina 7 di 17

8 Pertanto qualora i ruoli e/o attributi definiti sul sistema ARPA non fossero sufficienti per 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 17

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 Errore. L'origine riferimento non è stata trovata.. 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 Pagina 9 di 17

10 SSO che possono essere messi in campo. 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 Pagina 10 di 17

11 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 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 Pagina 11 di 17

12 ruolo di SP. Nel caso in cui si desideri offrire, ad un utente di ARPA, i servizi messi a disposizione da 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 17

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 17

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 17

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. Pagina 15 di 17

16 Per poter lavorare in modalità delegata, l applicazione dovrà inoltre creare una propria 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 17

17 Pagina 17 di 17