D3.1.5 Proof of concept for home healthcare
Contents
1. cccccccceccceccceeeceeece cece eeseeeseeeseeeseeeseeeseeeees 24 List of figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 interdependency chait tor WPS EE 3 Healthcare TPaaS architecture iicsicwcrcesesesnsviarosscoseneaseneiunssonnswsnsvidsesenteeneaenneiense reves 5 Home healthcare platform deployment block diagram ccccccecceecceeeeeeeeeeaeeeees 7 Trustworthy Healthcare Architecture 9 Normalu si CaSe aan mentee anette eeu net ore ner eee eee eee ee eee 10 ACUN UC RE 11 Independent device use Case 11 Figure 8 authenticated user use Case 12 Figure 9 authorized user use Case 12 Figure 10 Relationship dagram 13 Figure 11 OAUIIZ O protocol hei 15 Figure 12 normal use case protocol low 16 Figure 13 Independent device protocol flOW ccccccceececeeeeeeeeeeeeeseeeeeeseueeaeeeseeeeseeesaeeess 17 Figure 14 Authenticated user protocol How 19 Figure 15 Authorized user protocol fIOW cccccecceccceecceccceecceecceeecaeecseecseecaeeceescaeseaeeeaes 20 Figure 16 IP bounding with Healthcare appliance on TClouds TrustworthyOpestack dashDoard E 24 Figure 17 Ping of thbaas eServiCeS4life omg 24 Figure 18 Relationship among demo users into TPaaS ccccceeceseeeeeeeeceeeeseeesaeeeseeesaeess 25 Figure 19 TPaaS homepage 25 FOUC E e et EE 26 FIGULCZ Ie OGOCC E 26 Figure 22 App MU lincsisdsdstsnseantstsesantsidesantaisesdntsas decade sicdatstsd2. Ga Be 10 Ee Da Eug soccer oer errs rece a shee we ene Ge ecient eee epee aes epee en ene eee 10 de e 0 g 0 6 e 10 3 2 1 3 Authenticated user 11 Sea AUO O US T a E E EE E O EE I E EE iR 12 Sei El e EE 12 Bid SClOClICG Belt e te ee E 13 5 0 e ne OAU E 13 3 4 Basic protocol cccceeccsececeeeceeeeceeeceeeceeeeneeeseueeeeeseesaueseueeseeseeesaueeseeeseeeeags 16 3 4 1 Normal usecasee ccc cccccecceeccneceeeceecaeececaeecuecaeeceseeecaeseeeseesauesaesaeeseeseeeseesaeenaes 16 3 4 2 Independent device usecase 17 39 ehre iere 5 Ee EE 18 3 5 1 Authenticated user extension cecenii E a E E E 18 292 Au ihorized WISER EE esseni case eeeee ieee eects 20 26 une Eu En E O MR 21 TClouds D3 1 5 IV D3 1 5 Proof of concept for home healthcare Chapters Us r manual sssini inaina inaianei ainia aiamaa eiir sees 22 AA General Descrip eiseressen neee REENEN NEA EEEE EENEN ENNER EE RESE 22 All Vu EC ME eu 22 id NN CAS WAY re seat pees escent eee sense oneness eee eee eee 22 4 1 1 2 The Hard RE 22 dle Ee ell En E EE 24 4 1 3 App Market EE 26 4 1 4 Adding new friendS EE 27 E Developer ALCS tee 28 ao 2 e E 30 Aad FOU ANCA E 31 SNE Third Party lee dee AT ER Chapter 5 MEEEEMEEeeeeeEEEEEE 34 BIDHO ADN A E 36 TClouds D3 1 5 V D3 1 5 Proof of concept for home healthcare List of tables Table 1 Healthcare TPaaS layer description As written in Evans 20021 6 Table 2 Demo users Saved into the platform
3. VM properties audit auditmanager properties audit dbsessionmanager properties audit plainlog properties com tcloud portlet configuration properties configuration properties Configuration files has to be changed in order to connect to the remote databases and to the remote TClouds LogService TClouds D3 1 5 23 D3 1 5 Proof of concept for home healthcare 4 1 2 Login Sig in TPaaS Healthcare platform is available online at hitps tpaas eservices4life org DNS points to TClouds Infrastructure as we can see in the images below TCilouds Trustworthy OpenStack Dashboard Logged in as admin Impostazioni Help Sign Out Accesso e Sicurezza a mmm m ct ct et et H Hi bi j UN WII kA ka ka ki no lo tO lo W Figure 17 Ping of topaas eservices4life org eservices4life org domain is a domain owned by San Raffaele and refers to the IRIS research unit that whose researcher cooperates within TClouds consortium In order to login into the platform is necessary to be registered You can freely chose to register yourself or use one of the pre registered demo users NOTE password is 12345 for all users Table 2 Demo users saved into the platform Following is depicted the relationship among users TClouds D3 1 5 24 D3 1 5 Proof of concept for home healthcare Can R W all data Patrick Figure 18 Relationship among demo users into Haat The idea is to reproduce a very simple relationship b
4. close interaction between Activity 3 and Activity 2 in order to make sure that the platform and applications match the specifications and that the TClouds project achieves its overall objectives TClouds D3 1 5 1 TClouds D3 1 5 Proof of concept for home healthcare 1 3 Work package 3 1 Cloud Applications Data Structures for Home Healthcare Benchmark Scenario WP3 1 s main objective was to define the cloud architecture and specification for running TClouds selected application i e to provide technical requirements for cloud computing for the medical sector especially in the area of home healthcare devices and then turn the analysis into an architecture API and protocols for client side This architecture is closely linked and integrated with WP2 1 WP2 2 and WP2 3 The protocols will be validated in collaboration with the demonstrator implementation 1 4 Deliverable 3 1 5 Proof of concept for home healthcare 1 4 1 Overview This document provides explanatory information of the proof of concept for home healthcare trustworthy platform The document details the implementation design architecture and embedded trust protocols which extend the draft proof of concept for home healthcare in D3 1 3 It also considers security and resilience requirements for the underlying cloud environments The document provides some instructions on how the prototype can be used 1 4 2 Structure Chapter 2 introduces design and implementation
5. data providing easy and straightforward REST interfaces SSL TLS Channel Figure 4 Trustworthy Healthcare Architecture TClouds D3 1 5 9 D3 1 5 Proof of concept for home healthcare 3 2 Requirements In order to define the trust protocols first the use cases will be discussed Based on the use cases the relations between the various components will be defined Both use cases and relations will be used to define the trust protocols a boundary condition is to define RESTful protocols 3 2 1 Use cases Four use cases have been identified But before going into the specifics of each use case first the context will be sketched The trustworthy healthcare platform allows for the creation of applications apps in Figure 4 The trust protocols provide the means to give an app access to PHR EHR data in a secure and RESTful way authenticated and authorized when the PHR EHR data owner or his delegate has given consent The four use cases explained in the following chapters focus on the different ways consent can be given 3 2 1 1 Normal In the normal use case the data owner wants access to his or her data see Figure 5 In this case no delegation of rights is needed the owner can authorize the access The owner delegates the rights needed for the app to access the requested data Furthermore the owner subscribes to the app to make him known to the app The app takes care of the data access to the trustworthy healthcare platfo
6. device access to resource get refresh token l provide credentials l l l l l l l l l l l l l l i owner grant l l l l l l l l l l l l owner grant get refresh token user grant request resource owner id user refresh token user access token owner refresh token owner access token owner acces token user access token l l l l I requested resource owner id l l Figure 14 Authenticated user protocol flow TClouds D3 1 5 19 D3 1 5 Proof of concept for home healthcare 3 5 2 Authorized user extension The authorized user extension is based on the normal communication flow The only difference being that the data owner has delegated the right to grant access to another user However to be able to verify who accessed the data the authorized user has to logon This is described in the first part of Figure 15 the second part shows the access itself The actual delegation is not part of the trust protocol this is functionality of the privacy policies layer of the trustworthy healthcare platform and the extension uses this information via the authorization server user client authorization server resource server l l l I logon user authentication get refresh token provide credentials user credentials user grant use
7. in the privacy policies database When an app wants to retrieve information from the PHR EHR database it first has to check the privacy policies database whether or not this is allowed see Figure 10 Creating the delegates to relations and putting them into the privacy policies database is not part of the trust protocols this is done by the UI part of the trustworthy healthcare platform see Figure 4 The trust protocols ensure that this policy is enforced TClouds D3 1 5 12 TClouds D3 1 5 Proof of concept for home healthcare delegates to wm mee em e 4 emm lt d emm emm app is related to user PHR Figure 10 Relationship diagram 3 3 Selected protocol For implementing the requirements the OAuth2 0 protocol has been chosen The choice has been based on three properties 1 OAuth2 0 complies with the REST requirement 2 OAuth2 0 already supports the normal and the independent device use case 3 OAuth2 0 allows for extension of the protocol In this chapter the general idea behind OAuth2 0 will be explained In the section 3 4 the normal and independent device use cases will be handled these are standard OAuth2 0 and section 3 5 the extensions needed for the authenticated user and authorized user use cases will be introduced 3 3 1 OAuth2 0 According to abstract in RFC6749 The OAuth2 0 Authorization Framework The OAuth 2 0 authorization framework enables a third party application
8. interface it enables functionalities such as login sign in adding new friends privacy policy specification and auditing The Platform is accessible from the web at https tpaas eservices4life org TClouds D3 1 5 II TClouds D3 1 5 Proof of concept for home healthcare Contents afetten 1 1 1 TClouds Trustworthy Clouds cccccccseccceeeeseeeeseeeeseeeeeeeeseaeesseesseeesaeeeeas 1 1 2 Activity 3 Benchmark Applications amp User centric Evaluation 00 0000000 1 1 3 Work package 3 1 Cloud Applications Data Structures for Home Healthcare BENCINA I 5 CITA OF eres EEA 2 1 4 Deliverable 3 1 5 Proof of concept for home bealihcare 2 T amp T e E 2 E Ee 2 143 DVeViatlOn Trom Work DIAN E 2 1 4 4 Target Audience 2 14 0 Rektonio Oiler RE 3 Chapter 2 Home Healthcare proof of concept implementation 0000 4 2T e ele Lee 4 ene ene er ene eee 4 2 2 Archjechure ccc cecccecccecccecceeeceeeceecaeecaeeseeesuecauecaeecaeesueeeuesaueceeeseeeseeesaesauesages 4 20 SOlWalre abshracions and MOGUICS csis lt ascsccadecwidsacoansdeasocasiondasnseensaaesdeadeewtouncoans 6 2 4 Deployment scenario s nnoennennennsnnoenoannnnnsrnrrrrrrrnnrsrerrrrnrenrrsnrrnrrnrrsrrrnernenerene 7 Chapter 3 Trust pProtOCOlS ssoi 9 6 a 0 0 0 6 6 6 9 eee enter nen ee ene enone en ene eee eee no ee nee ee 9 3 2 Requirements ccccccccscecsecccececseeceueceacecseesaueceaeesseesaueceusenseeseeeseuseneeeseeesegs 10
9. logging auditing service has been deployed on TClouds as well Furthermore the user interface allows a user to manage the third party applications Finally several third party applications of medical use cases have been developed which can access users data under their privacy control The Healthcare TPaaS aims to be a platform that runs in the cloud in a secure and trustworthy fashion allowing third party healthcare applications to use it and benefit from the service it provides The idea is to build a trusted platform to manage health records on top of TClouds security components In particular the TPaaS platform is deployed on top if the trustworthy OpenStack provided by TClouds A2 The Healthcare TPaaS is a multilevel platform that aims to provide novel services such as Store trustworthy health related data relying on a trusted laaS Provide API for 3rd party apps to access to users health data in a privacy preserving manner Paas Provide API for 3rd party apps to use identity role management services PaaS Provide an interface to allow 3rd party app developers to register their application s in order to access the users data SaaS Allow End Users to manage their data and specify privacy policy about which data a particular application user can access SaaS TPaas is built in layer abstractions In this chapter we will describe each of them JPA layer this is the lowest layer abstraction It manages all
10. the persistency with the databases It is able to store health data in a specific database depending on the user policies and geo location moreover it manages all the transactions with the persistence unit and ensures that each task submitted to it has an atomic nature allowing highly parallelism and integrity of data TPaaS domain implements all the entities involved into the system from users to applications to relationships among them including privacy policies The domain layer knows all the actors involved and offers a set of interfaces that allows upper layers to use the domain properly The domain implements all the main security features from policy change to relationship management This TClouds D3 1 5 34 TClouds D3 1 5 Proof of concept for home healthcare means that any other layer needs to ask the domain layer in order to persist or modify a policy Application layer instead acts as a use case container in which every single use case in the platform is implemented and satisfied Log Service is an independent module used to store log information in the remote Log Service User interface consists in specific view to allow user to access the platform and their user area QOauth2Share is the trust protocol that enforces authorization and access control between application and end user The Healthcare Platform consists in 4 Virtual Machines to be deployed on the TClouds trustworthy Openstack A
11. 15614108e9a45td2a5 896e5035 52ac 490a 9705 181460964350 Fri Oct 04 17 5227 GMT 2013 TPAAS Sba64fach452355802bad4I9614108e9a45td2a5 2196 4919 351d 4605 bc 49 Da2a6401 1D48 Fri Oct 04 17 52 39 GMT 2013 TPAAS Sba64facb452355802bad415614106e9a45td2a5 attab4d0 61 f 4567 82b5 23d5c4n0t643 Fri Oct 04 17 53 06 GMT 2013 TPAAS Sba6 facb452355802bad415614106e9a45td2a5 cece717a ade4 485f ad4e cb 148304844 Fri Oct 04 18 00 36 GMT 2013 TPAAS SbaGdfacb452355602bad415614108e9a45td2a5 2336 48 6 2027 404b 8939 7 2350077a26 Fir Oct 04 18 11 22 GMT 2013 Shab4tach452395802bad 41961 4 108e9a45td2a5 60ce0eD 6124 4411 Geslo baBB26e98310 Fri Oct 04 18 14 55 GMT 2013 TPAAS Sba6b4tacb452355602bad415614106e9a4Std2a5 b337a750 e377 4671 Okcb 3792t47c1a3b Fri Oct 04 21 44 14 GMT 2013 TPAAS Sba6 fachb452356802bad415614108e9a45td2a5 90 3ed12 83e dad4 bdst In2c 7M 6ce6b Sat Oct 05 20 44 46 GMT 2013 TPAAS Sba64tacb452995602bad419614108e9a45td2a5 OfeStca7 a79a 472e Nes cS77a7Boo3td Verty Remove All Verification Started Status Resun Session i Ventication ID Sun Oct 06 17 59 27 GMT 2013 60cebeth6124 44 Seb0 bdsa2be9s3id S0dtb6b e196 41ctd 9941 1 S2ba02b8sa Entries of class class tclouds tpaas audit model TPaaSLogEntryData actionid appid dataOwperia datatypeld exalt spec result umestamp userid read actwatch patrick burrows eservicesdiite org activity Result with D entries true Fri Oct 04 16 11 22 GMT 2013 patrick bu read actwaten patrick burrows eservicesali
12. 3 1 5 5 TClouds D3 1 5 Proof of concept for home healthcare Description SaaS PaaS Responsible for showing information to the user and interpreting the Interface user s commands The external actor might sometimes be another computer system rather than a human user Application Defines the jobs the software is supposed to do and directs the Layer expressive domain objects to work out problems The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems This layer is kept thin It does not contain business rules or knowledge but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down It does not have state reflecting the business situation but it can have state that reflects the progress of a task for the user or the program Domain Layer Responsible for representing concepts of the business information or Model Layer about the business situation and business rules State that reflects the business situation is controlled and used here even though the technical details of storing it are delegated to the infrastructure This layer is the heart of business software Infrastructure Provides generic technical capabilities that support the higher Layer layers message sending for the application persistence for the domain drawing widgets for the Ul and so on The infrastructure layer may also support th
13. E READ Figure 26 Developer area Register a new application Name Philips Actwatch App Secret mysecret Publication_date 26 02 13 Ten Granter type F Need refresh tokens avaible only for owner apps Figure 27 Create a new App TClouds D3 1 5 29 D3 1 5 Proof of concept for home healthcare Ad Policies Current policies you ve selected Figure 28 Add minimum policy requirements to the new app 4 1 6 User Area The user area provides users with the ability to see some information about their developer activity whether the user is a developer and provides audit features to know who is using his data and how This feature access and uses TClouds LogService subcomponent in fact is possible to perform validation checks on the logged data TClouds D3 1 5 30 D3 1 5 Proof of concept for home healthcare T Leah Gs Lal Sy OY KI Gi eG S Homepage Market Relationships Develper area User Area Esci Personal details Pubic id a77d6tac 0a55 457c O7et e75372c34c08 Firstname marco Middiename abi Secondname abi Birthday 01 01 62 Emai marco adbi hotmal com Gender Male Developer Area Last month activity S 2 VM MN e eg 8 ee e gg 4 e o o o o o NEE WE o o o 8 8 0 WT aye p Log analizer 10 00 13 E 1109073 5 AnGR events related with one of your applications AUS events related with your personal data Ap events related with your usage of the platform Audit all event
14. SEVENTH FRAMEWORK PROGRAMME D3 1 5 Proof of concept for home healthcare Project number 257243 Project acronym TClouds Trustworthy Clouds Privacy and Resilience Project title oe for Internet scale Critical Infrastructure Start date of the project 17 October 2010 Duration 86 months FP7 IP Deliverable type Prototype Deliverable reference number ICT 257243 D3 1 3 PU 1 0 Activity and Work package 28 contributing to the deliverable pc September 2013 M36 Actual submission date 8 October 2013 Responsible organization Editor Mina Dong Dissemination level Revision O This document describes what has been accomplished during the development of the Home Healthcare Proof of Concept as a Trusted Platform as a Service on TClouds trustworthy OpenStack Kevwords Healthcare Trusted PaaS cloud based We l healthcare platform proof of concept D3 1 5 Proof of concept for home healthcare Editor Mina Deng PHI Contributors Marco Abitabile FCSR Kees Wouters Andres Monge Moreno PHI Disclaimer This work was partially supported by the European Commission through the FP7 ICT program under project TClouds number 257243 The information in this document is provided as is and no warranty is given or implied that the information is fit for any particular purpose The user thereof uses the information at its sole risk and liability The opinions expressed in this deliverable are thos
15. any user subscribed to the app In the authorized user use case the data owner explicitly gives another user the right to access his or her data D3 1 5 Proof of concept for home healthcare Based on the use cases the relations between the various components are defined Privacy rights as delegated to the apps or other users in the delegates to relation are stored in the privacy policies database When an app wants to retrieve information from the PHR EHR database it first has to check the privacy policies on whether or not this is allowed Creating the delegates to relations and putting them into the privacy policies database is not part of the trust protocols this is done by the UI part of the trustworthy healthcare platform The trust protocols ensure that this policy is enforced Trust protocols is designed and developed based on and extends the general idea behind OAuth2 0 The normal and independent device use cases can be handled by the protocolsof standard OAuth2 0 To support the authenticated user and authorized user use cases the OAuth2 0 protocol is extended The document also provides a user manual on how the proof of concept of the Healthcare TPaaS may be operated The distribution of the proof of concept of the Healthcare TPaasS is not provided in the form of binary files due to the complex installation Instead this platform is accessible online i e on the TClouds Trustworthy Openstack cloud With a graphical user
16. app is a phone book any user of the phone book has access to the phone numbers published Although in this case the user has to identify him before he is allowed to look into the phone book Like in the independent device use case the data owner should be careful with respect to the rights given to the app as the data owner has no prior knowledge on who will access the data TClouds D3 1 5 11 TClouds D3 1 5 Proof of concept for home healthcare delegates to subscribes to data access Trustworthy Healthcare Platform Figure 8 authenticated user use case 3 2 1 4 Authorized user In the authorized user use case the data owner explicitly gives another user the right to access his or her data see Figure 9 delegates to between owner and user From the app point of view the user is considered to be a data owner Hence the delegates to relation is between the user and the app To use the app the user subscribes to the app The access rights of the user can delegates are determined by the rights the owner granted him or her in the delegates to relation delegates to Trustworthy Healthcare Platform subscribes to data access delegates to Figure 9 authorized user use case 3 2 2 Relationships The use cases base their effectiveness on the rights that have been delegated to the apps or to other users in the delegates to relation Properties of the delegates to relation are stored
17. arco hsr it BloogpH marco abi hotmailcom READ DELETE RE CHANGE RELATIONSHIP PATIENT TO PATIENT mosconi marco hsr R HearRate marco abi hotmailcom UPDATE DELETE CREATE READ UP Figure 29 User area and audit 4 1 7 Admin area The platform administrator has some extra features not available to other user type DB backup by using DepSky TClouds subcomponents Extended log audit features over all the activities performed by all the users into the platform by using TClouds LogService subcomponent TClouds SAVE deployment check TClouds D3 1 5 31 D3 1 5 Proof of concept for home healthcare WOU cn en L e Gi Gi Homepage Marker Relationships Develper area User Area Administration BecamePatient You are a Patient BackupPHR Create a new backup Backup ALL PHR File size Kb Restore selected backup Backups Name Date Humpen C2FS_marcotest 07 29 2013 1 45 10738 aed2 de0 O4st ddse22e4edea 09 12 2013 2 8670b664 5797 49dc 9617 Gda5ac6icd3d 10 03 2013 2 7Se7ctdb dtt3 413t ab2d ab0tc 7560710 10 03 2013 1 6ca7t01e 4048 4ac0 8c63 D600007D966F 09 12 2013 2 07553a1D a25c 490d Dd9d 46590d409C0f 08 02 2013 1 Logger analizer 04 10 13 PS Get Sessions 06 10 13 Pa Recovered Sessions Select which to verity Time Label Machine 10 Seseson ID Fri Oct 04 17 52 06 GMT 2013 TPAAS Sba64tacb452355802bad4156 14106e9a4Std2a5 Sec6c572 8773 408c a2e2 a6Snd3d1d156 Fri Oct 04 17 52 22 GMT 2013 TPAAS Sba64fachb452355802bad4
18. ce active Log Service active Figure 3 Home healthcare platform deployment block diagram The Healthcare Platform consists in 4 Virtual Machines Appliance it is the main VM In here resides all the logic of the platform It manages platform users their relations Ul and all the business logic to work with DepSky LogService and Tailored Memecached sub component TClouds D3 1 5 7 It is able to receive data from external requests and dispatch it in the correct Database VM Due to its nature to have sensitive data mainly username and password plus all the user information we decided that it needs to have an encrypted VM in order to increase the security PHR VM it is a virtual machine that stores all the PHR data EHR_IT VM it stores all the EHR data of legal entities that resides in Italy e g an Italian hospital D3 1 5 Proof of concept for home healthcare EHR_DE VM tt stores all the EHR data of legal entities that resides in Germany e g a German hospital TClouds D3 1 5 8 D3 1 5 Proof of concept for home healthcare Chapter 3 Trust protocols Chapter Author Kees Wouters Andres Monge Moreno PHI 3 1 Introduction This chapter describes the trust protocols used at the application interface of the trustworthy healthcare platform see Figure 4 The goal of the trust protocols is to enforce the authorization rights given by a user to another user or an app with respect to accessing his or hers health
19. decisions of the proof of concept for home healthcare which is the Healthcare TPaaS Trusted Platform as a Service Discussions on design and implementation decisions will be provided with an overall architecture and underlying implementation modules Chapter 3 provides the trust protocols used at the application interface of the trustworthy healthcare platform The goal of the trust protocols is to enforce the authorization rights given by a user to another user or an app with respect to accessing the user s PHR EHR data Chapter 4 provides a user manual on how the proof of concept of home healthcare may be operated 1 4 3 Deviation from Work plan The implementation of this prototype was fully compliant with the defined work plan 1 4 4 Target Audience Target audience of this deliverable includes all TClouds partners and parties that wish to have a deeper view of the development result of the trustworthy healthcare platform The deliverable to be fully understood requires some background in software engineering and healthcare IT systems TClouds D3 1 5 2 TClouds D3 1 5 Proof of concept for home healthcare 1 4 5 Relation to Other Deliverables D3 1 5 covers Task 3 1 3 trust protocols and Task 3 1 4 Proof of concept prototypes Trust protocols are related to WP1 2 legal implications of cross border cloud implementations and WP2 3 cross layer security and privacy management Moreover D3 1 5 is based on D3 1 3 the draft proof of c
20. e In Transit Data Secure Privacy Connecting apps and devices to PHR data The Healthcare Trustworthy Platform uses a Sharing healthcare data may become a becomes easy with the Healthcare resilient storage feature to store data on senous privacy issue T Platform commodity clouds untrusted by nature in a With our platform solution users are enabled Giving a doctor the permission to check your secure way via fragmentation and encryption to manage every detall of their data and blood pressure trends or asking a frend to of the data have the ability to query the system and see share his data is done in a secure way sine who has had access to users data and why every single piece of data wil be sent in an Every activity of the Healthcare Trustworthy Having privacy policies that allow encrypted form to increase security of Piatform is encrypted as well as every single other people to acces user s data through sensitive private data piece of user s data This ensures that no third party applications gives her all the one not even the cloud owner can have power she needs to properly manage the ACCESS to and exploit the users data data Figure 21 Logged in 4 1 3 App Market Every user can access to the app market Here he she can see Whether an application still owns an Oauth2Share access token providing the ability to remove it Add remove grants to applications TClouds D3 1 5 26 D3 1 5 Proof of concept for home healthcare eat
21. e of the authors They do not necessarily represent the views of all TClouds partners TClouds D3 1 5 D3 1 5 Proof of concept for home healthcare Executive Summary This document describes the final proof concept of the Healthcare Trustworthy Platform as a Service or TPaasS for TClouds home healthcare It describes the requirements the architecture the underlying implementation modules and the user manual of the proof of concept which is built on top of TClouds as a benchmark application and user centric evaluation The implementation of TPaaS involves a service oriented architecture including services that guarantee security manage databases and provide a user interface The Healthcare TPaasS offers a set of on board software security modules and trust protocols In TClouds Activity 3 specifies cloud applications functionalities and requirements defines application prototypes to be implemented on the cloud platform and validates the application prototypes and the TClouds platform Two applications have been defined In this document we describe the proof of concept for home Healthcare Trusted Platform as a Service TPaaS which is the use case discussed in work package 3 1 The Healthcare TPaaS aims to be a platform that runs in the cloud in a secure and trustworthy fashion allowing third party healthcare applications to use it and benefit from the service it provides The Healthcare TPaaS is deployed on TClouds Trustworthy Op
22. e pattern of interactions between the four layers through an architectural framework Table 1 Healthcare TPaaS layer description As written in Evans 2003 Moreover the layering strategy adopted has to respect some straightforward principles Given a layer abstraction it is able to use lower levels It has references to it and knows how lower levels exchange data meanwhile it does not know upper levels functionalities nor have their references The most of the calls should be singletons giving session concept to higher levels e g Ul 2 3 Software abstractions and Modules As shown in Figure 2 and described in the previous chapter TPaaS is built in layer abstractions In this chapter we will describe each of them JPA layer this is the lowest layer abstraction It manages all the persistency with the databases It is able to store health data in a specific database depending on the user policies and geo location moreover it manages all the transactions with the persistence unit and ensures that each task submitted to it has an atomic nature allowing highly parallelism and integrity of data TPaaS domain implements all the entities involved into the system from users to applications to relationship among them including privacy policies The domain layer knows all the actors involved and offers a set of interfaces that allows upper layers to use the domain properly The domain implements all the main s
23. ecadsisdcdasshidenatisdcdassnidonacontcatd 27 Figure 23 Add a new app and accept policies cccecccceecceeeeceeeeseeeeeeeeseeeeseeesaueeseeesaeeess 27 Fod e 2A Fendo etr ana Ce E 28 Figure 25 Add new policy tO AN user 28 Figure 26 Developer are 29 Fig re 27 Create a NEW ADD E 29 Figure 28 Add minimum policy requirements to the new app 30 Figure 29 User area and aud 31 Figure 30 Admin area auditing ON user activities ccc cecceeccseeeseeeneeeneeeseeeneenseenseenaeeneeenaes 32 TClouds D3 1 5 VI D3 1 5 Proof of concept for home healthcare Chapter 1 Introduction Chapter Author Mina Deng PHI 1 1 TClouds Trustworthy Clouds TClouds aims to develop trustworthy Internet scale cloud services providing computing network and storage resources over the Internet Existing cloud computing services today are generally not trusted for running critical infrastructure which may range from business critical tasks of large companies to mission critical tasks for the society as a whole The latter includes water electricity fuel and food supply chains TClouds focuses on power grids electricity management and patient centric health care systems as main applications The TClouds project identifies and addresses legal implications and business opportunities of using infrastructure clouds assesses security privacy and resilience aspects of cloud computing and contributes to building a regulatory framewo
24. ecurity features from policy change to relationship management This TClouds D3 1 5 6 means that any other layer needs to ask the domain layer in order to persist or modify a policy D3 1 5 Proof of concept for home healthcare Application layer acts as a use case container in which every single use case in the platform is implemented and satisfied Log Service is an independent module used to store log information in the remote Log Service and used to record successful and failed access data attempts as well as privacy policy updates User interface UI consists in specific view to allow users to access the platform and their user area QOauth2Share is the trust protocol that enforces authorization and access control between application and end user 2 4 Deployment scenario Below it is described the deployment scenario that will be used into the TClouds Trustworthy Openstack Infrastructure Host 1_IT Host 2_DE 192 168 249 xxx 192 168 249 xxx Healthcare TVD ERH_DE SkyDrive fs PH R VM SS Log Service Client VM 512MB ram VM 4GB ram Debian 512MB ram debian mysql 512MB ram tomcat mysql debian mysql debian mysql Appliance VM ERH IT Log Service Tailored Memcached Trustworthy Openstack Trustworthy Openstack with Xen hypervisor ACESS SINE ACaasS active Remote Attestation active Remote Attestation active Crypto_aaS active Crypto_aaS active TVD active TVD active Log Servi
25. enStack integrated with effort from Activity 2 To manage the third party healthcare applications trust protocols and a user interface for access control has been provided so users can be in full control of their data and who has access to the data The Healthcare TPaaS is a multilevel platform that aims to provide novel services such as Store trustworthily health related data relying on a trusted laaS Provide API for 3rd party apps to access to users health data in a privacy preserving manner PaaS Provide API for 3rd party apps to use identity role management services PaaS Provide an interface to allow 3rd party app developers to register their application s in order to access the users data SaaS Allow End Users to manage their data and specify privacy policy about which data a particular application user can access SaaS Healthcare TPaaS follows the best practices in terms of software development Modularity has been taken into account in order to allow different develooment teams to interact among them and build the platform in parallel TPaaS is built in layer abstractions namely the JPA layer as the lowest layer abstraction the Domain layer that implements all the entity and main security features the Application layer that acts as a use Case container the Log Service the User interface that allows users to access the platform and user data Rest Services that allow the application layer to co
26. etween Katherine and his son Patrick for this reason Katherine has all privileges on Patrick s data being his guardian John instead is a Doctor and has Read abilities on Patrick and Katherine s data TPaas the safe place for your health data this is TpaaS TClouds D3 1 5 Secure In Transit Data Connecting apps and devices to PHR data becomes easy with the Healthcare Trustworthy Platform Giving a doctor the permission to check your blood pressure trends or asking a friend to share his data is done in a secure way since every single piece of data will be sent in an encrypted form to increase security of sensitive private data of the data Every activity of the Healthcare Trustworthy Platform is encrypted as well as every single plece of users data This ensures that no one not even the cloud owner can have access to and exploit the user s data Privacy Sharing healthcare data may become a serious privacy issue With our platform solution users are enabled to manage every detall of their data and have the ability to query the system and see who has had access to users data and why Having privacy policies that allow other people to acces user s data through third party applications gives her all the power she needs to property manage the data Figure 19 TPaaS homepage D3 1 5 Proof of concept for home healthcare Figure 20 Login the safe place for your health data this is TpaaS Secur
27. fe org activity Result with 4736 entries true Fri Oct 04 16 11 30 GMT 2013 patrick dt read marvin doctor patrick burrows eservicesdiite org white_ight Result with 0 entries true Fri Oct 04 16 1205 GMT 2013 katherine read marvin doctor patrick burrows eservcesdiite org white_tght Result with 6056 entries true Fri Oct 04 16 12 19 GMT 2013 katherine read actwatch patrick burrows eservcesdiite org activity Result with D entries true Fri Oct 04 16 13 06 GMT 2013 patrick bu F read actwaten patrick Durrows eservicesdiite org activity Result with 0 entries true Fri Oct 04 16 13 07 GMT 2013 patrick Di read actwatch patrick Durrows eservicesdiite org activity Result with 0 entries true Fri Oct 04 16 13 09 GMT 20173 patrick DL read actwatch patrick burrows eservicesdiite org activity Result with 4736 entries true Fn Oct 04 16 13 15 GMT 2013 patrick D read actwatch patrick burrows eservicesdiife org activity Result with 3352 entries true Fri Oct 04 16 13 38 GMT 2013 patrick dt Save analizer Start SAVE Figure 30 Admin area auditing on user activities 4 1 8 Third Party applications Esei In order to show potentialities of the Healthcare Platform we developed three third party applications They are owned by tpaas_admin eservices4life org user thus you can discover more information on these app my accessing the developer area of this user The three applications are Actigraphs allows users to upload Philips Actiwatch data a
28. frastructure features nonetheless if the Healthcare platform itself is not well designed an attacker may pass directly through the VM instead of trying to pass through an extremely hard to brake and complex cloud system TClouds D3 1 5 A TClouds D3 1 5 Proof of concept for home healthcare We evolved these ideas by enhancing the layering concept and introducing stronger design theories and a precise layering of the platform supporting ourselves with tools that allow TPaaS to be oriented to large concurrent systems l LA SSL TLS Channel Figure 2 Healthcare TPaaS architecture Health TPaaS follows the best practices in terms of software development In addition modularity has been taken into account in order to allow different develooment teams to interact among them and build the platform in parallel TPaaS Trustworthy Healthcare Platform s architecture takes inspiration of Domain Driven Design concepts and theory The whole system has been developed maintaining the Domain as the core of the problem This allows building safe strong and reliable code In fact building application and complex platform systems requires programming techniques that allow expanding the system capabilities without damaging other part or without creating new bugs of pitfalls TPaasS layering is done taking into account some concepts considering Evans 2003 s best practices in terms of application s layers TClouds D
29. healthcare applications to use it and benefit from the service it provides In particular the TPaaS platform is deployed on top if the trustworthy OpenStack provided by TClouds This section describes in detail the functionalities and services offered at the Platform as a Service PaaS layer In this we try to outline the meaning of Healthcare Trusted PaaS or simply Healthcare TPaaS Indeed some of the services actually have an interface for End Users and we consider them to be Software as a Service SaaS The Healthcare TPaaS is a multilevel platform that aims to provide novel services such as Store trustworthily health related data relying on a trusted laaS Provide API for 3rd party apps to access to users health data in a privacy preserving manner Paas Provide API for 3rd party apps to use identity role management services PaaS Provide an interface to allow 3rd party app developers to register their application s in order to access the users data SaaS Allow End Users to manage their data and specify privacy policy about which data a particular application user can access SaaS 2 2 Architecture It is well Known that the more lines of code are written the more the software is prone to have errors The main discriminators of this rule are good programmers and good software architecture TPaaS aims to be a Trustworthy platform Its trustworthy concept leverages most of TClouds in
30. irtual Machines First of all it is necessary to setup the VMs that acts as remote databases for PHR and HER data Requirements are Min 512MB Ram Min 1CPU TClouds D3 1 5 22 D3 1 5 Proof of concept for home healthcare Min 20GB HDD Linux Debian Wheezy Mysql Once installed provide the VM with a specific IP address and write it down for later use Preparation of the Appliance Virtual Machine Appliance VM is the one that have all the platform logic In order to make it run it is necessary to install the following software Linux Debian Wheezy Java 7 Tomcat Liferay Bundle Mysal TClouds DepSky subcomponent client TPaaS Healthcare Java code to be deployed into the Tomcat Liferay bundle Libvirt package installed TClouds SAVE client DepSky code SAVE code and Healthcare platform code can be retrieved by the respective TClouds partner and or downloaded from hitp svn tclouds project eu Once everything is in place it is necessary to change the IP addresses written into the following config files Starting from the Tomvat Liferay bundle TOMCAT BUNDLE webapps TCloua portlet WEB INF classes application properties application properties log properties auditmanager properties log properties remoteseclog properties log properties dbsessionmanager properties log properties seclog properties log properties plainilog properties log properties seclogconstants properties log properties plainlog
31. mmunicate to the outside world and trust protocol Oauth2Share that enforces authorization and access control between application and end user The Healthcare Platform consists in 4 Virtual Machines to be deployed on the TClouds trustworthy Openstack namely Appliance as the main VM the PHR VM it is a virtual machine that stores all the PHR data the EHR_IT VM that stores the EHR data of legal entities that resides in Italy and the EHR DE VM that stores all the EHR data of legal entities that resides in Germany TClouds D3 1 5 lI Please note that the list of verified security components provided by the TClouds Trustworthy OpensStack that the healthcare TPaaS is built on is provided in D3 3 4 The generic trust protocols describe the trust protocols used at the application interface of the trustworthy healthcare platform The goal of the trust protocols is to enforce the authorization rights given by a user to another user or an app with respect to accessing his or hers PHR EHR data and to do this in a REST full manner In order to define the trust protocols four use cases are discussed In the normal use case the data owner wants access to his or her data In this case no delegation of rights is needed the owner can authorize the access An independent device is a device including an app that can access data without direct owner control In the authenticated user use case the data owner gives consent to an app to access his or her data for
32. nd show that data into graphs Actigraphs application can be used directly by accessing to http actiwatch eservices4life org and by using the related Android device TClouds D3 1 5 32 Marvin 2 it consists of porting of Y1 Marvin application Marvin has been developed with the idea to develop a portal for patients and doctors to monitor patient generated data related with depression among this data there is Actiwatch light data Marvin 2 is the porting of the doctor features and allows doctors to access patients data collected by different devices into the Healthcare platform Marvin2 web app can be used directly by accessing to http marvin2 eservices4life org 8080 D3 1 5 Proof of concept for home healthcare DocMob android App it represents a demo application that is used by doctors to store and retrieve users data TClouds D3 1 5 33 D3 1 5 Proof of concept for home healthcare Chapter 5 Conclusion Chapter Author Mina Deng PHI In TClouds Activity 3 has specified cloud applications functionalities and requirements has implemented application prototypes on the cloud platform and has validated the application prototypes and the TClouds platform In this document we describe the proof of concept for home Healthcare Trusted Platform as a Service TPaaS which is the use case discussed in work package 3 1 The Healthcare TPaaS is deployed on TClouds Trustworthy OpenStack integrated with effort from A2 The
33. oncept and provides a list of security and privacy requirements which can be covered by IClouds security components as presented in D2 4 2 WP1 1 Requirements and M1 1 1 D242 Roadmap D313 WP2 4 Architecture and Integrated WP3 1 Platform Cloud Applications and D Data Structures for Home KR Healthcare Benchmark aga R1 222 Scenario Implications of Cross Border Cloud Implementations TASK 3 1 1 Technical Requirements for Privacy aware and Resilient Home Care D333 WP3 3 Validation and Evaluation of the TASK 3 1 2 Definition TCLOUDS Platform of application architecture Components APIs and Data structures WP2 1 Trustworthy Cloud Infrastructure TASK 3 1 3 Trust Protocols R3 1 3 1 WP4 1 Standardisation and Dissemination WP2 Cloud of Clouds Middleware for TASK 3 1 4 Proof of Concept Prototypes Adaptive Resilience TASK 3 1 5 Integration between Activities A amp A3 WP2 3 Cross layer Security and Privacy Management Figure 1 Interdependency chart for WP3 1 TClouds D3 1 5 3 D3 1 5 Proof of concept for home healthcare Chapter 2 Home Healthcare proof of concept implementation Chapter Author Marco Abitabile FCSR In this chapter we provide some insights on the implemented Home Healthcare Platform namely the Healthcare TPaaS 2 1 Introduction The Healthcare TPaaS aims to be a platform that runs in the cloud in a secure and trustworthy fashion allowing third party
34. ource owner and obtaining authorization The term access token used in the roles definition will be explained after the protocol flow description The protocol flow see Figure 11 shows three exchanges of information Starting point is when the client wants to access to a protected resource In order to achieve this the client first performs a request to the resource owner for an authorization grant The authorization grant is a credential representing the resource owner s authorization Please keep in mind that the grant can be limited in scope and in time In the next step the client by presenting the authorization grant requests the authorization server for an access token while in the third step the client can get the protected resource from the resource server by presenting the access token The lifetime of the authorization grant and the access token are different typically the grant has a very short lifetime whereas the access token has a lifetime in line with the usage of the protected resource http tools ietf org html rfc6749 TClouds D3 1 5 14 TClouds D3 1 5 Proof of concept for home healthcare Authorization Request a CT Owner Authorization Grant Authorization Grant Authorization Cent RN Server Access Token Access Token Resource Server Protected Resource Figure 11 OAuth2 0 protocol flow The access token provides an abstraction layer replacing different authorization construc
35. ous components are defined Privacy rights as delegated to the apps or other users in the delegates to relation are stored in the privacy policies database When an app wants to retrieve information from the PHR EHR database it first has to check the privacy policies on whether or not this is allowed Creating the delegates to relations and putting them into the privacy policies database is not part of the trust protocols this is done by the UI part of the trustworthy healthcare platform The trust protocols ensure that this policy is enforced Trust protocols is designed and developed based on and extends the general idea behind OAuth2 0 the normal and independent device use cases can be handled by the protocols of standard OAuth2 0 To support the authenticated user and authorized user use cases the OAuth2 0 protocol is extended The distribution of the proof of concept of the Healthcare TPaaS is not provided in the form of binary files due to the complex installation Instead this platform is accessible online With the graphical user interface of this platform a user can create his profile log in this platform add his friends and audit the behaviors of third party applications The Platform is accessible from the web at https tpaas eservices4life org TClouds D3 1 5 35 D3 1 5 Proof of concept for home healthcare Bibliography Evans E 2003 Domain Driven Design Addison Wesley TClouds D3 1 5 36
36. ppliance it is the main VM In here resides all the logic of the platform It manages platform users their relations UI and all the business logic to work with DepSky LogService and Tailored Memecached sub component PHR VM tt Is a virtual machine that stores all the PHR data EHR_IT VM it stores all the EHR data of legal entities that resides in Italy e g an Italian hospital EHR_DE VM it stores all the EHR data of legal entities that resides in Germany e g a German hospital The generic trust protocols describe the trust protocols used at the application interface of the trustworthy healthcare platform The goal of the trust protocols is to enforce the authorization rights given by a user to another user or an app with respect to accessing his or hers PHR EHR data and to do this in a REST full manner In order to define the trust protocols four use cases are discussed In the normal use case the data owner wants access to his or her data In this case no delegation of rights is needed the owner can authorize the access An independent device is a device including an app that can access data without direct owner control In the authenticated user use case the data owner gives consent to an app to access his or her data for any user subscribed to the app In the authorized user use case the data owner explicitly gives another user the right to access his or her data Based on the use cases the relations between the vari
37. r grant user grant refresh token user id request resource owner_id refresh token user id acess token l access token requested resource owner id Figure 15 Authorized user protocol flow TClouds D3 1 5 20 D3 1 5 Proof of concept for home healthcare 3 6 Implementation The extensions described in the previous chapters are implemented by extending the OAuth2 0 implementation of the Spring Security package http projects spring io spring security oauth The actual implementation can be found in the archive of the trustworthy healthcare platform TClouds D3 1 5 21 D3 1 5 Proof of concept for home healthcare Chapter 4 User manual Chapter Author Marco Abitabile FCSR In this chapter we describe the main functionalities of the home healthcare platform and application from a user perspective 4 1 General Description 4 1 1 Installation 4 1 1 1 The easy way Just download TPaasS Virtual Machines and deploy them into a cloud environment Appliance VM requirements Min 4GB Ram Min 4CPUs Min 20GB HDD PHR EHRs VM requirements Min 512MB Ram Min 1CPU Min 20GB HDD 4 1 1 2 The Hard way Installing the healthcare platform requires many subcomponents and software to be installed We will provide a brief description of the steps needed to make the system work Preparation of PHR EHRs V
38. rk enabling resilient and privacy enhanced cloud infrastructure The main body of work in TClouds defines an architecture and prototype systems for securing infrastructure clouds by providing security enhancements that can be deployed on top of commodity infrastructure clouds as a cloud of clouds and by assessing the resilience privacy and security extensions of existing clouds Furthermore I Clouds provides resilient middleware for adaptive security using a cloud of clouds which is not dependent on any single cloud provider This feature of the TClouds platform will provide tolerance and adaptability to mitigate security incidents and unstable operating conditions for a range of applications running on a cloud of clouds 1 2 Activity 3 Benchmark Applications amp User centric Evaluation Activity 3 focuses on the applications and the evaluation of the TClouds platform The activitys objective is to define and validate cloud applications architecture and specifications the medical and the smart grid use case For this purpose Activity 3 has specified cloud and application functionalities and requirements has defined application prototypes to be implemented on the cloud platform and has validated the application prototypes and the TClouds platform For this purpose the requirements defined in Activity 1 have served as a generic guideline which has been refined and consolidated in Activity 3 Finally there was a continuous and
39. rm Trustworthy Healthcare Platform subscribes to data access delegates to Figure 5 Normal use case 3 2 1 2 Independent device An independent device is a device including an app that can access data without direct owner control An example of such a device is the ActiWatch see Figure 6 This is a wrist wearable device that measures the activity of the wearer and the light conditions under which the activity is taking place TClouds D3 1 5 10 D3 1 5 Proof of concept for home healthcare Figure 6 ActiWatch In case of an independent device the data owner has given consent to the app controlling the device to access the data see Figure 7 The consent is given as part of the delegates to relation between the data owner and the app As the device will run without direct owner control one should be careful with respect to the rights given to the device There are several ways to restrict the rights e g by limiting the data fields which can be accessed by limiting the time that the device can work before renewal of the consent is needed etc delegates to Trustworthy Healthcare data access Platform Figure 7 Independent device use case 3 2 1 3 Authenticated user In the authenticated user use case the data owner gives consent to an app to access his or her data see Figure 8 delegates to for any user subscribed to the app see Figure 8 subscribes to An example of such an
40. s eege Sr a GO ES a a at a ee 3 E Market Applications avaible on market App Details Name Actiwatch Marvin4Patent EHR Publication_date 03 10 13 Granter type owner Marvin4Doctor This app has no token for you white light activity Mamm Applications avaible on market App Details Name San Raffaele Mobile Hee fdsafds Publication_date 01 00 13 Gtwsqdsa Granter type consumer San Raf i Mot He Figure 23 Add a new app and accept policies 4 1 4 Adding new friends From the Relationship tab is possible to see all the users that are registered into the platform and create grants to them You can also see who is giving you grants on their data TClouds D3 1 5 27 TClouds D3 1 5 Proof of concept for home healthcare Figure 24 Friends list and details Figure 25 Add new policy to an user 4 1 5 Developer Area Users that ask to become developers can access al to the developer area In this area you can register a new app that will appear into the app market and create policy templates that users have to accept in order to allow the app to access data TClouds D3 1 5 28 D3 1 5 Proof of concept for home healthcare e App Details Name San Raffaele Mobile Hearth Monitor Public id a7309ab9 51 492c acGa dbe Tee 848 Secret 12345 Granter type consumer Pubikaton_date 01 09 13 Policy tempiates BreathRate UPDATE CREAT
41. s involving you Extra Audit events by tags All Verity Remove V erfte ton Started Status Result Session ID Venficaton ID OO Thu Sep 12 01 24 32 GMT 2013 terminated true 71f445ae b214 4660 D1tc 29ac 7455 7eat 6241e900 e56a 4624 ab16 2003166f970 Thu Sep 12 01 24 33 GMT 2013 lerminated 06051020 0628 4802 9813 235ad52h0IM1 208 13a5F e3da 40cd a6ie f621Bfe48c ib Thu Sep 12 01 24 33 GMT 2013 mierrupted c false f cd1604 96 5 45ad 9386 06c2c 3032051 1590SB840 St22 45ic b12e 913329a446ea Entries of class class tclouds tpaas audit model PolicyManagementEntryData actiontype consumer Gatetype owne statusPost statusi CHANGE RELATIONSHIP PATIENT TO PATIENT mosconi marco hsr BioodpH marco abi hotmail com NO RE CHANGE RELATIONSHIP PATIENT TO PATIENT mosconimarcog merit ECG marco abi hotmail com READ DELETE CREATE RE REMOVE RELATIONSHIP PATIENT TO PATIENT mosconi marco hsr i ECG marco abi hotmail com NO DE ADD RELATIONSHIP PATIENT TO PATIENT Mosconi marco hsr it BioodpH marco abi hotmailcom READ DELETE NC CHANGE RELATIONSHIP PATIENT TO PATIENT mosconi mar o tsr 9 BioodpH marco abi hotmailcom READ DELETE RE CHANGE RELATIONSHIP PATIENT TO PATIENT mosconi marco hsrit HeanRate marco abi hotmailcom UPDATE DELETE CREATE READ NC CHANGE RELATIONSHIP PATIENT TO PATIENT mosconi maro hsr it HeartRate marco abi hotmail com UPDATE DELETE CREATE READ UP CHANGE RELATIONSHIP PATIENT TO PATIENT mosconim
42. t for home healthcare 3 4 2 Independent device use case The communication flow of the independent device use case looks a bit different since the owner is not going to be the initiator of the communication instead the client itself will be To show this more prominent the activity bars have been split so the upper part of Figure 13 is about setting up the client device and the lower part is about the client device retrieving or writing resources owner client authorization server resource server give device access to resource get refresh token provide credentials owner credentials J owner grant l owner grant owner grant refresh token refresh token access token access token protected resource Figure 13 Independent device protocol flow An example of the independent device communication flow is a blood pressure measurement device which automatically measures the blood pressure and writes the data to the trustworthy healthcare platform TClouds D3 1 5 17 TClouds D3 1 5 Proof of concept for home healthcare 3 5 Protocol extensions The Oauth2 0 protocol has been extended for the authenticated user and authorized user use cases Part of this will be solved in OAuth2 0 and part via the privacy policies of the trustworthy healthcare platform It is important to be aware that the refresh and access token do not need to refer to the identity of the owner or user In other words an
43. to obtain limited access to an HTTP service either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service or by allowing the third party application to obtain access on its own behalf TClouds D3 1 5 13 TClouds D3 1 5 Proof of concept for home healthcare Thus OAuth2 0 out of the box supports the normal use case on behalf of the resource owner and the independent device use case by allowing the third party application to obtain access on its own behalf To support this OAuth2 0 has defined four different roles and a protocol flow between these roles In this document only the basic flows will be described For an in depth view please refer to the official Oauth2 0 RFC The roles are Resource owner An entity capable of granting access to a protected resource When the resource owner is a person it is referred to as an end user Resource server The server hosting the protected resources capable of accepting and responding to protected resource requests using access tokens Client An application making protected resource requests on behalf of the resource owner and with its authorization The term client does not imply any particular implementation characteristics e g whether the application executes on a server a desktop or other devices Authorization server The server issuing access tokens to the client after successfully authenticating the res
44. tokens is not part of OAUth2 0 and can be defined according to the security requirements of the resource server OAuth2 0 itself relies on the HTTPS protocol to secure the communication channel Remark In the Trustworthy Healthcare Platform the protected resource see Figure 11 normally is data so in the remainder the protected resource of mosily referred to as data TClouds D3 1 5 15 D3 1 5 Proof of concept for home healthcare 3 4 Basic protocol The basic protocol supports the regular use cases i e normal and independent device are standard OAuth2 0 use cases Logging on onto the system is kept implicit in these cases 3 4 1 Normal use case Figure 12 depicts the communication flow of the normal use case The main difference with respect to the flow in Figure 11 is that a refresh token is used owner authorization server resource server request resource get refresh token provide credentials owner p owner credentials awner ee a nt owner grant owner grant refresh token token refresh token I I I access Ee access token req uested resource Figure 12 normal use case protocol flow An example of the normal communication flow is a patient requesting to read his blood pressure measurements of the last week TClouds D3 1 5 16 D3 1 5 Proof of concep
45. ts e g username and password with a single token recognized by the resource server This abstraction enables issuing more restrictive access tokens than the authorization grant used to obtain them as well as removing the resource server s need to recognize a wide range of authentication methods The format of the access token is up to the implementation and is no part of OAuth2 0 This leaves room for adapting the token s format to the security requirements of the resource server Some applications need very powerful access tokens e g long lifetime which are undesirable from a security point of view To handle this the client should be able to request access tokens on its own account To accommodate this OAuth2 0 has defined a refresh token The refresh token allows the client to request additional access tokens thus reducing the need for very powerful access tokens Normally this construction is used when a longer lifetime is needed than normally issued to an access token As described in the protocol flow in Figure 11 when requesting a resource with an invalid access token an error will occur The only option for the client is to ask a new grant from the resource owner In case of a refresh token the client can directly ask the authorization server for a new access token based on the evidence given by presenting the refresh token Security As the reader may notice security has been barely mentioned beside that the format of the
46. ybody providing the correct refresh and access tokens can have access to the protected resource One of the main issues for the trustworthy healthcare platform is traceability so the extensions are made in such a way that they provide the required traceability 3 5 1 Authenticated user extension The communication flow of the authenticated user use case Is similar to the independent device flow rights are delegated to the app but there is another user which is not the owner controlling the app see Figure 14 In order to access the data the user has to authenticate himself logon onto the system To support this the independent device flow is extended to handle the identity information This is done in several places e The owner identification is explicitly made part of the refresh token see first part of protocol flow in Figure 14 e The user who wants access to the data logs on she or he will get a refresh token including her or his identification second part Figure 14 e To access the data both refresh tokens need to request access tokens and both access tokens are needed to get the actual access last part Figure 14 Part of the process on the server side not shown in Figure 14 is logging of the identity of the user accessing the data and logging of the owner identity TClouds D3 1 5 18 D3 1 5 Proof of concept for home healthcare authenticated user owner client authorization server resource server l give
Download Pdf Manuals
Related Search