POLITICHE DI SICUREZZA E GESTIONE

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "POLITICHE DI SICUREZZA E GESTIONE"

Transcript

1 UNIVERSITA DEGLI STUDI DELLA BASILICATA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA SPECIALISTICA IN INFORMATICA TESI DI LAUREA SPECIALISTICA POLITICHE DI SICUREZZA E GESTIONE DELL'IDENTITÀ NEL SISTEMA PUBBLICO DI COOPERAZIONE APPLICATIVA Relatore Prof. Giansalvatore MECCA Candidato Michele Santomauro Matricola 32821

2 Sommario Introduzione... 1 Capitolo 1 : Architetture SOA... 3 Web Service... 5 SOAP... 6 WSDL... 7 UDDI... 8 Sicurezza nelle architetture SOA... 9 Sicurezza hardware Sicurezza a livello trasporto Sicurezza del messaggio Capitolo 2 : Cooperazione Applicativa Architetture SOA nella cooperazione applicativa Specifiche del CNIPA Il progetto SPCoop Sistema informativo locale Porta di dominio Accordo di Servizio Servizi di registro SICA Busta e-gov Requisiti di sicurezza del progetto Capitolo 3 : Progetto ICAR Organizzazione del progetto OpenSPCoop FreESBee Capitolo 4 : Task INF-3 e relative implementazioni I componenti dell architettura Lo scenario di riferimento Lo scenario nella cooperazione applicativa Tecnologie di riferimento... 47

3 Reference Implementation Tecnologie di riferimento Integrazione nell architettura SPCoop FreESBee-SP Progetto SIL-VIO Progetto Shibboleth Scenario in cooperazione applicativa Configurazione delle istanze Tecnologie di riferimento Capitolo 5 : Sperimentazione dell architettura SPCoop Il caso d uso Identificazione assistito Il caso d uso Segnalazione ricovero Il caso d uso Variazione anagrafica Capitolo 6 : Soluzioni a confronto Sicurezza in OpenSPCoop e in FreESBee Reference Implementation vs FreESBee-SP Schema delle differenze Appendice Bibliografia... 86

4

5 Introduzione L avvento di internet nella società dell informazione ha segnato un cambiamento radicale nel modo di pensare ed agire delle persone, in tutti gli ambiti, soprattutto in quello professionale. Tale cambiamento ha interessato anche la pubblica amministrazione, che si è trovata a dover far fronte ad una richiesta sempre più pressante, da parte dei cittadini e delle imprese, di adozione di strumenti che permettano, da un lato, di fruire di servizi telematici per la compilazione di pratiche, e, dall altro, di snellire le procedure burocratiche per l assoluzione delle stesse. Tale compito, ad oggi, è stato assolto dalla pubblica amministrazione in maniera soddisfacente, sia mettendo a disposizione dei cittadini una serie di servizi cosiddetti G2C, ossia Government to Citizen, a cui è possibile accedere comodamente attraverso internet, sia adottando sistemi che automatizzano e velocizzano l elaborazione delle pratiche. Nonostante ciò, da qualche anno a questa parte, si è via via definita una nuova esigenza, che riguarda la necessità di mettere tutti gli enti della PA in comunicazione tra loro. L obiettivo a cui si vuole arrivare è quello di permettere, ad esempio, ad un cittadino della regione Lombardia, di origini Lucane, che ha la necessità di avere un certificato di nascita, di non recarsi necessariamente presso il comune di nascita per ottenerlo, bensì, può recarsi presso il proprio comune di residenza, il quale, per conto suo, in maniera telematica, può richiederlo al comune di nascita. A tale scopo, nel 2005, il CNIPA (Centro Nazionale per l Informatica nella Pubblica Amministrazione ha avviato due progetti paralleli, e stilato le specifiche per : la realizzazione di un infrastruttura che permetta l interoperabilità tra tutte le pubbliche amministrazioni italiane (progetto SPC - Sistema Pubblico di Connettività), e la cooperazione e la fruizione dei servizi che le stesse mettono a disposizione (progetto SPCoop - Sistema Pubblico di Cooperazione). Nell ambito di questa tesi si approfondiscono soltanto - 1 -

6 gli aspetti relativi ad SPCoop, con particolare attenzione alle tematiche riguardanti la sicurezza

7 Capitolo 1 : Architetture SOA SOA è l acronimo di Service Oriented Architecture, un architettura software che, come dice il nome stesso, è orientata ai servizi. La filosofia alla base è quella di decentrare la business logic in unità logiche più piccole, per lo più indipendenti, in grado di assolvere a specifici compiti, messi a disposizione sotto forma di servizi. Questi ultimi, infatti, rappresentano il punto di forza di tutta l architettura, in quanto permettono l interoperabilità tra sistemi eterogenei, al fine di realizzare quello che è il cosiddetto processo di business. Per questo motivo, quindi, non esiste una specifica piattaforma per realizzare questo tipo di architetture, in quanto gli elementi che ne fanno parte, sono proprio i processi applicativi già esistenti, opportunamente ristrutturati per l erogazione di servizi. Esempio di architettura distribuita - 3 -

8 Le proprietà che contraddistinguono le architetture SOA sono : loose coupling (basso accoppiamento) : gli elementi che ne fanno parte sono indipendenti gli uni dagli altri message orientation (orientamento ai messaggi) : la comunicazione tra i componenti avviene attraverso scambio di messaggi description orientation (orientamento alla descrizione) : la semantica di ciascun elemento viene descritta attraverso i metadati e resa pubblica per coloro che vogliono usufruire del servizio reso autonomia : i componenti sono autonomi riusabilità : per promuovere il riuso di funzionalità composizione : i servizi resi da ciascun componente possono essere aggregati e coordinati per formare una logica complessa neutralità della piattaforma : i messaggi hanno formati standard (ad esempio XML) I componenti principali che operano in tali architetture sono : Service Provider : è il componente che fornisce un servizio; Service Consumer : è il componente che richiede un servizio; Service Registry : è l intermediario che ha il compito di pubblicare le informazioni circa il servizio messo a disposizione dal Service Provider

9 L interazione tra i tre componenti avviene nel seguente modo : il Service Provider mette a disposizione dei servizi, le cui caratteristiche vengono pubblicate dal Service Registry (URL, modalità di accesso ecc). Quando il Service Consumer ha la necessità di usufruire di un servizio, contatta il Service Registry ottenendo tutte le informazioni che gli occorrono. Da quel momento in poi può contattare direttamente il Service Provider ed ottenere i servizi di cui necessita. Web Service Di seguito viene riportata la definizione del W3C (World Wide Web Consortium : E un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è quella di offrire un'interfaccia software (descritta in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language) utilizzando la quale altri sistemi possono interagire con il Web Service - 5 -

10 stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta" (la più famosa è SOAP): tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Fonte : Questa tecnologia, da quanto si evince anche dalla definizione, si basa su un certo numero di standard, quali SOAP, WSDL e UDDI, che ne permettono il funzionamento. Da notare che i Web Service non sono legati alle architetture SOA, tuttavia rappresentano dei candidati ideali ad essere utilizzati in tale ambito grazie alla loro indipendenza dalla piattaforma ed al linguaggio e alla modalità standard per definire l'interfaccia verso l esterno. SOAP E l acronimo di Simple Object Access Protocol e rappresenta uno standard per lo scambio di messaggi tra componenti distribuiti. Può operare su diversi protocolli, ma il più utilizzato è quello HTTP. I messaggi sono in formato XML e seguono la configurazione Head Body. L Header è opzionale e contiene informazioni circa il routing, la sicurezza e le transazioni, mentre il Body è obbligatorio e contiene il messaggio vero e proprio scambiato tra le due parti (chiamato in gergo Payload). <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:header> </soapenv:header> <soapenv:body> </soapenv:body> </soapenv:envelope> Esempio di messaggio SOAP - 6 -

11 WSDL E l acronimo di Web Service Description Language e rappresenta un linguaggio formale, in formato XML, per descrivere l interfaccia di un Web Service. Un documento WSDL è composto da cinque elementi: Types : definisce i tipi di dati coinvolti nello scambio dei messaggi (definiti nel linguaggio XML Schema) Message : specifica le informazioni sui parametri ed i loro tipi circa il messaggio di input e output PortType : indica le operazioni supportate da un servizio web Binding : stabilisce il protocollo da utilizzare per lo scambio dei messaggi, HTTP GET/POST, MIME o SOAP Service : riporta l URL al quale è possibile contattare il servizio <wsdl:definitions name="esempio" targetnamespace="http://namespaces.esempio.com" xmlns:es="http://www.esempio.com/esempiowsdl.wsdl" xmlns:esxsd="http://schemas.esempio.com/ EsempioWSDL.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> <xsd:schema targetnamespace="http://namespaces.example.com" xmlns:xsd="http://www.w3.org/1999/xmlschema"> <xsd:element name=" "> <xsd:complextype> <xsd:sequence> <xsd:element name=" " type="string"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:schema> </wsdl:types> <! - Messaggio di richiesta --> <wsdl:message name="messaggiorichiestaesempio"> <wsdl:part name="body" element="esxsd: "/> </wsdl:message> <! - Messaggio di risposta --> <wsdl:message name="messaggiorispostaesempio"> <wsdl:part name="body" element="esxsd: "/> </wsdl:message> - 7 -

12 <wsdl:porttype name="porttypeesempio"> <wsdl:operation name=" "> <wsdl:input message="es:messaggiorichiestaesempio"/> <wsdl:output message="es:messaggiorispostaesempio"/> <wsdl:fault message="es:messaggiofaultesempio"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="bindingesempio" type="es:porttypeesempio"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="operationesempio"> <soap:operation soapaction="http://www.esempio.com/esempi"/> <wsdl:input> <soap:body use="literal" namespace="http://schemas.esempio.com/esempiowsdl.xsd"/> </wsdl:input> <wsdl:output> <soap:body use="literal" namespace="http://schemas.esempio.com/esempiowsdl.xsd"/> </wsdl:output> <wsdl:fault> <soap:body use="literal" namespace="http://schemas.esempio.com/esempiowsdl.xsd"/> </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="servizioesempio"> <wsdl:documentation>esempio file WSDL</wsdl:documentation> <wsdl:port name=" " binding="es:bindingesempio"> <soap:address location="http://www.esempio.com/esempio"/> </wsdl:port> </wsdl:service> </wsdl:definitions> Esempio di WSDL UDDI E l acronimo di Universal Description, Discovery and Integration e rappresenta lo strumento attraverso cui è possibile dinamicamente accedere ai servizi disponibili sulla rete. Si compone di un registro, denominato UBR (UDDI Business Registry), che contiene informazioni sui servizi disponibili. Tali informazioni sono organizzate in modo da effettuare diversi tipi di ricerche basate sulla consultazione di tre cataloghi differenti : White Pages : contenenti informazioni generiche sull'azienda (ad - 8 -

13 esempio la ragione sociale, l'indirizzo, ecc) Yellow Pages : contenente una classificazione dei servizi sottoforma di tassonomia per poter effettuare le ricerche in base alla categoria a cui appartiene un servizio Green Pages : contenente informazioni tecniche sui servizi e grazie alle quali gli stessi possono essere invocati Esempio di utilizzo del registro UDDI Sicurezza nelle architetture SOA I vantaggi offerti da SOA nella realizzazione di infrastrutture complesse, si scontrano con la complessità di rendere una tale architettura completamente sicura. Quello della sicurezza è un problema che al giorno d oggi è molto sentito, soprattutto nell ambito informatico. Questo fenomeno è amplificato nelle architetture SOA, in quanto non si parla più di un singolo sistema, ma di molti - 9 -

14 sistemi indipendenti ed interoperanti, ciascuno dei quali deve agire nel rispetto dei requisiti di sicurezza, al fine di non pregiudicare la stabilità dell intera infrastruttura. Al giorno d oggi esistono una serie di strumenti, standard e specifiche (per lo più in via di standardizzazione) il cui scopo è quello di garantire la massima sicurezza possibile in tali architetture. Di seguito viene illustrato lo stato dell arte oggi in tale settore. Sicurezza hardware A livello hardware la sicurezza è garantita dai firewall XML, dispositivi in grado di filtrare il traffico di rete a livello applicativo, agendo fino al livello 7 della pila ISO/OSI. Il compito di tali apparecchi è quello di filtrare tutto il traffico XML, sia in ingresso che in uscita, in base a regole prestabilite. Sicurezza a livello trasporto Il canale di comunicazione svolge un ruolo molto importante, in quanto ad esso è affidato il compito di trasportare informazioni, dati e quant altro, da un mittente ad un destinatario. Avere a disposizione un canale sicuro limita, ma non evita, la possibilità di attacchi del tipo MITM (Man in the middle), oppure Spoofing ecc. Sia TLS (Transport Layer Security) che SSL (Secure Sockets Layer), sono due protocolli crittografici che permettono di criptare la comunicazione tra sorgente e destinazione a livello trasporto. TLS è uno standard IETF (Internet Engineering Task Force) e rappresenta l evoluzione di SSL, precedente protocollo sviluppato da Netscape Corporation. L utilizzo tipico che ne viene fatto è nelle applicazioni client server, più precisamente attraverso i browser web, infatti, viene utilizzato soprattutto quando si eseguono operazioni come transazioni online, inserimento di dati personali per l accesso ad un servizio (nome utente e password) ecc. Il funzionamento è basato sulla validazione, da parte del client (e

15 quindi del browser), della firma digitale contenuta in opportuni certificati che risiedono sul server stesso. Ovviamente tali certificati sono validi soltanto se vengono rilasciati da autorità preposte allo scopo, definite Certification Authority. HTTPS rappresenta l utilizzo del protocollo HTTP in un canale sicuro criptato con SSL, il cui principio di funzionamento si basa sul concetto di crittografia a chiave pubblica e privata ed i cui dettagli esulano dallo scopo di questa tesi. Per quanto tali protocolli risultino essere impeccabili, in realtà sono anch essi vulnerabili ad attacchi, infatti, recenti studi, hanno dimostrato che una vulnerabilità di tali protocolli è rappresentata dall attività di rinegoziazione che client e server effettuano periodicamente. Sicurezza del messaggio Dal momento che la sola sicurezza a livello trasporto non basta a garantire che la comunicazione sia esente da rischi, è stato necessario definire altre specifiche che permettono di salvaguardare la sicurezza dell intero messaggio. Nell ambito dei web service, le specifiche che garantiscono la sicurezza dei messaggi SOAP è parte di WS-*, termine con cui si indica l insieme di specifiche che riguardano i Web Service. Alcune di esse sono già diventate standard, altre, invece, sono in fase di standardizzazione. Quelle più rilevanti sono : WS-Security o XML Signature o XML Encryption SAML (Security Assertion Markup Language) XACML (extensible Access Control Markup Language)

16 Di seguito vengono analizzate nel dettaglio : WS-Security, XML Signature e XML Encryption E uno standard, promosso dalla OASIS (http://www.oasis-open.org), come estensione di SOAP per rendere sicuri i messaggi scambiati tra Web Service. Permette di garantire l integrità e la confidenzialità grazie all utilizzo di altri due standard, XML Signature ed XML Encryption, entrambi promossi, invece, dal consorzio W3C (http://www.w3.org). Il primo definisce le modalità con cui apporre la firma digitale su un documento XML, mentre il secondo specifica come criptare un messaggio XML. WS-Security prevede vari formati di firma e vari algoritmi per la crittografia dei dati, come, ad esempio : certificati X.509, Kerberos, USERID/Password, Asserzioni SAML, ecc. Tutte le informazioni vengono riportate nell header di un messaggio SOAP, pertanto vengono elaborate a livello applicazione. Un esempio di messaggio SOAP con WS-Security è il seguente : <soap:envelope > <soap:header> </soap:header> <soap:body> </soap:body> </soap:envelope> <soap:envelope> <soap:header> <wsse:security soap:mustunderstand="1"> <wsu:timestamp > <wsu:created> </wsu:created> <wsu:expires> </wsu:expires> </wsu:timestamp> <wsse:binarysecuritytoken > </wsse:binarysecuritytoken> <xenc:encryptedkey > <xenc:encryptionmethod > <ds:digestmethod/> </xenc:encryptionmethod> <KeyInfo > <wsse:securitytokenreference> <X509Data> <X509IssuerSerial> <X509IssuerName> </X509IssuerName> <X509SerialNumber> </X509SerialNumber> </X509IssuerSerial> </X509Data> </wsse:securitytokenreference>

17 </KeyInfo> <xenc:cipherdata> <xenc:ciphervalue> </xenc:ciphervalue> </xenc:cipherdata> <xenc:referencelist> <xenc:datareference /> </xenc:referencelist> </xenc:encryptedkey> <ds:signature> <ds:signedinfo> <ds:canonicalizationmethod /> <ds:signaturemethod /> <ds:reference> <ds:transforms> <ds:transform /> </ds:transforms> <ds:digestmethod /> <ds:digestvalue> </DigestValue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> </ds:signaturevalue> <ds:keyinfo> <wsse:securitytokenreference> <wsse:reference /> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> </wsse:security> </soap:header> <soap:body > <xenc:encrypteddata > <xenc:encryptionmethod /> <xenc:cipherdata> <xenc:ciphervalue> </xenc:ciphervalue> </xenc:cipherdata> </xenc:encrypteddata> </soap:body> </soap:envelope> Come si può notare dall esempio, l aggiunta della firma, unitamente alla crittografia dei dati, aggiunge un overhead sia nel trasporto, sia nell elaborazione del messaggio stesso, in quanto, nel primo caso, la dimensione fisica risulta di gran lunga maggiore di quella del messaggio originale, mentre, nel secondo caso,

18 è necessario un lavoro in più per decriptare ciò che si è ricevuto e verificare la firma. SAML E l acronimo di Security Assertion Markup Language. Rappresenta lo standard per l autenticazione e l autorizzazione tra domini differenti attraverso l uso di messaggi XML. E promosso dalla OASIS e ad oggi è alla versione 2.0. L obiettivo a cui cerca di assolvere SAML è quello di fornire una soluzione versatile, ma allo stesso tempo funzionale, al problema del Multiple Sign On. Infatti, ordinariamente, il service consumer è costretto all autenticazione su ciascun dominio nel quale intende richiedere l erogazione di un servizio. Il motivo per cui si è resa necessaria questa standardizzazione è dovuto al fatto che, le modalità e le tecniche utilizzate per realizzare il Single Sign On, sono varie, ad esempio attraverso l uso dei cookie, il che portava in una direzione di disomogeneità, che quindi rendeva impossibile l interoperabilità tra sistemi eterogenei. Grazie a questa soluzione, ciascun Service Consumer ha a disposizione un proprio profilo, col quale richiedere l accesso e l erogazione di servizi ai vari domini. Questi ultimi sono in grado di validare tale profilo ed erogare il servizio, qualora esso risulti essere coerente con le politiche di sicurezza definite per quel dato servizio. In questo modo l operazione di Sign On viene effettuata soltanto una volta, per l acquisizione del profilo, ed utilizzata tutte le volte che viene richiesto. Il meccanismo di funzionamento è basato sulle asserzioni, cioè pezzi di codice XML che contengono proprio le informazioni che descrivono il richiedente, come, l identificativo univoco ed i relativi attributi. Lo standard prevede che tali asserzioni vengano inserite all interno della sezione WS-Security, che a sua volta è contenuta nell header di un messaggio SOAP

19 Un esempio di asserzioni estratto da un messaggio è il seguente : <saml:subject> <saml:nameid Format=" "> </saml:nameid> <saml:subjectconfirmation Method=" "> <saml:subjectconfirmationdata Address=" " InResponseTo=" " NotOnOrAfter=" T18:10:58.030" Recipient="http://sp.unibas.it" /> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore=" T18:05:58.030" NotOnOrAfter=" T18:10:58.030"> <saml:audiencerestriction> <saml:audience>http://sp.unibas.it </saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant=" T18:05:57.643" SessionIndex=" " SessionNotOnOrAfter=" T18:35:57.643Z"> <saml:subjectlocality Address=" " /> <saml:authncontext> <saml:authncontextdeclref> </saml:authncontextdeclref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute FriendlyName="title" Name="idTitle" NameFormat=" "> <saml:attributevalue xmlns:xs=" " xmlns:xsi=" " xsi:type=" "> Borsista </saml:attributevalue> </saml:attribute> <saml:attribute FriendlyName="organizationUnit" Name="idOrganizationUnit" NameFormat=""> <saml:attributevalue xmlns:xs=" " xmlns:xsi=" " xsi:type=" "> Unibas </saml:attributevalue> </saml:attribute>

20 </saml:attributestatement> </saml:assertion> L immagine riportata di seguito mostra, invece, lo schema delle interazioni che avvegono tra i vari componenti : XACML E l acronimo di extensible Access Control Markup Language e rappresenta lo standard, promosso dalla OASIS, che comprende : un linguaggio per definire le policy, in formato XML, circa i requisiti di accesso alle risorse, come, ad esempio, nome dell organizzazione di appartenenza, ruolo ricoperto all interno dell organizzazione, ecc; un modello di processamento delle informazioni contenute nel profilo del richiedente ed inviate assieme al messaggio di richiesta

21 I componenti previsti dallo standard per realizzare il modulo di processamento sopra menzionato sono : PAP (Policy Administration Point) : è il componente in cui vengono memorizzate e gestite le policy. PDP (Policy Decision Point) : è il componente incaricato di valutare i requisiti del profilo e decidere se permettere o negare la fruizione del servizio richiesto. PEP (Policy Enforcement Point) : è il componente che intercetta la richiesta dell utente ed esegue le azioni decise dal PDP. PIP (Policy Information Point) : è il componente di supporto al PDP che fornisce informazioni aggiuntive come, ad esempio, informazioni provenienti da directory LDAP. Un esempio di policy, richiesta e risposta è il seguente : <Policy > <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <Resource> <ResourceMatch > <AttributeValue > </AttributeValue> <ResourceAttributeDesignator /> </ResourceMatch> </Resource> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule > <Target> <Subjects> <AnySubject/>

22 </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch> <AttributeValue > </AttributeValue> <ActionAttributeDesignator/> </ActionMatch> </Action> </Actions> </Target> <Condition> <Apply > <SubjectAttributeDesignator /> </Apply> <AttributeValue > </AttributeValue> </Condition> </Rule> </Policy> Policy <Request> <Subject> <Attribute > <AttributeValue> </AttributeValue> </Attribute> <Attribute> <AttributeValue> </AttributeValue> </Attribute> </Subject> <Resource> <Attribute> <AttributeValue> </AttributeValue> </Attribute> </Resource> <Action> <Attribute> <AttributeValue> </AttributeValue> </Attribute> </Action> </Request> <Response> <Result> <Decision> </Decision> <Status> <StatusCode /> </Status> </Result> </Response> Risposta Richiesta

23 Attualmente XACML è alla versione 2.0, ma è in fase di approvazione la nuova versione 3.0 che comprende una serie di miglioramenti riguardo nuove tipologie di profili, nuovi attributi e datatypes, meccanismi di delega ecc. Di seguito è riportato uno schema di interazione tra i componenti :

24 Capitolo 2 : Cooperazione Applicativa L idea della realizzazione di un infrastruttura che permetta l interoperabilità tra le varie pubbliche amministrazioni italiane si concretizza nel 2005, con due progetti denominati, rispettivamente, SPC ed SPCoop. L ente promotore dell iniziativa è il CNIPA, Centro Nazionale per l Informatica nella Pubblica Amministrazione, che definisce una serie di specifiche per la realizzazione di entrambi i progetti. Il primo è l acronimo di Sistema Pubblico di Connettività, e riguarda la realizzazione di un infrastruttura di rete privata che colleghi tutte le amministrazioni italiane. Il secondo, invece, è l acronimo di Sistema Pubblico di Cooperazione, e riguarda la realizzazione di un infrastruttura software che permetta la comunicazione e lo scambio di dati e/o informazioni tra i sistemi informativi delle varie amministrazioni. Per quanto i due progetti siano partiti insieme, viene da se che il completamento del primo è propedeutico al secondo, in quanto non ci può essere scambio di informazioni, se prima non c è un canale di comunicazione che si fa carico del trasporto delle stesse. In questa tesi si analizzano soltanto le caratteristiche di SPCoop, perché oggetto di studio. Architetture SOA nella cooperazione applicativa Lo sviluppo delle architetture SOA ha dato un notevole impulso alla definizione delle specifiche del sistema SPCoop, in quanto, come si vedrà in seguito, rientrano appieno tutti gli elementi, precedentemente visti, che compongono tali architetture, ovviamente adattati per renderli più consoni al caso che si sta trattando

25 Specifiche del CNIPA Il progetto SPCoop Le specifiche pubblicate dal CNIPA riguardo il progetto SPCoop sono dieci, tutti documenti che definiscono il quadro tecnico implementativo dell intera infrastruttura. Gli elementi fondamentali che caratterizzano tale architettura sono : Sistema informativo locale Porta di dominio Accordo di servizio Servizi di registro SICA Busta e-gov Sistema informativo locale Nel seguito sarà definito SIL. Come si intuisce dal nome, è il componente attraverso cui si fa riferimento ai sistemi informativi di cui è dotata ciascuna pubblica amministrazione. Rappresenta quindi l endpoint da cui si originano, rispettivamente, le richieste e le risposte per l erogazione un servizio. A seconda dei casi, tale componente si definisce fruitore, se effettua una richiesta ad un altro componente; altrimenti, erogatore, se fornisce un servizio ad un altro SIL. Nell ottica delle architetture SOA tali elementi non sono altro che dei servizi web che si scambiano messaggi in un formato XML particolare, così come vedremo più avanti

26 Esempio di SIL all interno dell infrastruttura Porta di dominio Nel seguito sarà indicata con il termine PdD. Rappresenta l unico punto d ingresso nell architettura SPCoop. E ad essa che vengono indirizzate tutte le richieste e le risposte provenienti dai SIL, pertanto svolge una funzione di gateway per tutti i messaggi in transito. Ogni dominio ne possiede una. Al suo interno è composta a sua volta da un architettura complessa che svolge operazioni cosiddette di imbustamento e sbustamento, rispettivamente, delle richieste e delle risposte; tale funzionalità sarà descritta nel dettaglio più avanti. Oltre a queste due che sono le funzionalità principali della PdD, ci sono anche altre funzionalità secondarie, ma non meno importanti, quali la tracciatura del log dei messaggi in transito, la gestione della sicurezza del messaggio, la verifica dei livelli di qualità offerti dalla stessa porta ecc. I due elementi più importanti che compongono tale componente sono : la Porta Delegata (nel seguito PD) e la Porta Applicativa (nel seguito PA). Entrambe sono i punti che interfacciano i SIL con la PdD, e quindi con l infrastruttura SPCoop

27 La PD è l elemento invocato dal SIL fruitore quando ha la necessità di usufruire di un servizio. I compiti che deve svolgere sono due : prendere in consegna la richiesta e trasformarla in un messaggio standard, conforme alle specifiche SPCoop, e viceversa, cioè far pervenire il messaggio di risposta al richiedente. La PA è invece incaricata di trasformare il messaggio, conforme alle specifiche SPCoop, in un formato conforme allo standard SOAP, e di far pervenire, quindi, la richiesta ad un SIL erogatore, ed il viceversa per la risposta. Anche in questo caso, dal punto di vista di SOA, sia la PD che la PA sono dei servizi web che inviano e ricevono messaggi da e verso altri servizi web, rappresentati dai SIL. Esempio delle porte di dominio all interno dell infrastruttura

28 Accordo di Servizio Di seguito AS, è a tutti gli effetti un contratto, in formato XML, tra fruitore ed erogatore, che definisce le modalità di erogazione e fruizione di un servizio. Le informazioni contenute in un AS sono : tipo e funzionalità del servizio schema dei messaggi di richiesta e risposta requisiti di sicurezza requisiti di qualità Ciascun AS si riferisce soltanto a due soggetti : l erogatore ed il fruitore, il che significa che se un soggetto intende usufruire di servizi messi a disposizione da vari altri soggetti erogatori, deve stipulare un AS con ciascuno di essi. A causa di questo fenomeno, la ridondanza di informazioni comuni, all interno di ciascun AS, potrebbe essere notevole, pertanto i documenti del CNIPA prevedono la suddivisione di ciascun accordo in due parti : la parte comune e la parte specifica. Nella parte comune sono riportate informazioni riguardanti il servizio, che pertanto possono essere riutilizzabili tra più accordi. La parte specifica, invece, prevede soltanto gli elementi caratteristici che differenziano ciascun accordo dagli altri, come, appunto, i soggetti erogatore e fruitore. Parte Comune Parte Specifica

29 Dal punto di vista tecnologico, un AS è composto da vari WSDL : WSDL Concettuale, WSDL Logico Fruitore e WSDL Logico Erogatore. Servizi di registro SICA Acronimo di Servizi di Interoperabilità, Cooperazione ed Accesso; sono, come dice la parola stessa, componenti che forniscono servizi di supporto alla cooperazione applicativa. Le attività che essi devono svolgere sono : la registrazione e la ricerca degli Accordi di Servizio e dei soggetti SPCoop, la gestione ed il monitoraggio dei livelli di servizio offerti, ecc. Le informazioni gestite riguardano quindi : i soggetti che operano in SPCoop i servizi erogati da tali soggetti gli accordi di servizio per l accesso ai servizi All interno dell architettura, tali componenti sono organizzati a livello gerarchico, infatti, è previsto un Registro SICA Generale, che contiene tutte le informazioni necessarie all erogazione di servizi, e più Registri SICA Secondari, che, invece, contengono parte delle informazioni contenute su quello generale. Questo approccio è stato scelto perché permette di garantire una ridondanza delle informazioni, utile nel caso in cui qualche registro non sia disponibile, ed allo stesso tempo una rapidità nell erogazione dei servizi, proprio grazie al fatto che solo una parte delle informazioni risiede su ciascun registro, snellendo quindi le attività di ricerca e registrazione. Nella specifica è previsto che ciascuna Porta di Dominio contatti il registro per ottenere informazioni circa i soggetti ed i servizi previsti nell Accordo di Servizio

30 Esempio del registro SICA all interno dell infrastruttura Busta e-gov Rappresenta il messaggio scambiato all interno dell architettura SPCoop tra PdD. Non è altro che un messaggio SOAP elaborato, cioè è un messaggio che mantiene la struttura prevista dallo standard SOAP 1.1 (un solo header ed un solo body), ma al cui interno vengono specificate informazioni aggiuntive, utili al trattamento ed all elaborazione da parte delle varie PdD. Tale busta viene generata dalle stesse porte di dominio a seguito della trasformazione del messaggio di richiesta proveniente da un SIL. Eccone un esempio : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:header> <egov_it:intestazione > <egov_it:intestazionemessaggio> <egov_it:mittente> <egov_it:identificativoparte > </egov_it:mittente> <egov_it:destinatario> <egov_it:identificativoparte > </egov_it:destinatario> <egov_it:profilocollaborazione> </egov_it:profilocollaborazione> <egov_it:servizio > </egov_it:servizio> <egov_it:azione> </egov_it:azione>

31 <egov_it:messaggio> <egov_it:identificatore> </egov_it:identificatore> <egov_it:oraregistrazione > </egov_it:oraregistrazione> </egov_it:messaggio> <egov_it:profilotrasmissione /> </egov_it:intestazionemessaggio> <egov_it:listatrasmissioni> <egov_it:trasmissione> <egov_it:origine> <egov_it:identificativoparte > </egov_it:identificativoparte> </egov_it:origine> <egov_it:destinazione> <egov_it:identificativoparte > </egov_it:identificativoparte> </egov_it:destinazione> <egov_it:oraregistrazione > </egov_it:oraregistrazione> </egov_it:trasmissione> </egov_it:listatrasmissioni> </egov_it:intestazione> </soap:header> <soap:body> </soap:body> </soap:envelope> Come si può notare, tale messaggio è specifico per il dominio SPCoop, pertanto, risulterebbe non comprensibile per i SIL. E per questo motivo che, prima di essere inoltrato, è necessario che venga trasformato in un messaggio conforme allo standard SOAP, attraverso l operazione di sbustamento. Tale operazione, assieme a quella di imbustamento, viene effettuata automaticamente dalla Porta di Dominio, nelle operazioni di inoltro dei messaggi di richiesta e di risposta, generati dai SIL, verso l infrastruttura di cooperazione applicativa. Nello specifico, il messaggio originale, viene scomposto nella parte Header e nella parte Body. Le informazioni, contenute in ciascuna sezione, vengono inserite nelle relative sezioni Header e Body di un nuovo messaggio SOAP, conforme, però, al formato della busta e-gov. Il motivo, per cui è necessario effettuare questa trasformazione, è che tale messaggio contiene informazioni aggiuntive utili al processamento dello stesso, da parte delle varie Porte di Dominio, durante il suo tragitto. Di seguito è riportata un immagine dell intera infrastruttura di cooperazione applicativa

32 Vista globale dell infrastruttura Requisiti di sicurezza del progetto Dal momento che i dati scambiati nell ambito della cooperazione applicativa sono molto sensibili, è necessario garantire elevati livelli di sicurezza riguardo la gestione degli stessi. Pertanto, in un architettura distribuita di questo genere, è obbligatorio tenere in considerazione i seguenti requisiti : Identificazione : stabilire univocamente chi sta richiedendo il servizio a cui si cerca di accedere Autenticazione : stabilire senza dubbio che chi sta richiedendo il servizio sia veramente colui che afferma di essere Autorizzazione : stabilire se il fruitore è autorizzato a richiedere lo specifico servizio

33 Integrità : garantire che non ci siano state manomissioni nelle informazioni trasmesse Confidenzialità : garantire che solo erogatore e fruitore del servizio abbiano visibilità sulle informazioni trasmesse Tracciamento : mettere in atto meccanismi che permettano di tracciare qualsiasi evento legato all erogazione/fruizione del servizio, in maniera da poter analizzare tali tracce per scoprire eventuali problemi Non ripudio : permette di provare l'identità di coloro che hanno preso parte ad una determinata transazione Secondo le specifiche SPCoop, questi requisiti sono garantiti da tutti i componenti dell infrastruttura, infatti, ad esempio, nella PdD, vengono garantiti : Identificazione Autenticazione Autorizzazione Confidenzialità Non ripudio Inoltre, durante lo scambio di messaggi sia tra le Porte di Dominio che tra SIL e Porte Delegate, vengono utilizzate tecnologie opportune, quali : HTTPS per il trasporto sicuro delle informazioni sul protocollo HTTP WS-Security per la crittografia e la firma dei messaggi SOAP (tra SIL e Porte Delegate) e delle buste e-gov (tra Porte di Dominio stesse e tra Porte di Dominio e NICA)

34 Capitolo 3 : Progetto ICAR Le specifiche di SPCoop si concretizzano attraverso il progetto ICAR, acronimo di Interoperabilità e Cooperazione Applicativa tra le Regioni. Tale progetto nasce come iniziativa, promossa dalle regioni, con il fine di rendere possibile, come dice il nome stesso, l interoperabilità e la cooperazione applicativa tra gli organi aderenti. Inizialmente vi prendono parte soltanto sedici regioni italiane ed una provincia autonoma, ma nel seguito hanno aderito anche tutte quelle rimanenti. Il coordinamento delle attività è stato assegnato al CISIS, Centro Interregionale per i Sistemi Informatici, Geografici e Statistici, che tuttora cura le attività di bootstrap dell intera infrastruttura sul territorio italiano e pianifica ulteriori sviluppi. Organizzazione del progetto Per una corretta realizzazione, il progetto è stato suddiviso in task infrastrutturali e task applicativi. I task infrastrutturali previsti sono tre e sono : INF-1 : Infrastruttura di base per la Cooperazione Applicativa Interregionale INF-2 : Gestione di Strumenti Interregionali di Service Level Agreement INF-3 : Sistema Federato Interregionale di Autenticazione Tali task sono trasversali a tutto il progetto, in quanto definiscono l infrastruttura sulla quale si baserà la cooperazione applicativa. I task applicativi, invece, sono sette, e caratterizzano specifici domini applicativi sottoforma di servizi SPCoop. Nello specifico sono : AP-1 : Cooperazioni e Compensazioni Sanitarie Interregionali AP-2 : Cooperazione tra sistemi di Anagrafe AP-3 : Area Organizzativa Omogenea

35 AP-4 : Lavoro e Servizi per l Impiego AP-5 : Tassa automobilistica regionale AP-6 : Osservatorio Interregionale sulla rete distributiva dei carburanti AP-7 : Sistema Informativo Interregionale di Raccordo con Cinsedo Di seguito è riportato uno schema dell organizzazione del progetto : Organizzazione del progetto ICAR Per ciascuno di questi task è stata individuata una regione, cosiddetta capofila, che ha il compito di sviluppare e rendere disponibile, nell architettura SPCoop, il task assegnato. Quello della Regione Basilicata è il task AP-1. OpenSPCoop La soluzione di riferimento per ICAR è rappresentata dal progetto OpenSPCoop (http://www.openspcoop.org/ ww.openspcoop.org/), un implementazione open source delle specifiche del CNIPA. Comprende tutti gli elementi architetturali, quali : Porta di dominio, Registro SICA, ecc. E una soluzione che si basa sulla piattaforma J2EE ed utilizza come server applicativo JBOSS,, sfruttandone alcune funzionalità integrate, quali le code JMS (Java Message Service) e gli MDB (Message Driven Bean) ecc. Le altre tecnologie utilizzate sono JiBX ed AXIS per la realizzazione dei

36 web service. Il componente più importante e più complesso di tutta la soluzione è la Porta di Dominio, in quanto racchiude al suo interno tutti i meccanismi alla base del funzionamento di SPCoop. Di seguito è riportato uno schema della PdD SPCoop, estratto dalla documentazione ufficiale del progetto, che mostra proprio quanto sia complesso questo componente. Architettura della Porta di Dominio OpenSPCoop Il cuore è rappresentato dal modulo di controllo, che svolge funzioni molto importanti, come, ad esempio : la gestione della sicurezza, in termini di autorizzazione e tracciamento dei messaggi in transito attraverso la PdD

37 l imbustamento delle richieste, che consiste nel trasformare il messaggio SOAP proveniente dai SIL nel formato della busta e-gov lo sbustamento delle risposte, che consiste nell attività contraria, cioè, trasformare la busta e-gov nel messaggio SOAP interpretabile dai SIL Ovviamente si interfaccia con il registro dei servizi per acquisire le informazioni necessarie al processamento delle richieste / risposte. Al fine di evitare la comunicazione punto punto tra le varie PdD, in ICAR sono stati definiti dei componenti aggiuntivi, non previsti nelle specifiche SPCoop. Tali componenti sono denominati NICA (Nodo di Interconnessione per la Cooperazione Applicativa). Si tratta di PdD evolute, il cui scopo è quello di interconnettere diversi domini cooperanti tra loro. Con l aggiunta di questo componente, l architettura di SPCoop si trasforma nella seguente : Esempio di architettura SPCoop con NICA

38 Come si può osservare dall immagine, l adozione di tali componenti ha definito una struttura gerarchica, in cui ciascuna pubblica amministrazione ha una propria PdD. Tutte le PdD appartenenti ad un dominio afferiscono ad un unico NICA, il quale si preoccupa di instradare i messaggi agli altri NICA definiti per gli altri domini. FreESBee Si tratta di un progetto open source, alternativo ad OpenSPCoop, che nasce nel 2007, a seguito di una convenzione stipulata tra la Regione Basilicata e l Università degli studi della Basilicata (http://freesbee.unibas.it/). L obiettivo del progetto è quello di re implementare le specifiche definite dal CNIPA, attraverso soluzioni architetturali più snelle ed efficienti di quelle utilizzate per lo sviluppo di OpenSPCoop, in modo da rendere tutta l architettura di cooperazione più snella e leggera. Dal punto di vista tecnologico, infatti, FreESBee utilizza come server applicativo Apache Tomcat, come tecnologie per il trasporto dei messaggi : ESB (Enterprise Service Bus), mentre per l elaborazione e l interfacciamento ai SIL attraverso i web service : CXF ed i componenti EIP (Enterprise Integration Pattern). Proprio grazie a questi ultimi, che rappresentano uno strumento innovativo sia nell ambito della progettazione che in quello dello sviluppo, è stato possibile riprogettare gli elementi dell architettura in maniera abbastanza rapida ed efficace. Il motivo di ciò deriva dal fatto che gli EIP definiscono una serie di pattern che rappresentano dei componenti elementari, una sorta di mattoncini LEGO, che possono essere collegati l un l altro. Ovviamente tali pattern definiscono soltanto una struttura scheletro, al cui interno dev essere implementato il codice che permette di svolgere le funzionalità richieste. Ciascuno degli elementi, da un punto di vista logico, è rappresentato da un simbolo grafico; ciò significa che una volta collegati tra di loro, si può ottenere

39 anche una rappresentazione grafica dell architettura realizzata, utilizzabile a scopo di documentazione. E secondo questi principi che è stata rivista e realizzata l implementazione della PdD e degli altri componenti dell architettura SPCoop. Ecco di seguito lo schema della PdD di freesbee riconcettualizzata : Vista globale della Porta di Dominio di FreESBee Invio di una richiesta / risposta Nell immagine viene illustrato il percorso fatto da un messaggio di richiesta / risposta inviato da un SIL alla propria Porta di Dominio. Vengono descritti macroscopicamente i pattern che la compongono, no, senza entrare nel merito dei moduli di imbustamento e sbustamento, che a loro volta sono stati completamente riconcettualizzati

40 Di seguito, invece, è riportato lo schema che descrive, sempre macroscopicamente, il percorso fatto dal messaggio precedente, quando arriva alla Porta di Dominio, per l inoltro della risposta al SIL richiedente, oppure della richiesta al SIL erogatore. Vista globale della Porta di Dominio di FreESBee Inoltro della risposta / richiesta Come nella soluzione SPCoop, anche in FreESBee,, il cuore di tutta la Porta di Dominio è rappresentato dai moduli di imbustamento e sbustamento. Non a caso nelle immagini precedenti, tali moduli sono stati raffigurati come semplici blocchi all interno della PdD. In realtà essi hanno richiesto il maggior lavoro di riconcettualizzazione in termini di pattern EIP. Di seguito sono riportati gli schemi di dettaglio sia del modulo di imbustamento che di quello di sbustamento

41 Vista di dettaglio dei moduli di imbustamento e sbustamento della PdD di FreESBee

42 Vista globale della Porta di Dominio di FreESBee Invio di una richiesta / risposta A differenza dell immagine utilizzata per descrivere la PdD di OpenSPCoop, il ruolo svolto da ciascun componente è reso, chiaramente, dal simbolo, dal nome e dalla descrizione definita per ciascun pattern. Questa è la dimostrazione del fatto che l utilizzo di tali soluzioni può essere anche utile per fini di documentazione, facilmente interpretabile e comprensibile, senza la necessità di ricorrere alla stesura di documenti il più delle volte non chiari. Alla fine dei lavori, seguendo sempre questi stessi principi, sono stati realizzati i tre moduli software conformi alle specifiche dei rispettivi task infrastrutturali (INF-1, INF-2 ed INF-3), il test dell intera architettura e lo sviluppo di un sistema per la simulazione dei SIL

43 Capitolo 4 : Task INF-3 e relative implementazioni Il task infrastrutturale INF-3, nel progetto ICAR, prevede la realizzazione del Sistema Federato Interregionale di Autenticazione, con conseguente implementazione del paradigma di Single Sign On (SSO), che prevede, una volta effettuata l autenticazione sul dominio, l accesso a più risorse, senza dover ogni volta autenticarsi per ciascuna di esse. La regione capofila incaricata di ciò è il Piemonte, che ha definito una serie di specifiche, e rilasciato la Reference Implementation, di un sistema basato sulla gestione ed utilizzazione delle identità digitali all interno del dominio di cooperazione. Per ciò che riguarda la documentazione prodotta, sono stati definiti : Un modello logico di riferimento dell infrastruttura interregionale di autenticazione ed autorizzazione Un modello architetturale di riferimento del sistema federato interregionale di autenticazione Una serie di specifiche che descrivono le interfacce interne ed esterne Una cosa molto importante da precisare è che nell ambito dello scambio di informazioni tra PdD, attraverso buste e-gov, si assume di disporre di un canale protetto, sicuro ed affidabile, in quanto INF-3 prescinde da questo, e si posiziona al livello superiore, garantendo i meccanismi per la cooperazione inter dominio; mentre, al livello ancora superiore, i servizi cooperano in maniera del tutto trasparente

44 Di seguito è riportato uno schema che mostra la pila infrastrutturale di ICAR appena descritta : Pila infrastrutturale di ICAR I componenti dell architettura Un ruolo fondamentale all interno del task è rappresentato dalle Autorità di certificazione, componenti dell architettura a cui, per definizione, può essere data fiducia da parte di altre entità coinvolte nel processo di cooperazione, circa la veridicità delle informazioni prodotte. Quelle più importanti in ICAR sono prevalentemente tre : Profile Authority : sono i componenti incaricati di gestire i profili degli utenti. Questo perché ciascun utente può possedere diversi profili, come, ad esempio, il profilo di impiegato del comune, attraverso il quale può accedere alle procedure interne per la risoluzione di pratiche, oppure, il profilo di cittadino, per accedere ai servizi per i cittadini messi a disposizione sempre dal comune Certification Authority : sono i componenti che certificano l identità di un

45 utente, previa autenticazione attraverso diverse tipologie di credenziali, come : nome utente e password, oppure codice fiscale e PIN ecc. Attribute Authority : sono i componenti che certificano gli attributi contenuti nel profilo di un utente. Tali attributi vengono utilizzati durante il processo di verifica dell autorizzazione all accesso ad una risorsa. Un esempio di attributi sono : la mansione svolta, l organizzazione presso cui si lavora, il titolo di studio ecc. Il formato delle informazioni rilasciate da tali autorità è conforme allo standard SAML 2.0, pertanto, per convenzione, esse vengono definite asserzioni. Ovviamente, proprio perché rilasciate da un entità certificata e non da un elemento qualunque, esse sono considerate attendibili. Affinché un entità di certificazione sia attendibile, ed evitare fenomeni secondo cui, una qualunque autorità possa certificare qualsiasi attributo, è obbligatorio, da parte dell ente certificatore, apporre la propria firma digitale sugli attributi da esso rilasciati. Questo però non basta, in quanto è stata prevista l esistenza di un organismo super partes, esterno al dominio, definito Garante, che è considerato a sua volta affidabile da parte delle varie autorità, e che appone anche la sua firma sulle certificazioni rilasciate, al fine di avere un più elevato livello di sicurezza

46 Organizzazione delle varie autorità e relazioni con il Garante Altri due componenti importanti all interno dell architettura di INF-3 3 sono lo User Agent ed il Service Provider. Provider Il primo rappresenta gli utenti che interagiscono con il sistema, tipicamente un browser web, mentre il secondo rappresenta un generico fornitore di servizio, nonché l elemento a cui spetta il compito di verificare se le informazioni fornite per l accesso / erogazione del servizio sono coerenti e conformi ai requisiti di sicurezza stabiliti. Per la verifica dell autenticazione ed autorizzazione, tale componente si avvale dell ausilio di altri due componenti, l Access l Manager (o Local Proxy) ed il Gestore delle Politiche di Autorizzazione. Autorizzazione. Il primo ha il compito di accedere alle varie autorità di certificazione, per ottenere la certificazione degli attributi giunti assieme alla richiesta; il secondo, invece, ha il compito di verificare che tali attribuiti siano s conformi ai requisiti richiesti per l erogazione del servizio. Ovviamente all interno

47 dell infrastruttura è presente un registro, accessibile da tutte le comunità federate, che contiene l URL delle varie PA, CA e AA. Lo scenario di riferimento Lo scenario di riferimento definito dalle specifiche è il seguente : tutto ha origine attraverso lo User Agent (in seguito UA), che richiede una risorsa al Service Provider (in seguito SP) il quale, come prima cosa controlla se lo UA è autenticato. Qualora non lo fosse, invia una richiesta di autenticazione al Local Proxy (in seguito LP), il quale a sua volta la rigira allo UA. A questo punto lo UA introduce le proprie credenziali e specifica qual è la Profile Authority (in seguito PA) desiderata. Tale risposta viene così inoltrata al LP, il quale interroga il registro per conoscere la URL della PA. Ottenuto l URL, il LP interroga la PA per ottenere il nome della Certification Authority (di seguito CA) scelta dall utente. Come prima, il LP interroga il registro per risolvere la URL della CA, ed una volta ottenuta l informazione, inoltra a quest ultima una richiesta di autenticazione, con la quale la CA inizia con lo UA la cosiddetta challenge di autenticazione. Al termine di questa fase il LP avrà acquisito un asserzione generata dalla CA che invia allo UA il quale a sua volta la gira al SP. A questo punto l utente è autenticato e il SP è in possesso della relativa asserzione. Lo scenario procede con la verifica dell autorizzazione. Il SP, come prima cosa, controlla se UA è autorizzato per l accesso alla risorsa richiesta, e supponiamo che non lo sia. Come per l autenticazione, il SP invia una richiesta al LP, il quale determina quale sia la PA che contiene il profilo utente. Quest azione può essere compiuta in due modi : mantenendo una cache delle informazioni recuperate durante la fase di autenticazione, oppure richiedendo allo UA, durante l operazione di autenticazione, di specificare qual è la PA da cui desidera farsi rilasciare gli attributi. Il LP chiede quindi alla PA il profilo dell utente ed interroga il registro per conoscere l URL della / delle Attribute Authority (di seguito AA) specificate

48 nel profilo selezionato. A questo punto il LP richiede alle AA gli attributi per lo UA, e queste gli restituiscono le asserzioni con i relativi attributi. Il LP estrae le asserzioni e le invia al SP. Quest ultimo, ricevute le asserzioni, le valida rispetto alle politiche iche di accesso definite per il servizio, e se risultano essere coerenti, fornisce la risorsa richiesta. L immagine seguente mostra l interazione tra i vari componenti finora descritti : Interazioni nello scenario di riferimento di INF-3 Nel gergo di INF-3, l insieme di asserzioni raccolte dal LP, prende il nome di portafoglio di asserzioni. Lo scenario nella cooperazione applicativa Lo scenario di riferimento precedentemente descritto rimane inalterato anche nell ambito dell interazione in cooperazione applicativa, infatti, prima di effettuare una richiesta, si assume che il modello di INF-3 abbia acquisito il

49 portafoglio delle asserzioni relative all utente richiedente, in termini di identità ed attributi, ed inserito tale elemento nella richiesta rivolta alla PdD. Una volta che tale richiesta è giunta a destinazione, essa risulta essere completa di tutte le informazioni necessarie per la verifica e l autorizzazione all accesso delle risorse. Il fatto di avere il portafoglio delle asserzioni completo all interno della stessa richiesta è un vantaggio notevole, in quanto non è necessario, in fase di verifica, prima dell erogazione del servizio, consultare ulteriori autorità per sopperire ad eventuali dati mancanti. In questo modo si raggira il problema secondo cui, le stesse autorità, per poter fornire le informazioni richieste a causa di dati mancanti, hanno bisogno a loro volta di verificare icare l autenticazione e l autorizzazione del richiedente, ma quest ultimo potrebbe non avere i privilegi sufficienti per accedere a tali informazioni, che riguardano, quindi, un soggetto appartenente ad un dominio diverso, ottenendo così lo spiacevole risultato di non poter erogare il servizio. Di seguito viene riportata una rappresentazione di tale scenario : Scenario di integrazione di INF-3 all interno di SPCoop

50 Come al solito tutto lo scenario lo innesca lo UA, che contatta un Service Provider del dominio richiedente (di seguito SP DR ), che in questo caso rappresenta il front-end con cui lavora l operatore. Quest ultimo accede all infrastruttura di autenticazione e autorizzazione del proprio dominio per verificare che l utente abbia diritto all accesso. Per fare questo interroga il componente GPA DR, che accede al profilo del servizio e passa il controllo al LP DR, che a sua volta contatta i vari certificatori, costruisce il portafoglio delle asserzioni e lo restituisce al GPA DR. Il GPA DR, sulla base delle informazioni contenute nel portafoglio, può effettuare il policy enforcement ed abilitare l utente all accesso al SP DR, a cui trasmette l intero portafoglio delle asserzioni. Il messaggio giunge così alla PdD DR, e da questa alla PdD DE (dominio erogatore). Per il transito tra la PdD DR e la PdD DE il messaggio viene dapprima criptato e firmato, rispettando lo standard WS-Security, e successivamente affidato al livello infrastrutturale INF-1 per il trasporto su canale sicuro HTTPS. Una volta giunto alla PdD DE, il messaggio viene prima decriptato, verificata la firma, e se è valido viene inoltrato al SP DE. Quest ultimo richiede al sistema federato di autenticazione e autorizzazione INF- 3 un controllo sull identità e sul ruolo del richiedente, passando il portafoglio delle asserzioni al GPA DE, il quale effettua il policy enforcement utilizzando le asserzioni contenute nel portafoglio giunto assieme alla richiesta. Dal momento che gli attributi sono controfirmati dal Responsabile del Dominio di Cooperazione, il GPA DE attribuisce il corretto valore e fiducia ad essi. A questo punto, se i dati ricevuti lo consentono, il GPA DE comunica a SP DE che il richiedente è abilitato ad usufruire del servizio. Per come è strutturata l architettura, ora il richiedente di SP DE è il SP DR e non più lo UA. Ciò significa che nel portafoglio delle asserzioni ricevuto, il policy enforcement sarà effettuato sulle asserzioni relative a SP DR

51 Eseguito il servizio, ha ora inizio l interazione del flusso dei messaggi di risposta, ovviamente nella direzione opposta a quella attualmente descritta, ma secondo le stesse modalità, facendo infine pervenire tale risposta allo UA che ha avviato l interazione. Tecnologie di riferimento Riguardo alle tecnologie utilizzate per la realizzazione del task, nelle specifiche si fa riferimento a : standard SAML 2.0 per l incapsulamento del portafoglio di asserzioni nel messaggio SOAP standard XACML per la verifica e la validazione dei requisiti di autorizzazione rispetto alle politiche di accesso ai servizi standard WS-Security per la crittografia dei dati e la firma dei messaggi inviati Reference Implementation L implementazione di riferimento del task INF-3 (di seguito RI) è stata rilasciata dalla regione Piemonte a maggio del Essa è conforme alle specifiche SAML 2.0, pertanto prevede l interazione con tutte le entità classiche di una federazione basata su tale standard, che, come già detto precedentemente, sono: Profile Authority (PA) Identity Provider (IdP) Attribute Authority (AA) Service Provider (SP) Da notare che tale RI non fornisce queste autorità, in quanto assume che ciascun dominio sia già in possesso delle stesse. Inoltre, coerentemente con quanto

52 definito nelle specifiche ICAR, sono state implementate due nuove entità, che sono : il Local Proxy (LP) e l Authority Registry (AR). L unico componente visto finora, che nella terminologia di SAML assume una denominazione differente, è l Identity Provider. Con tale nome, infatti, si intende fare riferimento alla Certification Authority che rilascia le attestazioni sull identità degli utenti. E stato ampliamente trattato e descritto in precedenza il compito svolto dal LP, mentre risulta completamente nuovo il ruolo dell AR. Essa è l entità, di cui si è brevemente parlato prima, accessibile da tutte le federazioni, che mantiene il registro con gli URL delle varie PA, IdP ed AA. Grazie all introduzione del componente LP, ed al fatto che tale implementazione è conforme allo standard SAML 2.0, è possibile avere l interazione tra la RI ed altre soluzioni, siano esse open source o commerciali, che forniscono le autorità necessarie alla realizzazione di un sistema federato. Questa è una cosa voluta, sia per non vincolare la scelta delle autorità ad una particolare soluzione, permettendo quindi ai singoli domini di utilizzare le authority che risultano essere più idonee alle specifiche esigenze; sia perché, allo stato attuale, alcuni domini possono essere già provvisti di tali elementi, il che significa quindi che è già possibile operare in un ambiente federato, senza dover modificare o adattare alcunché, rendendo così indolore l adozione del sistema di autenticazione ed autorizzazione federato per l accesso alla cooperazione applicativa. Purtroppo, il punto cruciale di tutta l architettura è rappresentato proprio dalle authority, infatti è su di esse che si basa tutto il funzionamento del task INF-3. Come già detto, nella Reference Implementation si assume che ciascun dominio sia già provvisto di tali entità, tuttavia, per fornire una implementazione funzionante, sono state rilasciate anche delle authority giocattolo, senza alcun

53 valore legale, che simulano il funzionamento delle corrispettive reali. Sono inoltre stati allestiti degli esempi, che mostrano il funzionamento dell architettura fin qui descritta. Di seguito sono riportati degli screenshot dell esempio predisposto nella RI : Servizi resi dal Service Provider di esempio della Reference Implementation

54 Esempio di inserimento delle credenziali e scelta del profilo

55 Tecnologie di riferimento La Reference Implementation è stata rilasciata sotto licenza open source. Dal punto di vista tecnologico, è stata realizzata utilizzando la piattaforma Java JDK 1.5 ed il framework, anch esso open source, OpenSAML 2.0 (http://www.opensaml.org). Come server applicativo è stato utilizzato Tomcat , mentre, per le interfacce di esempio, la tecnologia JSF (Java Server Faces). Integrazione nell architettura SPCoop Il punto debole della Reference Implementation di INF-3 è rappresentato dal fatto che è impossibile effettuare dei test con gli esempi forniti a corredo del rilascio, in quanto questi sono statici, cioè, possono essere eseguiti soltanto così come vengono forniti, non è possibile apportare nessuna modifica, se non quelle che riguardano gli attributi degli utenti registrati sulle finte authority. Questo pone un vincolo non banale, sia alla comprensione del funzionamento dell interazione tra i vari task infrastrutturali, e tra questi ed i task applicativi, sia alla sperimentazione dell intera infrastruttura di cooperazione applicativa, in quanto, se non previsti, non possono essere aggiunti dinamicamente altri componenti, come SP, IdP ecc. Ciò significa, quindi, che per avere l implementazione di INF-3 realmente funzionante, è necessario modificare i SIL in modo tale che implementino la logica del SP, e siano così in grado di acquisire il portafoglio di asserzioni, prima dell invio di una richiesta di esecuzione di un servizio, oppure di validarlo prima di generare la risposta relativa. Ciò significa che una reale sperimentazione di tutta l architettura ICAR potrà essere fatta soltanto quando tali modifiche saranno effettuate, il che richiederà qualche anno, in quanto i SIL in questione, soprattutto nel caso della pubblica amministrazione, sono i sistemi informativi su cui si basano tutte le procedure burocratiche ed amministrative che governano l ente, il cui processo di modifica non è una cosa banale e soprattutto rapida

56 FreESBee-SP Nell ambito del progetto FreESBee, il componente che si occupa di implementare le specifiche dettate da ICAR, per la realizzazione del sistema federato di autenticazione, è FreESBee-SP. Come per la Reference Implementation, ovviamente, l utilizzo di tale modulo è subordinato alla realizzazione di un infrastruttura di authority, con le quali esso interagisce, per l acquisizione delle informazioni che permettono di descrivere l utente. La differenza, come si vedrà più avanti, è data dal fatto che viene fornita un implementazione reale di tali componenti, ovviamente senza nessun valore legale, in modo da poter effettuare una sperimentazione sul campo dell intera infrastruttura federata. Dal punto di vista logico, tale soluzione è un wrapper, che agisce come intermediario tra i SIL e la porta di dominio, ed è in grado di comunicare con i primi, in maniera interattiva oppure in maniera automatica. Nel primo caso, richiedendo esplicitamente le credenziali all utente, mentre, nel secondo caso, specificando opportuni parametri nella query string. Grazie a questo meccanismo, FreESBee-SP si presta molto bene ad essere utilizzato sia nella fase di fruizione, che in quella di erogazione di un servizio, infatti, dal lato fruitore, si occupa della raccolta delle informazioni circa l identità del richiedente e del relativo portafoglio di asserzioni; dal lato erogatore, invece, si occupa della validazione di tali informazioni, rispetto alle policy definite per l accesso e/o erogazione di ciascun servizio. Tali policy vengono dichiarate nella parte specifica dell accordo di servizio, che a sua volta risiede sul NICA. E perciò con tale componente, più precisamente con il registro dei servizi, che FreESBee-SP collabora per l acquisizione delle policy e la validazione del portafoglio di asserzioni

57 Quanto appena detto è riassunto nello schema seguente : Integrazione di FreESBee-SP nell architettura SPCoop La posizione, ricoperta da tale modulo, offre il duplice vantaggio di : lasciare inalterati i sistemi informativi già abilitati all interazione attraverso web service, rendendo quindi immediato lo start-up dell infrastruttura federata modificare i sistemi già presenti, non abilitati all interazione attraverso web service, prescindendo dalle problematiche proprie del componente service provider, e quindi dalla la raccolta e validazione degli attributi In entrambi i casi il tutto si trasforma in un risparmio, in termini sia di tempo che di costi di sviluppo / adattamento

58 Come strumenti di supporto a FreESBee-SP, sia per il test che per la realizzazione del sistema federato, si è ricorso ad altri due progetti open source : SIL-VIO e Shibboleth. Progetto SIL-VIO SIL-VIO è l acronimo di Sistema Informativo Locale Virtuale per l InterOperabilità. Nasce nell ambito del progetto FreESBee come strumento di test open source per l architettura SPCoop, con l obiettivo di simulare il tipico funzionamento di un SIL. Per tale motivo, quindi, l architettura di SIL-VIO è stata sviluppata per essere modulare, e permetterne l utilizzo in vari scenari applicativi. Attraverso questo strumento è infatti possibile simulare i più disparati sistemi, da quelli legacy, fino a quelli più avanzati. Il punto di forza su cui si basa è un articolato motore di trasformazioni che, a partire dai dati, è in grado di generare un messaggio SOAP di richiesta conforme alle specifiche; e viceversa, cioè, data una richiesta, effettuare delle operazioni (come una interrogazione o un inserimento nel DB) e produrre la relativa risposta. I dati per la generazione della richiesta possono essere sere forniti in modo differente: prelevati automaticamente da un DB attraverso una query richiesti interattivamente all utente dichiarati come costanti Eccone uno schema : Schema della generazione di un messaggio SOAP di richiesta

59 Schema della generazione di un messaggio SOAP di risposta Seguendo la linea di sviluppo con cui è stato implementato il progetto FreESBee, anche in questo caso è stato utilizzato l approccio di EIP, per la realizzazione delle operazioni che portano alla creazione di un messaggio di richiesta, all elaborazione, ed alla produzione produz del messaggio di risposta. Ecco di seguito la rappresentazione dell architettura con cui è stato concepito SIL-VIO : Pattern EIP nell architettura di SIL-VIO

60 Progetto Shibboleth Shibboleth è un progetto open source sviluppato dal consorzio Internet2 (http://shibboleth.internet2.edu/). L obiettivo per cui è nato è quello di permettere la condivisione e l accesso, attraverso meccanismi di Single Sign On, ai contenuti didattici riservati ed a pagamento, messi a disposizione dalle università. Con il tempo si è evoluto, e grazie all adozione di standard quali SAML per l identificazione e l accesso, si è rivelato utile anche in altri contesti. Ad oggi, infatti, risulta essere una soluzione di riferimento, una sorta di standard de facto, soprattutto nel campo della pubblica amministrazione. Tale soluzione è del tutto conforme con le specifiche di ICAR, in quanto prevede l interazione con vari tipi di componenti, quali : l Identity Provider, il Service Provider e lo User Agent. E inoltre previsto un altro servizio, cosiddetto, WAYF (Where Are You From), che si occupa della ricerca degli attributi tra le varie authority, in base al profilo che l utente ha scelto di utilizzare. Ovviamente questi componenti sono tutti reali ed indipendenti l uno dall altro; l interazione tra essi è descritta dalla seguente immagine : Interazione tra i componenti di Shibboleth

61 Per ciò che riguarda l Identity Provider, può essere configurato per accettare modalità di autenticazione di tipo Basic; basata su database relazionali; su directory LDAP o interfaccia web. L Attribute Authority, invece, può essere configurata solamente per acquisire informazioni da una directory LDAP, da cui prelevare gli attributi definiti per l utente. FreESBee-SP si interfaccia con Shibboleth per gestire tutto il meccanismo di autenticazione ed acquisizione del portafoglio di asserzioni. Per la precisione, interagisce principalmente con il componente SP, che, in riferimento alle specifiche ICAR, ingloba al suo interno il funzionamento sia del Local Proxy che del Service Provider stesso. Il punto di forza di tale soluzione è che il SP è in grado di interfacciarsi a qualsiasi Identity Provider ed Attribute Authority, purché queste siano conformi allo standard SAML. Grazie a questo approccio, ed al fatto che le componenti sono tutte indipendenti, è possibile supporre vari scenari : usare soltanto il componente SP qualora i domini siano già in possesso di proprie authority implementare una propria authority, opportunamente certificata, basata su IdP e AA di Shibboleth adottare IdP e AA di Shibboleth per soli scopi di test Quest ultima ipotesi è stata utilizzata allo scopo di testare il funzionamento di tutta l architettura ICAR. Scenario in cooperazione applicativa Fino ad ora è stato solo descritto il funzionamento di FreESBee-SP, l interazione che ha con i moduli degli altri progetti e dove esso si posiziona all interno dell architettura ICAR / SPCoop. Di seguito viene analizzato un classico scenario

62 di utilizzo in cooperazione applicativa. Per una migliore comprensione, tale scenario, è suddiviso in due fasi : la generazione di una richiesta da parte del dominio fruitore la verifica delle autorizzazioni e relativa erogazione del servizio nel dominio erogatore Prima di passare alla descrizione viene riportato di seguito lo schema di riferimento con le relative interazioni nel dominio fruitore : Schema delle interazioni nel dominio fruitore Come già detto in precedenza, l avvio del caso d uso di richiesta di erogazione di un servizio, può essere effettuato interattivamente, da parte di un utente che agisce su un sistema informativo, oppure, automaticamente, da parte del sistema informativo stesso, per completare una certa elaborazione. Con FreESBee-SP SP è possibile eseguire entrambe le modalità, tuttavia, per

63 differenziare l una dall altra si è scelto di utilizzare come terminologia : utente quando il caso d uso viene avviato da un utente ed eseguito interattivamente, altrimenti, agente, quando il caso d uso viene avviato da un sistema informativo ed eseguito in modalità automatica. In entrambi i casi, il passaggio dall applicazione del SIL a FreESBee-SP, e viceversa, avviene attraverso il meccanismo dei redirect. E ovvio che in base alla modalità scelta, è necessario fornire a FreESBee-SP informazioni differenti, in quanto anche le operazioni che deve eseguire sono diverse. Se si utilizza la modalità utente, per accedere all interfaccia per l inserimento delle credenziali, è necessario fornire opportuni parametri attraverso la query string, che sono : Modalità di autenticazione (UTENTE / AGENTE) L URI di destinazione, cioè l URI a cui FreESBee-SP deve redirigere l utente a seguito della raccolta del portafoglio di asserzioni L ID della sessione avviata sul SIL a cui riagganciarsi dopo aver raccolto il portafoglio L URI della risorsa protetta a cui si intende accedere Un esempio di richiesta inviata dal SIL a FreESBee-SP è il seguente : https://hostfreesbeesp:8443/freesbeesp/schermologin.faces?autenticazione=u TENTE&uriDiDestinazione=/silvio/eseguiIstanzaOperation.faces&silSessionId=05 B99142ACD21DD9CC76124DA5FB5AAE&risorsa=https://sp.example.unibas.org/ PD_PUBBLICAZIONE_VARIAZIONE_ANAGRAFICA/ A questo punto l utente può inserire le proprie credenziali effettuando così l accesso al meccanismo di SSO

64 Esempio di procedura di login per l acquisizione del portafoglio di asserzioni FreESBee-SP estrae dai parametri ricevuti attraverso la query string l URI della risorsa protetta a cui si vuole accedere, ed assieme alle credenziali, inoltra la richiesta al componente SP di Shibboleth, come se fosse lui a richiederlo in prima persona. Il SP di Shibboleth, attraverso il LP interno, e se configurato, con l ausilio del servizio WAYF, si incarica di raccogliere il portafoglio di asserzioni e farlo validare al SP. Quest ultimo, in base alle politiche definite per l accesso al servizio, può decidere se autorizzare l erogazione o meno. La decisione presa dal SP viene rimandata all utente, che, in caso di mancanza di requisiti, vedrà un messaggio che lo informa di ciò, altrimenti, sarà automaticamente rediretto sul sistema informativo del SIL per continuare ad eseguire il caso d uso. In caso di esito positivo, cioè se l utente è correttamente autenticato ed autorizzato ad accedere ad un servizio, FreESBee-SP mantiene, per suo conto, il portafoglio di asserzioni acquisito durante il primo accesso, in modo che, per accessi successivi

65 non sarà necessario fornire nuovamente le credenziali. Ovviamente, tali informazioni, vengono mantenute per un periodo di tempo limitato alla durata della sessione avviata dal SIL su FreESBee-SP. Esempio di portafoglio di asserzioni acquisito correttamente Nella redirezione verso l applicazione del SIL, anche FreESBee-SP invia dei parametri attraverso la query string, che sono : freesbeespsessionid e jsessionid. Il primo verrà descritto più avanti, mentre il secondo serve all applicazione per recuperare la sessione precedentemente avviata con l utente. Un esempio di redirect da FreESBee-SP all applicazione SIL è il seguente : https://hostsilvio:8443/silvio/eseguiistanzaoperation.faces;jsessionid=05b99142 ACD21DD9CC76124DA5FB5AAE?freesbeeSPSessionId=5R2821R6WGHQ76O9YC H6JJ1FA4FB4ETI

Progetto SIRPE De-materializzazione delle prescrizioni. Servizi personalizzati della CIL

Progetto SIRPE De-materializzazione delle prescrizioni. Servizi personalizzati della CIL Pag. 1 di 17 Progetto SIRPE De-materializzazione personalizzati CIL per la cooperazione Versione 1.0 INDICE Pag. 2 di 17 1 INTRODUZIONE 4 1.1 Scopo del documento 4 1.2 Riferimenti 4 2 GENERALITÀ 4 2.1

Dettagli

l identità digitale federata nel progetto ICAR

l identità digitale federata nel progetto ICAR l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza INTEROPERABILITÀ E COOPERAZIONE APPLICATIVA Informatizzazione dell iter procedurale e dei controlli

Dettagli

La sicurezza nel Sistema Pubblico di Connettività Prima parte

La sicurezza nel Sistema Pubblico di Connettività Prima parte La sicurezza nel Sistema Pubblico di Connettività Prima parte Ing. Gianfranco Pontevolpe Responsabile Ufficio Tecnologie per la sicurezza Centro Nazionale per l Informatica nella Pubblica Amministrazione

Dettagli

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni Alcune considerazioni nell ambito di un sistema di cooperazione informatico che preveda lo scambio di dati tra due o più organizzazioni. Quando parliamo di un sistema di cooperazione informatico ci riferiamo

Dettagli

RILEVAZIONE PRESENZE SPECIFICHE TECNICHE COLLOQUIO

RILEVAZIONE PRESENZE SPECIFICHE TECNICHE COLLOQUIO 1)d ALLEGATO 14 RILEVAZIONE PRESENZE SPECIFICHE TECNICHE COLLOQUIO TRA IL SISTEMA INFORMATICO DEL COMUNE ED IL SISTEMA INFORMATICO DELLA SOCIETA PREPOSTA AL SERVIZIO DI REFEZIONE vers. 2.2 Indice 1. SCOPO

Dettagli

Service Oriented Architectures (SOA)

Service Oriented Architectures (SOA) Facoltà di Ingegneria dell Informazione Laurea Specialistica in Ingegneria Informatica Facoltà di Ingegneria dei Sistemi Laurea Magistrale in Ingegneria Biomedica Dipartimento di Elettronica e Informazione

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE EGIDIO PICERNO POTENZA 9 LUGLIO 2010 Interoperabiltà è la capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto

Dettagli

Logo Cliente o Partner Un modello di sicurezza per servizi bancari!

Logo Cliente o Partner Un modello di sicurezza per servizi bancari! SECurity Logo Cliente o Partner Un modello di sicurezza per servizi bancari! Agenda La società SEC Servizi Presentazione generale Numeri chiave e Clienti Il modello di Sicurezza di SEC Servizi Access Control

Dettagli

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE Pag. 1 di 11 VERIFICHE E APPROVAZIONI VERSIONE REDAZIONE CONTROLLO AUTORIZZAZIONE APPROVAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA V01 Mauro Pavese 17/05/12 Mauro Pavese 29/11/2012 STATO DELLE VARIAZIONI

Dettagli

INF-1: Specifiche Tecniche di Interfaccia

INF-1: Specifiche Tecniche di Interfaccia INF-1: Specifiche tecniche di Interfaccia INF-1: Specifiche Tecniche di Interfaccia Versione 1.1 Nome doc.: INF-1 Specifiche Interfaccia v1.0.doc Edizione: 1.0 Data emissione: 12/1/2007 INDICE Modifiche

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza SISTEMA FEDERATO DI AUTENTICAZIONE Informatizzazione dell iter procedurale e dei controlli relativi

Dettagli

QUALIFICAZIONE DELLA PORTA DI DOMINIO

QUALIFICAZIONE DELLA PORTA DI DOMINIO QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA Versione 1.0 Qualificazione della Porta di INDICE 1. PROCESSO DI QUALIFICAZIONE DELLA PORTA DI DOMINIO IN MODALITÀ PROVVISORIA 3 2. DESCRIZIONE

Dettagli

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4

Manuale Gestione di OpenSPCoop 1.4 i. Manuale Gestione di OpenSPCoop 1.4 i Manuale Gestione di OpenSPCoop 1.4 ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Prerequisiti per la Configurazione della Porta di Dominio 1 2.1 Verifica dell applicazione di gestione

Dettagli

PROGETTO TESSERA SANITARIA WEB SERVICE CMS ATTIVAZIONE E REVOCA TS-CNS IN INTEROPERABILITA FRA CARD MANAGEMENT SYSTEM

PROGETTO TESSERA SANITARIA WEB SERVICE CMS ATTIVAZIONE E REVOCA TS-CNS IN INTEROPERABILITA FRA CARD MANAGEMENT SYSTEM PROGETTO TESSERA SANITARIA WEB SERVICE CMS ATTIVAZIONE E REVOCA TS-CNS IN INTEROPERABILITA FRA CARD Pag. 2 di 14 INDICE 1. INTRODUZIONE 4 2. DESCRIZIONE DEL SERVIZIO DI RICHIESTA DI ATTIVAZIONE E REVOCA

Dettagli

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE Flavia Marzano marzano@cibernet.it 10/05/2004 ARPA Club Forum PA 2004 Contenuti Cenni normativi Sistema di gestione documentale:

Dettagli

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana UNIVERSITÀ DI PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Tecnologie Informatiche Tesi di Laurea Specialistica OpenSPCoop: un implementazione della Specifica

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 Prerequisiti per

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Piattaforma STS. Specifiche Tecniche. Versione 1.1

Piattaforma STS. Specifiche Tecniche. Versione 1.1 Piattaforma STS Specifiche Tecniche Versione 1.1 Questo documento contiene informazioni proprietarie e riservate di Dedalus SpA Nessuna parte di questa pubblicazione può essere riprodotta, trasmessa, trascritta,

Dettagli

ASPETTI DI SICUREZZA NELLA

ASPETTI DI SICUREZZA NELLA ASPETTI DI SICUREZZA NELLA COOPERAZIONE TRA I SERVIZI Versione 1.0 INDICE 1. PREFAZIONE...3 1.1. Autori... 3 1.2. Modifiche Documento... 3 1.3. Riferimenti... 4 1.4. Acronimi e Definizioni... 4 2. OBIETTIVI

Dettagli

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop i Tutorial di configurazione e programmazione di OpenSPCoop ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Introduzione 1 2 Ambiente di sviluppo 1 3 Presentazione degli scenari di esempio 2 4 Comunicazione

Dettagli

Visione Generale. Versione 1.0 del 25/08/2009

Visione Generale. Versione 1.0 del 25/08/2009 Visione Generale Versione 1.0 del 25/08/2009 Sommario 1 Premessa... 4 2 Le componenti applicative... 6 2.1 Porta di dominio... 7 2.2 Infrastrutture per la cooperazione... 9 2.2.1 Registro degli Accordi

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

Dettagli

A2A Specifiche Web Services

A2A Specifiche Web Services A2A Specifiche Web Services Contenuti 1 CONTENUTI...1 1 INTRODUZIONE...3 2 UPLOAD SEGMENTATO...5 2.1 RICHIESTA UPLOAD SEGMENTATO...5 2.1.1 Input del WS...5 2.1.2 Output del WS...6 2.2 UPLOAD SEGMENTATO...7

Dettagli

Web Service SOAP e WSDL. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

Web Service SOAP e WSDL. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com Web Service SOAP e WSDL Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com SOAP Originariamente: Simple Object Access Protocol E poi evoluto in un Framework per lo scambio di messaggi in XML 2

Dettagli

Governance e linee guida tecnicoorganizzative

Governance e linee guida tecnicoorganizzative Allegato 1 Servizio Governance e linee guida tecnicoorganizzative del sistema ICAR-ER INDICE 1. Introduzione 3 1.1 Definizione e Acronimi 3 1.2 Scopo del documento 4 1.3 Destinatari 4 2. Il Sistema ICAR-ER

Dettagli

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa

JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa JBoss ESB Un caso d'uso italiano: La Porta di Dominio per la Cooperazione Applicativa Andrea Leoncini JBoss Stefano Linguerri - Pro-netics Agenda JBoss ESB le SOA e la Porta di Dominio Le specifiche CNIPA

Dettagli

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop

Tutorial di configurazione e programmazione di OpenSPCoop. Tutorial di configurazione e programmazione di OpenSPCoop i Tutorial di configurazione e programmazione di OpenSPCoop ii Copyright 2005-2008 Link.it s.r.l. iii COLLABORATORI TITOLO : Tutorial di configurazione e programmazione di OpenSPCoop AZIONE NOME DATA FIRMA

Dettagli

fornitore di servizi utente all interazione tra utenti e sistemi

fornitore di servizi utente all interazione tra utenti e sistemi WEB SERVICES Successo del Web Negli anni passati il Web ha avuto un enorme successo principalmente per due motivi: Semplicità: Ubiquità Per un fornitore di servizi è semplice raggiungere un numero molto

Dettagli

Specifiche tecniche per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica

Specifiche tecniche per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica Specifiche tecniche per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica 1/20 1.1 Modifiche Documento Descrizione Modifica Edizione Data Prima emissione 1 28/07/2008 1.2

Dettagli

SIRV-INTEROP Sicurezza basata sui ruoli

SIRV-INTEROP Sicurezza basata sui ruoli SIRV-INTEROP (UML-A8.2-0) 06 ottobre 2004 Approvazioni Il presente documento è stato approvato da: UML-A8.2-0 18/11/05 16.25 2 Storia delle Modifiche Versione Data Descrizione Riferimenti Numero Titolo

Dettagli

Allegato Tecnico IcarER

Allegato Tecnico IcarER Allegato Tecnico IcarER Nota di lettura 1 Descrizione del Servizio 1.1 Definizioni e Acronimi 1.2 Descrizione generale 1.2.1 Accordo di servizio 1.3 Descrizione dei servizi offerti 1.3.1 Gestione in service

Dettagli

Accordo di servizio. Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML:

Accordo di servizio. Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML: Accordo di servizio Insieme delle definizioni, delle funzionalità, delle interfacce, dei requisiti di sicurezza e di qualità di uno o più servizi applicativi che vengono scambiati tra due amministrazioni

Dettagli

Framework di sicurezza della piattaforma OCP (Identity & Access Management)

Framework di sicurezza della piattaforma OCP (Identity & Access Management) Smart Cities and Communities and Social Innovation Bando MIUR D.D. 91/Ric. del 5 luglio 2012 Framework di sicurezza della piattaforma OCP (Identity & Access Management) AAI: Il problema che OCP ha affrontato

Dettagli

UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica

UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica UNIVERISTA DEGLI STUDI DELLA BASILICATA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica TESI DI LAUREA SPECIALISTICA CONFRONTO TRA PIATTAFORME OPEN-SOURCE

Dettagli

Ministero della Giustizia

Ministero della Giustizia Ministero della Giustizia DIPARTIMENTO DELL ORGANIZZAZIONE GIUDIZIARIA, DEL PERSONALE E DEI SERVIZI DIREZIONE GENERALE PER I SISTEMI INFORMATIVI AUTOMATIZZATI AREA CIVILE POLISWEB Piano delle verifiche

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS)

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS) Progetto cofinanziato dall Unione Europea Fondo Europeo di Sviluppo Regionale POR FESR Sardegna 2007-2013 [TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi

Dettagli

Web Service per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica

Web Service per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica Web Service per il controllo e la trasmissione telematica delle pratiche di Comunicazione Unica Versione: 3 Data: 16/10/2014 Autore: InfoCamere 1. Introduzione al documento...3 1.1 Modifiche al documento...

Dettagli

Web Services Servizio Telematico Dogane

Web Services Servizio Telematico Dogane Web Services Servizio Telematico Dogane MANUALE PER L'UTENTE Pagina 1 di 21 Indice 1 Introduzione... 3 2 Test funzionale dei web services... 6 3 Creazione del client... 10 3.1 Soluzioni Open Source...

Dettagli

PROGETTO TESSERA SANITARIA SERVIZI DI COMUNICAZIONE ATTIVAZIONE E REVOCA DELLE TS-CNS

PROGETTO TESSERA SANITARIA SERVIZI DI COMUNICAZIONE ATTIVAZIONE E REVOCA DELLE TS-CNS PROGETTO TESSERA SANITARIA Pag. 2 di 13 INDICE 1. INTRODUZIONE 4 2. CANALI DI COMUNICAZIONE DEI SISTEMI REGIONALI CON IL SISTEMA TS 5 3. SERVIZIO DI COMUNICAZIONE ATTIVAZIONE/REVOCA CNS 6 3.1 DESCRIZIONE

Dettagli

SERVICE BROWSER. Versione 1.0

SERVICE BROWSER. Versione 1.0 SERVICE BROWSER Versione 1.0 25/09/2008 Indice dei Contenuti 1. Scopo del documento... 3 2. Introduzione... 3 3. Accordi di Servizio... 4 4. Servizi... 5 5. Servizio: Schede Erogatori... 8 6. Servizio:

Dettagli

Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa

Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa Soluzioni Infrastrutturali Open Source per il Sistema Pubblico di Cooperazione Applicativa Giansalvatore Mecca Alessandro Pappalardo Salvatore Raunich Il Gruppo di Sviluppo ICAR 1 Dipartimento di Matematica

Dettagli

OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa

OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa OpenSPCoop Un Implementazione Open Source della specifica SPCoop di Cooperazione Applicativa Tito Flagella tito@link.it http://openspcoop.org La Cooperazione Applicativa Regolamentazione delle modalità

Dettagli

Il modello ICAR per la gestione dell Identit

Il modello ICAR per la gestione dell Identit Il modello ICAR per la gestione dell Identit Identità Digitale Federata Architettura, opportunità e prospettive di convergenza Forum PA 2008, Roma 15 maggio 2008 Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

DESCRIZIONE DELLE SPECIFICHE DI

DESCRIZIONE DELLE SPECIFICHE DI DESCRIZIONE DELLE SPECIFICHE DI SICUREZZA NEGLI ACCORDI DI SERVIZIO Versione 1.1 INDICE 1. PREFAZIONE...3 1.1. Autori... 3 1.2. Modifiche Documento... 3 1.3. Riferimenti... 4 1.4. Acronimi e Definizioni...

Dettagli

Web Services Dogane LINEE GUIDA

Web Services Dogane LINEE GUIDA Web Services Dogane LINEE GUIDA Pagina 1 di 17 Indice Indice... 2 1. INTRODUZIONE... 3 2. TEST FUNZIONALI SUI WEB SERVICES... 8 3. SICUREZZA... 14 4. FIRMA... 14 5. TRASFORMAZIONE CERTIFICATO DI FIRMA...

Dettagli

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA. Versione 1.1

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA. Versione 1.1 Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Versione 1.1 INDICE 1. MODIFICHE DOCUMENTO... 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO... 5 2.1. Scopi del documento... 6 2.2. Note di lettura del

Dettagli

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n.

DigitPA. VISTI gli articoli 16 e 16 bis del decreto Legge 29 novembre 2008, n. 185 convertito con modificazioni dalla Legge 28 gennaio 2009 n. DigitPA VISTO l art. 6, comma 1 bis, del decreto legislativo 7 marzo 2005 n. 82 (indicato in seguito con l acronimo CAD), come modificato dal decreto legislativo 30 dicembre 2010 n. 235; VISTI gli articoli

Dettagli

Definizione delle interfacce di colloquio fra le componenti

Definizione delle interfacce di colloquio fra le componenti Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA

Dettagli

Manuale gestione Porta di Dominio OpenSPCoop 1.1

Manuale gestione Porta di Dominio OpenSPCoop 1.1 i Manuale gestione Porta di Dominio ii Copyright 2005-2008 Link.it srl Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti i diritti sono riservati. Non è permesso

Dettagli

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP Web Services I web services servono a rendere interoperabili le applicazioni e favoriscono la loro integrazione. I servizi web sono applicazioni software che possono essere scoperte, descritte e usate

Dettagli

REGOLE PROCEDURALI DI CARATTERE TECNICO OPERATIVO PER L ACCESSO AI SERVIZI DISPONIBILI TRAMITE LA POSTA ELETTRONICA CERTIFICATA

REGOLE PROCEDURALI DI CARATTERE TECNICO OPERATIVO PER L ACCESSO AI SERVIZI DISPONIBILI TRAMITE LA POSTA ELETTRONICA CERTIFICATA Dipartimento per gli Affari di Giustizia Direzione Generale della Giustizia Penale Decreto Dirigenziale Articolo 39 D.P.R. 14 Novembre 2002, N. 313 Decreto Dirigenziale del 5 dicembre 2012 recante le regole

Dettagli

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA

Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Sistema Pubblico di Connettività e Cooperazione Sistema pubblico di cooperazione: SERVIZI DI SICUREZZA Versione 1.0 INDICE 1. MODIFICHE DOCUMENTO... 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO...5 2.1. Scopi

Dettagli

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop i Guida alla programmazione e integrazione di servizi in OpenSPCoop ii Copyright 2005-2008 Link.it s.r.l. iii COLLABORATORI TITOLO : Guida alla programmazione e integrazione di servizi in OpenSPCoop AZIONE

Dettagli

Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop

Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Laurea specialistica in Ingegneria Informatica Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Relatore:

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione

Centro Nazionale per l Informatica nella Pubblica Amministrazione Centro Nazionale per l Informatica nella Pubblica Amministrazione Procedura ristretta n. 2/2006 per l affidamento della progettazione, realizzazione e gestione di componenti di cooperazione applicativa,

Dettagli

Identity Access Management nel web 2.0

Identity Access Management nel web 2.0 Identity Access Management nel web 2.0 Single Sign On in applicazioni eterogenee Carlo Bonamico, NIS s.r.l. carlo.bonamico@nispro.it 1 Sommario Problematiche di autenticazione in infrastrutture IT complesse

Dettagli

Introduzione alla Cooperazione applicativa in Campania

Introduzione alla Cooperazione applicativa in Campania Introduzione alla Cooperazione applicativa in Campania Cos è SPICCA è una infrastruttura costituita dall insieme di risorse hardware e componenti applicative, rappresenta la piattaforma per la realizzazione

Dettagli

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Allegato n. 2 al Capitolato speciale d appalto. ENTE PUBBLICO ECONOMICO STRUMENTALE DELLA REGIONE CALABRIA POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Procedura aperta sotto

Dettagli

Allegato alla deliberazione n. 34/2006 Regole Tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML

Allegato alla deliberazione n. 34/2006 Regole Tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML Allegato alla deliberazione n. 34/2006 REGOLE TECNICHE PER LA DEFINIZIONE DEL PROFILO DI BUSTA CRITTOGRAFICA PER LA FIRMA DIGITALE IN LINGUAGGIO XML www.cnipa.gov.it DB/CNI/2006_034 Sommario 1 Definizioni...3

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket.

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket. Portale regionale della Salute Servizi di prenotazione prestazione e pagamento ticket. Specifiche di integrazione dei servizi di cooperazione applicativa e dei web services. Versione 1.10 16 Ottobre 2013

Dettagli

Il modello di gestione delle identità digitali in SPCoop

Il modello di gestione delle identità digitali in SPCoop Il modello di gestione delle identità digitali in SPCoop Francesco Tortorelli Il quadro normativo e regolatorio di riferimento 2 Il codice dell amministrazione digitale (CAD) CAD Servizi Access di services

Dettagli

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2

Release Notes di OpenSPCoop2. Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 i Release Notes di OpenSPCoop2 Release Notes di OpenSPCoop2 ii Copyright 2005-2015 Link.it srl Release Notes di OpenSPCoop2 iii Indice 1 Versione 2.1 1 1.1 Gestione del protocollo

Dettagli

La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop

La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop Università degli Studi di Pisa Facoltà di Scienze Matematiche Fisiche e Naturali Dipartimento di Informatica TESI DI LAUREA La Gestione degli Accordi di Cooperazione nel progetto OpenSPCoop Relatori prof.

Dettagli

1 Oggetto del documento... 2 2 Definizioni, Acronimi ed Abbreviazioni... 2 3 Riferimenti... 2 4 Architettura generale... 2 4.1 Anagrafe operatori...

1 Oggetto del documento... 2 2 Definizioni, Acronimi ed Abbreviazioni... 2 3 Riferimenti... 2 4 Architettura generale... 2 4.1 Anagrafe operatori... 1 Oggetto del documento... 2 2 Definizioni, Acronimi ed Abbreviazioni... 2 3 Riferimenti... 2 4 Architettura generale... 2 4.1 Anagrafe operatori... 3 4.2 Anagrafe assistiti... 3 4.3 Fascicolo Sanitario

Dettagli

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione Comunicazioni sicure su Internet: https e SSL Fisica dell Informazione Il servizio World Wide Web (WWW) Come funziona nel dettaglio il Web? tre insiemi di regole: Uniform Resource Locator (URL) Hyper Text

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Architettura CART Versione 3.6 14/09/2010

Architettura CART Versione 3.6 14/09/2010 Versione 3.6 14/09/2010 Indice dei Contenuti 1. PREFAZIONE... 3 2. INTRODUZIONE... 3 3. ARCHITETTURA GENERALE DEL CART... 4 3.1. COMPONENTI DELL ARCHITETTURA E INTERFACCE... 7 3.1.1. Il Registro SICA Secondario...

Dettagli

MANUALE UTENTE FORMULA PEC

MANUALE UTENTE FORMULA PEC MANUALE UTENTE FORMULA PEC Stampato il 03/12/10 16.22 Pagina 1 di 22 REVISIONI Revisione n : 00 Data Revisione: 01/04/2010 Descrizione modifiche: Nessuna modifica Motivazioni: Prima stesura Stampato il

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

WebCare. Specifiche Tecniche recupero dati per tariffazione. Redatto da: STUDIOFARMA 28 MAGGIO 2009 Verificato da: Approvato da:

WebCare. Specifiche Tecniche recupero dati per tariffazione. Redatto da: STUDIOFARMA 28 MAGGIO 2009 Verificato da: Approvato da: WebCare Specifiche Tecniche recupero dati per tariffazione Progetto: WEBCARE 2 Versione 1.3 Data 05 AGOSTO 2011 Redatto da: STUDIOFARMA 28 MAGGIO 2009 Verificato da: Approvato da: CRONOLOGIA DELLE VERSIONI

Dettagli

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it Attori nella Federazione e Profili SAML Massimiliano Pianciamore Agenda Ruoli e Attori in una infrastruttura federata Service Provider Identity Provider Attribute Authorities Lo standard SAML 2.0 Asserzioni

Dettagli

LE TECNOLOGIE PER IL CAMBIAMENTO 2

LE TECNOLOGIE PER IL CAMBIAMENTO 2 LE TECNOLOGIE PER IL CAMBIAMENTO 2 CITTADINANZA DIGITALE: GLI STRUMENTI La cooperazione applicativa - ICAR Andrea Nicolini PM ICAR - CISIS Roma, 1 ottobre 2010 Agenda E-gov in Italia negli ultimi 10 anni

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

SDK-CART. Versione 1.1

SDK-CART. Versione 1.1 SDK-CART Versione 1.1 20/04/2008 Indice dei Contenuti 1 INTRODUZIONE...2 2 L USO DEL COMPONENTE DI INTEGRAZIONE DELLA PORTA DI DOMINIO... 2 2.1 Modalità d'uso trasparente dei Servizi...3 2.2 Uso del Servizio

Dettagli

Agenda. Seminario. Cedac Software - Hardware. Cedac Software S.r.l.

Agenda. Seminario. Cedac Software - Hardware. Cedac Software S.r.l. Seminario Architetture SOA in ambito bancario: Tecnologia ed applicazioni Agenda Cedac Software ed il suo Business SOA e Web Services Realizzazione di un Caso di Studio Nuove tecnologie WS-* Q&A Cedac

Dettagli

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO Versione 1.1 INDICE 1. PREFAZIONE 3 1.1 Autori 3 1.2 Modifiche Documento 3 1.3 Riferimenti 4 1.4 Acronimi e Definizioni 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO

Dettagli

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

I Servizi dell'architettura Web Services. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com I Servizi dell'architettura Web Services Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com La struttura del messaggio SOAP Un messaggio SOAP consiste di: Envelope, identifica il contenuto del

Dettagli

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID)

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) Versione 1.5 INDICE 1. PREFAZIONE...5 1.1. Autori... 5 1.2. Modifiche Documento... 5 1.3. Riferimenti... 6 1.4. Acronimi e Definizioni... 6 2.

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Service Oriented Architecture and Web Services

Service Oriented Architecture and Web Services Service Oriented Architecture and Web Services Note per il corso di Ingegneria del Software Università di Camerino Dipartimento di Matematica ed Informatica Andrea Polini 11 gennaio 2007 Queste note sono

Dettagli

Eclipse Day 2010 in Rome

Eclipse Day 2010 in Rome Le infrastrutture open source per la cooperazione applicativa nella pubblica amministrazione: l'esperienza in Regione del Veneto Dirigente del Servizio Progettazione e Sviluppo Direzione Sistema Informatico

Dettagli

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop

Guida alla programmazione e integrazione di servizi in OpenSPCoop. Guida alla programmazione e integrazione di servizi in OpenSPCoop i Guida alla programmazione e integrazione di servizi in OpenSPCoop ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Introduzione 1 2 Modalità d integrazione trasparente 1 3 Modalità d integrazione tramite

Dettagli

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO

MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO MODALITÀ DI QUALIFICAZIONE DELLA PORTA DI DOMINIO Versione 1.0 INDICE 1. PREFAZIONE 3 1.1 Autori 3 1.2 Modifiche Documento 3 1.3 Riferimenti 4 1.4 Acronimi e Definizioni 4 2. OBIETTIVI E CONTESTO DI RIFERIMENTO

Dettagli

Guida alla configurazione freesbee-sla e freesbweb-sla

Guida alla configurazione freesbee-sla e freesbweb-sla Guida alla configurazione freesbee-sla e freesbweb-sla freesbee SLA freesbweb SLA Pagina 1 di 23 Sommario Guida alla configurazione freesbee-sla e freesbweb-sla... 1 Introduzione... 4 Installazione...

Dettagli

@CCEDO: Accessibilità, Sicurezza, Architettura

@CCEDO: Accessibilità, Sicurezza, Architettura Rev. 8, agg. Settembre 2014 @CCEDO: Accessibilità, Sicurezza, Architettura 1.1 Il Sistema di Gestione della Sicurezza Per quanto riguarda la gestione della Sicurezza, @ccedo è dotato di un sistema di autenticazione

Dettagli