in het Intensieve Zorgen platform

Transcriptie

1 Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Inwendige ziekten Voorzitter: prof. dr. Martine De Vos Efficiënt 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

2

3 Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Vakgroep Inwendige ziekten Voorzitter: prof. dr. Martine De Vos Efficiënt 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

4 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

5 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

6 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

7 Efficiënt 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 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

8 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. INTRODUCTION THE 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. A. XACML II. AUTHORISATION 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 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 particular 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. RTT(ms) Standard deviation handler class 38,55 7,24 class meditor 23,99 9,16 TABLE I RTT FOR A WEB SERVICE CALL WITH AUTHORISATION A. Authentication III. SECURITY 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

9 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 WSS end-to-end security x point-to-point security x transport layer security x message layer security x encryption x x partial encryption x digital signature x TABLE II TLS VERSUS WSS 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. 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 WS- SecureConversation IV. CONCLUSION 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. REFERENCES [1] OASIS, extensible Access Control Markup Language (XACML) Version 2.0, control-xacml-2.0-corespec-os.pdf [2] ANSI INCITS, NIST, Role Based Access Control, [3] OASIS WS-Trust 1.4, [4] IETF, RFC: 5246: The Transport Layer Security (TLS) Protocol Version 1.2, [5] OASIS WS-Security Core Specification 1.1, open.org/committees/download.php/16790/wss-v1.1-spec-os- SOAPMessageSecurity.pdf [6] OASIS WS-SecureConversation 1.4, Fig. 1. Detailed architecture which provides authorisation through XACML in a broker, authentication by a STS and encryption through TLS

10 INHOUDSOPGAVE v Inhoudsopgave Voorwoord Toelating tot bruikleen Overzicht Inhoudsopgave Gebruikte afkortingen i iii iv v viii 1 Inleiding 1 2 Technologiestudie XACML en RBAC extensible Access Control Markup Language Waarom XACML? Algemeen Werking XACML Huidige standaard Bestaande open source implementaties van XACML Role-Based Access Control Algemeen Standaard Core and hierarchical RBAC profile of XACML v e-health Rollen Noodgeval Metadata

11 INHOUDSOPGAVE vi Privacy Testen XACML Testbed Sun s XACML Implementation Ondersteuning referenties Prestatietesten Sun s XACML Implementation Conclusie Drie mogelijke oplossingen Case Case Case Functionele testen Load testen Voor- en nadelen van de verschillende locaties Conclusie Architectuur design Architectuurvoorstel Policy repository voor zorgomgeving Rollen Noodgeval Metadata Privacy Implementatie Model RTT Technologiestudie externe beveiliging Transport Layer Security WS-Security WS-Trust WS-SecureConversation Single Sign-On

12 INHOUDSOPGAVE vii Security Assertion Markup Language WS-Policy WS-XACML Beveiliging ICSP Architectuur met externe beveiliging TLS vs WSS Uitbreiding architectuur met externe beveiliging Via TLS Via WSS Implementatie Metro RTT Conclusie Conclussie Toekomstig werk A Broncode 76 A.1 Voorbeelden bij hoofdstuk A.1.1 Voorbeeld van PolicySet A.1.2 Voorbeeld van RPS en bijhorende PPS A.1.3 Voorbeeld van HasPrivilegesOfRole Policy en bijhorende XACML request 81 A.1.4 Voorbeeld van Role Assignment Policy A.2 Voorbeelden bij hoofdstuk A.2.1 urn:ehealth:icsp:policysetid:n A.2.2 urn:ehealth:icsp:policysetid:n:permcollections A.2.3 urn:ehealth:icsp:policysetid:n:rps:physician-vrole A.2.4 urn:ehealth:icsp:policysetid:n:pps:physician A.2.5 urn:ehealth:icsp:policysetid:cda A.2.6 urn:ehealth:icsp:policysetid:ma

13 GEBRUIKTE AFKORTINGEN viii 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

14 GEBRUIKTE AFKORTINGEN ix SICS SOAP SSL SSO STS TC TLS UBA UDDI WSDL WSS XACML XKMS Swedish Institute of Computer Science Simple Object Access Protocol Secure Sockets Layer Single Sign-On Security Token Service Technical Committee Trasport Layer Security User based access Universal Description Discovery and Integration Web Services Description Language Web Service Security extensible Access Control Markup Language XML Key Management Specification

15 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

16 INLEIDING 2 Figuur 1.1: ICSP nu men er nog rekening mee houdt dat er jaarlijks meer dan 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.

17 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.

18 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 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.

19 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] 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 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.

20 2.1 extensible Access Control Markup Language 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 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.

21 2.1 extensible Access Control Markup Language 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). <Request> <Subject SubjectCategory= "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType=" <AttributeValue>physician</AttributeValue> </Attribute> </Subject> <Resource>

22 2.1 extensible Access Control Markup Language 8 <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType=" <AttributeValue> file://example/med/record/patient/bartsimpson </AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType=" <AttributeValue>read</AttributeValue> </Attribute> </Action> </Request> 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. <Response> <Result ResourceID="file://example/med/record/patient/BartSimpson"> <Decision>Permit</Decision> <Status>

23 2.1 extensible Access Control Markup Language 9 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> </Status> </Result> </Response> 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. Policy of PolicySet root XML tag. Elk XACML policy document bevat exact één 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

24 2.1 extensible Access Control Markup Language 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]

25 2.1 extensible Access Control Markup Language 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 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 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.

26 2.1 extensible Access Control Markup Language 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.

27 2.1 extensible Access Control Markup Language 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 zichzelf 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 uitdrukken 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 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 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

28 2.1 extensible Access Control Markup Language 14 omtrent deze bèta en de laatste update van de source code dateert van november 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 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

29 2.1 extensible Access Control Markup Language 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

30 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. XACML 2.0 besproken. Tot slot wordt het RBAC profile of 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 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])

31 2.2 Role-Based Access Control 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 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

32 2.2 Role-Based Access Control 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.

33 2.3 e-health 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üniformiseerde 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 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 wordt er een oplossing aangeboden in de vorm van een uitbreiding van het RBAC Profile voor de ondersteuning van HL7 permissies.