1 Oggetto del documento Definizioni, Acronimi ed Abbreviazioni Riferimenti Architettura generale Anagrafe operatori...

Transcript

1 1 Oggetto del documento Definizioni, Acronimi ed Abbreviazioni Riferimenti Architettura generale Anagrafe operatori Anagrafe assistiti Fascicolo Sanitario Elettronico (FSE) Il Registry (indice documenti) L Access Gateway Il Repository dei documenti Funzionalità Flussi disponibili Flusso di autenticazione web services Flusso di sottomissione Flusso di interrogazione Flusso di retrieve Flusso di integrazione anagrafica Flusso gestione delle notifiche Flusso di integrazione CUP Flusso di integrazione Specifiche messaggistica Messaggio di richiesta token Saml Messaggio di risposta al messaggio di richiesta token Messaggio chiamata Proxy-ws con token Saml firmato Messaggio risposta proxy-ws Client Legacy... 19

2 1 Oggetto del documento L obiettivo del presente documento è la descrizione tecnico-funzionale delle tecnologie di sicurezza utilizzate per la protezione e la tutela dell accesso ai dati e ai servizi del progetto reti MMG della Regione Abruzzo e la modalità di integrazione con gli stessi. Sarà fornita la descrizione delle interfacce esposte per l accesso al sistema di archiviazione e di consultazione del FSE attraverso il modulo di Access Gateway, Anagrafe operatori e Anagrafe Assistiti. 2 Definizioni, Acronimi ed Abbreviazioni Acronimi Sigla Esteso SSO Single sign on WS Web services MMG Medici di Medicina Generale DN Distinguished name OU Organizational Unit CN Common Name FSE Fascicolo Sanitario Elettronico MMG Medici di Medicina Generale PLS Pediatri di Libera Scelta aka Also Known As HL7 Health Level 7 D-MIM Domain Message Information Model IHE Integrating HealthCare Enterprise SOA Service Oriented Architecture FSE Fascicolo Sanitario Elettronico 3 Riferimenti Client_legacy_integration.pdf IHE_ITI_TF_5.0_Vol2_FT_ doc Specifiche Tecniche Anagrafe Assistiti.doc Piano di test modulo Anagrafica Assititi.doc Specifiche Tecniche Modulo CUP.pdf Affinity Domain ReteMMG.pdf 4 Architettura generale Di seguito il Component Diagram relativo all infrastruttura del progetto reti MMG della Regione Abruzzo:

3 Dedalus FSE Mobile Client SSO Viewer Pronto Soccorso Service Provider ESB SAML, WS-Sec, WS-Trust, WS-Rest. POP3 Figura 1 - Architettura generale 4.1 Anagrafe operatori Il modulo Anagrafe Operatori è un insieme di software che permettono la creazione di un SSO utilizzabile sia in contesti di architetture SOA che in architetture rivolte ai Moduli Web. La gestione dell accesso ai servizi costituisce un punto nevralgico di ogni architettura, il modulo Anagrafe Operatori rappresenta un supporto che permette agli applicativi di svincolarsi dalle logiche di autenticazione e profilazione degli utenti. Il modulo Anagrafe Operatori come accennato in precedenza può essere utilizzato in architetture Web Oriented in cui l utente è una persona fisica. In questo caso le applicazioni che sono costituite da un front-end web e l utente fruisce della risorsa protetta dal SSO attraverso l uso di un comune browser web. Il modulo Anagrafe Operatori può essere anche utilizzato in un architettura SOA, l utente fruisce dei servizi attraverso un applicativo chiamante. I servizi sono esposti attraverso l uso di Web Services protetti dal SSO che sono invocati dall applicativo chiamante. 4.2 Anagrafe assistiti Per assicurare l univocità di identificazione degli assistiti all interno del domino operativo (i.e. la rete MMG/PLS), quindi garantire la corretta attribuzione delle informazioni anagrafiche e di posizione assistenziale (informazioni su medico curante, esenzioni, ) viene proposto un modello di collaborazione fra sistemi anagrafici di tipo gerarchico, in cui il modulo MAC (Modulo Anagrafe Centrale) svolga il ruolo di Anagrafe Sanitaria Master per l intero sistema informativo della Rete dei Medici a livello Regionale. L ownership delle informazioni identificative ed anagrafiche sarà comunque detenuta dall Anagrafe Regionale: il modulo fornito (MAC) - oggetto di questo progetto sarà quindi mantenuto in

4 sincrono con l Anagrafe Regionale attraverso il servizio SIAR fungendone da cache ed operando come interfaccia di collaborazione verso la rete MMG. Il modello di collaborazione fra anagrafiche adottato (modello gerarchico) prevede tutti i sistemi periferici (Cartelle Ambulatoriali MMG/PLS,etc) si comportino in termini di identificazione anagrafica come slave : tutte le informazioni anagrafiche ed identificative sono quindi derivate dal sistema MAC. Data la peculiarità del processo assistenziale territoriale gestito dai Medici di Medicina Generale e delle caratteristiche della infrastruttura informativa e di comunicazione utilizzata a supporto di quest ultimo, è stato scelto deciso di utilizzare un modello di interazione fra MAC e sistemi periferici così strutturato: per le comunicazioni da MAC verso i sistemi periferici si prevede una interazione di tipo asincrono attraverso un meccanismo di polling (gestione di code) - per le notifiche di variazioni anagrafiche o di riconduzione di posizioni duplicate; i meccanismi di collaborazione fra sistemi periferici e MAC (consultazione anagrafe, notifica aggiornamenti dati) saranno invece realizzati attraverso servizi sincroni. Ogni servizio è realizzato tramite servizi conformi allo standard HL7 V3, dove necessario, localizzato nel Realm Italiano. Dal punto di vista funzionale, il medesimo database del sistema MAC è utilizzato oltre che dall interfaccia applicativa di cooperazione descritta nei paragrafi seguenti, anche un front-end web per la consultazione delle informazioni gestite dal sistema 4.3 Fascicolo Sanitario Elettronico (FSE) All interno del progetto rete MMG il Fascicolo Sanitario Elettronico viene definito come un indice di oggetti informativi sanitari firmati digitalmente e creati nella storia dei suoi contatti dell assistito con i diversi attori del Sistema Sanitario Nazionale. Esso è accessibile dal cittadino e dagli operatori sanitari giuridicamente autorizzati in qualunque luogo ed in qualunque momento nel rispetto della regolamentazione nazionale e regionale e della tutela della privacy. Il Fascicolo Sanitario Elettronico deve permettere la gestione dei dati clinici sia da un punto di vista tecnico/informatico, sia dal punto di vista logico sanitario. Esso è uno strumento informativo condiviso e accessibile da tutti coloro che ne hanno il diritto, strutturato come una raccolta cronologica di eventi e informazioni longitudinale alla storia clinica del paziente. In base a questa definizione il tavolo di progettazione condivisa individua quindi nel Fascicolo Sanitario Elettronico un entità concettuale costituita dall'aggregazione logico-funzionale dei tre componenti rappresentati dall Access Gateway, dal Registry e dal Repository Il Registry (indice documenti) Il componente Registry è l indice del Fascicolo Sanitario Elettronico. Contiene l insieme dei metadati dei documenti memorizzati sui Repository e permette di recuperare questi ultimi, conformemente ai diritti di accesso dell utente richiedente, è centralizzato a livello regionale. Il Registry presenta le seguenti principali funzionalità: 1. recupero delle informazioni sui documenti (metadati) 2. creazione e modifica dello stato di un documento (modifica dei metadati) a fronte di una notifica dell Access Gateway"

5 4.3.2 L Access Gateway Il componente AccessGateway nella architettura IBSE è stato inizialmente concepito per realizzare le funzionalità necessarie a supportare comunicazioni sicure tra sistemi clinici e componenti interne del FSE, e tra queste ultime (in particolare, tra registry e repository). Può essere implementato sia a livello di ASL/AO sia a livello regionale. L Access gateway presenta le seguenti principali funzionalità: gestione delle comunicazioni tra le componenti interne al FSE gestione della criptazione a livello di messaggio. gestione degli aspetti di sicurezza e controllo degli accessi, mediante verifica e autorizzazione degli utenti (con il supporto dei sistemi anagrafici sanitari e delle Certification Authority) all accesso alle risorse del sistema. Pertanto, implementa primariamente le fasi di autenticazione forte (basata sull uso di CIE/CNS) identificazione forte (basata sull uso di CIE/CNS) autorizzazione gestione del tracciamento degli accessi Ulteriori componenti che non fanno parte del FSE, ma che sono di supporto alle funzionalità dell Access Gateway nel controllo degli accessi sono: Database a supporto alla sicurezza per la gestione di politiche e diritti di accesso 1, correlazioni tra medici e assistiti. Essi possono essere realizzati centralmente a livello regionale, distribuiti a livello di ASL/AO, oppure a livello di entrambi. Anagrafi operatori ed assistiti per la gestione degli utenti del sistema (operatori ed assistiti). Ciascuna tipologia di anagrafe può essere realizzata centralmente o a livello di ASL/AO. In tale contesto (i.e. in IBSE) l Access Gateway funge da facilitatore nell accesso ai componenti Registry e Repository, rendendo l infrastruttura trasparente dalle specifiche di implementazione del repository (qualora il sistema sia già presente sul territorio) Il Repository dei documenti Contiene documenti informatici[1] firmati digitalmente[2], la cui memorizzazione avviene secondo le modalità previste dal d.lgs.196/2003 (in particolare art. 22, comma 6). E normalmente distribuito a livello aziendale (ASL/AO), che ne è responsabile ai fini del trattamento, poiché i documenti risiedono nelle strutture sanitarie in cui sono stati creati. Il Repository presenta le seguenti principali funzionalità: 1. recupero di un documento a partire da un suo riferimento 2. memorizzazione di un documento [1] Tali documenti sono strutturati secondo lo standard internazionale HL7/CDA2, esplicitamente progettato per la rappresentazione di documenti clinici. 1 Si veda il documento DIT Matrice degli accessi (IBSE-RMMG-matrice-accessi-v01.00-BOZZA01.pdf)

6 [2] In base agli artt 20 comma 2 e 21 comma 2 del d.lgs n. 82 del 7/03/2005 Codice dell amministrazione digitale. Inoltre, in questo modo, per questi documenti si garantisce integrità e non ripudio. 5 Funzionalità Nell architettura prevista dal progetto tutti i servizi esposti verso gli attori attraverso l uso di architetture SOA dovranno essere protetti con l uso di WS-Security e SAML Assertion. Lo scambio di messaggi tra i componenti del sistema, cioè gli attori che partecipano al processo interattivo, identificabili dai componenti fisici come i client (Applicativi di Cartella, ADT, etc.) o dai componenti logici come quelli che espongono i servizi applicativi (Registry, Repository, CUP, Anagrafe regionale, etc), sarà filtrato da un componente proxy che realizza le funzionalità dei componenti logici definiti Access Gateway(AG) e Anagrafe Operatori. Tale proxy espone i servizi erogati dagli attori del progetto rete MMG in modo configurabile effettuando le funzionalità di filtro e controllo descritte in precedenza. 5.1 Flussi disponibili Il modulo proxy espone le interfacce per la gestione e mette a disposizione una serie di funzioni classificabili nelle seguenti categorie : Flusso di autenticazione Flusso di sottomissione Flusso di interrogazione Flusso di retrieve Flusso di integrazione anagrafica Flusso gestione delle notifiche Flusso di integrazione CUP Flusso di autenticazione web services Un applicativo che intende fruire di un servizio esposto deve necessariamente effettuare una chiamata verso il modulo di autenticazione. Il modulo valida le credenziali fornite dall applicativo chiamante sull anagrafe operatori verificando se l utente che intende fruire del servizio sia effettivamente censito ed autorizzato ad effettuare l operazione richiesta. Di seguito un schema riassuntivo di questa architettura:

7 Figura 2: Schema Architettura Modulo Autenticazione Web Services L applicativo di cartella prima di effettuare la chiamata SOAP verso il Web Service che vuole invocare, richiede l autenticazione dell operatore al modulo di autenticazione. Il componente Identity Provider del modulo di autenticazione, verifica sul Server OpenLDAP la validità delle credenziali inserite nel messaggio di richiesta(username e password). In caso di successo restituisce una asserzione SAML firmata con chiave privata. Tale asserzione viene quindi veicolata tramite il SOAP header ed usata dal Proxy Web Services per verificare l abilitazione dell operatore ad accedere al servizio invocato. L operazione di verifica avviene utilizzando i seguenti passi: prima viene verificata la firma della SAML Assertion,con la chiave pubblica per controllare l autenticità delle identità e del profilo (ruoli) trasmessi; quindi verifica che almeno uno dei ruoli associati all utente sia abilitato all invocazione del servizio. Se tutti i controlli sopraelencati vanno a buon fine il modulo instrada la chiamata verso il WS che eroga il servizio. Nel caso in cui i controlli non abbiano esito positivo, ossia l utente non risulta validato sull anagrafe operatori o il suo ruolo non permette di invocare il servizio e/ dell operazione richiesta, viene restituito all applicativo chiamante un messaggio di errore. L applicativo chiamante utilizza nelle successive chiamate il token Saml firmato fino alla scadenza dello stesso. Le policy di accesso relative alle singole operazioni (sottomissioni di documenti, interrogazioni, etc.) è oggetto di altri documenti descriventi il sistema nel suo complesso. Le funzioni di autenticazione sono le seguenti : RequestSecurityToken Tale metodo viene esposto dal modulo Identity provider che effettua il controllo delle credenziali sull Anagrafe Operatori. Le funzionalità esposte sono conformi ai seguenti standard: WS-Security

8 SAML Flusso di sottomissione Le funzioni di sottomissione sono le seguenti : DocumentRepository_ProvideAndRegisterDocumentSetB Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di interrogazione Le funzioni di interrogazione sono le seguenti : RegistryStoredQuery Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di retrieve Le funzioni di retrieve sono le seguenti: DocumentRepository_RetrieveDocumentSet Per questa funzionalità fare riferimento alla documentazione IHE relativa al profilo XDS-B Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc Rif.: Affinity Domain ReteMMG.pdf Flusso di integrazione anagrafica Le funzionalità di integrazione sono le seguenti per maggiori dettagli fare riferimento al documento di specifiche tecniche: SIA Servizio Identificazione Assistiti; STAA Servizio Trasmissione Aggiornamenti; SRDPR - Servizio Riconduzione Paziente; SNVA - Servizio notifica variazione anagrafica. Rif.: Specifiche Tecniche Anagrafe Assistiti.doc Rif.: Piano di test modulo Anagrafica Assititi.doc Flusso gestione delle notifiche Un applicativo client pubblica un referto, il Registry utilizzando il profilo IHE-NAV inoltra una mail al medico dell assistito per il quale è stato prodotto il referto. L applicativo di cartella può così procedere con lo scaricamento del documento dal Repository e l acquisizione in cartella. Rif.: IHE_ITI_TF_5.0_Vol2_FT_ doc

9 5.1.7 Flusso di integrazione CUP E prevista dalle specifiche di progetto l integrazione degli applicativi di cartella con il sistema regionale di SovraCup. Per questo scopo è stato realizzato un componente che espone le seguenti funzionalità: SRPECUP - Servizio Ricerca Prestazioni Erogabili CUP; SIPCUP - Servizio Inserimento Prenotazione CUP; SRLPA - Servizio Recupero Lista Prenotazioni per Assistito; SAPCUP - Servizio Annullamento Prenotazione CUP. Rif.: Specifiche Tecniche Modulo CUP.pdf 5.2 Flusso di integrazione L applicativo che si integra con l architettura deve eseguire le seguenti operazioni per effettuare l inserimento di un referto CDA2 nel Fascicolo Sanitario Elettronico: I. Autenticazione sul sistema e ricezione del token SAML. (RequestSecurityToken 2 ) II. Utilizzare il Token SAML ricevuto per effettuare le successive chiamate al proxy dei servizi, tali chiamate possono devono essere effettuate verso: a. Il modulo di anagrafe assistiti (invocazione del servizio SIA 3 )Dal messaggio HL7 tornato viene recuperato l identificativo dell assistito che sarà utilizzato nei flussi successivi. b. Il Repository per effettuare la sottomissione di un referto CDA2 e dei relativi metadati previsti dal framework IHE (DocumentRepository_ProvideAndRegisterDocumentSetB).Per la sottomissione è del referto è necessario utilizzare l identificativo regionale ottenuto con l interrogazione anagrafica. Il referto deve essere trasmesso in formato CDA2 come previsto dalle specifiche del TSE Per la firma digitale e la gestione dei fogli di trasformazione dei documenti CDA da inviare si faccia riferimento a quanto definito da CNIPA. c. Il Registry per effettuare la ricerca dei documenti che soddisfano una specifici criteri di ricerca. 5.3 Specifiche messaggistica Messaggio di richiesta token Saml Il messaggio comprende oltre alle intestazioni di WS-Security un tag UsernameToken contenente le credenziali dell operatore che vuole autenticarsi ed ottenere il Token firmato. Il Body contiene la richiesta di un token SAML, RequestSecurityToken. <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" xmlns:wsa=" <soapenv:header> <wsse:security xmlns:wsse=" 2 Integrazione_AnagrafeOperatori_AG.doc 3 D Specifiche Tecniche Anagrafe Assistiti Completo_ _vdef.doc

10 wssecurity-secext-1.0.xsd" soapenv:mustunderstand="1"> <wsu:timestamp xmlns:wsu=" wsu:id="timestamp "> <wsu:created> t15:16:06.938z</wsu:created> <wsu:expires> t15:21:06.938z</wsu:expires> </wsu:timestamp> <wsse:usernametoken xmlns:wsu=" wsu:id="usernametoken "> <wsse:username>ccrttl55m08d472i</wsse:username> <wsse:password Type=" > </wsse:Password> </wsse:usernametoken> </wsse:security> <wsa:to> <wsa:messageid>urn:uuid:8a2238b7aa83b35dca </wsa:messageid> <wsa:action> </soapenv:header> <soapenv:body> <wst:requestsecuritytoken xmlns:wst=" <wst:requesttype> > <wst:tokentype> 1.1#SAMLV1.1</wst:TokenType> <wsp:appliesto xmlns:wsp=" <wsa:endpointreference> <wsa:address/> </wsa:endpointreference> </wsp:appliesto> <wst:keytype> <wst:keysize>256</wst:keysize> </wst:requestsecuritytoken> </soapenv:body> </soapenv:envelope> Messaggio di risposta al messaggio di richiesta token Il messaggio contiene nel SOAP body l asserzione SAML firmata dal modulo server IDP che il client utilizza per effettuare le chiamate verso i servizi.

11 <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" xmlns:xenc=" xmlns:wsa=" <soapenv:header> <wsse:security xmlns:wsse=" wss-wssecurity-secext-1.0.xsd" soapenv:mustunderstand="1"> <wsu:timestamp xmlns:wsu=" wss-wssecurity-utility-1.0.xsd" wsu:id="timestamp "> <wsu:created> t15:16:03.067z</wsu:created> <wsu:expires> t15:21:03.067z</wsu:expires> </wsu:timestamp> </wsse:security> <wsa:action> <wsa:relatesto>urn:uuid:8a2238b7aa83b35dca </wsa:relatesto> </soapenv:header> <soapenv:body> <wst:requestsecuritytokenresponse xmlns:wst=" <wst:tokentype> 1.1#SAMLV1.1</wst:TokenType> <wst:requestedattachedreference> <wsse:securitytokenreference xmlns:wsse=" <wsse:reference URI="#_a4f71af ec164694edef4361d4" ValueType=" /> </wsse:securitytokenreference> </wst:requestedattachedreference> <wst:requestedunattachedreference> <wsse:securitytokenreference xmlns:wsse=" <wsse:reference URI="_a4f71af ec164694edef4361d4" ValueType=" /> </wsse:securitytokenreference> </wst:requestedunattachedreference> <wst:lifetime> <wsu:created xmlns:wsu=" wss-wssecurity-utility-1.0.xsd"> T15:16:03.046Z</wsu:Created> <wsu:expires xmlns:wsu=" wss-wssecurity-utility-1.0.xsd"> T15:21:03.046Z</wsu:Expires> </wst:lifetime> <wst:requestedsecuritytoken> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:1.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" xmlns:xsi=" xmlns:xsd="

12 AssertionID="_a4f71af ec164694edef4361d4" IssueInstant=" T15:16:03.058Z" CN=DedalusCA, OU=Sviluppo, O=Dedalus S.p.A., L=Firenze, ST=Firenze, C=IT" MajorVersion="1" MinorVersion="1"> <Conditions NotBefore=" T15:16:03.058Z" NotOnOrAfter=" T16:16:03.058Z" /> <AuthenticationStatement AuthenticationInstant=" T15:16:03.048Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"> <Subject> <NameIdentifier>VVRTTL55M07D472I</NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-ofkey</ConfirmationMethod> <KeyInfo xmlns=" <xenc:encryptedkey xmlns:ds=" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm=" /> <ds:keyinfo> <wsse:securitytokenreference xmlns:wsse=" <wsse:keyidentifier EncodingType=" ValueType=" 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> </AuthenticationStatement> <AttributeStatement> <Subject> <NameIdentifier>VVRTTL55M07D472I</NameIdentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-ofkey</ConfirmationMethod> <KeyInfo xmlns=" <xenc:encryptedkey xmlns:ds=" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod

13 Algorithm=" /> <ds:keyinfo> <wsse:securitytokenreference xmlns:wsse=" <wsse:keyidentifier EncodingType=" ValueType=" 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> <Attribute AttributeName="role" AttributeNamespace="urn:dedasso:attribute"> <AttributeValue>ME</AttributeValue> </Attribute> </AttributeStatement> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" /> <ds:signaturemethod Algorithm=" /> <ds:reference URI="#_a4f71af ec164694edef4361d4"> <ds:transforms> <ds:transform Algorithm=" /> <ds:transform Algorithm=" <ec:inclusivenamespaces xmlns:ec=" PrefixList="code ds kind rw saml samlp typens #default xsd xsi" /> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" /> <ds:digestvalue>oood1x8j7v2wb4zo3uqcb94vt2y=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>dawfelfslucp1qozzax3/54mnjhifmucwulyx8fglfrrbhdahpledl

14 YCa8c3iHKzY/RbMbhIty/ziFPwdv6KCXLY2EVYg4a1v1PiVqrpQxKd0XmyCr6H1KAZOSD 6KGREAbIFR94J2u5ygTRiF3kEHoA3j3ZTja+61DiqEhA9RXA=</ds:SignatureValue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidjzccavigawibagideaahma0gcsqgsib3dqebbauamigum QswCQYDVQQGEwJJVDEQMA4GA1UECBMHRmlyZW56ZTEQMA4GA1UEBxMHRmly ZW56ZTEXMBUGA1UEChMORGVkYWx1cyBTLnAuQS4xETAPBgNVBAsTCFN2aWx1c HBvMRIwEAYDVQQDEwlEZWRhbHVzQ0ExITAfBgkqhkiG9w0BCQEWEmRlZGFsdXND QUBkZWRhLmNvbTAeFw0wODA4MDQxNDQzMTRaFw0wOTA4MDQxNDQzMTRaMGA xczajbgnvbaytaklumrawdgydvqqiewdgaxjlbnplmrcwfqydvqqkew5ezwrhbh VzIFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEzARBgNVBAMTClRlc3RTZXJ2ZXIw gz8wdqyjkozihvcnaqebbqadgy0amigjaogbajbylbhcb/if54pwarr1rx/p30sd51 PeWu9SsY/Z/96HdnJFOYBl7Na/4VZ6404zBuMSl/el+GbWLcodJZMEcSF9c7bu+fhc7OW UbdEEoLlnuEbYmYy3Y2XE935e1/CJu+OJovX3fHzdbEtwJ8piF2HkBIgH6wYYM7AsCMp/ 76A1AgMBAAGjggEgMIIBHDAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1P cgvuu1nmiedlbmvyyxrlzcbdzxj0awzpy2f0ztadbgnvhq4efgquvyvywdkvmpst Z9lZRFzAXFQH LckwgcEGA1UdIwSBuTCBtoAU2QbXrQbbTpVrMswHI4MUq8KHPJyhgZqkgZcwgZQxCz AJBgNVBAYT AklUMRAwDgYDVQQIEwdGaXJlbnplMRAwDgYDVQQHEwdGaXJlbnplMRcwFQYDVQQ KEw5EZWRhbHVz IFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEjAQBgNVBAMTCURlZGFsdXNDQTEh MB8GCSqGSIb3 DQEJARYSZGVkYWx1c0NBQGRlZGEuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBAC PB5DlNlCaQB5h3 Smscyg4boO4MiQANMK5H6S+zWh72B8Ly/iYy1Rtg8VqKkbR44y2shYoD1Oooax4qFg1L uo1gsla8 o1j+uf8urb2ca5p8jsteqi4jqab7vxailgjgtv3x6dykvhwcvvegtc4mjcvu1xfzzs04zt p7xkqf +odh </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> </Assertion> </wst:requestedsecuritytoken> </wst:requestsecuritytokenresponse> </soapenv:body>

15 5.3.3 Messaggio chiamata Proxy-ws con token Saml firmato Il messaggio verso il modulo proxy è costituito nel body da una normale chiamata al servizio applicativo che si desidera invocare. Nell header deve essere inserito il token SAML ottenuto dalla chiamata effettuata all identity provider. Di seguito un esempio di header SOAP: <soapenv:header> <wsse:security xmlns:wsse=" wss-wssecurity-secext-1.0.xsd" soapenv:mustunderstand="true"> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:1.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" xmlns:axis2ns1="urn:oasis:names:tc:saml:1.0:assertion" xmlns:xsi=" xmlns:xsd=" AssertionID="_a4f71af ec164694edef4361d4" IssueInstant=" T15:16:03.058Z" CN=DedalusCA, OU=Sviluppo, O=Dedalus S.p.A., L=Firenze, ST=Firenze, C=IT" MajorVersion="1" MinorVersion="1"> <Conditions xmlns:axis2ns2="urn:oasis:names:tc:saml:1.0:assertion" NotBefore=" T15:16:03.058Z" NotOnOrAfter=" T16:16:03.058Z" /> <AuthenticationStatement xmlns:axis2ns3="urn:oasis:names:tc:saml:1.0:assertion" AuthenticationInstant=" T15:16:03.048Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"> <Subject xmlns:axis2ns4="urn:oasis:names:tc:saml:1.0:assertion"> <NameIdentifier xmlns:axis2ns5="urn:oasis:names:tc:saml:1.0:assertion">vvrttl55m07d472i</nameid entifier> <SubjectConfirmation xmlns:axis2ns6="urn:oasis:names:tc:saml:1.0:assertion"> <ConfirmationMethod xmlns:axis2ns7="urn:oasis:names:tc:saml:1.0:assertion">urn:oasis:names:tc:saml:1.0:c m:holder-of-key</confirmationmethod> <KeyInfo xmlns=" xmlns:axis2ns8=" <xenc:encryptedkey xmlns:xenc=" xmlns:ds=" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm=" /> <ds:keyinfo> <wsse:securitytokenreference> <wsse:keyidentifier EncodingType=" ValueType=" 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata>

16 <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> </AuthenticationStatement> <AttributeStatement xmlns:axis2ns9="urn:oasis:names:tc:saml:1.0:assertion"> <Subject xmlns:axis2ns10="urn:oasis:names:tc:saml:1.0:assertion"> <NameIdentifier xmlns:axis2ns11="urn:oasis:names:tc:saml:1.0:assertion">vvrttl55m07d472i</namei dentifier> <SubjectConfirmation xmlns:axis2ns12="urn:oasis:names:tc:saml:1.0:assertion"> <ConfirmationMethod xmlns:axis2ns13="urn:oasis:names:tc:saml:1.0:assertion">urn:oasis:names:tc:saml:1.0: cm:holder-of-key</confirmationmethod> <KeyInfo xmlns=" xmlns:axis2ns14=" <xenc:encryptedkey xmlns:xenc=" xmlns:ds=" Id="EncKeyIdurn:uuid:2FE4F707E339CD75D "> <xenc:encryptionmethod Algorithm=" /> <ds:keyinfo> <wsse:securitytokenreference> <wsse:keyidentifier EncodingType=" ValueType=" 1.1#ThumbprintSHA1">pfF7kNK/csb7tO/sRH4ZVqkHThE=</wsse:KeyIdentifier> </wsse:securitytokenreference> </ds:keyinfo> <xenc:cipherdata> <xenc:ciphervalue>ljwgs2spo7feagn+mwamvacsn916pfbvkvyfm7nwqgjbedn7yky fcuqvgtqiybialliumh1calik4doymf90bxiq8srl5mr4e9k+afosdfteaq/i1gfpjeood2leax oo5yrbbzxbixj3+9ncdvsuzmjulay5umretmwk4htf6ds=</xenc:ciphervalue> </xenc:cipherdata> </xenc:encryptedkey> </KeyInfo> </SubjectConfirmation> </Subject> <Attribute xmlns:axis2ns15="urn:oasis:names:tc:saml:1.0:assertion" AttributeName="role" AttributeNamespace="urn:deda-sso:attribute"> <AttributeValue xmlns:axis2ns16="urn:oasis:names:tc:saml:1.0:assertion">me</attributevalue> </Attribute> </AttributeStatement>

17 <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" /> <ds:signaturemethod Algorithm=" /> <ds:reference URI="#_a4f71af ec164694edef4361d4"> <ds:transforms> <ds:transform Algorithm=" /> <ds:transform Algorithm=" <ec:inclusivenamespaces xmlns:ec=" PrefixList="code ds kind rw saml samlp typens #default xsd xsi" /> </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" /> <ds:digestvalue>oood1x8j7v2wb4zo3uqcb94vt2y=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>dawfelfslucp1qozzax3/54mnjhifmucwulyx8fglfrrbhdahpledl YCa8c3iHKzY/RbMbhIty/ziFPwdv6KCXLY2EVYg4a1v1PiVqrpQxKd0XmyCr6H1KAZOSD 6KGREAbIFR94J2u5ygTRiF3kEHoA3j3ZTja+61DiqEhA9RXA=</ds:SignatureValue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidjzccavigawibagideaahma0gcsqgsib3dqebbauamigum QswCQYDVQQGEwJJVDEQMA4GA1UECBMHRmlyZW56ZTEQMA4GA1UEBxMHRmly ZW56ZTEXMBUGA1UEChMORGVkYWx1cyBTLnAuQS4xETAPBgNVBAsTCFN2aWx1c HBvMRIwEAYDVQQDEwlEZWRhbHVzQ0ExITAfBgkqhkiG9w0BCQEWEmRlZGFsdXND QUBkZWRhLmNvbTAeFw0wODA4MDQxNDQzMTRaFw0wOTA4MDQxNDQzMTRaMGA xczajbgnvbaytaklumrawdgydvqqiewdgaxjlbnplmrcwfqydvqqkew5ezwrhbh VzIFMucC5BLjERMA8GA1UECxMIU3ZpbHVwcG8xEzARBgNVBAMTClRlc3RTZXJ2ZXIw gz8wdqyjkozihvcnaqebbqadgy0amigjaogbajbylbhcb/if54pwarr1rx/p30sd51 PeWu9SsY/Z/96HdnJFOYBl7Na/4VZ6404zBuMSl/el+GbWLcodJZMEcSF9c7bu+fhc7OW UbdEEoLlnuEbYmYy3Y2XE935e1/CJu+OJovX3fHzdbEtwJ8piF2HkBIgH6wYYM7AsCMp/ 76A1AgMBAAGjggEgMIIBHDAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcG VuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUVYvYwDkvMPStZ9l ZRFzAXFQHLckwgcEGA1UdIwSBuTCBtoAU2QbXrQbbTpVrMswHI4MUq8KHPJyhgZqkg ZcwgZQxCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdGaXJlbnplMRAwDgYDVQQHEwdG axjlbnplmrcwfqydvqqkew5ezwrhbhvzifmucc5bljerma8ga1uecxmiu3zpbhvw cg8xejaqbgnvbamtcurlzgfsdxndqtehmb8gcsqgsib3dqejaryszgvkywx1c0 NBQGRlZGEuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBACPB5DlNlCaQB5h3Smscyg 4boO4MiQANMK5H6S+zWh72B8Ly/iYy1Rtg8VqKkbR44y2shYoD1Oooax4qFg1LuO1GS La8o1J+UF8urb2cA5P8JsTeqi4JQAB7VXaiLgjGtv3x6dyKVhWcVvEgTC4MjCVU1xFZzS0 4ZTp7xKqf+odh</ds:X509Certificate> </ds:x509data> </ds:keyinfo> </ds:signature> </Assertion> </wsse:security>

18 <wsa:to> etb</wsa:to> <wsa:messageid>urn:uuid:8a2238b7aa83b35dca </wsa:messageid> <wsa:action>documentrepository_provideandregisterdocumentsetb</wsa:action> </soapenv:header> Messaggio risposta proxy-ws In caso di risposta con esito positivo il modulo proxy risponde con il messaggio proprio del servizio invocato così come nel caso di errori che potremmo definire nativi che sono tornati dagli applicativi dopo i controlli effettuati dal modulo Access Gateway. In caso di errori durante la fase di trattamento del messaggio da parte del modulo proxy questo ritorna il seguente formato di errore: <soapenv:fault xmlns:soapenv=" <faultcode>axis2ns3:203</faultcode> <faultstring>org.apache.synapse.synapseexception: ruoli 'ME' non abilitati per operazione 'READ', documento 'registrystoredquery' e confidentiality code 'NA' (urn:ihe:iti:2007:registrystoredquery).</faultstring> <detail/> </soapenv:fault> Di seguito uno schema degli errori: Cod. Descrizione Errore 201 INVALID_DATE Data dell'asserzione SAML non valida 202 INCOMPATIBLE_ROLES Ruolo utente e/o operazione invocata non censito.(profile.xml) 203 ABILITAZIONE_MEDIATOR L operazione invocata non è consentita 204 REPOSITORY_RETRIEVE_MEDIATOR Repository non trovato N/A 205 OUT_FILTER Errore generico N/A filtraggio risultati 206 ROLE_MEDIATOR Errore generico AG N/A 101 DOCUMENT_TYPE_MEDIATOR Non è possibile stabilire N/A il tipo di documento 102 OPERATION_MEDIATOR Non è possibile stabile N/A il tipo di operazione 104 ROLE_RETRIEVER_COD_FISC_UTENTE Non è possibile estrarre N/A il CF dell utente 105 ROLE_RETRIEVER_COD_FISC_MMG Non è possibile estrarre N/A il CF del MMG 106 ARIT_SERVICES_NOT_STARTED Il client non è avviato correttamente 108 CUSTOM_CLASS_MEDIATOR Errore generico Access Gateway Comportamento Far effettuare nuovamente la login. N/A N/A Avviare nuovamente il Client Tentare nuovamente l invocazione

19 6 Client Legacy Sul fronte territoriale, l architettura proposta si apre all integrazione con il software applicativo installato sulla Postazione di Lavoro (PdL) dell attore MMG/PLS. Il flusso operativo, che chiameremo di pubblicazione, prevede che il MMG/PLS sia dotato di un software di cartella clinica provvisto dei componenti di Add-On e Plug-In, anch essi installati sulla PdL, che gli permettano, rispettivamente: la redazione dei documenti (PS, SSI, prescrizioni farmaceutiche e diagnostiche, ecc.) nel formato HL7 CDA2 e la trasmissione di questi al FSE (cfr. Figura 3). Il flusso operativo di consultazione consentirà la ricezione delle notifiche di disponibilità di documenti, il loro reperimento e l interrogazione del Registry. Client MMG/PLS PlugIn Back End Add-On Repository FSE: Prescrizioni Farmaceutiche e Diagnostiche Cartella clinica Informatizzata MMG/PLS Figura 3 Architettura della PdL

20