in het Intensieve Zorgen platform

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Inwendige ziekten Voorzitter: prof. dr. Martine De Vos

Effici¨ ent profielbeheer in het Intensieve Zorgen platform door Chris Wauman

Promotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Johan Decruyenaere Scriptiebegeleiders: ir. Sofie Van Hoecke, Kristof Taveirne

Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Inwendige ziekten Voorzitter: prof. dr. Martine De Vos

Effici¨ ent profielbeheer in het Intensieve Zorgen platform door Chris Wauman

Promotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Johan Decruyenaere Scriptiebegeleiders: ir. Sofie Van Hoecke, Kristof Taveirne

Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

VOORWOORD

i

Voorwoord

Het zoeken naar een thesisonderwerp nam niet zoveel tijd in beslag. Na de presentatie over de thesisonderwerpen bij INTEC waren vooral de praktische scripties over het e-Health platform me bijgebleven. Bij de nadere uitleg van Sofie stak deze over de beveiliging van het platform er bovenuit. Binnen de ICT is mijn grootste interesse immers steeds naar beveiligingsaspecten gegaan. Reeds bij het vakoverschrijdend project uit het derde jaar Bachelor in de ingenieurswetenschappen had ik de beveiliging van de netwerkcommunicatie voor mijn rekening genomen via SSL over RMI. Daarnaast was het ook zeer leuk en een extra motivatie om te weten dat mijn thesis zou gebruikt worden als basis voor de eigenlijke implementatie van autorisatie in het ICSP. Dit werk is er niet alleen gekomen door mijn interesse in de materie, er zijn nog tal van mensen die, elk op hun manier, hun steentje bijgedragen hebben om dit werk te maken tot wat het nu is. Graag wil ik dan ook van deze gelegenheid gebruik maken om hun te bedanken. Ik zou graag in de eerste plaats mijn thesisbegeleiders, Sofie en Kristof, willen bedanken voor alle tijd en energie die ze in dit werk staken. Hun advies en begeleiding waren van onschatbare waarde. Tevens wens ik ook mijn promotoren te bedanken voor hun vertrouwen en de geboden kans. Mensen voor wie geen dank te veel kan zijn, zijn mijn ouders. Zij hebben mij in de loop der jaren alle kansen gegeven die ik maar wou en hebben mij ten volle gesteund in mijn keuzes. Zij hebben mij de mogelijkheden gegeven om te staan waar ik nu sta, om mij te verdiepen in mijn interesses en mij te ontplooien. Daarnaast dank ik ook Kurt, mijn broer. In het bijzonder wil ik ook nog mijn vader en Sofie bedanken voor het nalezen van de hele scriptie en het in de gaten houden van de gebruikte spelling en grammatica, consistentie,... Ook dank aan al mijn vrienden die voor ontspanning zorgden tijdens het maken van de thesis en de mensen die steun boden wanneer het wat tegen zat of me extra motiveerden wanneer het

werk goed opschoot. Tot slot wil ik nog een aantal mensen bedanken die hier niet bij naam vermeld zijn maar toch op een of andere manier voor mij een uitlaatklep geweest zijn of die mij gesteund hebben. Bedankt!

Chris Wauman, juni 2009

TOELATING TOT BRUIKLEEN

iii

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Chris Wauman, juni 2009

Effici¨ ent profielbeheer in het Intensieve Zorgen platform door Chris Wauman Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2008-2009 Promotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Johan Decruyenaere Scriptiebegeleiders: ir. Sofie Van Hoecke, ir. Kristof Taveirne Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Inwendige ziekten Voorzitter: prof. dr. Martine De Vos

Samenvatting In dit werk wordt wordt gekeken hoe men autorisatie kan bekomen via XACML en RBAC in een web service omgeving. Daarnaast worden ook enkele e-Health aspecten onderzocht specifiek voor het Intensive Care Service Platform (ICSP), zoals privacy, ondersteuning van een noodgeval situatie, etc. Ten slotte wordt ter volledigheid ook de externe beveiliging (authenticatie en encryptie) bekeken voor het ICSP.

Trefwoorden e-Health, web services, XACML, RBAC, security

Efficient access control in the Intensive Care Service Platform Chris Wauman Supervisor(s): Filip De Turck, Johan Decruyenaere, Sofie Van Hoecke, Kristof Taveirne Abstract— In this article, authorisation is being investigated for the Intensive Care Service Platform (ICSP) through XACML and RBAC. In addition, a complete architecture is suggested and for completeness, security technologies, such as authentication and encryption, will be added. Keywords—e-Health, Web service, XACML, RBAC, security

I. I NTRODUCTION

T

HE Intensive Care Service Platform integrates all actors in the medical diagnostic process, such as doctors, nurses, etc. Since the architecture consists of multiple Web service components, that separate functionality, it is easily extensible. It is obvious that security is important to this platform as medical data from patients are processed and sent. Firstly, violations on the inside must be avoided through access control. It is not allowed that any doctor or nurse has access to any medical service, or that he or she will be allowed to view the complete dataset. Secondly, the system must also ensure authentication and encryption, so that violations from the outside are impossible. In this abstract, authorisation through XACML and RBAC is being investigated for the ICSP. In addition, an complete architecture is suggested and for completeness, security technologies, such as authentication and encryption, will be added. II. AUTHORISATION A. XACML eXtensible Access Control Markup Language (XACML) is the first standard for access control and was for the first time published by the Organization for the Advancement of Structured Information Standards (OASIS) in 2003. The current standard is XACML 2.0[1]. XACML has two languages. The first, the policy language, is responsible to describe general access control requirements. The second language, the request / response language, allows to compose a query to find out if a particular action on a resource by a certain subject is allowed or not. XACML provides through the policy language a solution for various e-Health issues such as privacy and the emergency case, it supports RBAC and the standardized HL7 permissions, use of metadata for resources, for example for blocking access to unfinished research results, etc B. RBAC Role-Based Access Control (RBAC) is a method to prevent unauthorized users to access a computer system. Just as in an organization, different users get a role. These roles are associated with given permissions (the allowance to perform a particu-

lar action). Important here is that a user is not given permissions directly, but only through the role assigned to him or her. RBAC is standardized by ANSI INCITS in 2004[2] and is supported by XACML through the standardized RBAC Profile for XACML 2.0. C. Architecture with authorisation There are two possible places to perform authorisation by XACML in an e-Health broker platform. Firstly, access control can be performed in the broker (implemented as Apache Synapse) by a mediator class. Secondly, access control can be performed in a handler class just before a Web service in the handler chain. The RTT for both cases is given in Table I.

handler class class meditor

RTT(ms) 38,55 23,99

Standard deviation 7,24 9,16

TABLE I RTT FOR A WEB SERVICE CALL WITH AUTHORISATION

III. S ECURITY A. Authentication Authentication is achieved by means of a Security Token Service (STS), as described in WS-Trust[3]. The user authenticates itself to the STS through login/password, X.509, Kerberos, or an electronic identity card. The STS provides an unique SAML Assertion which can be used to identify the user. B. Encryption Data confidentiality and integrity can be achieved through transport layer security (TLS) or message layer security. TLS[4] provides point-to-point security and is a well-known, proven and well performing solution. One advantage of TLS is that it is independent of the application protocol. The protocol runs on top of transport protocols (TCP/IP) and application protocols such as HTTP. It uses the RSA asymmetric encryption protocol for the exchange of a symmetric key and for authentication during the handshake process. Then the symmetric key is used for encryption of the data. Message layer security is obtained by WS-Security (WSS)[5] and provides end-to-end security. Encryption is obtained by XML Encryption, an asymmetric encryption protocol. It has the advantage to be independant of the transport layer, the possibility to secure data over multiple SOAP hops and to support partial encryption. WSS also provides the possibility to add a

digital signature through XML Digital Signature. Performance can be improved by using WS-SecureConversation, a WSS extension. WS-SecureConversation[6] provides a mechanism similar to TLS where a symmetric key is exchanged through asymmetric encryption. A summary is given in Table II. TLS end-to-end security point-to-point security transport layer security message layer security encryption partial encryption digital signature

WSS x

x x x

C.2 Encryption through WS-SecureConversation Because WSS provides end-to-end security, authorisation in the broker is impossible. The information in the SOAP body would be encrypted and inaccessible. Therefore, authorization is only done in the handler class. The communication between the user and the STS is secured through WS-SecureConversation as is the communication between the user and the Web service and between de handler class and the STS. This is shown in Figure 2.

x x x x

TABLE II TLS VERSUS WSS

C. Architecture with security Two possible architectures are proposed. The first one wil use TLS as method to provide encryption and the second one will use WSS. C.1 Encryption through TLS Because TLS provides point-to-point security, authorisation through XACML can take place in the broker. The Web services will only accept calls from the broker. The communication between the user and the STS is secured through 2-way SSL as is the communication between the broker and the STS and between the broker and the Web service. Communication between the user and the broker is secured through 1-way SSL and the XML Digital Signature option of WSS. This is shown in Figure 1.

Fig. 2. Detailed architecture which provides authorisation through XACML in a handler class, authentication by a STS and encryption through WSSecureConversation

IV. C ONCLUSION Authorisation through the first access control standard XACML has certainly a future. XACML provides a solution for various e-Health issues such as privacy and the emergency case, it supports RBAC and the standardized HL7 permissions, use of metadata for resources, for example for blocking access to unfinished research results, etc Furthermore, the entire ICSP can be protected through interoperable standards. Authorisation through XACML, authentication through WS-Trust and SAML and data confidentiality and integrity through TLS or WSS. R EFERENCES [1] OASIS, eXtensible Access Control Markup Language (XACML) Version 2.0, http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-corespec-os.pdf [2] ANSI INCITS, NIST, Role Based Access Control, http://csrc.nist.gov/rbac/ [3] OASIS WS-Trust 1.4, http://docs.oasis-open.org/ws-sx/wstrust/v1.4/os/ws-trust-1.4-spec-os.pdf [4] IETF, RFC: 5246: The Transport Layer Security (TLS) Protocol Version 1.2, http://tools.ietf.org/html/rfc5246 [5] OASIS WS-Security Core Specification 1.1, http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf [6] OASIS WS-SecureConversation 1.4, http://docs.oasis-open.org/ws-sx/wssecureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf

Fig. 1. Detailed architecture which provides authorisation through XACML in a broker, authentication by a STS and encryption through TLS

INHOUDSOPGAVE

v

Inhoudsopgave Voorwoord

i

Toelating tot bruikleen

iii

Overzicht

iv

Inhoudsopgave Gebruikte afkortingen

v viii

1 Inleiding

1

2 Technologiestudie XACML en RBAC

4

2.1

2.2

2.3

eXtensible Access Control Markup Language . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Waarom XACML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.3

Werking XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.4

Huidige standaard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.1.5

Bestaande open source implementaties van XACML . . . . . . . . . . . .

13

Role-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.1

Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.2

Standaard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.3

Core and hierarchical RBAC profile of XACML v2.0 . . . . . . . . . . . .

17

e-Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.1

Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.2

Noodgeval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.3.3

Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

INHOUDSOPGAVE

2.3.4

vi

Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Testen XACML

20 22

3.1

Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.2

Sun’s XACML Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.2.1

Ondersteuning referenties . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2.2

Prestatietesten Sun’s XACML Implementation . . . . . . . . . . . . . . .

24

3.2.3

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

Drie mogelijke oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.3.1

Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.3.2

Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.3.3

Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3.4

Functionele testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.3.5

Load testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.3.6

Voor- en nadelen van de verschillende locaties . . . . . . . . . . . . . . . .

35

3.3.7

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.3

4 Architectuur design

38

4.1

Architectuurvoorstel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.2

Policy repository voor zorgomgeving . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.2.1

Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.2.2

Noodgeval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.2.3

Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.2.4

Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.3.1

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.3.2

RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.3

5 Technologiestudie externe beveiliging

58

5.1

Transport Layer Security

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.2

WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

5.2.1

WS-Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.2.2

WS-SecureConversation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.3

INHOUDSOPGAVE

5.3.1 5.4

5.5

vii

Security Assertion Markup Language . . . . . . . . . . . . . . . . . . . . .

63

WS-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.4.1

WS-XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

Beveiliging ICSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6 Architectuur met externe beveiliging

66

6.1

TLS vs WSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.2

Uitbreiding architectuur met externe beveiliging . . . . . . . . . . . . . . . . . .

67

6.2.1

Via TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

6.2.2

Via WSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.3.1

Metro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.3.2

RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.3

7 Conclusie

74

7.1

Conclussie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

7.2

Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

A Broncode

76

A.1 Voorbeelden bij hoofdstuk 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

A.1.1 Voorbeeld van PolicySet . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

A.1.2 Voorbeeld van RPS en bijhorende PPS . . . . . . . . . . . . . . . . . . . .

78

A.1.3 Voorbeeld van HasPrivilegesOfRole Policy en bijhorende XACML request

81

A.1.4 Voorbeeld van Role Assignment Policy . . . . . . . . . . . . . . . . . . . .

83

A.2 Voorbeelden bij hoofdstuk 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

A.2.1 urn:eHealth:ICSP:policysetid:N . . . . . . . . . . . . . . . . . . . . . . . .

85

A.2.2 urn:eHealth:ICSP:policysetid:N:PermCollections . . . . . . . . . . . . . .

87

A.2.3 urn:eHealth:ICSP:policysetid:N:RPS:physician-vrole . . . . . . . . . . . .

91

A.2.4 urn:eHealth:ICSP:policysetid:N:PPS:physician . . . . . . . . . . . . . . .

91

A.2.5 urn:eHealth:ICSP:policysetid:CDA . . . . . . . . . . . . . . . . . . . . . .

94

A.2.6 urn:eHealth:ICSP:policysetid:MA . . . . . . . . . . . . . . . . . . . . . . .

96

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen ANSI

American National Standards Institute

EPAL

Enterprise Privacy Authorization Language

ESB

Enterprise Service Bus

HITSP

Healthcare Information Technology Standards Panel

HL7

Health Level 7

ICSP

Intensive Care Service Platform

IETF

Internet Engineering Task Force

INCITS

InterNational Committee for Information Technology Standards

INTEC

Department of Information Technology

LAN

Local Area Network

MA

Masked access

NIST

National Institute of Standards and Technology

OASIS

Organization for the Advancement of Structured Information Standards

OECD

Organisation for Economic Co-operation and Development

PAD

Policy Administration Point

PDP

Policy Decision Point

PEP

Policy Enforcement Point

PIP

Policy Information Point

PPS

Permission PolicySet

QoS

Quality of Service

RBAC

Role-Based Access Control

REA

Role Enablement Authority

RPS

Role PolicySet

SAML

Security Assertion Markup Language

viii

GEBRUIKTE AFKORTINGEN

SICS

Swedish Institute of Computer Science

SOAP

Simple Object Access Protocol

SSL

Secure Sockets Layer

SSO

Single Sign-On

STS

Security Token Service

TC

Technical Committee

TLS

Trasport Layer Security

UBA

User based access

UDDI

Universal Description Discovery and Integration

WSDL

Web Services Description Language

WSS

Web Service Security

XACML

eXtensible Access Control Markup Language

XKMS

XML Key Management Specification

ix

INLEIDING

1

Hoofdstuk 1

Inleiding Binnen de vakgroep informatietechnologie (INTEC) is, in samenwerking met de Intensieve Zorgen van het UZ Gent, een architectuur ontworpen voor automatische medische diagnose op basis van patiënt monitoringgegevens, genaamd het Intensive Care Service Platform (ICSP). Dit platform integreert alle actoren binnen het medisch diagnose proces zoals labo’s, monitoren, artsen, verpleegkundigen, etc. Aangezien de architectuur bestaat uit meerdere web service componenten, die functionaliteit (database toegang, inschrijving, communicatie, etc) scheiden, is de architectuur eenvoudig uitbreidbaar. Een platform prototype is al ge¨ımplementeerd en wordt momenteel door het IZ geëvalueerd, zoals te zien is in Figuur 1.1. Er bestaan meerdere web services die allen toegang hebben tot één of meerdere databanken. Nadat men geauthenticeerd is via zijn eigen identiteit, steunt de autorisatie op de eed van Hippocrates. Het is vanzelfsprekend dat beveiliging van groot belang is bij dit platform aangezien er medische data van de patiënten verwerkt en verstuurd wordt. Enerzijds dienen inbreuken van binnenaf voorkomen te worden via toegangscontrole. Het is immers niet toegestaan dat iedere arts of verpleegkundige zomaar toegang krijgt tot elke medische service, of hiervan de volledige dataset zal mogen inkijken. Anderzijds moet er ook voor authenticatie en encryptie gezorgd worden, zodat inbreuken van buitenaf onmogelijk zijn. Toegangscontrole is de mogelijkheid om het gebruik van een bepaalde resource (bv service of medisch dossier van een patiënt) door een bepaalde gebruiker al dan niet toe te laten. Tot voor kort werden permissies per gebruiker individueel toegewezen. In het UZ dat over meer dan 5500 medewerkers [1] beschikt is zo’n systeem echter niet praktisch. Stel u immers voor dat u van meer dan 5500 medewerkers de bevoegdheden zou moeten beheren en up to date houden. Als

INLEIDING

2

Figuur 1.1: ICSP nu

men er nog rekening mee houdt dat er jaarlijks meer dan 400000 consultaties [1] plaatsvinden en de bevoegdheden van een medewerker kunnen verschillen per patiënt, dan komt men snel tot de vaststelling dat deze methode niet schaalbaar is. In de meeste huidige bedrijven, en ook in het UZ Gent, is er een hiërarchie in het personeel. Elke medewerker heeft een rol en heeft via deze rol bepaalde bevoegdheden. Het zou dan ook logisch zijn om toegangscontrole te doen op basis van deze rollen, die beperkt zijn in aantal, en niet op individuele bevoegdheden. Dit is weergegeven in Figuur 1.2, waar is aangegeven dat het systeem de gebruikers behandelt via hun rol en niet via hun identiteit. Binnen dit afstudeerwerk zal onderzocht worden hoe service en data autorisatie op de meest efficiënte manier kan ontworpen worden, gebruikmakend van gebruikersrollen. Op die manier kan per gebruikersrol beslist worden welke services toegankelijk zijn, alsook welke data ingekeken mogen worden. Hiervoor zal de huidige standaard voor rolgebaseerde toegangscontrole, RBAC, worden bestudeerd, alsook de eerste standaard voor toegangscontrole, XACML. Verder zal onderzocht worden hoe het huidige broker platform kan uitgebreid worden met deze toegangscontrole mechanismen en welke inpact dit heeft op beveiligingsmechanismen zoals authenticatie en encryptie.

INLEIDING

3

Figuur 1.2: ICSP met rolgebaseerde toeganscontrole

De structuur van de scriptie is als volgt: Hoofdstuk 2 ’Technologiestudie XACML en RBAC’ bevat een literatuurstudie over XACML, RBAC en de toepassing van beide in een e-Health omgeving. Hoofdstuk 3 In ’Testen XACML’ wordt de prestatie bekeken van een XACML implementatie en wordt gekeken op welke plaats in een web service omgeving er het beste aan toegangscontrole kan worden gedaan. Hoofdstuk 4 In ’Architectuur design’ wordt er, op basis van de resultaten uit hoofdstuk 3, een ultieme architectuur voorgesteld voor een web service omgeving waarin men aan toegangscontrole wil doen. Hoofdstuk 5 ’Technologiestudie beveiliging’ behandelt de literatuurstudie van authenticatie, encryptie en beveiligingstechnieken in een web service omgeving. Hoofdstuk 6 In ’Architectuur met externe beveiliging’ wordt de architectuur uit hoofdstuk 4 uitgebreid met externe beveiliging. Hoofdstuk 7 ’Conclusie’ behandelt het toekomstig werk en hier wordt ook een globale conclusie geformuleerd.

TECHNOLOGIESTUDIE XACML EN RBAC

4

Hoofdstuk 2

Technologiestudie XACML en RBAC Binnen dit hoofdstuk wordt er een literatuurstudie uitgevoerd over eXtensible Access Control Markup Language (XACML), Role-Based Access Control (RBAC) en de toepassing van beide in een e-Health omgeving.

2.1

eXtensible Access Control Markup Language

Voor XACML wordt enerzijds de werking bekeken van toegangscontrole met XACML in het algemeen en anderzijds gedetailleerd de twee talen, de policy language en de request/response language, die deel uitmaken van de standaard. Vervolgens wordt ook de standaard en de uitbreidingen in de verschillende profielen in detail bekeken en de bestaande open source implementaties met elkaar vergeleken.

2.1.1

Waarom XACML?

Er zijn meerdere voordelen van XACML ten opzichte van de verschillende bestaande bedrijfseigen en applicatiespecifieke talen zoals bijvoorbeeld EPAL[2, 3] of Rei[4]. Allereerst is XACML een erkende standaard. Het is dus beoordeeld door een groep experts en gebruikers. Verder hoef je geen eigen beveiligingssysteem uit te werken en alle gevoelige aspecten van een nieuwe taal in detail te bekijken.

2.1 eXtensible Access Control Markup Language

5

XACML is generiek in dat opzicht dat in plaats van toegangscontrole in een specifieke omgeving of voor een specifieke resource te voorzien, het kan gebruikt worden in elke omgeving. Een policy kan gebruikt worden voor heel verschillende soorten applicaties en policy management wordt een heel stuk eenvoudiger wanneer slechts één gemeenschappelijke taal wordt gebruikt. XACML is gedistribueerd in die zin dat policies naar andere policies kunnen verwijzen, die zich niet noodzakelijk op dezelfde locatie bevinden. Verder kunnen ook de verschillende componenten van XACML zich op verschillende locaties bevinden en communiceren via Security Assertion Markup Language (SAML)[5]. De standaard is reeds enorm uitgebreid, zodat de meeste omgevingen niet zelf voor eigen uitbreidingen hoeven te zorgen. Het voorziet immers reeds meerdere data typen, functies en algoritmen om de resultaten van verschillende policies te combineren. Verder zijn in de standaard reeds verschillende profielen voorzien voor integratie met andere standaarden zoals SAML (OASIS) en XML Digital Signature (W3C)[6].

2.1.2

Algemeen

XACML is een XML-gebaseerde taal voor toegangscontrole, die is gestandaardiseerd door de Organization for the Advancement of Structured Information Standards (OASIS)[7] in 2003. In het Technical Committee (TC)[8] zetelen onder meer vertegenwoordigers van Cisco Systems, IBM, Oracle Corporation, Sun Microsystems, The Boeing Company, Veterans Health Administration, etc. XACML bestaat uit twee talen [9]. De eerste, de policy language, is verantwoordelijk voor het beschrijven van algemene toegangscontrole eisen. Het bevat ook de mogelijkheid voor het definiëren van nieuwe datatypes, nieuwe functies en nieuwe algoritmen voor het combineren van deze twee. De tweede taal, de request/response language, maakt het mogelijk om een query te formuleren waarmee men kan achterhalen of een bepaalde actie op een resource al dan niet toegelaten is. Elk antwoord bevat een beslissing in de vorm van één van de volgende vier mogelijkheden: Permit: De actie is toegelaten. Deny: De actie is verboden.


6

Indeterminate: Er is een fout opgetreden of een vereiste waarde ontbrak, zodat er geen

beslissing kon genomen worden. Not Applicable: De request kan niet beantwoord worden door de service.

In Figuur 2.1 wordt een vereenvoudigd model weergegeven van toegangscontrole via XACML. Als een gebruiker een bepaalde actie wil ondernemen op een bepaalde (data) resource, zal hij hiervoor een toegangsverzoek versturen naar de entiteit die deze resource beschermt. Deze entiteit noemen we in XACML het Policy Enforcement Point (PEP). Op basis van bepaalde gegevens (de gebruiker, de actie en de resource) zal het PEP een XACML request formuleren en dit naar het Policy Decision Point (PDP) sturen ter evaluatie. Het PDP analyseert de request tezamen met de policies die van toepassing zijn op deze request en maakt op basis hiervan een beslissing. Het PDP stuurt deze beslissing dan terug naar het PEP in een XACML response. Het PEP zal de actie op basis van de XACML response vervolgens al dan niet toelaten.

Figuur 2.1: Eenvoudig XACML model

2.1.3

Werking XACML

Zoals vermeld, beschrijft de XACML Core standaard [10, 9, 11] zowel een policy language als een request/response language. In het vervolg van deze sectie worden beide in detail besproken. Request/response language

De request/response language maakt het mogelijk om een query te maken waarmee men kan vragen of een bepaalde actie op een zekere resource al dan niet toegelaten is en om het antwoord te interpreteren.


7

In Figuur 2.2 wordt het model weergegeven voor een architectuur met toegangscontrole via XACML. Als een gebruiker een bepaalde actie (web method) wil ondernemen op een resource (patiënt), zal hij hiervoor een toegangsverzoek sturen naar de component, die deze resource beschermt. Zoals reeds gezegd, wordt deze component het Policy Enforcement Point (PEP) genoemd. Het PEP zal dan een XACML request opmaken op basis van de attributen in het toegangsverzoek van de gebruiker, de resource in kwestie, de actie op deze resource en andere informatie in de request. Om deze XACML request te vervolledigen kan de PEP bij het Policy Information Point (PIP) ontbrekende gegevens opvragen. Het PEP stuurt deze XACML request vervolgens door naar het Policy Decision Point (PDP).

Figuur 2.2: XACML model

Hieronder vindt men een eenvoudig voorbeeld van een XACML request. Een dokter (subject) vraagt hierbij de toelating om het medisch dossier van de patiënt Bart Simpson (resource) te mogen lezen (action). <Subject SubjectCategory= "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> physician


8

file://example/med/record/patient/BartSimpson read

Het Policy Administration Point (PAP) is verantwoordelijk voor het creëren van de policies en voor het beheer ervan in een repository. Deze repository kan eventueel gedistribueerd zijn in bijvoorbeeld een Lightweight Directory Access Protocol (LDAP) repository. Op basis van de verschillende policies, die op de request van toepassing zijn, zal de PDP een antwoord formuleren of acces al dan niet toegelaten moet worden en dit antwoord in een XACML response terugsturen naar het PEP. Het PDP kan, net als het PEP, bij het PIP achter ontbrekende gegevens vragen. Zoals eerder aangegeven zijn er vier mogelijke antwoorden: Permit, Deny, Indeterminate of Not Applicable. Het PEP zal dan de bepaalde actie op die bepaalde resource al dan niet toelaten op basis van deze XACML response en optioneel op basis van de meegegeven obligations (zie verder) bijkomende actie ondernemen. Hieronder vindt men een mogelijk antwoord op de XACML request die eerder als voorbeeld werd gegeven. Hier beslist het PDP dat de actie van de gebruiker op de resource wordt toegelaten. Permit <Status>


9

<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

In de XACML standaard heeft men ook al voorzien dat het PEP en het PDP gedistribueerd kunnen zijn en via het SAML Profile wordt beschreven hoe deze kunnen communiceren via SAML. Dit is echter geen vereiste en zal in elke situatie apart moeten overwogen worden. Policy language

De policy language wordt gebruikt om algemene toegansgcontrole vereisten te beschrijven en heeft standaard extensiepunten om nieuwe functies, data typen, etc. te definiëren. Figuur 2.3 toont een UML voorstelling van het policy language model. Zoals men kan zien, is de root van een policy een Policy- of een PolicySet-object. Een PolicySet is een container die zowel Policies als PolicySets kan bevatten en zelfs referenties naar policies die zich op andere locaties bevinden. Een Policy vertegenwoordigt één toeganscontrole policy, uitgedrukt door een reeks van Rule-objecten. Een Rule-object bevat dan weer een Condition (boolean function) en het bijhorende Effect. Elk XACML policy document bevat exact één Policy of PolicySet root XML tag. Omdat een PolicySet meerdere Policies en een Policy meerdere Rules kan bevatten, die elk toegangscontrole zullen evalueren in een verschillende situatie, heeft XACML zes policy/rulecombining algoritmen voorzien: Deny-overrides (Ordered) Deny-overrides (Unordered) Permit-overrides(Ordered) Permit-overrides (Unordered) First applicable Only-one-applicable


10

Elk algoritme vertegenwoordigt een andere manier voor het combineren van de verschillende Policies en/of Rules tot één definitieve autorisatie beslissing. Het is in XACML mogelijk om één of meerdere voorwaarden op te leggen aan de PEP, alvorens deze een actie op een resource al dan niet zal toelaten volgens de PDP beslissing. In XACML worden deze voorwaarden obligations genoemd. Wanneer een Policy of PolicySet geëvalueerd is, dan zal de bijhorende obligation worden doorgegeven aan het volgende level, indien het effect van de geëvalueerde Policy of PolicySet gelijk is aan dat van het FulfillOn attribuut van de obligation. Als gevolg hiervan zal een obligation nooit worden doorgegeven indien zijn Policy of PolicySet niet geëvalueerd wordt, of indien het geëvalueerde resultaat Indermediate of NotApplicable is. Nadat een PDP een XACML request heeft ontvangen, moet het zoeken naar alle policies die

Figuur 2.3: Het policy language model cfr. OASIS [10]


11

van toepassing kunnen zijn. Om dit sneller te laten verlopen bevat XACML een Target-object. Een Target is een set van gesimplificeerde condities voor het Subject, Resource, Action en Environment, waaraan moet voldaan zijn opdat een PolicySet, Policy of Rule van toepassing zou zijn. Er wordt gebruik gemaakt van boolean functions om de waarden van de XACML request te vergelijken met die van een Target. Als aan alle voorwaarden is voldaan, dan is de aan de Target verbonden PolicySet, Policy of Rule van toepassing op de request. Hiernaast voorziet een Target ook een manier om de policies te indexeren, wat zeker nodig is indien men een zeer grote repository heeft en men toch snel tot een beslissing wil komen. In Bijlage A.1.1 kan men een voorbeeld vinden van een eenvoudige PolicySet.

2.1.4

Huidige standaard

XACML 2.0

De huidige XACML standaard is XACML 2.0 sinds 1/2/2005[10]. Deze is uitgebreid via zes profielen die eveneens tot de standaard behoren: Core and hierarchical RBAC profile[12]: definieert hoe men policies moet definiëren met

RBAC (zie sectie 2.2 voor meer informatie over RBAC en subsectie 2.2.3 voor een gedetailleerde beschrijving van dit profiel). Hierarchical resource profile[13]: staat het gebruik van XACML toe in omgevingen met

hiërarchisch georganiseerde resources, die men bijvoorbeeld presenteert als knopen in een xml-document. Het profiel laat dan toe om de knopen in de hiërarchie te identificeren, toegang te vragen tot zo’n knoop en policies te specificeren in een hiërarchische omgeving. Multiple resource profile[14]: laat toe om in één XACML request de toegang te vragen tot

meerdere resources of om via één response de toegang te geven tot een volledige hiërarchie van resources. Privacy policy profile[15]: beschrijft hoe men privacy policies dient te definiëren. SAML 2.0 profile[16]: beschrijft hoe men XACML 2.0 policies, requests en repsonses via

SAML kan versturen over een netwerklink.


12

XML Digital Signature profile[17]: voorziet het gebruik van W3C XML-Signature Syntax

and Processing Standard voor authenticatie en integriteit protectie voor XACML data objecten, zoals een PolicySet, Policy, Rule, Request context, etc.

Voor zowel de XACML Core 2.0 (29/01/2008)[18] als SAML 2.0 profile (19/07/2007)[19] bestaan erkende errata documenten. Deze errata documenten zijn niet gestandaardiseerd, maar bevatten wel de door de XACML TC erkende correcties. Voorheen

De wijzigingen in XACML 2.0 t.o.v. de vorige standaard XACML 1.0 (6/2/2003)[21] en de niet-gestandaardiseerde uitbreiding XACML 1.1 (24/7/2003)[22] zijn vrij groot [20]. Men heeft wijzigingen aangebracht in het schema en nog een aantal nieuwe functies (o.a. time-in-range), datatypes (o.a. ipAddress) en algoritmen (o.a. ordered-deny-overrides) toegevoegd. De belangrijkste toevoeging zijn natuurlijke de bijkomende profielen. Men heeft nu het RBAC profile gestandaardiseerd en uitgebreid, zodat ze voldoet aan het RBAC model van de ANSI INCITS standaard[23]. Voor XACML 1.0 bestond enkel de niet-gestandaardiseerde draft van XACML profile for Role Based Access Control[24]. Meer over RBAC vindt men in sectie 2.2. De Toekomst

Sinds 2007 is men ook gestart met XACML 3.0 [25] en onlangs (16/04/2009) zijn er voor de Core en de verschillende profielen een eerste Committee draft gepubliceerd. Naast updates van de bestaande profielen zal men alvast twee nieuwe profielen (XACML v3.0 Administration and Delegation profile[26] en Cross-Enterprise Security and Privacy Authorization (XSPA) profile of XACML v2.0 for Healthcare[27]) opnemen in de toekomstige standaard en heeft men er ook drie in overweging (Web Services Profile of XACML (WS-XACML)[28], XACML PDP Metadata[29] en XACML v3.0 Export Compliance- US (EC-US) profile[30]). XACML v3.0 Administration and Delegation Profile (committee draft 1, 16/04/2009):

bepaalt hoe men in XACML 3.0 de administratie van policies moet organiseren op basis van resource, action of subject. Verder zal men hier ook beschrijven hoe men eventueel permissies (tijdelijk) kan delegeren.


13

XSPA Profile (public review draft 02, 29/04/2009): beschrijft hoe men security en privacy

policies kan uitwisselen, consent directives kan evalueren en autorisaties kan bepalen op een uitwisselbare wijze via XACML. WS-XACML (WD 10, 10/08/2007): beschrijft het gebruik van XACML in de context

van web services voor autorisatie, toegangscontrole en privacy policies. Het specificeert hiervoor twee nieuwe Assertions voor het gebruik van WS-Policy en andere schema’s en protocols. Het beschrijft ook hoe men P3P policy preferences kan gebruiken en vergelijken met behulp van één van de nieuwe XACML Assertion types. (zie subsectie 5.3 voor en gedetailleerde beschrijving) XACML PDP Metadata (WD 1, 24/02/2008): beschrijft hoe een PDP metadata over zich-

zelf kan publiceren zoals bijvoorbeeld welke versie van XACML hij ondersteunt, optionele features, zijn locatie, etc. EC-US profile (WD 1, 17/04/2009): definieert het gebruik van XACML voor het uitdruk-

ken van policies voor het naleven van voorschriften van de V.S. voor export compliance (EC). Het definieert verder standaard attribuut identifiers voor deze policies en zal enkele waarde intervallen aanbevelen voor bepaalde attributen.

2.1.5

Bestaande open source implementaties van XACML

In het vervolg van deze sectie worden een aantal open source implementaties bekeken en vergeleken. Sun’s XACML Implementation

Sun’s XACML Implementation[31] is één van de allereerste open source implementaties van XACML. Het is geschreven in Java en het vereist enkel een Java 2 Platform, Standard Edition 1.4.0. Momenteel heeft men versie 1.2 waarmee men volledig XACML 1.1 covert. In versie 1.2 is wel al de functie time-in-range, die in XACML 2.0 is gestandaardiseerd, opgenomen bij de voorbeeldcode. Deze implementatie vormt ook de basis van vele andere open source implementaties en zelfs commerciële producten. Sun’s XACML Implementation biedt ook reeds een gedeeltelijke implementatie aan van XACML 2.0 in de vorm van een bèta-release. Sinds juni 2006 is de website echter nog steeds niet geupdate


14

omtrent deze bèta en de laatste update van de source code dateert van november 2006. Er is dus onzekerheid i.v.m. de stabiliteit en functionaliteit van deze bèta t.o.v. de XACML 2.0 standaard. Bijkomend voordeel is dat Sun Microsystems actief meewerkt met OASIS en gekend is voor zijn actieve user community en de bereikbaarheid en beschikbaarheid van de developers voor vragen. SICSACML

SICSACML[32] is een java implementatie gemaakt door het Security, Policy, and Trust Lab (SPOT) van het Swedish Institute of Computer Science (SICS). Het covert reeds gedeeltelijk de XACML 3.0 draft (WD 9) en is gereleased als een patch voor Sun’s XACML Implementation 2.0 Bèta. SICSACML wordt beschermd door de BSD license. Bijkomend voordeel is dat SICS actief meewerkt met OASIS. De laatste update dateert van 8/05/2008. Enterprise Java XACML 2.0 Implementation

Enterprise Java XACML 2.0 Implementation[33] is een Google Code Project, dat zich momenteel in een publieke bèta fase bevindt. Het heeft de XACML 2.0 standaard ge¨ımplementeerd en slaagt naar eigen zeggen reeds voor de meeste XACML 2.0 Core conformance tests. Het heeft een paar extra features t.o.v. Sun’s XACML Implementation, die er vooral op gericht zijn de performance te verbeteren (indexing mechanisme, caching, etc.). Het hele project valt onder de Apache License 2.0. De laatste source code update dateert van 09/01/2009. XACMLight

XACMLight[34] is ontworpen als een web service met de noodzakelijke componenten (o.a. PDP en PAP) voor policy evaluatie. Het is een open source java project dat gebruik maakt van XMLBeans. Voordeel hierbij is dat het zeer snel policies kan inlezen. Het project valt onder Apache License 2.0 en de laatste update dateert van juni 2008. XACML.NET

XACML.NET[35] biedt een implementatie van XACML 1.0 aan in de .NET taal C#. Het project valt onder de Mozilla license MPL 1.1. Het grootste nadeel van de implementatie is dat er dus


15

nog geen volledige ondersteuning is van XACML 1.1 en het daardoor minder goed presteert op de conformance testen van OASIS dan bv Sun’s XACML Implementation[36]. Aangezien enkel XACML 1.0 wordt ondersteunt, dateert de laatste update al van 10/03/2005. HERAS-AF

Recent is er nog een nieuwe partner van OASIS, die een open source implementatie beschikbaar stelt. HERAS-AF[37] is een open source project van de Zwitserse University of Applied Science Rapperswil. HERAS-AF implementeert de minimale functionaliteit van de XACML 2.0 standaard. Daarnaast voorziet het ook implementaties voor een PDP, PAP, PEP en PIP. De PDP kan ook overweg met request en responses zoals beschreven in het SAML 2.0 Profile. Aangezien deze implementatie nog maar recent is vrijgegeven, is er geen informatie beschikbaar over de prestatie van dit project. Vergelijking van de open source projecten

Er bestaan momenteel slechts twee afgewerkte open source projecten, namelijk Sun’s XACML Implementation 1.2 en XACML.NET. De tweede, XACML.NET, ondersteunt echter enkel XACML 1.0 en scoort hierdoor opvallende slechter op de conformance testen van XACML 1.1[36]. Ondanks dat de XACML 2.0 standaard al van 2005 dateert, is er nog geen enkele afgewerkte open source implementatie beschikbaar, die deze ondersteunt. Er is momenteel ook geen algemene informatie beschikbaar over de prestaties en stabiliteit van de verschillende bèta’s. Voor het verdere verloop van de scriptie zal er gebruik worden gemaakt van Sun’s XACML Implementation 1.2 en dit om volgende redenen: afgewerkte, veelvuldig geteste en gebruikte implementatie ondersteuning van XACML 1.1 standaard Sun Microsystems is lid van OASIS actieve user community

De actieve community en de bereikbaarheid van de developpers bij Sun’s XACML Implementation is hier doorslaggevend. Aangezien XACML een recente technologie is, wordt er nog niet

2.2 Role-Based Access Control

16

wereldwijd gebruik van gemaakt en is de informatie erover beperkt. Er bestaan geen algemene faq (frequently asked questions) voor veelvoorkomende problemen en voorbeeldcode is onbestaande m.u.v. de Sun Tutorial[11] en de specificaties. Via de community van Sun (forum en mailinglist) was het echter wel mogelijk om antwoorden te krijgen op bijkomende vragen of problemen. Het enige nadeel is het nog niet ondersteunen van de XACML 2.0 standaard.

2.2

Role-Based Access Control

Deze sectie gaat dieper in op de algemene werking van RBAC, waarna er ook zal geschetst worden hoe men tot de huidige standaard is gekomen. Tot slot wordt het RBAC profile of XACML 2.0 besproken.

2.2.1

Algemeen

Role-Based Access Control (RBAC) is een methode om te voorkomen dat niet geautoriseerde gebruikers toegang kunnen krijgen tot een computersysteem. Net zoals in een organisatie wordt bij RBAC aan verschillende gebruikers een rol toegediend. Aan deze rollen zijn dan bepaalde permissies verbonden (de toelating om een bepaalde actie uit te voeren). Belangrijk hierbij is dat een gebruiker dus geen individuele permissies krijgt, maar deze enkel ontvangt via de rol, die hem wordt toebedeeld. In RBAC kunnen rollen overlappende privileges hebben. Hiermee wordt bedoeld dat gebruikers die tot verschillende rollen behoren wel dezelfde operaties mogen ondernemen. Omdat het inefficiënt is om basisoperaties telkens opnieuw aan een nieuw gecreëerde rol te binden, staat men hiërarchie van rollen toe. Dit definieert dat een rol naast zijn permissies ook andere rollen mag bevatten en m.a.w. alle permissies van deze rollen.

2.2.2

Standaard

RBAC is voor het eerst voorgesteld door David Ferraiolo and Rick Kuhn in 1992[38]. In 2000 is dit model ge¨ıntegreerd in het framework van Sandhu (1996)[39] om tot een uniform RBAC model te komen dat als National Institute of Standards and Technology (NIST) RBAC model[40] is gepubliceerd en in 2004 is aangenomen als een ANSI INCITS (American National Standards Institute[42] / InterNational Committee for Information Technology Standards[41])


17

standaard[23]. Die standaard is nog steeds de huidige RBAC standaard. Dit jaar (2009) zal men wel starten met de revisie van deze standaard.

2.2.3

Core and hierarchical RBAC profile of XACML v2.0

Dit gestandaardiseerde profiel definieert hoe men via XACML RBAC kan ondersteunen zodat het voldoet aan de requirements van de ANSI INCITS standaard. Het profiel zorgt ervoor dat een PDP kan antwoorden op volgende 3 vragen: Als subject X over de rollen R1, R2,... Rn beschikt, krijgt subject X dan toegang tot een

gegeven resource gegeven een bepaalde actie? Is het toegelaten voor subject X om over rol Ri te beschikken? Als een subject beschikt over rollen R1, R2,... Rn, betekent dit dat het subject beschikt

over de permissies geassocieerd met de rol R’, gegeven dat R’ gelijk is aan of een kind van één van de rollen R1, R2,... Rn?

Er worden hiervoor vier verschillende type policies gedefinieerd: Role PolicySet (RPS) Permission PolicySet (PPS) HasPrivilegesOfRole Policy Role Assignment Policy of PolisySet

Een RPS associeert houders van een bepaald rolattribuut en waarde met een PPS, die dan de eigenlijke permissies van de rol bevat. Het Target element van de RPS beperkt de toepasbaarheid van de PolicySet tot de subjects die over het geassocieerde rolattribuut en waarde beschikken. Elke RPS refereert naar maximum één PPS. Een PPS bevat dan de permissies geassocieerd met een bepaalde rol. Het bevat Policy elementen en Rules, die de resource en actie beschrijven tot welke het subject toegang mag krijgen, uitgebreid met verdere condities zoals bijvoorbeeld het tijdstip van de dag. Een PPS mag ook steeds referenties bevatten naar andere PPS geassocieerd met andere rollen, die kind zijn van de


18

gegeven rol, zodat deze alle bevoegdheden erft van de rol van de gerefereerde PPS. Het Target van een PPS, indien aanwezig, mag de subjects niet limiteren voor wie de PolicySet van toepassing is. Men dient er op te letten dat een PPS nooit rechtstreeks is aan te spreken door een PDP als initiële policy en enkel bereikbaar is via de referentie van de bijhorende RPS. Het is door de opsplitsing van RPS en PPS dat hiërarchische RBAC wordt ondersteunt, omdat men via referentie vrij toegang kan krijgen tot de permissies van een andere PPS. In Bijlage A.1.2 kan men een eenvoudig voorbeeld vinden van een RPS en bijhorende PPS. Een HasPrivilegesOfRole Policy is een policy in een PPS die het mogelijk maakt om de vraag te beantwoorden of een subject over de privileges beschikt geassocieerd met een gegeven rol. Indien het systeem deze vraag wil ondersteunen, dient elke PPS over een HasPrivilegesOfRole Policy te beschikken. In het andere geval is deze policy optioneel. In deze scriptie zal er geen gebruik worden gemaakt van deze optie. In Bijlage A.1.3 kan men een eenvoudig voorbeeld vinden van een HasPrivilegesOfRole Policy en bijhorende XACML request. Er dient opgemerkt te worden dat ofwel de request in het subject gedeelte ook de rol van de gebruiker dient te bevatten, ofwel dat de PDP deze kan opvragen via het PIP. Een HasPrivilegesOfRole Policy heeft niet de taak om een subject met een rol te linken. Een Role Assignment Policy of PolicySet definieert welke rol kan aangewezen worden aan welk subject. Het kan ook restricties specificeren tot combinaties van rollen of het totaal aantal toegewezen rollen waarover een subject mag beschikken. Dit type policy dient gebruikt te worden door een Role Enablement Authority (REA), welke dan ook de verantwoordelijkheid heeft om te kunnen antwoorden op volgende vraag: welke rollen zijn er aan subject X toegewezen? Dit alles is optioneel, aangezien een REA niet deel uitmaakt van de standaard XACML onderdelen. In deze scriptie zal er geen gebruik worden gemaakt van deze optie, aangezien er in het UZ reeds een LDAP repository aanwezig is die identiteiten aan rollen koppelt. In Bijlage A.1.4 kan men een eenvoudig voorbeeld vinden van een Role Assignment Policy.

2.3 e-Health

2.3

19

e-Health

Een e-Health omgeving brengt een aantal extra eisen en situaties mee. In deze sectie wordt onderzocht of deze kunnen opgevangen worden met XACML. Daarom wordt eerst gekeken hoe men tot een ge¨ uniformiseerde rollenverdeling kan komen. Vervolgens wordt ook de noodgeval situatie besproken en de situatie waarbij onafgewerkte verslagen zouden kunnen worden ingekeken. Tot slot wordt privacy bekeken. Een aantal van onderstaande bemerkingen zijn gebaseerd op de beide Interop Use Cases van OASIS[43, 44] waarin men zich gebaseerd heeft op het werk van het Healthcare Information Technology Standards Panel (HITSP)[45]. Het HITSP maakt deel uit van het US Departement of Health and Human Services en is een onderdeel van het ANSI[42], dat bijvoorbeeld ook RBAC heeft gestandaardiseerd.

2.3.1

Rollen

In praktijk werkt niet elke zorgomgeving met dezelfde rollenverdeling of naamgeving (bijvoorbeeld Engelstalige versus Nederlandstalige benamingen), noch worden dezelfde permissies toegekend aan deze rollen. Dit kan variëren van omgeving tot omgeving. Aangezien XACML juist is uitgevonden ter bevordering van de uitwisseling, zou er toch enige uniformiteit moeten zijn. Health Level 7 (HL7)[46] is een Amerikaanse organisatie die standaarden ontwikkelt voor de gezondheidszorg en is inmiddels erkend in meer dan 30 landen. In België is er momenteel nog geen HL7-organisatie, maar HL7 Nederland heeft meerdere Vlaamse leden. Het HL7 Security Technical Committee heeft op 20/02/2008 een RBAC Healthcare Permission Catalog[47] gestandaardiseerd. In het document zijn zelf geen goed beschreven rollen opgenomen, maar men kan zelf rollen definiëren op basis van de gestandaardiseerde permissies. Het is juist een kwestie van bepaalde permissies te koppelen aan de gewenste rol. In subsectie 4.2.1 wordt er een oplossing aangeboden in de vorm van een uitbreiding van het RBAC Profile voor de ondersteuning van HL7 permissies.

2.3 e-Health

2.3.2

20

Noodgeval

In een e-Health omgeving moet het zeker zijn toegelaten om de normale toegangsregels te omzeilen in geval van nood. Op deze wijze zouden medici die normaal geen bevoegdheid hebben om gegevens van een bepaalde patiënt in te kijken, omdat ze bijvoorbeeld niet de behandelende arts zijn of een vervanger wegens het verhinderd zijn van de normale geneeskundige, dit alsnog kunnen. De geneeskundige zal dan natuurlijk specifiek moeten opgeven dat het om een noodgeval gaat. In subsectie 4.2.2 wordt er een oplossing aangeboden in de vorm van een extra PolicySet in de top level PolicySet.

2.3.3

Metadata

Men kan ook via goedgekozen attributen extra functionaliteit toevoegen aan het platform. Het is bijvoorbeeld mogelijk een medisch dossier of een deel eruit, dat nog niet volledig is afgewerkt, onbeschikbaar te maken voor andere medici dan de auteur. Men kan zo bijvoorbeeld reeds een half afgewerkte bloedtest in het systeem toevoegen en de volgende dag de rest van de resultaten toevoegen, zonder bang te zijn dat een andere dokter reeds een verkeerde analyse maakt op een half afgewerkt onderzoek of deels ingevoegde resultaten. In subsectie 4.2.3 wordt er een oplossing aangeboden voor deze situatie.

2.3.4

Privacy

Privacy policy profile

In 1980 heeft de Organisation for Economic Co-operation and Development (OECD)[48] een aantal plichten[49] gedefinieerd voor entiteiten die beschikken over persoonsgebonden informatie. Het is op basis van twee van deze punten dat OASIS het Privacy policy profile[15] heeft opgesteld, namelijk de Purpose specification en het Use limitation principle. De Purpose specification bepaalt dat wanneer men persoonsgebonden data vastlegt, men er steeds een doel voor moet opgeven en het verder gebruik van deze data beperkt is tot dit doel. Het Use limitation principle bepaalt dat persoonsgebonden data niet vrij mogen gegeven

2.3 e-Health

21

worden of gebruikt worden voor een ander doel dan het vooraf gespecificeerde, behalve als er toestemming is van de persoon zelf of indien het toegelaten is bij wet. Het Privacy policy profile voegt hiervoor twee attributen toe aan de XACML 2.0 standaard, namelijk resource purpose (urn:oasis:names:tc:xacml:2.0:resource:purpose) en action purpose (urn:oasis:names:tc:xacml:2.0:action:purpose). Het eerste staat toe om een doel toe te voegen aan een resource en het tweede om bij een actie het doel van de actie mee te delen. Via een nieuw Rule element (urn:oasis:names:tc:xacml:2.0:matching-purpose) kan het doel van de resource vergeleken worden met het doel van de actie en op basis hiervan kan al dan niet toelating gegeven worden voor de actie op die resource. Pati¨ ent toestemming

Via XACML kan men ervoor zorgen dat een patiënt kan bepalen welke zaken uit zijn dossier zichtbaar zijn voor bepaalde medici en welke niet. Hij kan bijvoorbeeld beslissen dat een bepaalde dokter (bv een arts die zijn buur is) niet aan zijn medisch dossier kan, ook al zou die daar toestemming voor hebben vanuit zijn functie. In subsectie 4.2.2 wordt er een oplossing aangeboden in de vorm van extra PolicySets in de top level PolicySet, waar er, voordat men de normale toegangscontrole evalueert, wordt gecontroleerd of het subject geen toegangsverbod heeft.

TESTEN XACML

22

Hoofdstuk 3

Testen XACML In dit hoofdstuk worden twee verschillende zaken onderzocht. Ten eerste zal de prestatie van de door ons gekozen open source implementatie worden onderzocht. En tot slot zal worden onderzocht wat de beste plaats is om aan autorisatie te doen in een web service omgeving, zoals het ICSP.

3.1

Testbed

De testomgeving voor de experimenten in het vervolg van deze scriptie is een Windows Vista notebook met volgende configuratie: Intel Core 2 Duo Processor (2 GHZ, 667 MHz FSB, 2 MB L2 cache) 3 GB DDR2 320 GB HDD S-ATA (5400 rpm)

3.2

Sun’s XACML Implementation

Op basis van de vergelijking tussen de bestaande open source implementaties in het vorige hoofdstuk (zie subsectie 2.1.5), is gekozen voor Sun’s XACML Implementation 1.2. Deze open source java implementatie van XACML ondersteunt reeds heel XACML 1.1 en bevat in zijn voorbeeldcode ook reeds een implementatie van de time-in-range functie, die pas in XACML 2.0

3.2 Sun’s XACML Implementation

23

gestandaardiseerd is. Via deze functie is het mogelijk om permissies aan tijdstippen te koppelen en bijvoorbeeld acties toe te laten tijdens de werkuren/ploegenshift en daarbuiten niet. Er zijn ook nadelen verbonden aan de keuze voor Sun’s XACML Implementation 1.2. Sun’s XACML Implementation 1.2 ondersteunt immers nog niet de XACML 2.0 standaard uit 2005 en zijn bijkomende profielen. Verder biedt XACML ook de mogelijkheid aan om in een policy te verwijzen naar andere policies via referenties. De standaard beschrijft echter niet hoe dit ge¨ımplementeerd moet worden of op welke manier de referenties dienen behandeld te worden. Om deze reden voorziet Sun’ s XACML Implementation 1.2 hier geen rechtstreeks kant en klare oplossing voor.

3.2.1

Ondersteuning referenties

Aangezien de ondersteuning van referenties noodzakelijk is bij het gebruik van het RBAC profile, is er gezorgd voor een eigen implementatie, ge¨ınspireerd op voorbeeld code uit Sun’s XACML Implementation 2.0 Bèta. De basis zijn twee klassen die elk de PolicyFinderModule klasse uitbreiden, namelijk StaticPolicyFinderModule en StaticRefPolicyFinderModule. De eerste klasse, zijnde StaticPolicyFinderModule, ondersteunt het opzoeken van policies op basis van een XACML request en geeft true terug op de isRequestSupported methode. De tweede, zijnde StaticRefPolicyFinderModule, ondersteunt daarentegen enkel het opzoeken van policies op basis van hun PolicySetId en geeft true terug op de isIdReferenceSupported methode en false op de isRequestSupported methode, zodat ze niet rechtstreeks raadpleegbaar is voor vergelijking met een XACML request en men enkel bij de policies terecht kan via zijn referentie (eis van het RBAC profile). De architectuur is weergegeven in Figuur 3.1. Naast de StaticPolicyFinderModule en de StaticRefPolicyFinderModule bestaan er ook twee hulpklassen. In de PolicyCollection zullen de policies opgeslagen worden in een HashMap, zodat ze snel kunnen worden opgevraagd bij de evaluatie van een XACML request. De PolicyReader zorgt voor het inlezen van de policies. Een DocumentBuilder wordt gebruikt voor het inlezen van de DOM documenten. Zowel de StaticPolicyFinderModule als de StaticRefPolicyFinderModule worden ge¨ınitialiseerd met een List van policy locaties. Wanneer de PDP wordt ge¨ınitialiseerd, worden deze één voor één ingelezen via de PolicyReader hulpklasse en opgeslagen in een PolicyCollection.


24

Figuur 3.1: UML diagram voor het ondersteunen van referenties

Voor de testen in subsecties 3.2.2, 3.3.4 en 3.3.5 zal de StaticPolicyFinderModule een aantal Role PolicySets bevatten en de StaticRefPolicyFinderModule de bijhorende Permission PolicySets. Als de PDP een XACML request ontvangt, zal hij via de StaticPolicyFinderModule de RPS ophalen die hierop van toepassing is. Daarna zal hij via StaticRefPolicyFinderModule de bijhorende PPS ophalen waarnaar men verwijst via een PolicySetIdReference en eventueel een andere PPS waarnaar verwezen wordt.

3.2.2

Prestatietesten Sun’s XACML Implementation

XACML heeft een zekere initialisatie nodig. Alle policies, en eventueel bijkomende functies (bv time-in-range), dienen immers ingelezen te worden, de verschillende klassen dienen gecreëerd te worden, etc. Dit is een overhead die enkel de eerste keer voorkomt en dit ongeacht van de cases, die in sectie 3.3 beschreven worden. Daarna kost enkel nog de evaluatie van een XACML request tijd. Dit is weergegeven in Figuur 3.3. In Tabel 3.1 worden de gemiddelde tijden weergegeven voor de set-up van bepaalde onderdelen van de PDP bij 20 steekproeven. De PolicyFinder wordt ge¨ınitialiseerd aan de hand van de StaticPolicyFinderModule en StaticRefPolicyFinderModule. De PDP wordt dan weer mede ge¨ınitialiseerd met behulp van de PolicyFinder en de AttributeFinder. De cijfers zijn bepaald


25

Figuur 3.2: Stroomdiagram XACML

bij 5 rollen die allen in hun RPS verwijzen naar een basis PPS of in totaal 11 policies. Er wordt op gewezen dat, nu en ook in het vervolg van dit hoofdstuk, elke RPS wordt ingeladen in de StaticPolicyFinderModule en elke PPS in de StaticRefPolicyFinderModule. Onderdeel

Tijd(ms)

Standaarddeviatie

StaticPolicyFinderModule

21,89

2,28

StaticRefPolicyFinderModule

1,32

0,48

PolicyFinder

1,36

0,50

AttributeFinder

9,68

1,11

FunctionFactory

49,62

4,83

Initialiseren PDP

107,89

5,69

8,37

1,34

Eerste evaluatie

Tabel 3.1: Setup tijden van PDP onderdelen

Het is duidelijk dat de totale initialisatietijd vooral afhankelijk is van de PDP initialisatie en in mindere maten van het inladen van de time-in-range functie in de FunctionFactory. Er werd vastgesteld dat alle tijden van de initialisatie bijna constant zijn, ook bij een stijgend aantal policies, behalve de intialisatietijd van de PDP. De verklaring ligt hiervoor bij het moeten inlezen van meer policies wat pas in deze fase gebeurd. Bij het aanmaken van de StaticPolicyFinderMo-


26

dule en de StaticRefPolicyFinderModule worden immers enkel de bestandsnamen opgeslagen in een List-object. Bijvoorbeeld bij 10 rollen met hun eigen PPS, die elk verwijzen naar een basis PPS, of bij 21 policies, neemt de initialisatietijd van de PDP toe tot 138 ms, zoals weergegeven in Tabel 3.2. Onderdeel Initialiseren PDP

Tijd(ms)

Standaarddeviatie

138,84

27,24

Tabel 3.2: Initialisatietijd PDP bij 10 rollen

De toename van de totale initialisatietijd (dus de som van de tijd voor het creëren van de StaticPolicyFinderModule, de StaticRefPolicyFinderModule, de PolicyFinder, de AttributeFinder en de FunctionFactory en voor het initialiseren van de PDP) bij een toenemend aantal rollen werd onderzocht. Als configuratie werd één RPS met zijn eigen basis PPS (bv verpleegster) gebruikt. Het aantal rollen wijst dan op het aantal extra RPS’s (bv dokter, hoofdverpleegster) met hun eigen PPS, die elk verwijzen naar deze basis PPS. Het totaal aantal policies is hier dus: 2 x #rollen + 1. In Figuur 3.3 ziet men de totale initialisatietijd, die zoals verwacht en gehoopt, lineair stijgt bij een toenemend aantal rollen. Bij het experiment werden 40 steekproeven uitgevoerd en in de grafiek worden ook de hoog/laag-waarden aangeduid door middel van de standaarddeviatie.

Figuur 3.3: Invloed van het aantal rollen op de totale initialisatietijd

Bij een toenemend aantal referenties wordt ook een toename van de totale initialisatietijd vastgesteld. Dit is belangrijk voor bedrijven waar het personeelsbestand hiërarchisch is opgebouwd. Als basis configuratie werd één basis RPS gebruikt en één PPS. Deze PPS zal via een referentie


27

verwijzen naar een andere PPS van een lager geklasseerde collega. Op zich kan deze PPS opnieuw verwijzen naar een andere PPS. De diepte wordt gevarieerd van 1 tot 25 in stappen van 5. Een voorbeeld met diepte 2 is: dokter → hoof dverpleegster → verpleegster. Zoals men kan zien in Figuur 3.4, is ook hier de totale initialisatietijd lineair stijgend met het toenemend aantal referenties (= toenemend aantal PPS). Voor het bekomen van de waarden werden 40 steekproeven uitgevoerd en opnieuw worden de hoog/laag-waarden aangeduid. Het totaal aantal policies is hier dus: #referenties + 2.

Figuur 3.4: Invloed van het aantal referenties op de totale initialisatietijd

Uit bovenstaande experimenten blijkt dat de totale initialisatietijd lineair stijgt bij een toenemend aantal policies en niet speciaal bij het toenemend aantal rollen of referenties. Na deze initialisatie is de enige kost voor toegangscontrole de tijd voor een evaluatie. Bij een beperkt aantal policies wordt experimenteel vastgesteld dat deze constant is en deze nog daalt t.o.v. de eerste keer. Dit is weergegeven in Tabel 3.3. De tijd voor een evaluatie is zelfs zo verwaarloosbaar dat de metingen via System.currentTimeMillis() niet nauwkeurig genoeg zijn om een voldoend kleine standaarddeviatie te bekomen. Onderdeel

Tijd(ms)

Standaarddeviatie

Evaluatie

0,68

0,48

Tabel 3.3: Evaluatietijd


28

Recent onderzoek

Recent zijn er ook een nieuwe onderzoeksresultaten gepubliceerd omtrent de prestaties van de verschillende open source PDP implementaties in [51]. Het onderzoek naar de invloed van het aantal policies op zowel de initialisatie (inlezen van de policies) als de evaluatie werd hier uitgebreid tot 10000 policies. Voor het inlezen van policies in Sun’s XACML Implementation 1.2 wordt onze conclusie bevestigd dat de initialisatietijd lineair stijgt bij een stijgend aantal policies, ook bij grote aantallen. Bij een beperkt aantal policies (t.e.m. 1000 policies) wordt de conclusie bevestigd dat de evaluatietijd constant is, 40 ms in hun testomgeving. Bij een stijging naar 10000 policies merken ze een stijging van de evaluatietijd naar 600ms. Ten opzichte van de andere open source PDP implementaties scoort Sun’s XACML Implementation goed. Bij het inlezen van policies houdt het gelijke trend met XACMLight ondanks dat deze implementatie theoretisch gezien veel beter kan presteren door het gebruik van XMLBeans voor XML operaties. Bij 1000 policies is het verschil slechts 2s en in tegenstelling tot XACMLight kan Sun’s XACML Implementations wel 10000 policies inlezen bij een beperkt geheugen. Voor de evaluatie presteert Sun’s XACML Implementatie tot 1000 policies even goed als XACML Enterprise. Vanaf 10000 policies is het verschil in evaluatietijd zeer merkbaar (75 ms t.o.v. 700 ms). De oorzaak ligt hier bij het ondersteunen van indexing en caching bij XACML Enterprise.

3.2.3

Conclusie

Uit bovenstaande resultaten en [51] kan er geconcludeerd worden dat Sun’s XACML Implementation 1.2 zeer goede prestaties levert. Het inlezen van de policies bij initialisatie is lineair en de evaluatie is verwaarloosbaar tot meer dan 1000 policies. Ook bij een groot aantal policies blijft de evaluatietijd onder de 1 s. In de e-Health omgeving zal er vooral rekening gehouden moeten worden met de tijd voor een evaluatie, en in mindere mate met de tijd voor het inlezen van nieuwe of gewijzigde policies. Indien de policies zo zijn ontworpen dat er geen hard gecodeerde namen in voorkomen van patiënten, zullen de policies immers constant zijn en hoeven ze niet opnieuw ingelezen te worden na verloop van tijd. De enige keer dat er in dit geval policies moeten ge¨ updatet worden, is wanneer de bevoegdheden van de rollen wijzigen of wanneer er een nieuwe functionaliteit aan het systeem wordt toegevoegd, die men nog niet heeft voorzien in de policies.

3.3 Drie mogelijke oplossingen

29

Sun’s XACML Implementation scoort in beide gevallen goed wat het gebruik van deze open source XACML implementatie rechtvaardigt.

3.3

Drie mogelijke oplossingen

Het Intensive Care Service Platform (ICSP) van het UZ Gent bestaat uit een broker architectuur met meerdere web service componenten die verschillende functionaliteiten aanbieden. Het is in deze omgeving dat XACML zou moeten worden ingebracht, zodat niet iedere arts of verpleegkundige zomaar toegang krijgt tot elke medische service, of hiervan de volledige dataset zal mogen inkijken. In het vervolg van dit hoofdstuk wordt voor de eenvoudigheid de scope beperkt tot het al dan niet toegelaten zijn van een actie op een bepaalde web service en wordt er voorlopig geen rekening gehouden met de toegang tot bepaalde data (patiënten). Het doel is het ontdekken van de vooren nadelen van de locatie waar je toegangscontrole toepast in een systeem. Omdat de nadruk van deze scriptie op autorisatie ligt en authenticatie pas in hoofdstuk 6 in rekening wordt gebracht, zal de rol van de gebruiker worden meegegeven als parameter bij elke web method oproep. In deze scope zijn drie gegevens nodig om tot een XACML request te komen: de rol van de gebruiker, de web method en de web service. Om deze reden worden drie mogelijke plaatsen bekeken waar men XACML zou kunnen oproepen binnen een web service omgeving, zoals weergegeven in Figuur 3.5. Ten eerste kan de XACML request geformuleerd worden binnenin een web method zelf, zie subsectie 3.3.1. Ten tweede in een handler class net voor het binnengaan van de web service, zie subsectie 3.3.2. En ten derde door de toegangscontrole via XACML in de broker te doen, zie subsectie 3.3.3.

3.3.1

Case 1

De eerste mogelijkheid is om de toegangscontrole te doen in het begin van de opgeroepen web method, zoals weergegeven in Figuur 3.6. Op dat moment is logischer wijze de web method, die men oproept, gekend, alsook de web service waarvan deze methode deel uitmaakt. De rol van de gebruiker zou men kunnen bekomen doordat elke web method als argument een unieke


30

Figuur 3.5: Mogelijke plaatsen voor toeganscontrole

user identity token (bv. SAML user token) meekrijgt waarmee dan via het PIP de rol van de gebruiker wordt bekomen.

Figuur 3.6: Toeganscontrole in de Web Method zelf

3.3.2

Case 2

In het tweede geval wordt er aan toegangscontrole gedaan voordat men in de web service komt. Er wordt ingegrepen in de handler chain en via XACML wordt de toegang gecontroleerd in een handler class, zoals weergegeven in Figuur 3.7. Door middel van een annotatie wordt er in de web service verwezen naar een configuratie file: @WebService(targetNamespace=


31

Figuur 3.7: Toeganscontrole in handler chain

"http://be.ugent.eHealth.ICSP.services", name = "Service") @HandlerChain(file = "service_handler.xml") public class Service { ... }

In de configuratie file wordt naar de eigenlijke handler class verwezen waar de toegangscontrole wordt uitgevoerd: be.ugent.eHealth.ICSP.services.handlers.ServiceHandler be.ugent.eHealth.ICSP.services.handlers.ServiceHandler

De handler class implementeert de SOAPHandler interface, die vier methoden bevat. De belang-


32

rijkste hiervan is de handleMessage methode die automatisch wordt opgeroepen en waarin men over de SOAP message beschikt, waarmee men de web service oproept. Dit is weergegeven in onderstaand voorbeeld. Indien het om een inkomend bericht gaat, kan zowel de user (bv SAML user token) als de SOAP Action uit de SOAP message gehaald worden en hiermee via XACML aan toegangscontrole gedaan worden. public class ServiceHandler implements SOAPHandler<SOAPMessageContext> { @Override public Set getHeaders() {...} @Override public void close(MessageContext context) {...} @Override public boolean handleFault(SOAPMessageContext context) {...} @Override public boolean handleMessage(SOAPMessageContext context) {...} }

Verder kan ervoor gekozen worden om één handler class te maken die de toegangscontrole van alle web services doet en dus generiek de web service kan bepalen. In dit geval zal er dus vanuit de annotatie naar dezelfde xml file verwezen worden, die de generieke handler class oproept. Anderzijds kan er ook voor geopteerd worden dat elke web service over zijn eigen handler class beschikt.

3.3.3

Case 3

De laatste methode bestaat eruit om toeganscontrole te doen in de broker, zoals weergegeven in Figuur 3.8. De broker wordt ge¨ımplementeerd in Apache Synapse[50] als proxy. Apache Synapse is een open source lightweight Enterprise Service Bus (ESB). Synapse wordt geconfigureerd door middel van een xml configuratie file waarbij de acties worden gespecificeerd, die dienen te gebeuren in de proxy. In deze case dienen er twee zaken te gebeuren. Enerzijds dient de proxy de WSDL van de web services te publiceren en anderzijds moet men bij inkomende berichten aan toegangscontrole doen.


33

Figuur 3.8: Toeganscontrole in broker

In onderstaand voorbeeld van een configuratie file wordt de WSDL van de web service, Service, gepubliceerd. Inkomende berichten worden eerst doorgestuurd naar de class mediator, XACMLMediator, waar er aan toegangscontrole wordt gedaan. Indien de actie toegelaten is, wordt het doorgestuurd naar de gewenste web service. Uitgaande berichten (van web service naar cliënt) worden gewoon doorgestuurd. <definitions xmlns="http://ws.apache.org/ns/synapse"> <sequence name="proxy_documentation"> <send> <endpoint>
<enableAddressing/>


34

<sequence name="out"> <send/> <proxy name="DocumentationProxy">

Voor de toegangscontrole worden de inkomende berichten dus eerst naar de class mediator gestuurd, XACMLMediator in bovenstaand voorbeeld. Deze implementeert de Mediator interface, die vier methoden bevat. Dit is weergegeven in onderstaand voorbeeld. De belangrijkste is de mediate methode die automatisch wordt opgeroepen en waarin men beschikt over het SOAP bericht. In deze methode wordt er aan toegangscontrole gedaan op basis van dit SOAP bericht. Enkel indien deze methode true teruggeeft, zal het SOAP bericht worden doorgestuurd naar het endpoint gespecificeerd in de configuratie file. public class XACMLMediator implements Mediator { @Override public boolean mediate(MessageContext mc) {...} @Override public String getType() {...} @Override public int getTraceState() {...} @Override public void setTraceState(int arg0) {...} }

3.3.4

Functionele testen

Om een kleine vergelijking te maken tussen de snelheid van de drie scenario’s, wordt de gemiddelde RTT bekeken van 40 steekproeven na de initialisatie. Onze configuratie maakt gebruik


35

van vijf rollen die via hun PPS elk verwijzen naar een basis PPS. De resultaten zijn weergegeven in Tabel 3.4. RTT(ms)

Standaarddeviatie

web method

4

0,85

handler class

4,3

0,97

15,625

0,49

broker

Tabel 3.4: RTT

De RTT voor Case 1 en 2 zijn vrij gelijkaardig. Die van de Synapse ligt iets hoger. Om te vergelijken of deze vertraging ligt aan het gebruik van XACML in de broker of aan het gebruik van de Synapse, wordt ook de RTT bekeken bij gebruik van de broker zonder XACML. De resultaten in Tabel 3.5 tonen aan dat de overhead uitsluitend te wijten is aan de het gebruik van de Synapse en niet bij het feit dat XACML wordt opgeroepen vanuit een class mediator. Verder wordt hier opnieuw het bewijs geleverd dat de kost van een XACML evaluatie totaal verwaarloosbaar is bij een beperkt aantal policies. Synapse

RTT(ms)

Standaarddeviatie

Met XACML

15,625

0,49

Zonder XACML

15,525

0,51

Tabel 3.5: RTT proxy

3.3.5

Load testen

De resultaten van de load testen op de drie scenario’s zijn weergegeven in Figuur 3.9. In de test wordt het simultaan oproepen van de web service gevarieerd van 1 tot 1000 cliënts. De RTT stijgt in alle drie de gevallen lineair. Verder valt op dat de RTT bij Case 1 en 2 ook gelijkaardig blijven bij meerdere simultane requests. Bij de web service proxy ligt deze iets hoger, ongeveer 40%.

3.3.6

Voor- en nadelen van de verschillende locaties

De voordelen van toegangscontrole in de web method zijn de eenvoudigheid en behoud van end-to-end communicatie tussen cliënt en web service. Het grootste nadeel ligt bij de uitbreid-


36

Figuur 3.9: Resultaten van de load test op de drie scenario’s

baarheid van zo’n systeem of wanneer men het zou willen toepassen in een bestaande omgeving, zoals het ICSP. Men zou dan immers in elke web method van elke web service een stuk code moeten toevoegen waarin men toegangscontrole doet via XACML. Aangezien men in de web method niet aan de SOAP Message kan waarmee de web service wordt opgeroepen, zou ook elke web method een unieke user identifier moeten meekrijgen als argument. Wanneer men de wijze zou wijzigen waarmee een gebruiker zich kenbaar maakt, dient ook elke web method ge¨ updatet te worden in zijn XACML gedeelte. Om al deze redenen is deze methode eigenlijk praktisch niet aan te raden voor gedistribueerde architecturen. Toegangscontrole in een handler class is schaalbaarder dan de vorige en vereist in een bestaand systeem enkel de toevoeging van de annotatie in elke web service i.p.v. een deel code in elke web method van elke web service. Bij een nieuwe web service dient men enkel de annotatie op te nemen en de policies te updaten. Updaten van de policies is ook het enige noodzakelijke bij het toevoegen van een nieuwe web method in een bestaande web service. Ook kan geen enkele niet geautoriseerde gebruiker nog in een web service komen waarvoor hij geen toestemming heeft. Bij toegangscontrole in de broker wordt de end-to-end communicatie verloren tussen cliënt en endpoint. Wel is het bijvoorbeeld mogelijk om een SSL tunnel op de zetten tussen cliënt en broker enerzijds en broker en web service anderzijds. Voordeel is dat de web service omgeving volledig is afgeschermd van de cliënt en het systeem dus niet langer wordt lastig gevallen, tenzij de actie echt is toegelaten. Wel moet opgemerkt worden dat indien men uitsluitend de broker beveiligt, de web services onbeschermd zijn, indien men ze rechtstreeks zou kunnen benaderen.


37

Om deze reden is het aan te raden om nog een bijkomende toegangscontrole te doen aan de zijde van de web service, aangezien een XACML validatie toch een verwaarloosbare kost is (zie Tabel 3.3), of ervoor te zorgen dat enkel de broker mag communiceren met de web services en niemand anders. In een bestaand systeem met een broker zou er moeten gezorgd worden dat de cliënts via de broker de web service diensten opvragen en hoeft men enkel deze broker juist te configureren. Aanpassingen aan de bestaande web service omgeving zijn niet vereist. Wanneer men een nieuwe web service zou willen toevoegen aan het systeem, dient men er enkel voor te zorgen dat de broker de WSDL van de nieuwe web service publiceert en dat de policies worden ge¨ updatet met betrekking tot deze nieuwe web service. Bij het toevoegen van een web method aan een bestaande web service dienen enkel de policies ge¨ updatet te worden.

3.3.7

Conclusie

Praktisch gezien is het scenario waarbij aan toegangscontrole wordt gedaan in de web service zelf (case 1) niet aan te raden voor gedistribueerde architecturen. Dit vanwege de aanpassingen die moeten gedaan worden in een bestaand systeem en de volledige afhankelijkheid van de code voor toegangscontrole en de meegeleverde gebruikersidentiteit als parameter bij elke web method. Zo blijven enkel nog de twee andere mogelijkheden over. Het voordeel van toegangscontrole in de broker is dat deze dan gecentraliseerd is voor elke web service. Verder is er ook geen enkele aanpassing nodig aan bestaande web services. Het grootste nadeel is het verlies van de end-to-end communicatie. Verder is elke web service onbeschermd bij een rechtstreekse benadering, indien men enkel aan toegangscontrole doet in de broker. In hoofdstuk 4 wordt een complete oplossing voorgesteld op basis van deze bevindingen.

ARCHITECTUUR DESIGN

38

Hoofdstuk 4

Architectuur design Op basis van de experimenten uit hoofdstuk 3 wordt in dit hoofdstuk een architectuurvoorstel gedaan en zullen ook enkele eHealth aspecten, die we in hoofdstuk 2 aanhaalden, dieper bekeken worden op vlak van implementatie.

4.1

Architectuurvoorstel

Op basis van de experimenten uit hoofdstuk 3 wordt er voor gekozen om de toegangscontrole uit te voeren in de broker. Het grootste voordeel van een broker is de centralisatie van zowel de web service oproepen als de beveiliging. Het is dan ook logisch om hier aan autorisatie te doen, zodat de web services reeds hier worden afgeschermd van ongeoorloofde oproepen. Het grootste nadeel van deze keuze is dat de web services onbeschermd zijn binnen het LAN, indien er geen bijkomende beveiligingsmaatregelen zijn. Zolang er geen bijkomende security aspecten in rekening worden gebracht, wordt er daarom voorgesteld om toegangscontrole te doen zowel in de broker als in de handler chain net voor elke web service. Zeker omdat bij een beperkt aantal policies de tijd voor evaluatie verwaarloosbaar is (zie subsectie 3.2.2). Dit is weergegeven in Figuur 4.1. De meeste componenten in de architectuur zijn reeds eerder besproken in de hoofdstukken 2 en 3. De class mediator in de proxy en de handler class in de handler chain zullen optreden als PEP. Hier zullen aan de hand van het SOAP bericht de attributen worden samengesteld voor de XACML request. In het PEP zal ook bijkomende informatie worden ingewonnen over de resource en het subject via het PIP.

4.1 Architectuurvoorstel

39

Figuur 4.1: Architectuurvoorstel

Er worden in de architectuur twee nieuwe componenten ge¨ıntroduceerd, namelijk Context Handler Client en Context Handler Server. In de Context Handler Client zal de eigenlijke XACML request worden opgesteld. Op deze wijze is het mogelijk om applicatie specifieke benamingen om te zetten in uniforme begrippen. Men zal bijvoorbeeld de rol ’physician’ omzetten in ’urn:eHealth:ICSP:role:physician’ waarmee in de policies wordt gewerkt. Dit heeft tot gevolg dat men binnenin het ICSP kan blijven werken met de vereenvoudigde rol ’physician’ of zelfs met Nederlandstalige benamingen, die dan in de Context Handler Client worden vertaald naar uniforme benamingen, zodat uitwisselbaarheid van de policies blijft gegarandeerd. In de Context Handler Server wordt de XACML request ontvangen en kan bijkomende info worden opgevraagd bij de PIP. Daarna wordt de volledige request doorgegeven aan de PDP, die een beslissing maakt. Via XACML kunnen verschillende zaken worden gecontroleerd. Eerst zal men in de policy repository filteren op basis van de rol van de gebruiker in de zorgomgeving en dit volgens het RBAC Profile. Aan deze rollen zullen er meerdere permissies zijn toegekend. Deze kunnen onafhankelijk zijn van een patiënt of per patiënt verschillen. Iemand van de boekhouding zal immers van elke patiënt de kosten mogen opzoeken van de voorgeschreven medicatie, maar een dokter zal enkel het medische dossier van een patiënt mogen inkijken als hij de behandelende geneesheer

4.2 Policy repository voor zorgomgeving

40

is. Dit alles wordt ondersteund via onze architectuur, waar er vanaf nu ook toegangscontrole zal plaatsvinden op basis van de resource. Wanneer men het medische dossier van een patiënt wil inkijken, kan de PEP immers de identiteit opvragen van het subject bij het PIP, alsook de behandelende dokter van de patiënt. Deze kunnen dan vergeleken worden in een Rule gedeelte van een Policy en de actie zal enkel worden toegelaten indien beide gelijk zijn aan elkaar.

4.2

Policy repository voor zorgomgeving

Voor de opbouw van de policy repository moeten er een aantal zaken in rekening worden gebracht specifiek voor een zorgomgeving. Dit gaat dan over: ondersteuning van uniforme rollenverdeling via HL7 permissies omzeilen normale toegangsregels in geval van nood zorgen dat onafgewerkte onderzoeken niet beschikbaar zijn voor iedereen ondersteunen van privacy

4.2.1

Rollen

In XACML kan men, mits een kleine uitbreiding van het RBAC profile, zowel een collectie HL7 permissies als zelf gedefinieerde rollen (op basis van deze permissies) naast elkaar gebruiken door het invoegen van virtuele rollen. Het standaard RPS van het RBAC Profile verwijst nu niet langer rechtstreeks naar een PPS met hierin de permissies van de rol, maar doet dit via een nieuwe RPS, die de virtuele rol voorstelt. Een collectie van HL7 permissies kan eveneens naar zo’n virtuele rol verwijzen, die dan naar dezelfde PPS doorverwijst. Men kan dus nu zowel toegang aanvragen via een rol als via een aan u toegekende collectie van HL7 premissies. De virtuele rol en de PPS stellen dan de RPS en PPS voor uit het standaard RBAC Profile. Dit alles in voorgesteld in onderstaande Figuur 4.2. Specifiek voor het ICSP platform betekent dit dat, als we de rollen kennen en deze kunnen koppelen aan HL7 permissies, dat een gebruiker uit een andere zorginstelling ook gebruik zou kunnen maken van de resources van het ICSP, indien de collectie van HL7 permissies van deze gebruiker gekend zijn, dit ongeacht van de naam van de rol van deze gebruiker in zijn eigen


41

Figuur 4.2: RBAC uitgebreid voor ondersteuning van HL7 permissies

zorgomgeving. Men moet er dan wel zorgen dat een externe gebruiker steeds toegang vraagt via zijn HL7 permissies en niet via de naam van de rol uit zijn eigen zorgplatform. In praktijk betekent dit dat er via de top level PolicySet zowel wordt doorverwezen naar de RPS waarin men een virtuele rol koppelt aan een rol van de zorgomgeving, als naar de RPS waarin men via een collectie van HL7 permissies zal doorverwijzen naar bijhorende virtuele rol. Dit is weergegeven in onderstaand voorbeeld waar de PolicySet met id urn:eHealth:ICSP:policysetid:N degene is die een rol uit het zorgplatform zal linken met een virtuele rol. De PolicySet met id urn:eHealth:ICSP:policysetid:N:PermCollections zal dan weer een collectie van HL7 permissies koppelen aan een virtuele rol. Via het policy combining algoritme (permit-overrides) zorgen we ervoor dat als men toegang heeft verkregen via zijn rol, dit niet opnieuw wordt gecontroleerd via zijn HL7 permissies. Indien men geen rol heeft en enkel over een collectie HL7 permissies beschikt, zal men geen toegang verkrijgen via urn:eHealth:ICSP:policysetid:N en wordt de toegang gecontroleerd via uw HL7 permissies. Deze top level policy zal ingeladen worden via de StaticPolicyFinderModule en alle andere policies in de StaticRefPolicyFinderModule. Een request zal immers steeds door de top level policy worden geëvalueerd. urn:eHealth:policysetid:N


42

urn:eHealth:ICSP:policysetid:N:PermCollections

In de bijlagen zijn voorbeelden opgenomen van de urn:eHealth:ICSP:policysetid:N PolicySet (zie Bijlage A.2.1) en de urn:eHealth:ICSP:policysetid:N:PermCollections PolicySet (zie Bijlage A.2.2). Een voorbeeld van de virtuele rol van een dokter vindt men terug in Bijlage A.2.3 en een vereenvoudigde PPS in Bijlage A.2.4. De bedoeling is natuurlijk dat de collectie permissies die een dokter voorstellen naar dezelfde virtuele rol doorverwijst als de RPS waar de rol van dokter wordt gekoppeld aan een virtuele rol. In praktijk is het zo dat er een rol management infrastructuur zou moeten worden ontwikkeld, zodat de naam van de rol in het zorgplatform en de collectie permissies, die deze rol voorstellen, kunnen worden geëxporteerd en automatisch worden ge¨ımporteerd naar de PolicySet defenities. Het is immers beter dat men niet voor consistentie moet zorgen op Policy niveau, maar dit kan doen in een extern rol management systeem.

4.2.2

Noodgeval

In geval van nood moet het mogelijk zijn om de normale toegangscontrole te omzeilen. Dit wordt gedemonstreerd in Figuur 4.3. Ook dit ondersteunt XACML door middel van het toevoegen van een nieuwe PolicySet in de top level PolicySet: Top level policy.


43

Figuur 4.3: Toeganscontrole bij noodgeval

urn:eHealth:ICSP:policysetid:emergency urn:eHealth:ICSP:policysetid:N urn:eHealth:ICSP:policysetid:N:PermCollections


44

Het globale policy combining algoritme is nog steeds permit-overrides. Indien er immers voldaan is aan de noodgeval vereisten, moet de rest niet meer gecontroleerd worden. Er wordt aan het systeem wel opgelegd dat in geval van nood steeds de noodgeval permissie (urn:eHealth:ICSP:hl7:pea001) van de gebruiker aan het subject wordt toegevoegd, indien de gebruiker hierover beschikt (in het andere geval zal zijn toegang zelfs bij noodgeval worden geweigerd), en dat dit in een normale situatie nooit wordt vermeld (anders wordt immers steeds de normale toegangscontrole omzeild). Verder wordt er ook een obligation (urn:eHealth:ICSP:obligation:emergency:permit) aan de Policy toegevoegd, die de PEP verplicht de juiste acties te ondernemen bij een noodgevalsituatie. Dit kan gaan van extra logging tot het verwittigen van de juiste instanties, zodat men kan controleren of het uitroepen van de noodgeval situatie gewettigd was. Dit resulteert in de volgende PolicySet voor noogevallen: PolicySet die vereisten voor noodgeval controleert Wanneer het subject beschikt over een emergency permissie, wordt de actie toegelaten


<Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:hl7:pea-001 <SubjectAttributeDesignator AttributeId="urn:eHealth:ICSP:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"/>

45


4.2.3

46

Metadata

In deze sectie wordt er gedemonstreerd dat via XACML ervoor kan gezorgd worden dat onafgewerkte medische documenten beschermd zijn. Enkel indien men de auteur is zal het document beschikbaar zijn. Voor anderen zullen documenten enkel beschikbaar zijn indien de auteur van het document het heeft vrijgegeven en hiermee bevestigd dat het afgewerkt is. Dit wordt weergegeven in Figuur 4.4.

Figuur 4.4: Toeganscontrole bij gebruik van metadata

De ondersteuning van metadata in XACML zal gedemonstreerd worden door uitbreiding van de vereenvoudigde PPS uit subsectie 4.2.1, zie Bijlage A.2.4 voor het orgineel. Er wordt uitgegaan van het gegeven dat er metadata aan elke resource kan toegevoegd worden en dat deze kan opgevraagd worden door de PIP. Zo zal het mogelijk zijn om delen uit een medisch dossier of onderzoek te beveiligen, indien het om een niet afgewerkte of niet bevestigde versie gaat. Zolang het document niet is getekend of vrijgegeven door de auteur, zal het niet beschikbaar zijn voor anderen. Onderstaand voorbeeld is opnieuw de PPS van een dokter waar de permissies worden bekeken met betrekking tot de resource ’LaboratoryOrder’. In de eerste Rule van de PPS worden nu twee zaken gecontroleerd. Enerzijds moet de dokter nog steeds de behandelende arts zijn (controle in Condition) en anderzijds is het nu ook vereist dat het document getekend is door de auteur


47

(controle in Target). Zolang de laborant zijn onderzoeksresultaten niet heeft ondertekend en daarmee bevestigt dat ze voltooid zijn, zal het document niet beschikbaar zijn voor de arts. Op deze wijze kan voorkomen worden dat men conclusies trekt uit onafgewerkte of onvolledige onderzoeken. Via een obligation wordt ervoor gezorgd dat de arts wel wordt verwittigd indien de toegang hem is geweigerd vanwege het feit dat het document nog niet is vrijgegeven. Policy set voor de permissies van een doctor <Subjects> urn:eHealth:ICSP:resource:hl7:LaboratoryOrder


<Subjects> True <Apply FunctionId=

48


49

"urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <SubjectAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> Indien men hierboven geen Permit heeft gekregen, dan Deny als default.


50

4.2.4

Privacy

Pati¨ ent toestemming

Via XACML kan ervoor gezorgd worden dat de patiënt mee inspraak heeft over de vrijgave van zijn dossier of delen eruit. Via aanpassingen in de top level PolicySet zal het mogelijk zijn dat een patiënt bepaalde medici de toegang tot zijn dossier volledig ontzegt (User based access(UBA)) of dat een patiënt bepaalde delen uit zijn dossier onzichtbaar maakt voor bepaalde medici (Masked access (MA)). Dit laatste moet dan wel ondersteunt worden door het systeem ook, want wordt bekomen door het gebruik van obligations. In Figuur 4.4 wordt het gebruik van privacy getoond.

Figuur 4.5: Toeganscontrole met privacy

In de top level PolicySet wordt een nieuwe overkoepelende PolicySet toegevoegd, die zowel de normale toegangscontrole als de pricavy controle combineert via het deny-overrides algoritme. Deze overkoepelende PolicySet wordt met de emergency policy gecombineerd met het permitoverrides algoritme, zodat een noodgeval nog steeds voorrang krijgt. Wanneer een patiënt een subject de volledige toegang weigert tot zijn gegevens, zal dit een Deny opleveren en wordt de evaluatie hier direct onderbroken. De PEP wordt wel verwittigd van de reden van de Deny door middel van een obligation (privacy:constraint) en kan dit dan melden aan het subject. Voor een gedeeltelijke data filtering wordt er gebruik gemaakt van


51

een omgekeerde logica. De evaluatie hiervan zal steeds een Permit opleveren en dus de verdere evaluatie niet verhinderen. Indien het subject echter een deel van de data niet mag inkijken, zal er wel een obligation (ma:privacy:constraint) worden meegegeven, die dit meldt en dan is het aan de PEP om gepast te reageren. Het subject zal niet op de hoogte worden gebracht van het filteren. Zowel de aanwezigheid van UBA als MA wordt via een Target gecontroleerd door te kijken of in de resource een confidentiality-code aanwezig is. De resulterende top level PolicySet ziet er als volgt uit: Top level policy. urn:eHealth:ICSP:policysetid:emergency

52

PolicySetId="urn:eHealth:ICSP:policysetid:toplevel:CDA" PolicyCombiningAlgId= "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides"> <Subjects> UBA urn:eHealth:ICSP:policysetid:CDA <Subjects>


53

MA urn:eHealth:ICSP:policysetid:MA Wanneer bovenstaande PolicySet een deny oplevert, wordt deze default in Permit gewijzigd.

4.3 Implementatie

54

urn:eHealth:ICSP:policysetid:N urn:eHealth:ICSP:policysetid:N:PermCollections

In de bijlagen zijn voorbeelden opgenomen van de urn:eHealth:ICSP:policysetid:CDA PolicySet (zie Bijlage A.2.5) en de urn:eHealth:ICSP:policysetid:MA PolicySet (zie Bijlage A.2.6). In het eerste voorbeeld wordt gedemonstreerd hoe de volledige toegang wordt geweigerd voor het subject en in de tweede hoe een raadpleging bij een andere dokter kan verborgen gehouden worden voor een behandelende arts.

4.3 4.3.1

Implementatie Model

Voor de ondersteuning van de verschillende e-Health aspecten en de metadata die hiervoor gekend moet zijn, wordt er gewerkt met het model uit Figuur 4.6, dat bestaat uit drie basis klassen, namelijk Resource, Patient en Employee. Voor het ondersteunen van de emergency case bevat de Employee klasse een boolean die aangeeft of de persoon al dan niet over de emergency permissie beschikt. In de Context Handler Client zal deze boolean dan worden omgezet in de HL7 permissie ’urn:eHealth:ICSP:hl7:pea-001’.

4.3 Implementatie

55

Figuur 4.6: Model

Om onafgewerkte verslagen te beschermen wordt in de Resource klasse een author en signed attribuut voorzien. De author verwijst naar de Employee die de resource heeft aangemaakt en signed geeft aan of de author de resource reeds heeft vrijgegeven voor andere medewerkers of niet. Zowel de Resource als de Patient klasse bevatten attributen voor het ondersteunen van privacy. De Resource klasse bevat de mogelijkheid om via de confidentialityCode MA een Employee (dissentedSubject) de toegang te weigeren tot deze specifieke resource. De Patient klasse bevat dezelfde attributen, maar via de confidentialityCode UBA zal hier een Employee de toegang kunnen worden geweigerd tot alle gegevens over deze patient.

4.3.2

RTT

Om de invloed van het in rekening brengen van de verschillende eHealth aspecten, het toevoegen van de nieuwe componenten (PIP, Context Handler Client en Server) en het controleren van de toegang in zowel de broker als de in een handler class te bekijken, wordt de gemiddelde RTT bekeken. Hiervoor wordt 40 keer dezelfde web method opgeroepen waarmee men een ’LaboratoryOrder’ kan bekijken. Er wordt gebruik gemaakt van de policies, die in sectie 4.2 besproken zijn, en de XACML request ziet er uit als volgt: <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

4.3 Implementatie

56

urn:eHealth:ICSP:role:physician Wauman Wauman De Meester Claes True urn:eHealth:ICSP:resource:hl7:LaboratoryOrder

4.3 Implementatie

57

urn:be:ugent:eHealth:ICSP:Documentation:readOrder

Een dokter Wauman probeert om een LaboratoryOrder van patiënt De Meester te lezen. Via metadata geeft men aan dat de auteur van dit laborant Claes is en dat hij het document reeds heeft vrijgegeven. De behandelende dokter is ook doktor Wauman. Via de policies zal men bekomen dat de actie is toegelaten. Ter vergelijking wordt ook de gemiddelde RTT berekent voor het geval wanneer er enkel toegangscontrole plaatsvindt in een handler class en er geen gebruik wordt gemaakt van een proxy. De resultaten vindt men in Tabel 4.1. RTT(ms)

Standaarddeviatie

Architectuur

39,15

7,24

Architectuur zonder proxy

23,99

9,16

Tabel 4.1: RTT architectuur

Het verschil van 15,15 ms kan volledig verklaard worden door het gebruik van de proxy, zoals ook in subsectie 3.3.4 werd vastgesteld. Het verschil met de resultaten uit subsectie 3.3.4 ligt aan het feit dat vanuit de handler class en de mediator het PIP wordt opgeroepen waaruit meerdere keren een database wordt geraadpleegd, die de informatie bevat van de resources, en dat in totaal gemiddeld 13 ms kost.

TECHNOLOGIESTUDIE EXTERNE BEVEILIGING

58

Hoofdstuk 5

Technologiestudie externe beveiliging In de vorige hoofdstukken werd de kern van de scriptie, het autorisatieprobleem, behandeld in een eHealth omgeving via XACML en RBAC. Externe beveiliging, zoals authenticatie en encryptie, werd hier achterwege gelaten. In dit hoofdstuk worden enkele technieken voor externe beveiliging bekeken. Op basis hiervan wordt in hoofdstuk 6 de architectuur uit het vorige hoofdstuk uitgebreid met authenticatie en encryptie.

5.1

Transport Layer Security

Transport Layer Security (TLS) en zijn voorganger, Secure Sockets Layer (SSL), zijn cryptografische protocols die authenticatie, data confidentialiteit en data integriteit voorzien voor communicatie over netwerken. Een voordeel van TLS is dat het onafhankelijk is van het applicatieprotocol. Het protocol loopt bovenop transport protocollen (TCP/IP) en onder applicatieprotocollen zoals HTTP. SSL 3.0[52] is ontwikkeld door Netscape en uitgebracht in 1996. Het maakt gebruik van het asymmetrische encryptie protocol RSA voor de uitwisseling van een symmetrische sleutel en voor authenticatie tijdens een handshake proces. Daarna wordt de symmetrische sleutel gebruikt voor encryptie van de uit te wisselen data. SSL 3.0 werd later de basis voor The TLS Protocol Version 1.0[53], een IETF standaard, gepubliceerd in RFC 2246 in 1999. Later werd deze versie nog uitgebreid voor het gebruik van Kerberos, AES en het gebruik van TLS over HTTP/1.1. De huidige standaard is TLS 1.2[54].

5.2 WS-Security

59

TLS bestaat bestaat, net als SSL, uit twee interne lagen (zie Figuur 5.1): TLS Record Protocol wordt gebruikt om data confidentialiteit en integriteit te garanderen

en zorgt ook voor de fragmentatie en encapsulatie van de parameters van de andere TLS protocols. Het Handshake Protocol, Change Cipher Protocol en Alert Protocol zorgen voor het tot

stand komen van de TLS connectie en het beheer ervan.

Zoals eerder vermeld zorgt TLS dus voor authenticatie, data confidentialiteit en integriteit gedurende een HTTPS sessie. Eenmaal de data de tunnel verlaat, is er echter geen protectie meer en is het bericht onbeveiligd. Wanneer er dus communicatie is via intermediaire hops wordt end-to-end integriteit niet langer gegarandeerd, omdat het gehele bericht verstuurd wordt via een beveiligde tunnel en partiële encryptie van een bericht niet wordt ondersteund.

5.2

WS-Security

Web Services Security (WSS) is een protocol ter beveiliging van web services en doet dit op het niveau van de message layer. WSS is oorspronkelijk ontworpen door IBM, Microsoft en VeriSign en voor het eerst uitgebracht als standaard in 2004 door OASIS als WS-Security 1.0. De huidige standaard, WS-Security 1.1 [55], dateert uit 2006. De specificatie bevat methoden om integriteit en confidentialiteit te ondersteunen in een web service omgeving. WSS laat toe om SOAP berichten te beveiligen onafhankelijk van de transportlaag. WSS beschrijft hiervoor hoe men handtekeningen, ecryptieheaders en beveiligingstokens kan toevoegen aan SOAP berichten. Het maakt hiervoor gebruik van XML Encryption[56] en XML Digital Signature[6]. XML Encryption is een W3C recommandatie die toelaat XML berichten geheel of gedeeltelijk te encrypteren en op deze wijze confidentialiteit te voorzien. XML Digital Signature is ook een W3C recommandatie en deze laat toe om XML documenten te tekenen. Verschillende delen van een document kunnen getekend worden zodat integriteit is gegarandeerd. XML Key Management Specification wordt bij beide technieken gebruikt voor het verkrijgen van informatie over de encryptiesleutel.

5.2 WS-Security

60

Figuur 5.1: TLS stroomdiagram

5.2 WS-Security

61

De beveiligingstokens worden typisch gebruikt voor de uitwisseling van de identiteit en de sleutels voor de encryptie. WSS definieert hoe men deze tokens kan toevoegen aan de SOAP header en hoe men ernaar kan verwijzen vanuit geëncrypteerde of getekende data, maar niet hoe men deze tokens bekomt. Hiervoor wordt verwezen naar de uitbreiding WS-Trust (zie subsectie 5.2.1), waar beschreven wordt hoe men security tokens kan opvragen, vernieuwen en valideren.

5.2.1

WS-Trust

WS-Trust is een OASIS standaard en de huidige standaard, WS-Trust 1.4[58], dateert uit 2009. Het is een uitbreiding van WSS en behandeld zowel het bekomen, vernieuwen en valideren van security tokens, als een manier om een vertrouwensrelatie op te zetten tussen verschillende actoren bij de uitwisseling van beveiligde berichten. WS-Trust definieert hiervoor een aantal nieuwe elementen en concepten, waaronder: het concept van een Security Token Service (STS) - een web service die security tokens

verdeelt zoals beschreven in de WSS standaard het formaat van de berichten om een security token aan te vragen en het antwoord hierop mechanismen voor de uitwisseling van sleutels

In Figuur 5.2 wordt het gebruik van WS-Trust gedemonstreerd. De gebruiker zal zich eerst authenticeren bij de STS via bijvoorbeeld een paswoord of X.509 digitale handtekening over een beveiligd kanaal via een RST (request security token) bericht. Vervolgens zal de STS de gebruiker valideren en een security token genereren. Het security token wordt vervolgens, meestal getekend, verstuurd naar de gebruiker in een RSTR (RST response) bericht. De gebruiker zal het security token toevoegen aan zijn request naar de service. Deze gaat dan na of het security token wel degelijk afkomstig is van de STS en niet is vervalst en kan het security token gebruiken als authenticatie bewijs van de gebruiker.

5.2.2

WS-SecureConversation

WS-SecureConversation werd voor het eerst gepubliceerd door IBM in 2004. De huidige standaard, WS-SecureConversation 1.4[57], is een OASIS standaard sinds 2009.

5.3 Single Sign-On

62

Figuur 5.2: Gebruik van een STS in WS-Trust

WS-SecureConversation is een uitbreiding van WSS en biedt een oplossing voor het geval er meerdere berichten worden uitgewisseld tussen een cliënt en een web service. Waar WSS encryptie doet via XML Encryption met asymmetrische sleutels, biedt WS-SecureConversation een oplossing gelijkaardig aan SSL en wordt er een security context ge¨ınitialiseerd. De WS-SecureConversation specificatie beschrijft hoe deze security context wordt bekomen en hoe de sessie sleutels worden berekend uit een nieuw SecurityContextToken. Op deze wijze bekomt men efficiëntere sleutels wat de prestatie ten goede komt.

5.3

Single Sign-On

Single Sign-On (SSO)[59] is een eigenschap van toegangscontrole, zodat een gebruiker slechts eenmaal moet inloggen om toegang te krijgen tot alle systemen waarmee men een trust relatie heeft, in plaats van telkens opnieuw te moeten inloggen bij elk systeem individueel. SSO maakt gebruik van een gecentraliseerde authenticatie server waarvan elk ander systeem gebruik maakt voor authenticatie doeleinden. Dit heeft meerdere voordelen: Vermindert paswoord vermoeidheid vanwege verschillende gebruikersnaam/paswoordcom-

binaties. Vermindert de tijd voor het steeds opnieuw te moeten inloggen voor zelfde identiteit bij

individuele systemen. Verlagen van de tijd voor het toevoegen en verwijderen van gebruikers door systeembe-

heerders en het wijzigen van de toegangsrechten.

5.4 WS-Policy

63

Verhoogde beveiliging door de verbeterde mogelijkheden van systeembeheerders om de in-

tegriteit van de configuratie van een gebruikersaccount op een gecoördineerde en coherente wijze te beheren met inbegrip van de mogelijkheid om individuele gebruikerstoegang tot alle systeembronnen te verhinderen of verwijderen.

5.3.1

Security Assertion Markup Language

Security Assertion Markup Language (SAML) is een product van het OASIS Security Services Technical Committee[60]. De eerste versie werd in 2002 gepubliceerd en de huidige standaard, SAML 2.0 [5], dateert van maart 2005. SAML is een XML-gebaseerde standaard voor het beschrijven en uitwisselen van authenticatie en autorisatie data tussen een identity provider en een service provider. Deze data wordt uitgedrukt in de vorm van uitwisselbare SAML assertions. SAML specificeert de syntax en regels voor het aanvragen, aanmaken, communiceren en gebruiken van deze SAML assertions. SAML is ontworpen als een oplossing voor het SSO probleem. Het veronderstelt dat de opdrachtgever (meestal een gebruiker) zich heeft ingeschreven bij een STS. Een service provider hangt dus af van de STS voor de identificatie van de opdrachtgever. Op verzoek van de opdrachtgever geeft de STS een SAML assertion door aan de service provider. Op basis van deze assertion zal de service provider een beslissing maken over de toegangscontrole.

5.4

WS-Policy

WS-Policy 1.5[61] is een W3C recommandatie sinds september 2007. WS-Policy voorziet een flexibele en uitbreidbare grammatica voor het uitdrukken van de mogelijkheden, voorwaarden en de algemene kenmerken van entiteiten in een XML web services-gebaseerd systeem. WS-Policy definieert een framework en een model voor de uitdrukking van deze eigenschappen als policies. WS-Policy definieert een policy als een verzameling van policy assertions. Sommige policy assertions zijn cruciaal voor een goede service selectie en gebruik, zoals privacybeleid, QoS kenmerken, transport protocol selectie, authenticatie schema’s, etc. WS-Policy zorgt voor een uniforme policy grammatica, zodat alle soorten policies worden gedefinieerd op een consistente manier.

5.4 WS-Policy

64

WS-Policy specificeert echter niet hoe de policies worden ontdekt of aan een web service worden gekoppeld. Andere specificaties zijn vrij in het bepalen van technologie-specifieke mechanismen voor policies met verschillende entiteiten en resources. WS-PolicyAttachment[62] definieert dergelijke mechanismen, vooral geassocieerd met willekeurige XML-elementen, WSDL artefacten en UDDI elementen.

5.4.1

WS-XACML

Web Services Profile of XACML (WS-XACML)[28] is een uitbreiding voor XACML en wordt momenteel overwogen als toevoeging voor de XACML 3.0 standaard. WS-XACML verschilt in die zin van XACML dat XACML gegeven een stel attributen en een policy zal zeggen of de attributen geldig zijn of niet en dat WS-XACML gegeven twee policies de gemeenschappelijke accepteerbare attributen zal geven, zoals weergegeven in Figuur 5.3.

Figuur 5.3: WS-XACML

Het profiel definieert eerst een XACML Assertion type, samen met de evaluatie en de matching semantiek. Het profiel beschrijft vervolgens twee specifieke Assertions die zijn afgeleid van dit type: XACMLAuthzAssertion voor gebruik met de autorisatie en toegangscontrole policies XACMLPrivacyAssertion voor gebruik met privacy policies

Verschillende nieuwe XACML functies en attributen worden beschreven voor het gebruik met deze Assertions. Het profiel biedt niet-normatieve voorbeelden van het gebruik van de XACMLPrivacyAssertion aan voor zowel de gebruiker als de service privacy voorkeuren en aanbiedingen met betrekking tot de P3P-privacybeleid.

5.5 Beveiliging ICSP

65

Om twee WS-XACML policies te combineren worden drie stappen uitgevoerd: De doelstellingen van de twee policies moeten overeenkomen. Als ze niet overeenkomen,

dan zijn de twee policies niet compatibel. De rules uit de twee policies worden gepaard in alle mogelijke combinaties en vervolgens

gesorteerd in de volgorde van de vragende partij, en daarna door de gewenste volgorde van de andere partij (andere algoritmen kunnen worden gebruikt). Alle rule paren worden gecombineerd tot een nieuwe rule. Als de twee rules in de koppeling

niet kunnen worden gecombineerd dan wordt de koppeling geëlimineerd. De resulterende reeks regels vertegenwoordigt de gecombineerde policy. Als deze set leeg is, dan zijn de twee policies niet compatibel.

Policy onderhandelingen kunnen zowel statisch of dynamisch. Het kan eenmaal gebeuren tussen twee partijen die statische policies hebben, met als gevolg dat het resultaat tekens opnieuw wordt gebruikt voor elke communicatie tussen hen. Anderzijds kan het worden gedaan ’at runtime’, gebaseerd op policies, die dynamische constraints voorstellen relevant tot de specifieke service request.

5.5

Beveiliging ICSP

In Tabel 5.1 worden enkele beveiliging requirements opgesomd voor het ICSP en via welke techniek ze kunnen worden ondersteund. XACML autorisatie

TLS

WSS

WS-Trust

SAML

x

x

x

authenticatie data confidentialiteit

x

x

data integriteit

x

x

eisen kenbaar maken geen replay

WS-Policy

x x Tabel 5.1: Security requirements ICSP

x

ARCHITECTUUR MET EXTERNE BEVEILIGING

66

Hoofdstuk 6

Architectuur met externe beveiliging In dit hoofdstuk worden eerst twee belangrijke methoden vergeleken voor het voorzien van data confidentialiteit en integriteit. Vervolgens zal de architectuur uit hoofdstuk 4 worden uitgebreid met mechanismen voor authenticatie en data confidentialiteit en integriteit. Tot slot zal een mogelijke globale oplossing worden ge¨ımplementeerd met behulp van Metro.

6.1

TLS vs WSS

Eerst en vooral moet er afgewogen worden of er gebruik wordt gemaakt van WSS of TLS. De eigenschappen van beide methoden worden samengevat in Tabel 6.1. TLS end-to-end

x

point-to-point

x

transport layer security

x

message layer security encryptie

WSS

x x

x

partiële encryptie

x

handtekening

x

prestatie

x

Tabel 6.1: Eigenschappen van TLS en WSS

Het belangrijkste gevolg van een keuze voor TLS is het verlies van de end-to-end communicatie.

6.2 Uitbreiding architectuur met externe beveiliging

67

Wanneer men deze techniek wil gebruiken in het broker platform, zal men een TLS tunnel moeten opzetten tussen cliënt en broker enerzijds en broker en web service anderzijds. Binnenin de broker zal het SOAP bericht onbeschermd zijn. Voordeel hiervan is natuurlijk dat men binnen de broker aan autorisatie kan doen op basis van de gegevens in het SOAP bericht. Voor een digitale handtekening bij de berichten, wat zeker vereist is in een e-Health omgeving, zal er sowieso gebruik moeten maken van de XML Digital Signature eigenschap van WSS. Enkel TLS gebruiken is dus niet mogelijk, maar een combinatie van TLS (encryptie) en WSS (handtekening) is zeker een oplossing. Wanneer men voor WSS kiest kan men end-to-end beveiliging voorzien. Voordeel is hier dat de berichten ook in elke intermediaire knoop zijn beschermd. Nadeel is dat men niet langer aan autorisatie kan doen in de broker aangezien men gegevens nodig heeft uit zowel de SOAP header als de SOAP body. De gegevens uit de SOAP header kunnen eventueel vrijgegeven worden door via partiële encryptie enkel de SOAP body te encrypteren, maar dan kan men nog steeds niet aan de gegevens in verband met de resource, die als parameter worden meegegeven bij een web method. Autorisatie zal in dit geval in een handler class dienen te gebeuren. Verder is het ook zo dat TLS voor encryptie beter presteert dan de standaard WSS [63, 64]. Door het gebruik van de WSS uitbreiding WS-SecureConversation kan dit prestatieverschil wel worden verwaarloosd. De keuze voor WSS of TLS is eigenlijk volledig arbitrair en hangt af van het feit of men erop staat om de autorisatie effectief in de proxy (ervan uitgaande dat deze niet gecompromitteerd kan zijn) uit te voeren, of dat men eerder de voorkeur geeft aan end-to-end communicatie. In het vervolg van dit hoofdstuk zal de architectuur uit hoofdstuk 4 voor beide gevallen worden uitgebreid.

6.2

Uitbreiding architectuur met externe beveiliging

Eerst zal de uitbreiding van de architectuur met TLS worden besproken en vervolgens die met WSS. Zowel voor het gebruik van TLS als van WSS worden de beveiliging eisen van de web services via WS-Policy gepubliceerd in hun WSDL.


6.2.1

68

Via TLS

Naast TLS wordt er ook gebruik gemaakt van WS-Trust en de STS die hierin wordt gedefinieerd. Elke gebruiker zal zich moeten authenticeren bij deze STS via login/paswoord, X.509, Kerberos, eID of een ander mechanisme en krijgt dan een SAML Assertion. De communicatie tussen de gebruiker en de STS wordt beveiligd via 2-way SSL, zodat zowel de STS als de gebruiker zich moeten authenticeren ten opzichte van elkaar. Verder kan het gebruik van het tragere XML Digital Signature zo ook worden voorkomen. De communicatie tussen de gebruiker en de broker wordt beveiligd met TLS en XML Digital Signature (WSS). Er wordt gebruik gemaakt van 1-way SSL, zodat enkel de proxy zich authenticeert ten opzichte van de gebruiker in de transport laag. Daarnaast zal gebruik worden gemaakt van WSS voor een XML Digital Signature (WSS DG). De broker zal aan de hand van de SAML Assertion de identiteit van de gebruiker kunnen controleren bij de STS via een 2-way SSL tunnel. Aan de hand van de identiteit van de gebruiker zal er in de broker aan autorisatie worden gedaan. Dit is verder de enige plaats waar er autorisatie plaatsvindt aangezien men via TLS kan bekomen dat de web services enkel oproepen aanvaarden die afkomstig zijn van de proxy. De communicatie tussen de broker en de web service wordt ook beveiligd via een 2-way SSL tunnel. Al het bovenstaande wordt weergegeven in Figuur 6.1. Op deze wijze wordt de beveiliging van het platform bekomen voor meerdere aspecten via de verschillende beveiligingstechnieken, zoals samengevat in Tabel 6.2: TLS authenticatie

WSS DG

WS-Trust (STS)

SAML

x

x

x

autorisatie

XACML

x

data confidentialiteit

x

data integriteit

x

geen replay

x

x

Tabel 6.2: Beveiliging via TLS

Een replay aanval wordt voorkomen door het gebruik van de 2-way SSL of door middel van


69

Figuur 6.1: Architectuurvoorstel met TLS als externe beveiliging

het toevoegen van een timestamp en geldigheidsperiode aan de SAML Assertion. Voor het voorkomen van een denial of service aanval zullen extra firewall maatregelen moeten worden genomen in de broker. Dit kan gaan van een simpele filter op basis van IP of door middel van een firewall die expliciet XML tags en SOAP headers kan lezen en hierop filteren.

6.2.2

Via WSS

Ook in het geval van beveiliging via WSS wordt er gebruik gemaakt van de STS, die in WSTrust wordt gedefinieerd. Na authenticatie zal er een SAML Assertion worden bekomen. De communicatie tussen de gebruiker en de STS wordt beveiligd via WS-SecureConversation (WSSC) of 2-way SSL, naar eigen voorkeur. De communicatie tussen de gebruiker en de web service (end-to-end security) wordt bekomen door gebruik van WS-SecureConversation waarbij gebruik wordt gemaakt van de encryptie mechanismen van WS-SecureConversation en XML Digital Signature van de standaard WSS. De


70

autorisatie vindt nu enkel plaats in de handler class aangezien men in de broker niet langer de SOAP body zal kunnen lezen. Om de mogelijkheid aan te bieden om aan extra beveiliging en routing te doen in de proxy zal enkel de SOAP body worden geëncrypteerd. In de broker zal men dus wel de identiteit van de gebruiker kunnen controleren en nagaan of het om een gelegitimeerde gebruiker gaat. Ook zal men bijvoorbeeld berichten kunnen filteren in een firewall op basis van informatie uit de SOAP header. Op deze wijze kan een denial of service aanval worden voorkomen. Al het bovenstaande wordt weergegeven in Figuur 6.2.

Figuur 6.2: Architectuurvoorstel met WSS als externe beveiliging

Op deze wijze wordt de beveiliging van het platform bekomen voor meerdere aspecten via de verschillende beveiligingstechnieken, zoals samengevat in Tabel 6.3.

6.3 Implementatie

71

WS-SC authenticatie

WSS DG

WS-Trust (STS)

SAML

x

x

x

autorisatie

XACML

x

data confidentialiteit

x

data integriteit

x

geen replay

x Tabel 6.3: Beveiliging via WSS

6.3

Implementatie

Om de invloed op de RTT te zien bij de toevoeging van externe beveiliging wordt er gezorgd voor een implementatie van de beveiliging met WSS. Hiervoor zal gebruik worden gemaakt van de tool Metro.

6.3.1

Metro

Metro[65] is een project van de Glassfish community. De huidige versie is Metro 1.5. Het voorziet ondersteuning van verschillende standaarden waarvan de belangrijkste de volgende zijn: JAX-WS 2.0/2.1 JAXB 2.0/2.1 Reliable Messaging v1.1 Security

– WS-Security v1.1 – WS-Trust v1.3 – WS-SecureConversation v1.3 Security Profiles

– Username Token Profile 1.1 – X.509 Token Profile 1.1 – SAML Token profile 1.1

6.3 Implementatie

72

– Kerberos Token Profile 1.1 Policy

– WS-Policy v1.5 – WS-PolicyAttachment v1.5

Metro is eenvoudig te integreren in de Glassfish servers en de Netbeans IDE omgeving, die gebruikt wordt bij de implementatie. Het enige nadeel van Metro is dat het nog niet SSO ondersteunt. Wanneer een omgeving dus uit meerdere services bestaat, zal de gebruiker voor elke service apart een SAML Assertion moeten opvragen bij de STS. Via WS-SecureConversation tussen de gebruiker en de STS kan wel worden voorkomen dat de gebruiker zich steeds opnieuw moet authenticeren bij de STS.

6.3.2

RTT

Aangezien Synapse slechts een lightweight ESB is, bleek het niet mogelijk om Metro hierin te integreren. Hierdoor bleek implementatie van de architectuur met externe beveiling via TLS niet mogelijk. Daarnaast verwijdert Synapse ook elke security header wanneer er WSSecureConversation wordt gebruikt tussen de gebruiker en de web service, zodat berichten bij de web service worden geweigerd. Om deze reden, en omdat het security luik niet de kern vormt van deze scriptie, werd enkel een implementatie voorzien waarbij gebruik wordt gemaakt van de architectuur zoals beschreven in subsectie 6.2.2, met dit verschil dat er geen gebruik wordt gemaakt van de broker. In Tabel 6.4 wordt de gemiddelde RTT weergegeven voor deze architectuur. Het grootste verschil met de RTT die bekomen werd in subsectie 4.3.2, ligt aan het gebruik van de digitale handtekening bij WSS en slechts in mindere mate aan het gebruik van de encryptie opties van WS-SecureConversation.

RTT

Tijd (ms)

Standaarddeviatie

257,85

23,21

Tabel 6.4: RTT bij externe beveiliging

6.3 Implementatie

73

Toevoegen van de broker zou deze RTT vermeerderen met 15,53 ms zoals reeds eerder vermeld in Tabel 3.5. Wanneer men gebruik zal maken de architectuur met TLS, zal deze RTT iets hoger liggen aangezien elk bericht in de broker wordt gedecrypteerd en vervolgens opnieuw wordt geëncrypteerd alvorens het bericht door te sturen naar de web service.

CONCLUSIE

74

Hoofdstuk 7

Conclusie 7.1

Conclussie

In deze scriptie werd autorisatie onderzocht voor het ICSP. De focus lag vooral op de ondersteuning van RBAC en de specifieke vereisten van een e-Health platform, zoals privacy, de noodgeval situatie, de ondersteuning van metadata en uniforme rollen. Via XACML konden al deze e-Health aspecten worden opgevangen. Daarnaast is de kost van een XACML evaluatie vrijwel verwaarloosbaar. XACML is dus zeker een oplossing voor autorisatie in het ICSP. In deze Masterproef werd ook gekeken naar de integratie van autorisatie via XACML met andere beveiligingstechnieken die voor externe beveiliging zorgen zoals authenticatie, data confidentialiteit en integriteit. Er werden twee suggesties gedaan. De eerste zorgt voor point-to-point security via TLS en de tweede zorgt voor end-to-end security via WS-SecureConversation. In beide gevallen wordt het systeem beschermt via autorisatie, authenticatie, data confidentialiteit en integriteit en het voorkomen van replay en denial of service aanvallen.

7.2

Toekomstig werk

Voor de implementatie van de autorisatie werd gebruik gemaakt van Sun’s XACML Implementation 1.2. Deze ondersteunde XACML 1.1. Het blijft echter uitkijken naar de eerste afgewerkte open source implementatie die de huidige standaard, XACML 2.0, ondersteunt. Daarnaast zal waarschijnlijk dit jaar nog XACML 3.0 worden gepubliceerd en gestandaardiseerd door het OASIS XACML TC. Het blijft interessant om te volgen welke van de drie profielen, die

7.2 Toekomstig werk

75

momenteel in overweging worden genomen, effectief tot de standaard zullen worden opgenomen. ANSI INCITS is dit jaar gestart met de herziening van de RBAC standaard. Ook deze evolutie is interessant om te volgen. Daarnaast moet er ook uitgekeken wordt of HL7 naast de permissies en het gebruik hiervan voor het definiëren van rollen, misschien overgaat tot de standaardisatie van echte rollen. Voor de implementatie van de externe beveiliging werd gebruik gemaakt van Metro 1.5. Deze steunt op de standaarden WS-Trust 1.3 en WS-SecureConverstation 1.3. Dit jaar werden in februari echter de nieuwe standaarden WS-Trust 1.4 en WS-SecureConversation 1.4 gepubliceerd. Eind deze maand (28 mei 2009) staat de release van Metro 2.0 gepland. Deze zal beide nieuwe security standaarden ondersteunen, net als de standaarden JAX-WS 2.2 en JAXB 2.2. Metro 1.5 voorzag ook geen ondersteuning voor SSO. In het ICSP, dat bestaat uit meerdere web services, zou SSO een grote prestatiewinst opleveren, omdat de gebruiker niet telkens opnieuw een unieke SAML Assertion moet opvragen bij de STS voor elke web service apart. Metro 2.0 voorziet de ondersteuning van SSO.

BRONCODE

76

Bijlage A

Broncode A.1

Voorbeelden bij hoofdstuk 2

A.1.1

Voorbeeld van PolicySet

Het volgende voorbeeld van een PolicySet bevat juist één Policy. Deze Policy is van toepassing op elke request waarin het subject over de rol van een dokter beschikt. Dit wordt aangegeven binnen het Target gedeelte van de Policy. Vervolgens bevat deze Policy één Rule, die zegt dat de actie ’read’ toegelaten is op de resource ’file://example/med/record/patient/BartSimpson’. Wanneer een dokter het medisch dossier van de patiënt Bart Simpson zal willen inlezen, zal de PDP op basis van deze policy beslissen dat de actie toegelaten is. <Subjects> <Subject>

A.1 Voorbeelden bij hoofdstuk 2

77

<SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> physician <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/> <Subjects> file://example/med/record/patient/BartSimpson


78

read

A.1.2

Voorbeeld van RPS en bijhorende PPS

In onderstaand voorbeeld van een RPS wordt er eerst gekeken of het subject uit de XACML request beschikt over de rol van dokter via het Target. Indien dit zo is, zal men doorverwezen worden naar de PolicySet met id ’PPS:physician:role’.


79

<Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> physician <SubjectAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/> PPS:physician:role

Onderstaand voorbeeld is de PPS waarnaar de RPS van hierboven verwijst. Men kan dus enkel via de voorwaarde uit die RPS tot deze PPS komen of vanuit een andere PPS van een rol die hoger in de hiërarchie staat. Met andere woorden de permissies die hier staan, behoren enkel een dokter toe of rollen die eveneens elke permissie van een dokter erven. De RPS bevat één Policy met één Rule. Deze Rule zegt dat wanneer men het medisch dossier van de patiënt Bart Simpson wil inlezen, dit toegelaten is. Daarnaast bevat de PPS ook nog een verwijzing naar een andere PPS, namelijk die met de permissies van een verpleegster. Door de combinatie van de RPS en de PPS, mag een dokter dus het medisch dossier inlezen van de patiënt Bart Simpson en daarnaast krijgt een dokter nog alle bevoegdheden van een verpleegster.


80

<Subjects/> file://example/med/record/patient/BartSimpson


81

read PPS:nurse:role

A.1.3

Voorbeeld van HasPrivilegesOfRole Policy en bijhorende XACML request

Onderstaand voorbeeld is de HasPrivilegesOfRole Policy voor de dokter rol. <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in">


82

physician <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:anyURI-is-in"> urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesofRole

Een bijhorende XACML request waarmee men te weten wil komen of het subject Anne over de privileges van de dokter rol beschikt, zal er dan als volgt uitzien: <Subject> Anne


83

physician urn:oasis:names:tc:xacml:2.0:actions:hasPrivilegesOfRole

A.1.4

Voorbeeld van Role Assignment Policy

Onderstaand voorbeeld is een Role Assignment Policy, waarmee het subject (Steve) de dotor rol kan worden toegewezen. <Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> Steve


84

<SubjectAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> physician urn:oasis:names:tc:xacml:2.0:actions:enableRole

85

"urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

A.2

Voorbeelden bij hoofdstuk 4

A.2.1

urn:eHealth:ICSP:policysetid:N

Dit is een voorbeeld van een RPS waar de rollen van dokter en verpleegster uit de zorgomgeving worden gekoppeld aan hun virtuele rol, respectievelijk physician-vrole en nurse-vrole. De controle of het om een dokter dan wel een verpleegster gaat, gebeurd via het Target. Policy set voor het linken van rollen uit het zorgplatform met hun virtuele rol <Subjects> <Subject>


86

<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:role:physician <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/> urn:eHealth:ICSP:policysetid:N:RPS:physician-vrole <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:role:nurse <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"


87

DataType="http://www.w3.org/2001/XMLSchema#string"/> urn:eHealth:ICSP:policysetid:N:RPS:nurse-vrole

A.2.2

urn:eHealth:ICSP:policysetid:N:PermCollections

In dit voorbeeld wordt een collectie van HL7 permissies erkend als die van een dokter en een verpleegster en gelinkt met hun virtuele rol, respectievelijk RPS:nurse-vrole en RPS:nurse-vrole. Hier vindt men ook een aantal voorbeelden van HL7 permissies terug: prd-012: lezen van informatie i.v.m. visites uit het verleden van een patiënt ppd-047: invoeren van een nieuwe inenting voor een patiënt prd-010: lezen van voorgeschreven medicatie van een patiënt prd-011: lezen van informatie over de allergieën van een patiënt

In deze PolicySet worden collecties van HL7 permissies gekoppeld aan de virtuele rol die ze voorstellen.

88

PolicySetId="urn:eHealth:ICSP:policysetid:N:perm-sets" PolicyCombiningAlgId= "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides"> Hier worden de HL7 permissies die minimaal nodig zijn voor een dokter rol, gekoppeld aan de virtuele rol van een dokter. <Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:prd-012 <SubjectAttributeDesignator AttributeId="urn:eHealth:ICSP:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"/>

...

<SubjectMatch MatchId=


89

"urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:hl7:ppd-047 <SubjectAttributeDesignator AttributeId="urn:eHealth:ICSP:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"/> urn:eHealth:ICSP:policysetid:N:RPS:physician-vrole Hier worden de HL7 permissies die minimaal nodig zijn voor een verpleegster rol, gekoppeld aan de virtuele rol van een verpleegster. <Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal">

DataType="http://www.w3.org/2001/XMLSchema#string"> urn:eHealth:ICSP:hl7:prd-010 <SubjectAttributeDesignator AttributeId="urn:eHealth:ICSP:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"/>

...

<SubjectMatch MatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> urn:eHealth:ICSP:hl7:prd-011 <SubjectAttributeDesignator AttributeId="urn:eHealth:ICSP:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"/> urn:eHealth:ICSP:ICSP:policysetid:N:RPS:nurse-vrole

90


A.2.3

91

urn:eHealth:ICSP:policysetid:N:RPS:physician-vrole

De PolicySet die de virtuele rol van de dokter voorstelt en doorverwijst naar de RPS met de permissies van een dokter. Virtuele rol van de dokter die doorverwijst naar de PPS met de eigenlijke permissies. urn:eHealth:ICSP:policysetid:N:PPS:physician

A.2.4

urn:eHealth:ICSP:policysetid:N:PPS:physician

Een vereenvoudigd voorbeeld van de PPS van een dokter. In de ene Policy die de PPS bevat wordt er eerst gefilterd op de resource ’urn:eHealth:ICSP:resource:hl7:LaboratoryOrder. Indien dit de opgevraagde resource is, zijn er twee Rules, waarvan de resultaten worden gecombineerd via permit-overrides. Als de eerste dus een Permit oplevert, wordt de tweede niet gecontroleerd. De eerste Rule kijkt na of het subject de behandelende arts is van de patiënt. Indien dit het geval is, zal de dokter alle acties (bijvoorbeeld creeër, delete, update, lees, etc) mogen uitvoeren op de resource. In het andere geval wordt de tweede Rule bekeken. Deze geeft altijd een Deny terug. Op deze wijze hebben we er dus voor gezorgd dat de resource ’LaboratoryOrder’ van een patiënt enkel toegankelijk is voor zijn behandelende arts.


92

Policy set voor de permissies van een dokter urn:eHealth:ICSP:resource:hl7:LaboratoryOrder


93

<Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <SubjectAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> Indien men hierboven geen Permit heeft gekregen, dan Deny als default.


A.2.5

94

urn:eHealth:ICSP:policysetid:CDA

Hiermee kan de volledige toegang tot een dossier worden geweigerd: Policy set voor de UBA confidentiality code. Wanneer de toegang van het subject niet is geweigerd, dan Permit <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <SubjectAttributeDesignator


95

AttributeId= "urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> Deny als default.


A.2.6

96

urn:eHealth:ICSP:policysetid:MA

Door middel van onderstaand voorbeeld kan een patiënt voorkomen dat zijn behandelende arts kan zien dat hij ook een andere dokter heeft geraadpleegd: Policy set voor de MA confidentiality code. <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> <Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <SubjectAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>


97

<Apply FunctionId= "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> Permit als default.

BIBLIOGRAFIE

98

Bibliografie [1] Uz gent, kerngetallen.

http://www.uzgent.be/wps/wcm/connect/nl/web/algemeen/

uzgent/Kerngetallen/. [2] The enterprise privacy authorization language (epal 1.1). http://www.zurich.ibm.com/ security/enterprise-privacy/epal/. [3] Anne Anderson. A comparison of two privacy policy languages: Epal and xacml. http:// research.sun.com/techrep/2005/smli_tr-2005-147/TRCompareEPALandXACML.html, 2005. [4] Lalana Kagal. Rei ontology specifications. http://www.csee.umbc.edu/~lkagal1/rei/. [5] OASIS. Security services (saml) tc. http://www.oasis-open.org/committees/download. php/22553/sstc-saml-tech-overview-2.0-draft-13.pdf, 2007. [6] W3C Recommendation. Xml signature syntax and processing (second edition). http: //www.w3.org/TR/xmldsig-core/, 2008. [7] Organization for the advancement of structured information standards.

http://www.

oasis-open.org/home/index.php. [8] OASIS. extensible access control markup language (xacml) tc. http://www.oasis-open. org/committees/tc_home.php?wg_abbrev=xacml. [9] OASIS.

A brief introduction to xacml.

http://www.oasis-open.org/committees/

download.php/2713/Brief_Introduction_to_XACML.html, 2006. [10] XACML 2.0. extensible access control markup language (xacml) version 2.0. http://docs. oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf, 2005.

BIBLIOGRAFIE

99

[11] Seth Proctor. Programmer’s guide for version 1.2. http://sunxacml.sourceforge.net/ guide.html, 2004. [12] OASIS.

Core

xacml v2.0.

and

hierarchical

role

based

access

control

(rbac)

profile

of

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.

0-rbac-profile1-spec-os.pdf, 2005. [13] OASIS. Hierarchical resource profile of xacml v2. http://docs.oasis-open.org/xacml/ 2.0/access_control-xacml-2.0-hier-profile-spec-os.pdf, 2005. [14] OASIS. Multiple resource profile of xacml v2.0. http://docs.oasis-open.org/xacml/2. 0/access_control-xacml-2.0-mult-profile-spec-os.pdf, 2005. [15] OASIS. Privacy policy profile of xacml v2.0. http://docs.oasis-open.org/xacml/2.0/ access_control-xacml-2.0-privacy_profile-spec-os.pdf, 2005. [16] OASIS.

Saml 2.0 profile of xacml v2.0.

http://docs.oasis-open.org/xacml/2.0/

access_control-xacml-2.0-saml-profile-spec-os.pdf, 2005. [17] OASIS. Xml digital signature profile of xacml v2.0. http://docs.oasis-open.org/xacml/ 2.0/access_control-xacml-2.0-dsig-profile-spec-os.pdf, 2005. [18] OASIS.

Xacml core version 2.0 errata.

http://www.oasis-open.org/committees/

download.php/26986/access_control-xacml-2.0-core-spec-os-errata.doc., 2008. [19] OASIS.

Saml 2.0 profile of xacml, version 2, wd 5.

http://www.oasis-open.org/

committees/download.php/24681/xacml-profile-saml2.0-v2-spec-wd-5-en.pdf, 2007. [20] OASIS. Changes since xacml 1.0. http://www.oasis-open.org/committees/download. php/12821/xacml_1.x_2.0_diffs_draft.doc, 2005. [21] OASIS. extensible access control markup language (xacml) version 1.0. http://www. oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf, 2003. [22] OASIS. extensible access control markup language (xacml) version 1.1. http://docs. oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf, 2003. [23] ANSI INCITS. Nist, role based access control. http://csrc.nist.gov/rbac/, 2004.

BIBLIOGRAFIE

100

[24] OASIS. Xacml profile for role based access control (rbac) committee draft 01. http: //docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf, 2004. [25] OASIS. extensible access control markup language (xacml) version 3.0 committee draft 1. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cd-1-en.pdf, 2009. [26] OASIS. king

Xacml

draft

19.

v3.0

administration

and

delegation

profile

version

1

wor-

http://www.oasis-open.org/committees/download.php/32060/

XACML-drafts-14-April-2009.zip, 2007. [27] OASIS.

Cross-enterprise security and privacy authorization (xspa) profile of xacml

v2.0 for healthcare version 1.0. http://www.oasis-open.org/xacml/xspa/v1.0/xspa-1. 0-pr01pr02.pdf, 2009. [28] OASIS.

Web services profile of xacml (ws-xacml) version 1.0 working draft

10.

http://www.oasis-open.org/committees/download.php/24951/xacml-3.

0-profile-webservices-spec-v1-wd-10-en.pdf, 2007. [29] OASIS. Xacml pdp metadata version 1.0 working draft 1. http://www.oasis-open.org/ committees/download.php/27316/xacml-3.0-metadata-v1-wd-01.zip, 2008. [30] OASIS.

Xacml

v3.0

export

compliance-

us

(ec-us)

profile

version

1.0.

http://www.oasis-open.org/committees/download.php/32131/xacml-3. 0-ec-us-v1-spec-wd-01-en.doc, 2009. [31] Sun Microsystems. Sun’s xacml implementation. http://sunxacml.sourceforge.net. [32] Swedish Institute of Computer Science. Sicsacml. http://www.sics.se/spot/xacml_3_ 0.html. [33] ppzian. Enterprise java xacml implementation. http://mvpos.sourceforge.net/. [34] Oleg Gryb. Xacmlight apache axis2 web service xacml 2.0 pdp/pap implementation. http: //sourceforge.net/projects/xacmllight/. [35] Lagash Systems. Xacml.net. http://code.google.com/p/enterprise-java-xacml/. [36] Tao Xie Nuo Li, JeeHyun Hwang. Multiple-implementation testing for xacml implementations, 2008.

BIBLIOGRAFIE

101

[37] University of Applied Science Rapperswil. Holistic enterprise-ready application security architecture framework. http://www.herasaf.org. [38] D.R. Kuhn D.F. Ferraiolo. Role based acces control. http://csrc.nist.gov/groups/SNS/ rbac/documents/ferraiolo-kuhn-92.pdf, 1992. [39] R.S. Sandhu. Role-based access control models. http://csrc.nist.gov/rbac/sandhu96. pdf, 1996. [40] R. Kuhn R. Sandhu, D. Farraiolo. The nist model for role-based access control: Towards a unified standard. http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00/pdf, 2000. [41] INCITS. International committee for information technology standards. http://www. incits.org/. [42] ANSI. American national standards institute. http://www.ansi.org/. [43] OASIS. Xacml 2.0 scenarios version 0.12. http://www.oasis-open.org/committees/ download.php/24475/xacml-2.0-core-interop-draft-12-04.doc, 2007. [44] OASIS. Xacml 2.0 rsa 2008 interop scenarios version 0.12. http://docs.oasis-open.org/ xacml/xacml-2.0-core-interop-draft-12-04.doc, 2008. [45] HITSP. Healthcare information technology standards panel. http://www.hitsp.org. [46] HL7. Health level 7. http://www.hl7.org. [47] HL7 Security Technical Committee. Hl7 version 3 standard: Role-based access control healthcare permission catalog. http://www.hl7.org/library/standards.cfm, 2008. [48] OECD. Organisation for economic co-operation and development. http://www.oecd.org. [49] OECD.

Guidelines on the protection of privacy and transborder flows of personal

data. http://www.oecd.org/document/18/0,3343,en_2649_34255_1815186_1_1_1_1, 00.html, 1980. [50] The Apache Software Foundation. Apache synapse enterprise service bus (esb). http: //synapse.apache.org/. [51] Bruno Crispo Fatih Turkmen. Performance evaluation of xacml pdp implementations, 2008.

BIBLIOGRAFIE

102

[52] Netscape. The ssl protocol version 3.0. http://www.mozilla.org/projects/security/ pki/nss/ssl/draft302.txt, 1996. [53] IETF. Rfc: 2246: The transport layer security (tls) protocol version 1.0. http://tools. ietf.org/html/rfc2246, 1999. [54] IETF. Rfc: 5246: The transport layer security (tls) protocol version 1.2. http://tools. ietf.org/html/rfc5246, 2008. [55] OASIS. Ws-security core specification 1.1. http://www.oasis-open.org/committees/ download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, 2006. [56] W3C. Xml encryption syntax and processing. http://www.w3.org/TR/xmlenc-core/, 2002. [57] OASIS.

Ws-secureconversation

1.4.

http://docs.oasis-open.org/ws-sx/

ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf, 2009. [58] OASIS.

Ws-trust 1.4.

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/

ws-trust-1.4-spec-os.pdf, 2009. [59] The Open Group. Single sign-on. http://www.opengroup.org/security/sso/. [60] OASIS. Security services (saml) tc. http://www.oasis-open.org/committees/tc_home. php?wg_abbrev=security. [61] W3C. Web services policy 1.5 - framework. http://www.w3.org/TR/ws-policy/, 2007. [62] W3C. Web services policy 1.5 - attachment. http://www.w3.org/TR/ws-policy-attach/, 2007. [63] W. Haerick S. Van Hoecke. Desing and implementation of a secure media content delivery broker architecture. http://www.ibcn.intec.ugent.be/papers/2323.pdf, 2005. [64] W. Haerick S. Van Hoecke.

Secure brokering of web services.

http://www.

ist-ipmedianet.org/GHN_Secure_Brokering_of_Web_Services-3.pdf, 2005. [65] GlassFish community. Metro. https://metro.dev.java.net/.

LIJST VAN FIGUREN

103

Lijst van figuren 1.1

ICSP nu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

ICSP met rolgebaseerde toeganscontrole . . . . . . . . . . . . . . . . . . . . . . .

3

2.1

Eenvoudig XACML model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

XACML model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Het policy language model cfr. OASIS [10] . . . . . . . . . . . . . . . . . . . . . .

10

3.1

UML diagram voor het ondersteunen van referenties . . . . . . . . . . . . . . . .

24

3.2

Stroomdiagram XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.3

Invloed van het aantal rollen op de totale initialisatietijd . . . . . . . . . . . . . .

26

3.4

Invloed van het aantal referenties op de totale initialisatietijd . . . . . . . . . . .

27

3.5

Mogelijke plaatsen voor toeganscontrole . . . . . . . . . . . . . . . . . . . . . . .

30

3.6

Toeganscontrole in de Web Method zelf . . . . . . . . . . . . . . . . . . . . . . .

30

3.7

Toeganscontrole in handler chain . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.8

Toeganscontrole in broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.9

Resultaten van de load test op de drie scenario’s . . . . . . . . . . . . . . . . . .

36

4.1

Architectuurvoorstel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.2

RBAC uitgebreid voor ondersteuning van HL7 permissies . . . . . . . . . . . . .

41

4.3

Toeganscontrole bij noodgeval . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.4

Toeganscontrole bij gebruik van metadata . . . . . . . . . . . . . . . . . . . . . .

46

4.5

Toeganscontrole met privacy

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

4.6

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

5.1

TLS stroomdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.2

Gebruik van een STS in WS-Trust . . . . . . . . . . . . . . . . . . . . . . . . . .

62

LIJST VAN FIGUREN

104

5.3

WS-XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.1

Architectuurvoorstel met TLS als externe beveiliging . . . . . . . . . . . . . . . .

69

6.2

Architectuurvoorstel met WSS als externe beveiliging . . . . . . . . . . . . . . .

70

LIJST VAN TABELLEN

105

Lijst van tabellen 3.1

Setup tijden van PDP onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.2

Initialisatietijd PDP bij 10 rollen . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.3

Evaluatietijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.4

RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.5

RTT proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.1

RTT architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

5.1

Security requirements ICSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.1

Eigenschappen van TLS en WSS . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.2

Beveiliging via TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

6.3

Beveiliging via WSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.4

RTT bij externe beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

in het Intensieve Zorgen platform

Recommend Documents