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

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

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

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

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE - Visto l articolo 17

Dettagli

Ministero dell Interno Dipartimento per gli Affari Interni e Territoriali Direzione Centrale per i Servizi Demografici

Ministero dell Interno Dipartimento per gli Affari Interni e Territoriali Direzione Centrale per i Servizi Demografici ALLEGATO TECNICO ALLA CIRCOLARE N. 23/05 Ai sensi del presente allegato tecnico si intende: a) per "S.S.C.E. il sistema di sicurezza del circuito di emissione dei documenti di identità elettronica; b)

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

SPECIFICHE TECNICHE OPERATIVE DELLE REGOLE TECNICHE DI CUI ALL ALLEGATO B DEL DM 55 DEL 3 APRILE 2013. Versione 1.1

SPECIFICHE TECNICHE OPERATIVE DELLE REGOLE TECNICHE DI CUI ALL ALLEGATO B DEL DM 55 DEL 3 APRILE 2013. Versione 1.1 SPECIFICHE TECNICHE OPERATIVE DELLE REGOLE TECNICHE DI CUI ALL ALLEGATO B DEL DM 55 DEL 3 APRILE 2013 Versione 1.1 INDICE 1. INTRODUZIONE 4 1.1 DEFINIZIONI 4 2. MODALITÀ DI EMISSIONE DELLE FATTURE ELETTRONICHE

Dettagli

Infrastrutture tecnologiche abilitanti della Regione Marche

Infrastrutture tecnologiche abilitanti della Regione Marche Infrastrutture tecnologiche abilitanti della Regione Marche II contenuto del presente documento costituisce materiale riservato e soggetto a copyright. 1 di 39 REDATTO DA < Amici Cinzia > Firma Data 18/01/2011

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO REGIONE BASILICATA PROCEDURA NEGOZIATA PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, REALIZZAZIONE E GESTIONE DEL SISTEMA INTEGRATO SERB ECM DELLA REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06)

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

Regole tecniche del servizio di trasmissione di documenti informatici mediante posta elettronica certificata

Regole tecniche del servizio di trasmissione di documenti informatici mediante posta elettronica certificata Regole tecniche del servizio di trasmissione di documenti informatici mediante posta elettronica certificata Pagina 1 di 48 INDICE 1 MODIFICHE DOCUMENTO...4 2 RIFERIMENTI...4 3 TERMINI E DEFINIZIONI...4

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone Paragrafo 1 Prerequisiti Definizione di applicazione server Essa è un servizio che è in esecuzione su un server 1 al fine di essere disponibile per tutti gli host che lo richiedono. Esempi sono: il servizio

Dettagli

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi.

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet: la rete delle reti Alberto Ferrari Connessioni

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

RELAZIONI TRA SERVIZI PER L IMPIEGO

RELAZIONI TRA SERVIZI PER L IMPIEGO RELAZIONI TRA SERVIZI PER L IMPIEGO E AZIENDE-UTENTI L IMPATTO DELLE PROCEDURE INFORMATIZZATE a cura di Germana Di Domenico Elaborazione grafica di ANNA NARDONE Monografie sul Mercato del lavoro e le politiche

Dettagli

Il World Wide Web: nozioni introduttive

Il World Wide Web: nozioni introduttive Il World Wide Web: nozioni introduttive Dott. Nicole NOVIELLI novielli@di.uniba.it http://www.di.uniba.it/intint/people/nicole.html Cos è Internet! Acronimo di "interconnected networks" ("reti interconnesse")!

Dettagli

Guida alla scansione su FTP

Guida alla scansione su FTP Guida alla scansione su FTP Per ottenere informazioni di base sulla rete e sulle funzionalità di rete avanzate della macchina Brother, consultare la uu Guida dell'utente in rete. Per ottenere informazioni

Dettagli

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE Pag. 1 di 14 INDICE 1. Glossario... 3 2. il servizio SPCoop - Ricezione... 5 3. Il web-service RicezioneFatture... 8 3.1 Operazione RiceviFatture... 9 3.1.1

Dettagli

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless La configurazione degli indirizzi IP Configurazione statica, con DHCP, e stateless 1 Parametri essenziali per una stazione IP Parametri obbligatori Indirizzo IP Netmask Parametri formalmente non obbligatori,

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

dott.ssa C.ristina Mugnai Revisione: 1

dott.ssa C.ristina Mugnai Revisione: 1 Tipo di documento: Progetto - Commissione Didattica 27 giugno 2011 Pag. 1 di 9 Premessa Il progetto nasce con l obiettivo di: a) informatizzare il processo di presentazione della domanda di laurea in analogia

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

[05/05/2008 NOTA 11] Le note sono elencate dalla più recente alla meno recente.

[05/05/2008 NOTA 11] Le note sono elencate dalla più recente alla meno recente. Questo documento riporta delle note integrative ai documenti di riferimento della Posta Elettronica Certificata (PEC). Nello specifico le seguenti note fanno riferimento a: Decreto del Presidente della

Dettagli

PAGAMENTO ELETTRONICO DELLA MARCA

PAGAMENTO ELETTRONICO DELLA MARCA PAGAMENTO ELETTRONICO DELLA MARCA DA BOLLO DIGITALE Allineato alla versione 1.7 delle Specifiche Attuative del Nodo dei Pagamenti-SPC Versione 1.0 - febbraio 2015 STATO DEL DOCUMENTO revisione data note

Dettagli

UN ARCHITETTURA UNITARIA. - Il nuovo modello di cooperazione SPC - PER L AGENDA DIGITALE

UN ARCHITETTURA UNITARIA. - Il nuovo modello di cooperazione SPC - PER L AGENDA DIGITALE UN ARCHITETTURA UNITARIA PER L AGENDA DIGITALE - Il nuovo modello di cooperazione SPC - documento.: INDICE ACRONIMI... 3 GLOSSARIO... 5 1. SCOPO E STRUTTURA DEL DOCUMENTO... 6 2. INTRODUZIONE... 7 2.1.

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

Attività relative al primo anno

Attività relative al primo anno PIANO OPERATIVO L obiettivo delle attività oggetto di convenzione è il perfezionamento dei sistemi software, l allineamento dei dati pregressi e il costante aggiornamento dei report delle partecipazioni

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

UNIVERSITÀ DEGLI STUDI DI TRENTO DOCUMENTO ELETTRONICO, FIRMA DIGITALE E SICUREZZA IN RETE.

UNIVERSITÀ DEGLI STUDI DI TRENTO DOCUMENTO ELETTRONICO, FIRMA DIGITALE E SICUREZZA IN RETE. UNIVERSITÀ DEGLI STUDI DI TRENTO DOCUMENTO ELETTRONICO, FIRMA DIGITALE E SICUREZZA IN RETE. INTRODUZIONE ALL ARGOMENTO. A cura di: Eleonora Brioni, Direzione Informatica e Telecomunicazioni ATI NETWORK.

Dettagli

Esperienza di interoperabilità tra servizi bibliotecari tramite protocollo ISO-ILL. Colloquio standard ILL- SBN/Aleph e ILL-SBN /Sebina Open Library

Esperienza di interoperabilità tra servizi bibliotecari tramite protocollo ISO-ILL. Colloquio standard ILL- SBN/Aleph e ILL-SBN /Sebina Open Library Esperienza di interoperabilità tra servizi bibliotecari tramite protocollo ISO-ILL. Colloquio standard ILL- SBN/Aleph e ILL-SBN /Sebina Open Library A. Bardelli (Univ. Milano Bicocca), L. Bernardis (Univ.

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

Guida ai Servizi Internet per il Referente Aziendale

Guida ai Servizi Internet per il Referente Aziendale Guida ai Servizi Internet per il Referente Aziendale Indice Indice Introduzione...3 Guida al primo accesso...3 Accessi successivi...5 Amministrazione dei servizi avanzati (VAS)...6 Attivazione dei VAS...7

Dettagli

TeamPortal. Servizi integrati con ambienti Gestionali

TeamPortal. Servizi integrati con ambienti Gestionali TeamPortal Servizi integrati con ambienti Gestionali 12/2013 Modulo di Amministrazione Il modulo include tutte le principali funzioni di amministrazione e consente di gestire aspetti di configurazione

Dettagli

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it Sicurezza delle reti wireless Alberto Gianoli alberto.gianoli@fe.infn.it Concetti di base IEEE 802.11: famiglia di standard tra cui: 802.11a, b, g: physical e max data rate spec. 802.11e: QoS (traffic

Dettagli

UNIVERSITÀ DEGLI STUDI DI PARMA

UNIVERSITÀ DEGLI STUDI DI PARMA UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA Tesi di laurea in RETI DI CALCOLATORI Autenticazione Centralizzata con il sistema CAS, integrando

Dettagli

Deutsche Bank. db Corporate Banking Web Guida al servizio

Deutsche Bank. db Corporate Banking Web Guida al servizio Deutsche Bank db Corporate Banking Web Guida al servizio INDICE 1. INTRODUZIONE... 3 2. SPECIFICHE DI SISTEMA... 4 3 MODALITÀ DI ATTIVAZIONE E DI PRIMO COLLEGAMENTO... 4 3. SICUREZZA... 5 4. AUTORIZZAZIONE

Dettagli

ARP (Address Resolution Protocol)

ARP (Address Resolution Protocol) ARP (Address Resolution Protocol) Il routing Indirizzo IP della stazione mittente conosce: - il proprio indirizzo (IP e MAC) - la netmask (cioè la subnet) - l indirizzo IP del default gateway, il router

Dettagli

F O R M A T O E U R O P E O

F O R M A T O E U R O P E O F O R M A T O E U R O P E O P E R I L C U R R I C U L U M V I T A E INFORMAZIONI PERSONALI Nome Indirizzo Laura Bacci, PMP Via Tezze, 36 46100 MANTOVA Telefono (+39) 348 6947997 Fax (+39) 0376 1810801

Dettagli

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it ISO 9001: 2008 Profilo Aziendale METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it Sede legale: * Viale Brodolini, 117-60044 - Fabriano (AN) - Tel. 0732.251856 Sede amministrativa:

Dettagli

INFORMATIVA PRIVACY AI VISITATORI DEL SITO www.wdc-international.com

INFORMATIVA PRIVACY AI VISITATORI DEL SITO www.wdc-international.com INFORMATIVA PRIVACY AI VISITATORI DEL SITO www.wdc-international.com La presente Informativa è resa, anche ai sensi del ai sensi del Data Protection Act 1998, ai visitatori (i Visitatori ) del sito Internet

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

COMMISSIONE PARLAMENTARE DI VIGILANZA SULL ANAGRAFE TRIBUTARIA AUDIZIONE DEL DIRETTORE DELL AGENZIA DELLE ENTRATE

COMMISSIONE PARLAMENTARE DI VIGILANZA SULL ANAGRAFE TRIBUTARIA AUDIZIONE DEL DIRETTORE DELL AGENZIA DELLE ENTRATE COMMISSIONE PARLAMENTARE DI VIGILANZA SULL ANAGRAFE TRIBUTARIA AUDIZIONE DEL DIRETTORE DELL AGENZIA DELLE ENTRATE Modello 730 precompilato e fatturazione elettronica Roma, 11 marzo 2015 2 PREMESSA Signori

Dettagli

CARATTERISTICHE DELLE CRYPTO BOX

CARATTERISTICHE DELLE CRYPTO BOX Secure Stream PANORAMICA Il sistema Secure Stream è costituito da due appliance (Crypto BOX) in grado di stabilire tra loro un collegamento sicuro. Le Crypto BOX sono dei veri e propri router in grado

Dettagli

Guida al nuovo sistema di posta. CloudMail UCSC. (rev.doc. 1.4)

Guida al nuovo sistema di posta. CloudMail UCSC. (rev.doc. 1.4) Guida al nuovo sistema di posta CloudMail UCSC (rev.doc. 1.4) L Università per poter migliorare l utilizzo del sistema di posta adeguandolo agli standard funzionali più diffusi ha previsto la migrazione

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

DigitPA. Dominio.gov.it Procedura per la gestione dei sottodomini di terzo livello

DigitPA. Dominio.gov.it Procedura per la gestione dei sottodomini di terzo livello DigitPA Dominio.gov.it Procedura per la gestione dei sottodomini di terzo livello Versione 3.0 Dicembre 2010 Il presente documento fornisce le indicazioni e la modulistica necessarie alla registrazione,

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

EMC Documentum xcp for Business Process Management

EMC Documentum xcp for Business Process Management Analisi dettagliata Abstract Oggi le aziende devono affrontare una sfida comune: ottimizzare i processi di business e la loro efficienza operativa. Per vincere questa sfida, EMC Documentum xcelerated Composition

Dettagli

Allegato 8 MISURE MINIME ED IDONEE

Allegato 8 MISURE MINIME ED IDONEE Allegato 8 MISURE MINIME ED IDONEE SOMMARIO 1 POLITICHE DELLA SICUREZZA INFORMATICA...3 2 ORGANIZZAZIONE PER LA SICUREZZA...3 3 SICUREZZA DEL PERSONALE...3 4 SICUREZZA MATERIALE E AMBIENTALE...4 5 GESTIONE

Dettagli

Concessione del servizio di comunicazione elettronica certificata tra pubblica amministrazione e cittadino (CEC PAC)

Concessione del servizio di comunicazione elettronica certificata tra pubblica amministrazione e cittadino (CEC PAC) Concessione del servizio di comunicazione elettronica certificata tra pubblica amministrazione e cittadino (CEC PAC) Information Day Ministero dello sviluppo economico Salone Uval, Via Nerva, 1 Roma, 2

Dettagli

Servizio Fatt-PA PASSIVA

Servizio Fatt-PA PASSIVA Sei una Pubblica Amministrazione e sei obbligata a gestire la ricezione delle fatture elettroniche PA? Attivate il servizio di ricezione al resto ci pensiamo noi Servizio Fatt-PA PASSIVA di Namirial S.p.A.

Dettagli

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine 1999 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright

Dettagli

Titolo I - AMBITO DI APPLICAZIONE, DEFINIZIONI ED ADEGUAMENTO ORGANIZZATIVO E FUNZIONALE DELLE PUBBLICHE AMMINISTRAZIONI

Titolo I - AMBITO DI APPLICAZIONE, DEFINIZIONI ED ADEGUAMENTO ORGANIZZATIVO E FUNZIONALE DELLE PUBBLICHE AMMINISTRAZIONI dalla G.U. n. 59 del 12 marzo 2014 (s.o. n. 20) DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 3 dicembre 2013 Regole tecniche per il protocollo informatico ai sensi degli articoli 40-bis, 41, 47, 57-bis

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

CURATORI E INFORMATIZZAZIONE PROCEDURE CONCORSUALI. presentazione novità Legge 221/2012 e Legge Stabilità

CURATORI E INFORMATIZZAZIONE PROCEDURE CONCORSUALI. presentazione novità Legge 221/2012 e Legge Stabilità CURATORI E INFORMATIZZAZIONE PROCEDURE CONCORSUALI presentazione novità Legge 221/2012 e Legge Stabilità Zucchetti Software Giuridico srl - Viale della Scienza 9/11 36100 Vicenza tel 0444 346211 info@fallco.it

Dettagli

Firma Digitale Remota. Manuale di Attivazione, Installazione,Utilizzo

Firma Digitale Remota. Manuale di Attivazione, Installazione,Utilizzo Firma Digitale Remota Manuale di Attivazione, Installazione,Utilizzo Versione: 0.3 Aggiornata al: 02.07.2012 Sommario 1. Attivazione Firma Remota... 3 1.1 Attivazione Firma Remota con Token YUBICO... 5

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

Circolare n. 64 del 15 gennaio 2014

Circolare n. 64 del 15 gennaio 2014 Circolare n. 64 del 15 gennaio 2014 Ordinativo informatico locale - Revisione e normalizzazione del protocollo sulle regole tecniche ed obbligatorietà dell utilizzo nei servizi di tesoreria PREMESSA L

Dettagli

Piazza delle Imprese alimentari. Viale delle Manifatture. Via della Produzione

Piazza delle Imprese alimentari. Viale delle Manifatture. Via della Produzione Piazza delle Imprese alimentari Viale delle Manifatture Via della Produzione PASSEPARTOUT MEXAL è una soluzione gestionale potente e completa per le imprese che necessitano di un prodotto estremamente

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto Scheda descrittiva del programma Open-DAI ceduto in riuso CSI-Piemonte in rappresentanza del Consorzio di progetto Agenzia per l Italia Digitale - Via Liszt 21-00144 Roma Pagina 1 di 19 1 SEZIONE 1 CONTESTO

Dettagli

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Tobia Castaldi Alessandro Amirante Lorenzo Miniero Simon Pietro Romano Giorgio Ventre 02/10/2009 GARR 2009 "Network

Dettagli

Utilizzato con successo nei più svariati settori aziendali, con Passepartout Mexal BP ogni utente può disporre di funzionalità

Utilizzato con successo nei più svariati settori aziendali, con Passepartout Mexal BP ogni utente può disporre di funzionalità PASSEPARTOUT MEXAL BP è una soluzione gestionale potente e completa per le imprese che necessitano di un prodotto estremamente flessibile, sia dal punto di vista tecnologico sia funzionale. Con più di

Dettagli

Le caratteristiche di interoperabilità del Terrapack 32 M

Le caratteristiche di interoperabilità del Terrapack 32 M I T P E l e t t r o n i c a Le caratteristiche di interoperabilità del Terrapack 32 M M. Guerriero*, V. Ferrara**, L. de Santis*** * ITP Elettronica ** Dipartimento di Ingegneria Elettronica Univ. La Sapienza

Dettagli

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi:

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Routing (instradamento) in Internet Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Stub AS: istituzione piccola Multihomed AS: grande istituzione (nessun ( transito Transit AS: provider

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

EESSI. Electronic Exchange of Social Security Information PROGETTO EESSI. Direzione centrale Pensioni Convenzioni Internazionali

EESSI. Electronic Exchange of Social Security Information PROGETTO EESSI. Direzione centrale Pensioni Convenzioni Internazionali Electronic Exchange of Social Security Information PROGETTO 1 Il passato appena trascorso 2006 Studio di fattibilità 2007 Accordo sull Architettura di Alto Livello di Il presente Basi Legali Articolo 78

Dettagli

Università degli Studi di Bergamo Policy sull accesso aperto (Open Access) alla letteratura scientifica

Università degli Studi di Bergamo Policy sull accesso aperto (Open Access) alla letteratura scientifica Università degli Studi di Bergamo Policy sull accesso aperto (Open Access) alla letteratura scientifica Indice 1 Definizioni 2 Premesse 3 Commissione di Ateneo per l Accesso aperto 4 Gruppo di lavoro 5

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Servizio Posta Elettronica Certificata P.E.C. Manuale Operativo

Servizio Posta Elettronica Certificata P.E.C. Manuale Operativo Servizio Posta Elettronica Certificata P.E.C. Manuale Operativo Informazioni sul documento Redatto da Ruben Pandolfi Responsabile del Manuale Operativo Approvato da Claudio Corbetta Amministratore Delegato

Dettagli

Fattura elettronica Vs Pa

Fattura elettronica Vs Pa Fattura elettronica Vs Pa Manuale Utente A cura di : VERS. 528 DEL 30/05/2014 11:10:00 (T. MICELI) Assist. Clienti Ft. El. Vs Pa SOMMARIO pag. I Sommario NORMATIVA... 1 Il formato della FatturaPA... 1

Dettagli

Di seguito sono descritti i prerequisiti Hardware e Software che deve possedere la postazione a cui viene collegata l Aruba Key.

Di seguito sono descritti i prerequisiti Hardware e Software che deve possedere la postazione a cui viene collegata l Aruba Key. 1 Indice 1 Indice... 2 2 Informazioni sul documento... 3 2.1 Scopo del documento... 3 3 Caratteristiche del dispositivo... 3 3.1 Prerequisiti... 3 4 Installazione della smart card... 4 5 Avvio di Aruba

Dettagli

INFORMATIVA SUI COOKIE

INFORMATIVA SUI COOKIE INFORMATIVA SUI COOKIE I Cookie sono costituiti da porzioni di codice installate all'interno del browser che assistono il Titolare nell erogazione del servizio in base alle finalità descritte. Alcune delle

Dettagli

Interfaccia Web per customizzare l interfaccia dei terminali e

Interfaccia Web per customizzare l interfaccia dei terminali e SIP - Session Initiation Protocol Il protocollo SIP (RFC 2543) è un protocollo di segnalazione e controllo in architettura peer-to-peer che opera al livello delle applicazioni e quindi sviluppato per stabilire

Dettagli

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting. explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.it Procedura di gestione per Laboratori di Analisi Cliniche Pag.

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli