Automatisch inloggen via RFID en rolgebaseerde activatie van medische services Bartel Braeckman
Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke Begeleiders: ir. Wannes Kerckhove, ir. Thomas Dupont Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010
Automatisch inloggen via RFID en rolgebaseerde activatie van medische services Bartel Braeckman
Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke Begeleiders: ir. Wannes Kerckhove, ir. Thomas Dupont Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010
Voorwoord Met het schrijven van deze eerste woorden van dit boek wordt merkwaardig genoeg ook meteen een punt gezet achter al het werk dat in deze masterproef gegaan is. Het is een lang, maar leerrijk jaar geweest. Een jaar waarin ik veel meer geleerd heb dan wat ik in dit boek heb geschreven: wijsheid die niet te verkrijgen is door het volgen van enkele lessen en het afleggen van een examen. Het is een zoektocht geweest naar informatie, inspiratie en motivatie. Het is een tocht geweest waarbij zoveel aspecten van het ontwikkelen van software aan bod zijn gekomen. Teamwerk. Solowerk. Technologiestudies. Implementaties. Te veel om op te noemen. Hoewel op het titelblad staat “auteur ” en niet “auteurs” en het enkel mijn naam is die onder dit voorwoord staat, zijn er toch een heleboel mensen betrokken bij het tot stand komen van dit boek. Ik grijp dan ook de kans om die hier te bedanken. Eerst en vooral wil ik mijn promotor bedanken, prof. dr. ir. F. De Turck, die het mogelijk heeft gemaakt dit onderwerp te nemen voor mijn masterproef. Daarnaast wil ik ook mijn co-promotor/begeleidster Sofie bedanken, zowel voor het enthousiasme waarmee het onderwerp mij aangeboden werd als voor de vele informatie en hints die ik doorheen dit jaar van haar gekregen heb. In ´e´en adem wil ik ook mijn andere begeleiders Thomas en Wannes bedanken, die er weliswaar pas later zijn bijgekomen, maar die zeker even veel geholpen hebben. Hun recente ervaringen hebben zeker ook bijgedragen tot de kwaliteit van dit werk. Bovendien wil ik ze extra bedanken voor het nalezen van dit werk en de vele suggesties die op die manier nog bij mij zijn terecht gekomen. Verder zijn er een aantal mensen die niet inhoudelijk hebben bijgedragen tot deze masterproef, maar zonder wie dit voorwoord nooit zou geschreven zijn. Zo zijn er mijn ouders, die mij de kans hebben gegeven deze opleiding te volgen en de nodige kwaliteiten hebben meegegeven om deze ook af te maken.
Natuurlijk wil ik ook mijn vriendin bedanken, die er altijd stond om mij, als dat nodig was, terug aan het werk te zetten. Ze zorgde ook voor de nodige afleiding en was mijn klankbord -willens nillens- als ik niet meer wist hoe verder te gaan met mijn werk. Het was zeker niet altijd even gemakkelijk mij als vriend te hebben dit jaar, maar samen zijn we alvast met brio geslaagd! Bovendien wil ik haar bedanken voor het nalezen en verbeteren van dit boek. Ten slotte zijn er nog een aantal mensen die ik zonder ze elk apart te benoemen wil bedanken. Mensen die mij doorheen dit en vele voorgaande jaren hebben gesteund, aangemoedigd, afgeleid en gevormd. Bedankt voor alles.
Bartel Braeckman, mei 2010
Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren 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.”
Bartel Braeckman, mei 2010
Automatisch inloggen via RFID en rolgebaseerde activatie van medische services door Bartel BRAECKMAN Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2009–2010 Promotors: prof. dr. ir. F. DE TURCK, dr. ir. S. VAN HOECKE Begeleiders: ir. W. KERCKHOVE, ir. T. DUPONT Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. D. DE ZUTTER
Samenvatting Op de dienst Intensieve Zorgen (IZ) van het UZ te Gent wordt momenteel het ICSP ge¨evalueerd. Dit platform heeft een service geori¨enteerde architectuur en biedt allerhande medische services aan die het verzorgend personeel kunnen helpen met hun taak. Om de gebruiksvriendelijkheid te verhogen, is er echter nood aan een systeem dat het inloggen automatiseert en de gebruikersinterface vereenvoudigt. Het uitwerken van dergelijke oplossing is het onderwerp van deze masterproef. Het automatiseren van de inlogprocedure wordt gedaan door gebruik te maken van RFID. Deze technologie maakt het mogelijk naderende gebruikers te herkennen door middel van een RFID tag die door elk personeelslid zal gedragen worden. Nadat een potenti¨ele gebruiker ge¨ıdentificeerd en geauthenticeerd is, kan die dan ingelogd worden. Na het inloggen worden op basis van de rol, niet de identiteit, van de gebruiker (RBAC) de gewenste services geactiveerd. Nagaan welke services dat zijn, wordt gedaan met XACML. Met XACML is het mogelijk toegansrechten toe te kennen aan rollen en deze op een effici¨ente manier te beheren.
Trefwoorden Intensive Care Service Platform (ICSP), Radio Frequency IDentification (RFID), Role Based Access Control (RBAC), eXtensible Access Control Markup Language (XACML), OSGi
Automated login procedure via RFID and role-based activation of medical services Bartel Braeckman Supervisor(s): prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke, ir. Wannes Kerckhove, ir. Thomas Dupont Abstract— This article gives more insight in the use of role-based access control (RBAC) in a medical environment: the Intensive Care Service Platform (ICSP). The system here proposed is accessible via a RFID login mechanism. Once a user is authenticated, several medical services are activated. The selection of these services is done via RBAC, which is achieved through the use of eXtensible Access Control Markup Language (XACML). The ICSP itself is an OSGi based platform and thus offers dynamic services. This means that the presence of the desired services can’t be guaranteed. Keywords— Intensive Care Service Platform (ICSP), Radio Frequency IDentification (RFID), Role-Based Access Control (RBAC), eXtensible Access Control Markup Language (XACML), OSGi
I. I NTRODUCTION HE intensive care service platform (ICSP) [1] is a service oriented software platform that is currently being evaluated in the Intensive Care Unit (ICU) of UZ Gent [2]. The platform helps the medical staff by providing a system that analyses most of the data generated by each of the patients. Each service has its own purpose, e.g. some services give advice concerning the antibiotics dose, others monitor the hart rate or analyse the kidney functions. The solution presented in this article discusses two aspects of the ICSP. First, there is the login procedure which will be automated by using RFID. This enhancement must be extremely user friendly, since the purpose is to make life easier for the staff, not to make it more complicated. Secondly, services to be shown must be chosen based on the role of the current user. That way, the user interface will be much more transparant (see figure 1).
T
Fig. 1. Chaos in the current system
II. S OLUTION The first part of this section gives an overview of the used technologies and a brief description for each. The second part focuses on how these concepts can be used to build the desired solution. A. Different technologies RFID is a technology that enables the exchange of data between a reader and a tag by using radiowaves [3]. The reader creates a magnetic field with a certain range. If a tag enters such
a field, it is able to send the data it contains to the reader. The RFID technology has many extensions, each with its own pros and cons. RBAC describes the advantages of controlling access based on the role of a person instead of the identity [6]. For one, if a new person needs some access rights, there’s no need to define all the permissions individually: assigning a role to that person is sufficient. XACML is a tool for managing the different rights for a role. Such a collection of permissions is called a policy. With XACML it is possible to retrieve if a subject (in this case a role) can carry out an action on a stipulated resource (the medical services in this context) [4]. OSGi is a java based, service oriented architecture [?]. Services are found and bound to a platform dynamically without the need of restarting the whole system. A disadvantage of this is that there is no information about the presence of the desired services, at the time the system is developed. So, an OSGi based system has to react in a proper way to the possible state changes of the services platform. B. Putting it all together It is obvious that the RFID will be used for automating the login procedure. The use of this technology enables fully automated login: no action at all has to be taken by a user to enter the system. This is, if a reader with a sufficient range is used. In that way each tag can be attached to the badge of the staff. When a user comes within the range of a reader, the system will ask for the data on the tag. If, based on that data, it appears to be a valid user, the user will automatically log in. Once the user is authenticated, a procedure is needed to determine which medical services must be activated. The services to which a user has access to, are described in a policy. Such a policy exist for each defined role. As described before, the user himself/herself has no access rights. It is the role that is assigned to the user which defines the permissions of the user. This is the core principle of RBAC. For each role there are two policies to be generated: one describes the role itself and the other sums the services up to which access is granted. These policies are used by XACML to evaluate a request (may the subject carry out the action to the given resource?). The ICSP itself is, as stated before, an OSGi based platform. So it can’t be guaranteed that the medical services provided in the ICSP, are actually ready for use. This means that with every attempt to login, a consultation of the environment is needed to determine which services are present. Once a list with these services is created, an XACML request for each element in that
list has to be generated and evaluated. Next, the response to each of these requests can be used to determine if the service, which was the subject of the request, must be activated for the new user. C. Architecture Interaction with a RFID reader is only achieved by polling the reader. This means that the ICSP is charged with a procedure that is polling the reader at a certain frequency (e.g. every one or two seconds). The polling process has a great influence on the performance of the system. To prevent that the response time of the ICSP becomes too high for practical use, the mechanism that polls the reader, is relocated to the reader (see figure 2). That way, the reader becomes a pushing device: only when new tags are detected, the ICSP is informed.
cies which can be loaded into the core of the XACML implementation. This means that the generation of the policies needs to be done by a person with sufficient knowledge. The PolicyBuilder presented in this solution offers a mechanism that can be used via a simple GUI. In this way, the policies can be managed by e.g. the administration department. B. RBACPolicyFinderModule Because known implementations only support the XACML 1.1 version and RBAC is introduced in the XACML 2.0 specification [5], it was necessary to foresee some extensions so RBAC can be used. The major change is the extension of the PolicyFinderModule. This module is used by XACML to manage all the policies. XACML 2.0 states that the description of the different roles and the list with their permissions are linked via references. These references are not supported in the known XACML implementations. IV. F UTURE W ORK
Fig. 2. Top view architecture
The platform itself is extended with a small number of bundles, most of which are needed for the purpose of a proof-ofconcept. The one bundle that embraces all the details for the new login procedure is called Cosara (see figure 3).
Before bringing this solution into practice, it can be useful to investigate some other approaches besides RFID. The use of RFID certainly has many advantages and is challenging to use for a software engineer. However, the investment that is needed for the purchase of sufficient readers can be an insuperable obstruction. If no other implementation of XACML is built in the future, it can be useful to foresee a custom built implementation. That way, the implementation can be adjusted to some specific requirements of the environment it is used in. Finally, it is necessary to give the GUI a significant upgrade, so it is possible for the users to use the functions provided by the PolicyBuilder and give the solution its full glory. V. C ONCLUSIONS
Fig. 3. Architecture of the Cosara bundle
As shown in figure 3 the Core component is responsible for the graphical user interface (GUI). The Users component communicates with the RFID reader. When new tags are detected, a connection with the database is established so authentication is possible. Optionally, this part decides who becomes the new user and holds a list with alternative users. The third component is called RBAC and provides the necessary functions to determine which services are to be activated. It is this component that contains the XACML implementation. III. I MPLEMENTATION
It must be clear for the reader that the subject of this abstract offers a lot of opportunities, both for the ICU environment and for a software developer. However it is clear that the described solution satisfies all conditions: users will be logged in automatically and the user interface is adjusted to the role of the user. Moreover, it appears to be sufficiently scalable to be used in practice, both now and in the future. R EFERENCES [1]
[2] [3] [4]
The implementation of the proposed solution has some important features. Two of them are described below.
[5]
A. PolicyBuilder
[6]
The PolicyBuilder offers the opportunity to automatically generate the XACML files, needed for a correct evaluation. Existing XACML implementations usually demand plain text poli-
[7]
S. Van Hoecke , J. Decruyenaere, C. Danneels, K. Taveirne, K. Colpaert, E. Hoste, B. Dhoedt, F. De Turck, Service-oriented subscription management of medical decision data in the Intensive Care Unit, Methods of Information in Medicine, 2008, 47/4 pp. 364-380. Universitair Ziekenhuis Gent Intensieve Zorg http://www.icu.be R. Want RFID Explained: A Primer On Radio Frequency Identification Technologies Morgan & Claypool (2006); ISBN-10: 1598291092 OASIS A brief introduction to XACML http://www.oasisopen.org/committees/download.php/2713/Brief Introduction to XACML.html (2003) A. Anderson Core and hierarchical role based access control (RBAC) profile of XACML v2.0 http://docs.oasis-open.org/xacml/2.0/accessc ontrol− xacml − 2.0 − rbac − prof ile1 − spec − os.pdf (2005) D.F. Ferraiolo, D.R. Kuhn Role-Based Access Controls 15th National Computer Security Conference (1992), Baltimore MD pg 554-563 OSGi Alliance The OSGi Architecture http://www.osgi.org/About/WhatIsOSGi
INHOUDSOPGAVE
x
Inhoudsopgave 1 Inleiding
1
1.1
Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Use Case
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Overzicht boek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Specificatie
5
2.1
Functionele analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Kwalitatieve vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Aanpasbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.3
Gebruiksvriendelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.4
Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.5
Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3 Technologie 3.1
3.2
9
RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.1
Radio Frequency IDentification . . . . . . . . . . . . . . . . . . . . . .
9
3.1.2
Een RFID systeem kiezen . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.3
RFID emulatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.1
eXtensible Access Control Markup Language . . . . . . . . . . . . . .
14
3.2.2
XACML Profile for RBAC
17
. . . . . . . . . . . . . . . . . . . . . . . .
INHOUDSOPGAVE
3.3
xi
OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.2
Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.3
Implementaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4 Architectuur 4.1
Top view
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
RFID Abstractie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Het ICSP platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.1
Cosara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.2
ABDose, AB7/14, ABSwitch IV/PO . . . . . . . . . . . . . . . . . . .
30
4.2.3
DB, API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Interactie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.3.1
Systeemstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.3.2
Nieuwe gebruiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.1.1 4.2
4.3
24
5 Implementatie 5.1
5.2
5.3
Gebruik van RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.1.1
Passief inloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.1.2
Passief uitloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
RBAC met XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.2.1
Standaardgebruik XACML . . . . . . . . . . . . . . . . . . . . . . . .
40
5.2.2
Verantwoordelijkheden RBAC . . . . . . . . . . . . . . . . . . . . . . .
46
Werken in een OSGi omgeving . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3.1
Beschikbaarheid van services . . . . . . . . . . . . . . . . . . . . . . .
48
5.3.2
Communicatie met de RFID lezer . . . . . . . . . . . . . . . . . . . .
48
6 Evaluatie 6.1
35
50
Functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.1.1
RFID abstractie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.1.2
Cosara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
INHOUDSOPGAVE
6.2
6.3
6.4
xii
Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.2.1
Dienst IZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.2.2
Testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Automatisch inloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.3.1
Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Rolgebaseerde activatie van services . . . . . . . . . . . . . . . . . . . . . . .
54
6.4.1
Initialisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.4.2
Effectief gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.4.3
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
7 Conclusie en verder onderzoek
63
7.1
Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
7.2
Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Bibliografie
66
INHOUDSOPGAVE
Gebruikte afkortingen µW
Microgolf
AB
Antibiotica
ASF
Apache Software Foundation
CDC
Connected Device Configuration
CLDC
Connected Limited Device Configuration
EMI
Elektromagnetische Interferentie
FIFO
First In, First Out
GUI
Graphical User Interface
HF
Hoge Frequentie
ICSP
Intensive Care Sercive Platform
IV
Intraveneus
IZ
Intensieve Zorgen
J2SE
Java 2 Platform, Standard Edition
LF
Lage Frequentie
LIFO
Last In, First Out
MVC
Model-View-Controller
OASIS
Organization for the Advancement of Structured Information Standards
OSGi
letterwoord (vroeger: Open Services Gateway initiative)
PAP
Policy Administration Point
PDP
Policy Decision Point
PEP
Policy Enforcement Point
PIP
Policy Information Point
PO
Peroraal
PPS
Permission PolicySet
xiii
INHOUDSOPGAVE
RAP
Role Assignment Policy (of PolicySet)
RBAC
Role Based Access Control
RFID
Radio Frequency IDentification
RPS
Role PolicySet
SAML
Security Assertion Markup Language
TCP
Transmission Control Protocol
UHF
Ultra Hoge Frequentie
XACML
eXtensible Access Control Markup Language
XML
eXtensible Markup Language
XSPA
Cross-Enterprise Security and Privacy Authorization
xiv
1
Hoofdstuk 1
Inleiding In dit inleidende hoofdstuk wordt eerst de huidige situatie beschreven. Daarna volgt een korte toelichting van de oplossing die in dit boek wordt voorgesteld. Ten slotte wordt het hoofdstuk afgesloten met een overzicht van het vervolg van deze masterproef.
1.1
Probleemstelling
Binnen de vakgroep informatietechnologie is, in samenwerking met de dienst Intensieve Zorgen (IZ) van het UZ Gent, een architectuur ontworpen voor automatische medische diagnose van de pati¨enten, genaamd het Intensive Care Service Platform (ICSP). Dit platform integreert alle actoren binnen het medisch diagnose proces zoals labo’s, monitoren, artsen en verpleegkundigen. Aangezien de architectuur bestaat uit meerdere web service componenten, die functionaliteit (database toegang, inschrijving, communicatie) scheiden, is de architectuur eenvoudig uitbreidbaar. Een platform prototype is al ge¨ımplementeerd en wordt momenteel door de dienst IZ ge¨evalueerd.
Het platform is momenteel wel beschermd met een wachtwoordsysteem, maar na het aanmelden krijgt elke gebruiker dezelfde interface te zien. Dit brengt meteen twee belangrijke minpunten met zich mee. Ten eerste is er het aspect van de privacy: het kan en mag niet de bedoeling zijn dat eender welke gebruiker alle medische gegevens van een pati¨ent kan inkijken of in sommige gevallen zelfs de behandeling kan bijsturen. Het tweede punt betreft de gebruikersinterface: doordat telkens alle services worden weergegeven is er sprake van een
1.2. OPLOSSING
2
onoverzichtelijke werkomgeving (zie figuur 1.1).
1.2
Oplossing
Een eerste stap bij het verbeteren van de situatie is een inlogprocedure met identificatie voorzien. Op die manier kan er een selectie gemaakt worden in de services die getoond worden op basis van het profiel van de gebruiker. Zo worden meteen beide problemen opgelost.
De keuze van de weer te geven services kan dan gebeuren door aan elke gebruiker een rol toe te kennen. Op basis van die rol wordt dan beslist welke services al dan niet getoond moeten worden. Bovendien kunnen specifiek voor elke rol belangerijke services op de voorgrond geplaatst worden en minder belangerijke op de achtergrond (zie figuur 1.1).
Figuur 1.1: Chaos in het huidige systeem
Omdat een dergelijke oplossing op verschillende manieren ge¨ımplementeerd kan worden, zijn er op voorhand al een aantal keuzes gemaakt.
Het aanmelden gebeurt door middel van Radio Frequency Identification (RFID). Met deze technologie is het mogelijk automatisch aanmelden te voorzien en kan het gebruiksgemak verbeterd worden. RFID kan op verschillende manieren gebruikt worden: in deze masterproef worden de mogelijkheden onderzocht van het gebruik van een RFID lezer met een relatief groot bereik. Een medestudent onderzoekt de voor- en nadelen van een RFID systeem met een klein bereik in de masterproef Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken [29].
1.3. USE CASE
Bepalen welke services getoond moeten worden gebeurt aan de hand van eXtensible Access Control Markup Language (XACML) in combinatie met Role Base Access Control (RBAC).
1.3
Use Case
Om het ontwikkelde systeem te kunnen toetsen met de praktijk wordt hierna een use case voorgesteld. Deze use case bevat een aantal elementen waarmee het systeem voldoende getest kan worden om te bepalen of het voldoet als oplossing voor het gestelde probleem.
In de use case wordt gebruik gemaakt van drie actoren: een hoofdarts, een arts en een verpleegkundige. Deze actoren zijn rollen die aan eender welke gebruiker van het systeem kan toegewezen worden. De rollen zijn hi¨erarchisch gestructureerd waarbij logischerwijs de arts boven de verpleegkundige staat en de hoofdarts nog eens boven die twee. Verder zijn er drie services die elk door ´e´en rol gebruikt kunnen worden. Alle services hebben betrekking op het gebruik van antibiotica (AB) en hoe er spaarzaam mee kan omgegaan worden. De verpleegkundige heeft het recht de AB Dose service te gebruiken. Deze service geeft advies over wanneer de dosis toegediende antibiotica gewijzigd moet worden. Dit advies wordt gegeven op basis van aantal metrieken die gedurende een bepaalde periode bijgehouden worden en waarvan de trend bestudeerd wordt. De service AB 7/14 wordt toegewezen aan de artsen. AB 7/14 controleert hoe lang een pati¨ent dezelfde antibiotica toegediend krijgt en adviseert de arts indien een wijziging gewenst is. Door het tijdig wijzigen van de antibiotica wordt resistentie tegen een bepaalde antibiotica tegengegaan. Ten slotte is er nog een laatste service die door de hoofdarts gebruikt wordt: AB Switch IV/PO, waarbij IV staat voor intraveneus en PO voor peroraal. Het is een service die controleert of een wisseling van intraveneuze naar perorale (pilvormige) toediening van een antibiotica mogelijk is.
1.4
Overzicht boek
Het vervolg van deze masterproef is als volgt opgebouwd:
3
1.4. OVERZICHT BOEK
Hoofdstuk 2 is een overzicht van de vereisten waaraan de ge¨ımplementeerde oplossing moet voldoen. Hoofdstuk 3 beschrijft het onderzoek dat gedaan is naar de gebruikte technologie¨en. De verschillende mogelijkheden worden besproken en de gemaakte keuzes worden gemotiveerd. Hoofdstuk 4 geeft een overzicht van de architectuur van de uiteindelijke oplossing. Hoofdstuk 5 beschrijft de implementatie meer in detail. Interessante aspecten en keuzes worden hier extra toegelicht. Hoofdstuk 6 geeft een overzicht van enkele prestatiemetingen die gebeurd zijn en de daaraan gekoppelde conclusies. Hoofdstuk 7 besluit deze masterproef en biedt nog enkele mogelijkheden voor verdere uitdieping van het onderwerp.
4
5
Hoofdstuk 2
Specificatie In dit hoofdstuk wordt een overzicht gegeven van de vereiste functionaliteiten en kwaliteiten waaraan de uiteindelijke voorgestelde oplossing moet voldoen. Eerst volgt een korte beschrijving van de functionele vereisten waaraan het systeem moet voldoen. Deze vereisten volgen uit de actuele situatie die in het eerste hoofdstuk geschetst is. Vervolgens worden een aantal kwaliteitsattributen en hun raakpunten met deze masterproef besproken.
2.1
Functionele analyse
Het onderwerp van deze masterproef bestaat uit twee delen: automatisch inloggen en rolgebaseerde activatie van services.
Automatisch inloggen kan op verschillende manieren worden ingevuld. In deze masterproef wordt onderzocht of het mogelijk is inloggen te voorzien zonder tussenkomst van de gebruiker, automatisch in de puurste zin van het woord dus. Het systeem moet in staat zijn rechtmatige gebruikers te authenticeren en toegang te verlenen tot het ICSP platform.
Nadat een gebruiker is ingelogd moeten er een aantal services worden geactiveerd op basis van de rol van de gebruiker. Er is dus nood aan een mechanisme dat in staat is het profiel van een gebruiker aan te wenden om een lijst van services samen te stellen die moeten weergegeven worden.
2.2. KWALITATIEVE VEREISTEN
Figuur 2.1: Algemene kijk op het systeem
Het use case diagram in figuur 2.1 geeft duidelijk de scenario’s weer die ondersteund moeten worden. De scenario’s spreken eigenlijk voor zich: een geregistreerde gebruiker moet toegelaten worden tot het platform en de services gekoppeld aan de rol van die gebruiker moeten opgestart worden, een niet-geregistreerde gebruiker moet de toegang ontzegd worden.
2.2
Kwalitatieve vereisten
In dit deel worden een aantal kwaliteitsattributen overlopen en besproken op welke manier ze impact hebben op het systeem. De attributen die de grootste invloed zullen hebben op de ontwikkeling van de oplossing zijn beveiliging, gebruiksvriendelijkheid en aanpasbaarheid.
2.2.1
Aanpasbaarheid
De aangeboden oplossing zal deel uitmaken van een dynamisch platform. Er zullen dus veranderingen gebeuren in de omgeving waarop het systeem op gepaste wijze zal moeten reageren. Dit kan verduidelijkt worden aan de hand van volgend voorbeeld. Het ICSP platform is een OSGi omgeving, dit wil zeggen dat aangeboden services at runtime kunnen aangepast, toegevoegd of verwijderd worden. Het systeem dat ontwikkeld wordt moet dus in staat zijn op een vlotte wijze met deze veranderingen om te gaan.
6
2.2. KWALITATIEVE VEREISTEN
2.2.2
Beveiliging
E´en van de belangerijkste vereisten van de oplossing die in dit boek wordt opgebouwd, is de veiligheid. Het spreekt voor zich dat er in een ziekenhuisomgeving betrouwbare informatie wordt gebruikt, informatie die afgeschermd moet worden voor derden. Het systeem dat in dit boek ontwikkeld wordt, is net verantwoordelijk voor het toekennen van toegang tot die gegevens. De voorgestelde oplossing moet dus kunnen garanderen dat enkel rechtmatige gebruikers toegang krijgen tot het systeem. In tweede instantie moet er ter bescherming van de persoonlijke levenssfeer van de pati¨ent aangetoond worden dat gebruikers enkel toegang krijgen tot de services die de voor hen toegewezen rol beschikbaar gesteld worden.
2.2.3
Gebruiksvriendelijkheid
Omdat een verbetering van het platform geen stap achteruit mag zijn voor het personeel, is ook gebruiksvriendelijkheid een groot aandachtspunt. Inloggen moet vlot gebeuren: intu¨ıtief en eenvoudig. Aangezien er gekozen wordt voor automatisch inloggen moet er ook een duidelijke procedure voorzien worden die kan aangeroepen worden indien een andere gebruiker gewenst is. Daarnaast moet er tijdens de implementatie steeds aan gedacht worden dat het afschermen van gegevens geen negatieve gevolgen mag hebben op het werkgemak binnen de dienst. Dit laatste is in principe de verantwoordelijkheid van de instantie die de rechten van de rollen vastlegt: het ontwikkelde systeem moet enkel garanderen dat de bevoegdheden van de rollen strikt gerespecteerd wordt. Het is onmiddellijk duidelijk dat een groot deel van de gebruiksvriendelijkheid bepaald wordt door de services die voor elke rol beschikbaar gesteld worden. Het opstellen van die toegangsrechten is dus een evenwichtsoefening tussen het in stand houden van de beveiliging en de gebruiksvriendelijkheid van het platform.
2.2.4
Performantie
De gebruiker mag niet het gevoel hebben te moeten wachten vooraleer te kunnen werken met het platform. Daarom moet het inloggen en activeren van de services binnen afzienbare tijd gebeuren. Zo moet het systeem klaar zijn voor gebruik minder dan vijf seconden nadat de gebruiker binnen het bereik van de RFID lezer gekomen is.
7
2.2. KWALITATIEVE VEREISTEN
2.2.5
Schaalbaarheid
In eerste instantie is het de bedoeling het systeem te gebruiken binnen de dienst IZ. De dienst telt momenteel 56 bedden, maar dat aantal zal al snel uitgebreid worden tot 94. Het systeem dat ontwikkeld wordt, moet dus zeker al in staat zijn die uitbreiding op te vangen. Daarnaast moet er rekening mee gehouden worden dat eventueel ergens in de toekomst het hele ziekenhuis gebruik zal maken van het ICSP. Het is dus van groot belang nu al met eventuele uitbreidingen rekening te houden om problemen in de toekomst te vermijden.
8
9
Hoofdstuk 3
Technologie Dit hoofdstuk biedt een overzicht van de gebruikte technologie¨en die tijdens de onderzoeksfase van deze masterproef werden bestudeerd. In het eerste deel wordt de RFID technologie besproken: het basisprincipe van de technologie en enkele voor- en nadelen die ermee gepaard gaan. Deel twee bestaat uit een korte inleiding van XACML en beschrijft hoe het kan gebruikt worden om rollen te defini¨eren. In het derde en laatste deel wordt het principe van OSGi besproken.
3.1
RFID
Na een algemene uitleg over RFID worden enkele aspecten overlopen die een rol spelen bij de keuze van een RFID systeem. Ten slotte worden enkele emulatoren besproken die in deze thesis gebruikt kunnen worden.
3.1.1
Radio Frequency IDentification
RFID is het best te beschrijven als de opvolger van de meer gekende barcodes. Bij RFID wordt informatie uitgewisseld tussen een drager en een lezer via radiogolven. Dit verklaart meteen het grootste voordeel van RFID: er is geen “line-of-sight” tussen lezer en drager nodig om informatie te kunnen uitwisselen.
Elke lezer zendt radiogolven uit op een bepaalde golflengte. Als een drager (Radio Frequency
3.1. RFID
10
tag, RF-tag of kortweg tag) binnen het bereik komt van de lezer wordt de tag geactiveerd en zendt die de aanwezige informatie terug naar de lezer. Die laatste kan dan op zijn beurt de gewenste berekeningen uitvoeren.
De principes van de technologie werden voor het eerst toegepast door de Britten tijdens WO II om eigen vliegtuigen te identificeren [1]. Deze toepassing kreeg de naam IFF (Identity: Friend or Foe). De technologie werd tijdens de jaren ´60 verder uitgewerkt voor gebruik bij toegangscontroles en evolueerde steeds meer naar wat nu gekend is als RFID. Ondanks de vele voordelen bleef de echte doorbraak van de technologie lang uit. Dit kwam vooral door de hoge kost in vergelijking met soortgelijke oplossingen. Door de steeds competitievere prijzen en technologische verbeteringen wordt RFID nog een mooie toekomst toegeschreven [1].
RF-tags kunnen op twee manieren ingedeeld worden. Ten eerste kunnen we spreken over actieve en passieve tags. De eerstgenoemde groep wordt getypeerd door de aanwezigheid van een energiebron waardoor de tag in staat is zichzelf van voldoende stroom te voorzien om data uit te zenden. De passieve tags gebruiken het elektromagnetisch veld van een lezer om een stroom te induceren in de chip, zo krijgt het ge¨ıntegreerde circuit in de tag genoeg energie om op te starten en een antwoord te genereren. Er bestaat nog een derde groep, de zogenaamde semi-passieve tags, die voorzien zijn van een kleine batterij. Hierdoor zijn de tags continu online waardoor de reactietijd op een aanvraag kleiner is. Actieve tags sturen dus zelf hun data uit, op eigen initiatief, terwijl passieve en semi-passieve tags daarvoor eerst een signaal van een lezer moeten ontvangen.
Ten tweede kunnen RF-tags ingedeeld worden volgens de frequentie waarop ze werken. Er zijn vier belangerijke banden waarbinnen dit gebeurd (zie tabel 3.1).
benaming
golflengte
bereik
richtprijs (euro)
lage frequentie (LF)
125 of 134.2kHz
-20cm
50 `a 100
hoge frequentie (HF)
13.56MHz
10cm - 90cm
500 `a 1000
ultra hoge frequentie (UHF)
868 tot 956MHz
3m - 10m
+1500
microgolf (µW)
2.45GHz of 5.8GHz
3m - ?
+2000
Tabel 3.1: Gebruikte frequenties, bereik en richtprijs [4, 5]
3.1. RFID
11
Figuur 3.1: Typische RFID opstelling
De keuze om al dan niet een tag met voedingsbron te gebruiken in combinatie met de golflengte waarop gecommuniceerd wordt, bepaalt het bereik en de kostprijs van de opstelling.
Ten slotte zijn er nog een aantal minder belangrijke redenen om voor een bepaalde soort tag te kiezen: de grootte van de tag, de mogelijkheid om data niet enkel te kunnen lezen, maar ook te kunnen schrijven naar de tag en de grootte van het beschikbare geheugen.
3.1.2
Een RFID systeem kiezen
Kwaliteit kent zijn prijs en dat is niet anders bij RFID systemen. Het is vooral het bereik dat de prijs be¨ınvloedt, dat varieert van enkele millimeters tot enkele honderden meters. Verder hebben eigenschappen zoals detectietijd, programmeerbaarheid en het aantal tags dat tegelijk gelezen wordt elk hun invloed op de kostprijs van een systeem. De prijs verbonden aan de tags is iets stabieler en vooral afhankelijk van de grootte van het aanwezige geheugen en de hoeveelheid tags die nodig zijn.
EMI Bij het gebruik van RFID in een medische omgeving, zoals hier van toepassing, is er nog een extra factor waar men rekening moet mee houden: elektromagnetische interferentie (EMI). De radiogolven die gebruikt worden om informatie over te dragen van drager naar lezer, kunnen de werking van medische apparatuur verstoren [2]. Deze storingen vari¨eren van onbelangrijk
3.1. RFID
12
(kleine afwijking in de polsslagmeter) tot rampzalig (stilvallen beademingsapparatuur, op hol slaan pacemaker). Het is snel duidelijk dat dergelijke bijwerkingen ongewenst zijn in een omgeving van intensieve zorgen. Studies hierover stellen dat gebruik van een lage frequentie minder nefaste gevolgen heeft dan de hogere frequenties [2, 3]. Het is echter ook uitgewezen dat interferenties tussen RFID en medische apparatuur sterk afhankelijk is van de producenten (zowel van de apparatuur als van het RFID systeem) of gebruikte materialen in de omgeving. Uitvoerig testen van de mogelijke systemen in de omgeving waarbinnen moet gewerkt worden is dus aangewezen.
Beveiliging Aangezien lezers vrij verkrijgbaar zijn en elke tag automatisch reageert op een bevraging, is het niet moeilijk de gegevens op een tag te kopi¨eren en vervolgens zelf uit te zenden om binnen te raken in een systeem. Dit is uiteraard niet de bedoeling. Daarom is er nood aan een beveiliging van de tags binnen bepaalde systemen, zodat de uniekheid van elke tag gegarandeerd is.
Figuur 3.2: Voorbeeld van RFID tag met geheugen
Zoals eerder vermeld zijn er tags beschikbaar die een eigen geheugen bezitten. Door dergelijke tag te kiezen binnen een systeem is het eenvoudig voldoende veiligheid te voorzien. Het volstaat de belangrijke informatie versleuteld op te slaan op de tag en een sleutelpaar te voorzien tussen het systeem en de tag. Tijdens het uitwisselen van de data kan dan gebruik gemaakt worden van een unieke, tijdsgebonden parameter om misbruik tegen te gaan [4]. Aangezien de RFID lezer(s) en de tags worden geplaatst en verdeeld door eenzelfde, vertrouwde instantie, heeft de keuze voor encryptie met een symmetrisch of een asymmetrische algoritme geen invloed op de graad van beveiliging. Op die manier is aan alle principes van beveiliging voldaan.
3.1. RFID
De inlogprocedure verloopt dan als volgt: de lezer detecteert een tag en vraagt zijn referentie op, aan de hand van die unieke benaming kan nagegaan worden of de bewuste tag wel degelijk deel uitmaakt van het systeem. Vervolgens wordt de informatie op het geheugen van de tag opgevraagd en kunnen de kritieke gegevens met de overeenstemmende sleutel gedecrypteerd worden.
3.1.3
RFID emulatoren
Voor een proof-of-concept is het interessanter om te werken met een emulator. Op deze manier kunnen gemakkelijk meerdere parameters getest en vergeleken worden. Met de gepaste middleware kan de ontwikkelde applicatie dan interageren met elk RFID systeem dat beschikbaar is op de markt. Hieronder staat een overzicht van verschillende emulatoren met telkens een korte uitleg.
RIFIDI RIFIDI is een open source project dat het licht zag in februari 2005 [7]. Het ontstond uit de noodzaak een degelijke en goedkope testopstelling te hebben om de prestaties van een RFID systeem in verschillende omstandigheden te kunnen onderzoeken en vergelijken. Sinds 24 juni 2006 is het project publiek beschikbaar en sindsdien is het de standaard RFID hardware emulator. Er wordt nog volop aan ontwikkeld en bijna dagelijks kent het platform nieuwe gebruikers. Het platform emuleert de lezers van de meest gangbare producenten, laat toe de populairste tags te genereren en biedt een omgeving om beide te laten interageren zoals verwacht wordt in een realistische gebruiksomgeving.
Sybase RFID Anywhere RFID Anywhere is een product van Sybase, Inc. binnen het iAnywhere gamma [8, 9]. Het is een commerci¨ele oplossing om RFID hardware te emuleren. De iAnywhere producten bestaan sinds mei 2000 en kennen momenteel meer dan 20 000 klanten. De onderneming belooft gratis gebruik van hun programma voor ontwikkelaars en onderzoekers na registratie,
13
3.2. XACML
maar door verouderde drivers en handleidingen is het een al een kunst op zich de gratis versie te kunnen opstarten.
OpenPICC Een heleboel emulatoren, zoals OpenPICC, beschikken over een hardwarecomponent die programmeerbaar is [10]. In een laatste testfase is dergelijke optie zeker te overwegen, maar de instapprijs (enkele honderden euro) laat niet toe dergelijke oplossingen snel te gebruiken. Door de kostprijs, het gebruiksgemak en de uitgebreide ondersteuning is de keuze voor RIFIDI snel gemaakt.
3.2
XACML
Eenmaal de gebruiker geauthenticeerd is via RFID, is er nog een tweede controle nodig om te bepalen tot welke gegevens de gebruiker toegang heeft. Op die manier wordt voldaan aan de wens van rolgebaseerde weergave waarover sprake was in het eerste hoofdstuk. Om die controle mogelijk te maken, wordt gebruik gemaakt van XACML. In deze sectie wordt besproken wat XACML is en wat er mee kan gedaan worden. Er wordt een klein overzicht gegeven van de huidige en toekomstige profielen van XACML, in het kader van deze thesis wordt er ´e´en profiel meer in detail besproken.
3.2.1
eXtensible Access Control Markup Language
XACML is in 2003 door OASIS[16] erkend als standaard. Het is een XML-gebaseerde taal die voorziet in toegangscontrole en eigenlijk bestaat uit twee verschillende talen: de policy language en de request/response language[11, 12]. De policy language staat in voor de beschrijving van de eisen wat betreft toegangscontrole. Er zijn mogelijkheden voorzien om nieuwe functies, datatypes en algoritmen te defini¨eren. Om te weten of een bepaalde actie al dan niet kan uitgevoerd worden, is er de request/response language. Deze taal maakt het mogelijk queries te vormen zodat gevraagd kan worden of de actie mag uitgevoerd worden en om vervolgens het verkregen antwoord te interpreteren. Er zijn vier verschillende beslissingen die kunnen genomen worden:
14
3.2. XACML
Permit Deny Indeterminate Not Applicable
Werking XACML Bij XACML is er typisch iets of iemand die een actie wenst uit te voeren op een zekere resource [12]. De bevrager zal een request aanmaken en die naar het Policy Enforcement Point (PEP) doorsturen die de bevraagde resource beschermt. Deze PEP stuurt op zijn beurt de aanvraag door naar het Policy Decision Point (PDP). De PDP zal dan op basis van de beschreven policies een beslissing nemen of de actie al dan niet mag uitgevoerd worden. Daarnaast zijn er nog twee andere entiteiten in XACML [11]. Er is het Policy Information Point (PIP) die kan bevraagd worden door het PEP of het PDP om extra informatie te verkrijgen om een request in te vullen, respectievelijk een beslissing te nemen. De tweede entiteit, het Policy Administration Point (PAP) is verantwoordelijk voor het cre¨eren en beheren van policies, waarin voor elke rol de toegewezen rechten staan. Rechten worden beschreven als een actie die uitgevoerd wordt op een resource. Of er toestemming verleend wordt voor een bepaalde actie is dus niet enkel afhankelijk van de beschreven actie, maar ook van de resource waarop deze actie moet uitgevoerd worden.
XACML 2.0 De huidige standaard is XACML 2.0 en geldt al sinds 1/2/2005. In deze standaard zijn bijkomstig nog zes profielen gedefinieerd [11]: Core and hierarchical RBAC is een profiel dat toelaat policies te defini¨eren met RBAC. (Er wordt dieper ingegaan op dit profiel in sectie 3.2.2) Hierarchical resource definieert hoe XACML kan gebruikt worden in een omgeving waar resources hi¨erarchisch georganiseerd zijn. Resources kunnen dan gerepresenteerd worden
15
3.2. XACML
16
Figuur 3.3: Overzicht werking XACML [13]
als knopen in een xml-document, op basis van de positie van de knoop in de hi¨erarchie kan dan een policie gespecifieerd worden. Multiple resource is een profiel dat het mogelijk maakt met ´e´en response, respectievelijk request, toegang te verlenen, respectievelijk te vragen, tot verschillende resources. Privacy policy beschrijft hoe men privacy policies dient te defini¨eren. SAML 2.0 beschrijft hoe XACML 2.0 policies, requests en responses over een netwerklink kunnen verstuurd worden aan de hand van de Security Assertion Markup Language (SAML). XML Digital Signature is het profiel waarin het gebruik van W3C XML-Signature Syntax and Processing Standard voor authenticatie en integriteit van XACML data objecten beschreven wordt. Sinds 2007 wordt gewerkt aan een nieuwe standaard, XACML 3.0. Daarin zullen bestaande profielen een update ondergaan en alvast twee nieuwe profielen worden bijgevoegd [11]: Administration en Delegation is een profiel dat definieert hoe de administratie van policies kan georganiseerd worden op basis van resource, action of subject. Daarnaast zal in dit profiel ook beschreven worden hoe permissies, al dan niet tijdelijk, kunnen gedelegeerd worden.
3.2. XACML
XSPA XSPA of Cross-Enterprise Security and Privacy Authorization beschrijft hoe security en privacy policies uitgewisseld, consent directives ge¨evalueerd en autorisaties bepaald kunnen worden.
Implementaties In de masterproef van Chris Wauman [11] werd besloten om de Sun XACML Implementation te gebruiken. De keuze werd gemotiveerd door een aantal punten: de volledige ondersteuning van de XACML 1.1 standaard, de mate waarin de implementatie gebruikt en getest wordt, het feit dat Sun Microsystems lid is van OASIS en het bestaan van een actieve user community. Na een korte herstudie blijkt dat deze punten nog steeds gelden. Daarom wordt ook in deze masterproef gebruik gemaakt van de Sun XACML Implementation.
3.2.2
XACML Profile for RBAC
In het kader van deze thesis is het interessant dieper in te gaan op het eerstgenoemde profiel: Core and hierarchical RBAC. Eerst wordt bekeken wat RBAC precies inhoudt, vervolgens wordt het profiel zoals beschreven in de standaard uitgediept.
Role Based Access Control Het principe van RBAC is eenvoudig: ken bevoegdheden niet toe aan de personen, maar wel aan de rollen die binnen een omgeving van toepassing zijn [17]. Het is best mogelijk aan elke werknemer afzonderlijk rechten toe te kennen, maar dan moet bij elke nieuwe werkkracht een hele aanpassing aan het rechtensysteem gebeuren. Het is eenvoudiger om de verschillende functies in een omgeving te ontleden en voor elk van die functies een verzameling rechten te beschrijven. Dergelijke functies worden in RBAC rollen genoemd. Vervolgens kan aan elke werknemer een rol toegekend worden en op basis van die rol wordt dan beslist of een werknemer een bepaalde actie al dan niet mag uitvoeren. Ten slotte worden de verschillende rollen hi¨erarchisch geordend, waardoor overerving van rechten mogelijk is.
Ter illustratie wordt dit principe toegepast op de use case die beschreven werd in het eerste hoofdstuk: hoofdarts, arts en verpleegkundige zijn de rollen die vastgelegd worden. De be-
17
3.2. XACML
18
schrijving van de rechten van elke rol blijft ongewijzigd, hoeveel personen een bepaalde rol toebedeeld krijgen of verliezen heeft daar geen enkele invloed op. Verpleegkundigen krijgen toegang tot de AB Dose service, artsen tot de AB 7/14 service en hoofdartsen tot de AB Switch IV/PO service. De hi¨erarchische eigenschap van RBAC zorgt er voor dat een hoofdarts ook toegang heeft tot de AB 7/14 en AB Dose services en een arts tot de AB Dose service (zie figuur: 3.4).
Figuur 3.4: Toepassing RBAC
Het principe van RBAC is voor het eerst beschreven in 1992 [17]. Pas sinds 2004 is het als een ANSI INCITS (American National Standards Industry / InterNational Committee for Information Technology Standards) standaard aangenomen [11].
Core and hierarchical RBAC Zoals eerder vermeld bestaat er een profiel van XACML dat specifiek gericht is op rolgebaseerde toegangscontrole: Core and hierarchical role based access control (RBAC) profile of XACML v2.0 [15]. Dit profiel voorziet vier types policies: Permission PolicySet (PPS) Deze policies beschrijven de eigenlijke rechten van een bepaalde rol, ze zijn een verzameling van regels en condities die moeten voldaan zijn om toegang tot de gewenste resource te krijgen. Role PolicySet (RPS) Policies van dit type binden een rol aan een PPS.
3.3. OSGI
Role Assignment Policy of PolicySet (RAP) Een policy dat voor elke persoon vastlegt welke rol(len) die vervult. HasPrivilegesOfRole Policy Dit laatste type is een uitbreiding van de PPS die het mogelijk maakt het systeem te bevragen of een persoon de voorrechten bezit van een gegeven rol. Deze structuur maakt het mogelijk rolgebaseerde toegangscontrole te voorzien met overerving van permissies. Dit gebeurt als volgt: voor elke rol wordt een RPS voorzien die verwijst naar de bijhorende PPS. Elke PPS beschrijft op zijn beurt de rechten van een rol en bevat eventueel referenties naar andere PPS’s die de rechten van ondergeschikte rollen beschrijven [14]. Op die manier erft de eerstgenoemde rol alle rechten van de gerefereerde rollen. Het spreekt voor zich dat rollen kunnen toegewezen worden aan personen aan de hand van een RAP.
3.3
OSGi
Op basis van de rechten die de ingelogde rol heeft, worden een aantal services dynamisch ingeladen. Dit gebeurt binnen een OSGi omgeving. In dit stuk wordt eerst dieper ingegaan op de werking van OSGi. Vervolgens worden een aantal implementaties besproken.
3.3.1
OSGi
Het letterwoord OSGi stond oorspronkelijk voor Open Services Gateway Initiative, tegenwoordig is het echter gewoon een naam. Het was de bedoeling een systeem te ontwikkelen waardoor de integratie van nieuwe software in een bestaande omgeving vlot kon verlopen. Op die manier wilde men voorkomen dat de ontwikkeling van nieuwe software tegengehouden zou worden door een te hoge integratiekost [20].
De drijvende kracht achter de ontwikkeling van OSGi is de OSGi Alliance [18], een onafhankelijke non-profit onderneming die bestaat uit ontwikkelaars en focust op de samenwerking van applicaties en services gebaseerd op hun eigen componentgebaseerde integratieplatform. De OSGi Alliance is opgericht in 1999, de laatste release van het ‘OSGi Service Platform’ is versie 4.2 en dateert van september 2009.
19
3.3. OSGI
20
OSGi is een java-gebaseerde, service geori¨enteerde architectuur: services worden dynamisch gevonden en gebonden aan het platform zonder dat een restart van het systeem nodig is [21]. Dit wil zeggen dat niet kan uitgegaan worden van de beschikbaarheid van een bepaalde service. Het platform wordt publiek beschikbaar gesteld, dat betekent dus dat men de clients in principe niet kent. Ten slotte is de communicatie met het platform protocol-onafhankelijk.
3.3.2
Architectuur
Het hoofddoel van OSGi is het laten samenwerken van verschillende componenten die elkaar niet kennen op voorhand, ontwikkelaars moeten dus de mogelijkheid hebben software te laten samenwerken met andere componenten waarvan ze de details niet kennen. De architectuur moet dus uiterst geschikt zijn voor het inpluggen van componenten en die dynamisch met elkaar te laten samenwerken. Om aan al deze specificaties te kunnen voldoen, is er gekozen voor een gelaagde architectuur (zie figuur 3.5) [19]. De kern van de OSGi-architectuur wordt het framework genoemd.
Figuur 3.5: OSGi Architectuur [19]
Framework Het framework is de belangerijkste component van de OSGi specificatie: het biedt een gestandaardiseerde omgeving voor applicaties. Binnen de OSGi context worden applicaties bundels genoemd, dit zijn componenten gemaakt door ontwikkelaars die ingeplugd worden
3.3. OSGI
in het framework. Het framework zelf bestaat uit de volgende vier grote lagen: execution environment, modules, life cycle management en service registry [20]. Execution Environment Dit is de specificatie van de Java omgeving. Voorbeelden van mogelijke execution environments zijn J2SE, CDC, en CLDC. Het is deze component die zorgt voor een zogenaamde abstractie van omgeving, dit wil zeggen dat eenzelfde applicatie opnieuw kan gebruikt worden in een andere OSGi omgeving. Modules Deze component beschrijft de class loading policies. Dit is nodig om de verschillende modules (of bundels) samen te laten werken: Java heeft normaal ´e´en classpath dat alle klassen en resources bevat. OSGi breidt deze optie uit in deze laag zodat het mogelijk is bovenop de eigenschappen van Java nog modularisatie toe te voegen. De moduleslaag voegt private klassen toe voor elke module en staat in voor het gecontroleerd linken van de verschillende modules. Life Cycle Management Deze laag voorziet de functionaliteit om bundels dynamisch te kunnen starten, stoppen, installeren, updaten en de¨ınstalleren. Service Registry In deze laag wordt een mechanisme aangeboden om bundels op een dynamische manier te verbinden. Hiervoor wordt een publish-find-bind model gebruikt. Een bundel krijgt de mogelijkheid een object te cre¨eren en dit te registreren bij het Service Registry. Eenzelfde object kan zelfs geregistreerd worden onder verschillende interfaces. Andere bundels kunnen dan bij het Service Registry op zoek gaan naar een gepaste service of wachten tot een gewenste service verschijnt. Omdat objecten onder eenzelfde interface geregistreerd kunnen zijn, wordt er gebruikt gemaakt van properties. Door het filteren van de verschillende objecten op basis van die properties wordt gegarandeerd dat de juiste service wordt aangeboden.
Andere componenten Zoals te zien is in figuur 3.5 zijn er nog een aantal andere componenten aanwezig in de architectuur van OSGi. Deze worden hierna opgesomd, telkens met een korte uitleg. Bundels OSGi componenten door ontwikkelaars gemaakt. Security Extra laag om de beveiligingsaspecten af te handelen.
21
3.3. OSGI
Java VM Dit is de omgeving waarin de bundels worden uitgevoerd. Anders dan bij klassieke containers, worden bundels hier uitgevoerd in eenzelfde container en kunnen ze effectief code delen. Samen met de execution environment zorgt deze component ervoor dat applicaties herbruikt kunnen worden in een andere OSGi omgeving.
3.3.3
Implementaties
In dit stuk worden de drie belangrijkste open source OSGi implementaties besproken. Een keuze maken tussen deze implementaties is overbodig, omdat die al gemaakt is door het platform waarin deze thesis moet ingeplugd worden. Het ICSP platform werkt met de Apache Felix implementatie.
Apache Felix Felix [22] is een project van de Apache Software Foundation (ASF) [23]. ASF voorziet op verschillende manieren steun voor een groot gamma open source software projecten. Het is de voortzetting van de Apache Group, heeft zijn hoodzetel in Delaware, U.S. en is opgericht in 1994. Het Felix project is een top-level project binnen ASF sinds 21 juni 2007 en wordt op heden geleid door Richard S. Hall. De laatste stabiele release is Apache Felix 2.0.1 en dateert van 12 oktober 2009. Deze versie implementeert de volledige OSGi R4 core framework specificatie. Het Felix project wordt nog steeds zeer actief opgevolgd, iedere update van de OSGi standaard wordt binnen afzienbare tijd in het project verwerkt.
Knopflerfish Knopflerfish [24] is het OSGi open source project van Makewave [25], een organisatie die de OSGi technologie implementeert in verschillende commerci¨ele sectoren. Het project bestaat sinds 2003 en heeft momenteel twee hoofdtakken: Knopflerfish 2 (KF2) en 3 (KF3). De laatste stabiele versie dateert van 11 september 2009, is KF2.3.3 en implementeert de OSGi R4 v4.01 standaard. Van KF3 zijn voorlopig enkel β-releases beschikbaar.
22
3.3. OSGI
Eclipse Equinox Equinox [26] is een project van Eclipse [27], ook een open source community. Origineel is Eclipse opgericht door IBM in november 2001, sinds januari 2004 is het een onafhankelijke organisatie. In de eerste fase van het Equinox project was het de bedoeling een nieuwe basis te ontwikkelen voor Eclipse. Met de lancering van Eclipse 3.0 is deze taak tot een succesvol einde gebracht. De huidige ontwikkelingen binnen Equinox, worden ook wel ‘Phase 2’ genoemd, en dragen bij tot de Equinox Incubator. Die laatste is als het ware een omgeving om nieuwe technieken te testen die moeten bijdragen tot de verbetering van het Eclipse platform. De laatste stabiele release is Equinox 3.5.1 en gebeurde op 17 september 2009.
De keuze om binnen deze masterproef gebruik te maken van de Apache Felix implementatie is makkelijk te verklaren. Enerzijds is er de uitgebreide documentatie en duidelijke tutorials die de leercurve relatief vlak houden, anderzijds werkt het ICSP platform ook met deze implementatie.
23
24
Hoofdstuk 4
Architectuur In dit hoofdstuk wordt de gebruikte architectuur opgebouwd en besproken. Er wordt eerst een algemene kijk op de architectuur gegeven. Daarna worden de elementen die aan het bestaande ICSP platform worden toegevoegd overlopen. In het laatste deel wordt aan de hand van enkele sequentiediagrammen de samenhang van de componenten nog eens extra ge¨ıllustreerd.
4.1
Top view
In dit deel worden de grote lijnen van de architectuur voorgesteld. De functionaliteiten die het systeem moet aanbieden zoals besproken in 2.1 zijn in principe louter uitbreidingen van het bestaande ICSP platform. Een voor de hand liggende oplossing zou dus het bestaande platform als basiscomponent kunnen nemen.
De vereiste om RFID te gebruiken om automatisch inloggen mogelijk te maken, brengt echter een nadeel met zich mee: een hoge belasting van het systeem. Daarom wordt eerst bekeken hoe RFID gebruikt moet worden en wordt gezocht naar een mogelijkheid om, ondanks het gebruik van RFID, het systeem toch competitief te houden.
4.1. TOP VIEW
4.1.1
25
RFID Abstractie
Een RFID lezer heeft typisch de eigenschap bevraagd te moeten worden, dat wil zeggen dat het systeem op regelmatige tijdstippen zelf moet nagaan bij de lezer of er nieuwe tags in het bereik zijn. Zoals te zien is op figuur 4.1 is dit een zeer belastend proces dat de prestaties van het systeem zeker niet vooruit helpt.
Figuur 4.1: Normale interactie lezer-software
Om dit probleem op te vangen is er gekozen om de logica die moet instaan om de omgeving op nieuwe tags te controleren te implementeren op de lezer zelf. Dit betekent dat de belasting van het bevragen van de lezer niet langer ten nadele is van de ganse applicatie en dus niet langer van belang is voor de algemene prestaties van de voorgestelde oplossing. Hierdoor is de frequentie waarmee de lezer bevraagd wordt minder beperkt en is de kans dat er meerdere nieuwe tags tegelijk gezien worden veel kleiner. Het is immers zo dat een kleiner tijdsinterval tussen twee bevragingen betekent dat er minder bewegingen kunnen plaatsvinden binnen het bereik van de lezer. Het aantal nieuwe tags die dus bij de volgende bevraging zullen ontdekt worden, zal dus ook gemiddeld lager liggen. Componenten die moeten op de hoogte gebracht worden van wijzigingen in de aanwezige tags, kunnen zich dan registreren bij de RFID lezer om zo de veranderingen via een publish-subscribe mechanisme te ontvangen (zie figuur 4.2).
4.1. TOP VIEW
26
Figuur 4.2: Aangepaste interactie lezer-software
Deze keuzes leiden tot een architectuur waar het RFID deel volledig buiten het ICSP platform ge¨ımplementeerd wordt. Dit wordt getoond in figuur 4.3. Zo wordt, zoals al gezegd, het platform niet belast met de continue bevraging van de lezer.
Figuur 4.3: Top view architectuur
De logica die voorzien wordt op de RFID lezer biedt een aantal publiek toegankelijke methodes aan. Die methodes worden weergegeven in figuur 4.4 en zijn de enige manier om vanuit het ICSP platform te communiceren met de lezer. De functionaliteiten die aangeboden worden zijn de volgende: het starten en stoppen van de bevraging van de lezer, controleren of de
4.2. HET ICSP PLATFORM
bevraging op correcte wijze verloopt en het toevoegen en verwijderen van een component die op de hoogte wil gebracht worden van de opgemerkte wijzigingen.
Figuur 4.4: Interface aangeboden door RFIDAbstraction
4.2
Het ICSP platform
In dit deel worden de bundels overlopen die aan het ICSP platform worden toegevoegd of die al aanwezig zijn, maar gebruikt worden binnen de voorgestelde oplossing. Zoals besproken in de studie van OSGi zijn bundels logische eenheden van software, volledige of gedeeltelijke applicaties die met elkaar samenwerken binnen een OSGi omgeving. Om de gewenste functionaliteiten aan het ICSP platform toe te voegen, zijn er dus een aantal bundels nodig die deze functies voorzien. Figuur 4.5 geeft een overzicht van al deze bundels.
4.2.1
Cosara
Deze bundel is de kern van de voorgestelde oplossing. De bundel staat volledig in voor het beheer van de gebruikers van het platform en de opstart van de werkomgeving. De bundel zelf bestaat uit drie grote delen: core, users en rbac (zie figuur 4.6). Er is sprake van een microkernel architectuur: alle communicatie binnen deze bundel gebeurt via de core.
De core is verantwoordelijk voor het opstarten van het systeem. Hier worden alle componenten ge¨ınitialiseerd en beheerd. Binnen deze package is ook de Graphical User Interface (GUI)
27
4.2. HET ICSP PLATFORM
Figuur 4.5: Fragment van het ICSP platform
geplaatst die verantwoordelijk is voor de weergave van de werkomgeving. Er wordt gebruik gemaakt van een Model-View-Controller (MVC) architectuur om de data en de interface consistent te houden. In dit opzicht dienen de deelcomponenten users en rbac als model en de GUI component zelf als view en controller. Dit wil zeggen dat er geen data wordt bijgehouden in de GUI component. Indien er wijzigingen optreden waaraan de GUI zich moet aanpassen, dan wordt die daarvan op de hoogte gebracht door de betrokken componenten.
Figuur 4.6: Architectuur van de Cosara bundel
Die componenten zijn, zoals eerder aangehaald, users en rbac en kunnen slechts via een beperkt aantal methoden worden aangesproken. Het afschermen van deelcomponenten, of het voorzien van een fa¸cade, verhoogt de aanpasbaarheid van het systeem. De aanpasbaarheid (of pluggability) waarvan hier sprake is niet dezelfde als uitgelegd in 2.2. Door het werken met dergelijke fa¸cades wordt de eigenlijke logica van elke component verborgen gehouden voor de rest van het systeem. Dit wil zeggen dat de inhoud van elke component kan gewijzigd worden zonder dat de rest van het systeem daar hinder van ondervindt, zolang de gedefinieerde fa¸cades
28
4.2. HET ICSP PLATFORM
29
gerespecteerd worden. Deze eigenschap is vooral van belang in de rbac component.
Figuur 4.7: Interface aangeboden door RBAC
Zoals te zien is in figuur 4.7 voorziet deze component slechts drie methoden waarlangs communicatie mogelijk is. De eerste methode, buildPolicies, verwacht een lijst van rollen en bouwt op basis van die lijst een structuur op die dan op latere tijdstippen eenvoudig bevraagd kan worden. De tweede methode verwacht een rol en een lijst met alle beschikbare services als input en stelt op basis daarvan een lijst samen met alle services waarvoor de gegeven rol gebruiksrechten bezit. De derde en laatste methode controleert of een rol toegangsrechten bezit tot een gegeven service.
Er werd eerder gesteld dat het gebruik van fa¸cades een belangrijk nut heeft en dat dit meteen tot zijn recht zou komen in deze component. In 1.2 werd beschreven dat het bepalen van de services die geactiveerd moeten worden zou gebeuren aan de hand van XACML. Tot zover is deze technologie echter nog niet aan bod gekomen in de architectuur. Het gebruik van XACML wordt in de architectuur volledig verborgen door de rbac component. Op die manier kan benadrukt worden dat de essentie van de voorgestelde oplossing het rolgebaseerd activeren van services is en niet het gebruik van XACML. Hoe die rolgebaseerde activatie tot stand komt is dus van geen belang voor de architectuur van het systeem. Het gebruik van XACML en dus de invulling van de rbac component, zijn implementatiespecifieke details en zullen besproken worden in 5.2.
De derde component van de Cosarabundel is het users deel. De interface aangeboden door deze component bezit enkele triviale, maar niettemin nodige, functies (zie figuur 4.8). Vooreerst is het mogelijk de huidige gebruiker op te vragen en aan te passen. Verder kan er een lijst met kandidaten opgevraagd worden. Kandidaten zijn personen die aanwezig zijn binnen het
4.2. HET ICSP PLATFORM
30
bereik van de lezer en in aanmerking komen om het systeem te gebruiken, maar niet ingelogd zijn. Ten slotte wordt de mogelijkheid aangeboden aan andere componenten om zich te registreren als luisteraar en zodoende van wijzigingen binnen het users deel op de hoogte gebracht te worden.
Figuur 4.8: Interface aangeboden door Users
4.2.2
ABDose, AB7/14, ABSwitch IV/PO
De drie services beschreven in de use case in 1.3 zijn allen een implementatie van de ICSPService interface. De GUI van elke medische service die beschikbaar gesteld wordt op het ICSP platform implementeert, in de context van de oplossing voorgesteld in deze masterproef, deze interface. Op die manier is het eenvoudig bundels die de GUI van een medische service aanbieden op te sporen en kan de Cosara bundel de vastgelegde functies gebruiken. Zoals eerder gesteld zijn de services die gebruikt worden binnen deze masterproef dummyservices. Hierdoor volstaat het dat ze een gebruikerspaneel en een titel van de voorgestelde service kunnen teruggeven. Dit wordt nog eens weergegeven in figuur 4.9.
Figuur 4.9: Interface ICSPService
4.3. INTERACTIE
4.2.3
DB, API
Deze twee bundels staan in voor enkele triviale functionaliteiten en zorgen ervoor dat de basisstructuren door het ganse platform gekend zijn. De bundel DB voorziet de connectie met een databank. Specifiek voor het systeem dat hier ontwikkeld wordt, kan via deze bundel informatie over gebruikers worden opgevraagd. De API voorziet structuren die het mogelijk maken personen, rollen, tags en services voor te stellen. Als voorbeeld hiervan kan de ICSPService interface uit figuur 4.9 aangehaald worden die dus via de API bundel aangeboden wordt.
4.3
Interactie
Hierna wordt aan de hand van twee sequentiediagrammen de samenhang van de verschillende componenten besproken. Het is de bedoeling dat het bespreken van die praktische situaties een nog beter inzicht in de verantwoordelijkheden van de afzonderlijke delen in de architectuur voortbrengt.
4.3.1
Systeemstart
In figuur 4.10 is een sequentiediagram te zien die de verschillende acties weergeeft die gebeuren tijdens het opstarten van het systeem. Alles start initieel bij de core.
In eerste instantie wordt geprobeerd de RFID lezer aan te spreken. Aangezien er voor gekozen is een abstractie te maken van de logica die het RFID deel ondersteund, moet de lezer op autonome wijze worden opgestart. Indien dit niet gebeurd is, of er een andere fout optreedt tijdens het maken van een verbinding met de RFID lezer, kan het systeem niet verder worden opgestart. Het is de implementatie die bepaalt of er op dit moment, bijvoorbeeld, een foutmelding wordt weergegeven of een alternatieve inlogprocedure wordt voorzien.
Indien er op correcte wijze een verbinding tot stand kan gebracht worden met de RFID lezer kan het systeem verder opgestart worden. In een tweede stap wordt dan het users deel aangesproken. Die component voorziet dan een instantie van de UserManager die door de core kan aangesproken worden. Tijdens de initialisatie wordt de UserManager meteen
31
4.3. INTERACTIE
32
geregistreerd als luisteraar bij de RFID lezer, zo wordt die van elke wijziging opgemerkt door de lezer op de hoogte gebracht.
De laatste stap is het initialiseren en beschikbaar stellen van een RBACManager. Dit object dat voortkomt uit het rbac deel, kan dan zoals eerder vermeld, aangesproken worden om te bepalen welke services opgestart moeten worden.
Het beheer van de aangemaakte objecten ligt volledig in handen van de core. Indien de verschillende besproken componenten gebruik willen maken van elkaars diensten, dan dient dit te gebeuren via de core. Dit is ook het principe van een microkernel architectuur waarover eerder reeds gesproken is.
Figuur 4.10: Sequentiediagram systeemstart
4.3. INTERACTIE
4.3.2
33
Nieuwe gebruiker
Het sequentiediagram dat te zien is in figuur 4.11 toont de verschillende stappen die genomen worden op het moment dat er zich een wijziging voordoet in het bereik van de RFID lezer.
Figuur 4.11: Sequentiediagram nieuwe gebruiker
Het is de lezer die zelf de users component op de hoogte brengt van deze wijziging. Deze component zal intern de verkregen informatie verwerken en indien nodig een nieuwe gebruiker aanduiden en de lijst met kandidaten aanpassen. Vervolgens verwittigt die de core, zodat deze op zijn beurt de gepaste acties kan uitvoeren. Na het opvragen van de huidige gebruiker en lijst met kandidaten kan de core bepalen of het een nieuwe gebruiker betreft. Indien dit zo is wordt een lijst samengesteld met alle medische services die op dat moment beschikbaar zijn op het platform. Op basis van die lijst wordt dan
4.3. INTERACTIE
aan de rbac component gevraagd een lijst samen te stellen met alle services die geactiveerd moeten worden voor de nieuwe gebruiker. Eenmaal al deze gegevens verzameld en opgebouwd zijn kan dan de opdracht gegeven worden om de GUI up te daten op basis van de nieuwe gegevens.
34
35
Hoofdstuk 5
Implementatie In dit hoofdstuk wordt dieper ingegeaan op enkele interessante aspecten van de implementatie. In het eerste deel worden de bijzonderheden en mogelijkheden van het gebruik van RFID uitgediept. Het bepalen van de te activeren services op basis van de rol van de gebruiker is het onderwerp van het tweede deel. In het derde en laatste deel van dit hoofdstuk ten slotte, wordt uitgelegd hoe die services geactiveerd worden in een OSGi omgeving en wat de impact is van het gebruik van OSGi op de oplossing voorgesteld in dit boek.
5.1
Gebruik van RFID
In deze masterproef wordt onderzocht hoe het inloggen geautomatiseerd kan worden zonder tussenkomst van de gebruiker, er is dus geen handeling nodig van de gebruiker om in het systeem te kunnen inloggen. Vanuit dat opzicht wordt er verder gesproken over passief inloggen. Het actief inloggen wordt onderzocht in een andere masterproef [29]. Het is belangrijk het verschil in gebruik van termen te vatten. De woorden ‘actief’ en ‘passief’ hebben in deze context niets te maken met de soort RFID tag die gebruikt wordt.
De eerste stap is het herkennen van gebruikers die mogen inloggen op het platform en een keuze maken wie er effectief wordt ingelogd. Het herkennen van rechtmatige gebruikers biedt niet veel mogelijkheden: als een tag gelezen wordt is een databankbevraging nodig om de gebruiker te identificeren en te bepalen of die al dan niet toegang mag krijgen. Beslissen over wie ingelogd wordt, heeft iets meer voeten in de aarde.
5.1. GEBRUIK VAN RFID
5.1.1
Passief inloggen
Aangezien er voor gekozen wordt te werken met een RFID lezer en passief inloggen hier het onderwerp is, zijn er onmiddellijk een aantal voorwaarden vastgelegd voor het systeem. Een eerste punt is de plaatsing van de tag. Die moet op een voor de gebruiker handige plaats ingewerkt worden, mag de werkhandelingen niet belemmeren en moet bij gebruik van een computer zo dicht mogelijk bij de lezer zijn (het is voordeliger een lezer te kunnen gebruiken met een klein bereik, om zo de kosten zoveel mogelijk te drukken). Er zijn verschillende mogelijkheden: de tag kan verwerkt worden in een sleutelhanger, in een gsm of pda, in een badge of in de kledij. De beste optie hier is de tag in te werken in de badges, omdat die nu toch al door alle personeelsleden gedragen worden. Op die manier wordt geen enkele aanpassing gevraagd van het personeel en is de afstand van badge tot computer steeds relatief klein omdat een badge normaal opgespeld wordt ter hoogte van de borst. Verder moet er ook nagedacht worden over de plaatsing en de keuze van de lezer. De keuze om de tag in te werken in de badge impliceert dat de lezer dus ook best op borsthoogte geplaatst wordt, dit komt normaalgezien overeen met schermhoogte. Een kleine, bescheiden lezer die aan de achterkant van het scherm bevestigd kan worden, lijkt hier de beste keuze. Omdat het een re¨ele situatie is dat er zich meerdere tags binnen het bereik van de lezer bevinden, is het nodig een lezer te kiezen die in staat is een aantal tags tegelijk te verwerken.
Het systeem laat maximaal ´e´en gebruiker toe om in te loggen, maar zoals net aangehaald kunnen er meerdere potent¨ıele gebruikers tegelijk aanwezig zijn. Er is dus nood aan een manier om vast te leggen welke ge¨ıdentificeerde persoon er daadwerkelijk mag inloggen. De beslissing om een abstractie te maken van het RFID deel, uitgelegd in 4.1.1, laat alvast toe de lezer met een hogere frequentie te bevragen. Dit betekent dat de kans op het gelijktijdig ‘ontdekken’ van nieuwe tags sterk verminderd wordt. De kans dat er immers meerdere personen binnen het bereik van de lezer komen in een tijdspanne van, bijvoorbeeld, twee seconden is beduidend kleiner dan een tijdsinterval van vijf seconden. Ook het aantal potenti¨ele gebruikers die ontdekt worden zal lager liggen waardoor de complexiteit om een nieuwe gebruiker te kiezen veel lager komt te liggen.
Hierna worden een aantal mogelijke algoritmen besproken hoe men kan handelen indien gebruikers toch in groep ontdekt worden door de lezer.
36
5.1. GEBRUIK VAN RFID
FIFO / LIFO Naar analogie met het gekende FIFO of LIFO principe uit de wachtlijntheorie, kan ervoor geopteerd worden altijd de persoon die als eerste (of laatste) van een groep in het bereik van de lezer komt in te loggen. Een nadeel aan deze optie is dat de volgorde waarin de lezer de kandidaten doorgeeft aan het systeem bepalend is voor de beslissing wie ingelogd wordt.
Willekeurig Er kan ook willekeurig een gebruiker gekozen worden die vervolgens wordt ingelogd. Het verschil tussen deze optie en de vorige zal echter niet merkbaar zijn voor de gebruikers. Zoals eerder aangehaald zijn we bij FIFO/LIFO immers afhankelijk van de lezer om een volgorde te kennen.
Hoogste rang / laagste rang Een andere mogelijkheid is de rollen van de verschillende kandidaat gebruikers te vergelijken en degene die de hoogste rang heeft binnen de hi¨erarchie in te loggen. Hiervoor moet de rollenhi¨erarchie eenduidig en strikt worden uitgewerkt, zodat alle rollen effectief zinvol kunnen vergeleken worden. In deze situatie bestaat er nog altijd de mogelijkheid dat meerdere personen dezelfde rang hebben zodat er toch op een andere manier beslist zal moeten worden wie wordt ingelogd. Analoog kan de gebruiker met de laagste rang gekozen worden om in te loggen. Zo is er nog een extra voordeel: veiligheid. Bij de keuze van de laagste rang is het niet mogelijk dat een gebruiker ongewenst toegang krijgt tot services die eigenlijk bestemd zijn voor rollen met een hogere rang.
De gebruiker de keuze laten Een beetje tegenstrijdig om dergelijke optie in een deel passief inloggen te bespreken, maar misschien moet toch overwogen worden om de uiteindelijke keuze aan de gebruikers zelf te laten. Enkel op die manier zijn we er immers zeker van dat de correcte persoon wordt ingelogd. Zo zou er een overzicht gegeven kunnen worden met alle kandidaten en kan men met ´e´en klik
37
5.1. GEBRUIK VAN RFID
inloggen. Dit betekent uiteraard ook dat alle personeel zich ervan bewust moet zijn dat indien ze zich in de buurt van een RFID lezer bevinden, het mogelijk is dat zij als gebruiker worden ingelogd. Het is duidelijk dat het niet gemakkelijk is te beslissen welke kandidaat precies moet worden ingelogd. In de implementatie van de oplossing voorgesteld in dit boek zijn de opties FIFO en hoogste rang voorzien. De laatst voorgestelde mogelijkheid, de gebruiker de keuze laten, is ook aanwezig en wordt, ondanks het thema passief inloggen van deze masterproef, best altijd ge¨ımplementeerd. Zo kan de gebruiker de beslissing van het systeem altijd corrigeren indien gewenst.
5.1.2
Passief uitloggen
Op het eerste zicht is het uitloggen een triviale zaak: als de gebruiker uit het bereik van de lezer verdwijnt, dan moet die worden uitgelogd. In de praktijk zijn er echter een aantal factoren waar best wordt over nagedacht. Zo is het vanuit financieel standpunt bekeken snel beslist om een lezer te kiezen met een minimaal bereik. Dit betekent echter dat de gebruiker bij de minste beweging weg van de lezer, wordt uitgelogd (bijhalen van medicatie, roepen van hulp, de pati¨ent van dichterbij onderzoeken). Een lezer met een groter bereik betekent dan weer dat er meer kans is op een gebied waar het bereik van meerdere lezers een gemeenschappelijke zone hebben. Er zijn een aantal eenvoudige oplossingen voor handen, bijvoorbeeld: de gebruiker moet een bepaalde tijd buiten het bereik zijn vooraleer die wordt uitgelogd, uitloggen gebeurt enkel als er een andere gebruiker in de buurt is, uitloggen moet actief gebeuren of een combinatie van deze opties.
De keuze van het algoritme dat in deze situatie gebruikt wordt, heeft een sterke invloed op de beveiliging van het platform. Indien een persoon immers niet onmiddellijk wordt afgemeld bij het verlaten van de werkomgeving, is het systeem een korte tijd voor iedereen toegankelijk. Het is mogelijk bij elke actie te controleren of de aangemelde persoon nog effectief aanwezig is in het bereik van de lezer. Deze aanpak heeft twee nadelen: er blijft een korte periode over tussen twee RFID bevragingen waarbinnen oude informatie gebruikt wordt en die extra testen zijn ook een extra belasting voor het systeem.
38
5.2. RBAC MET XACML
39
De implementatie die in het kader van deze masterproef opgebouwd is, logt de gebruiker uit zodra die uit het bereik van de lezer is. Er blijft een kort, onbeveiligd moment over afhankelijk van de bevraginsgfrequentie van de lezer, maar de duur daarvan laat toe aan te nemen dat via sociale controle de beveiliging van het systeem gegarandeerd blijft. De mogelijkheid om steeds actief uit te loggen en handmatig een nieuwe gebruiker te kiezen wordt ook aangeboden in de implementatie.
5.2
RBAC met XACML
In deze masterproef worden de services die moeten geactiveerd worden, gekozen op basis van de rol van de gebruiker, ook wel RBAC genoemd. De controle of een bepaalde rol gebruikersrechten bezit voor een zekere service wordt gedaan aan de hand van XACML. Deze twee concepten werden al bestudeerd in sectie 3.2.1 van dit boek.
In dit deel wordt besproken hoe deze twee technologie¨en gebruikt en gecombineerd worden in de voorgestelde oplossing. Er is gekozen om de basisprincipes van XACML te respecteren en het rolgebaseerde gebruik ervan weg te houden van het XACML deel. Op die manier is enerzijds de herbruikbaarheid van de XACML component gegarandeerd en wordt anderzijds nogmaals benadrukt dat rolgebaseerde selectie van services ook met een andere technologie dan XACML kan gerealiseerd worden. Dit wordt weergegeven in figuur 5.1.
Figuur 5.1: RBAC component
In wat volgt wordt eerst besproken hoe XACML in deze oplossing gebruikt wordt en wat de nodige wijzigingen waren. Verderop wordt dan de toegevoegde waarde van de RBAC component uitgelegd.
5.2. RBAC MET XACML
5.2.1
40
Standaardgebruik XACML
De werking van XACML werd al eerder besproken. Toch is het zinvol nog eens kort te bespreken hoe de techniek in de praktijk gebruikt wordt. De bedoeling van XACML is een aantal policies op te stellen die beschrijven welke rollen welke rechten hebben en deze vervolgens aan het PDP te overhandigen. Als dan later iets of iemand toegang wil tot een bron, dan wordt een specifiek request opgesteld. Het request bevat dan een subject (de instantie die de toegang wilt), een resource (de bron die aangesproken wordt) en een actie (de actie die het subject op de resource wil uitvoeren). Dat request wordt ge¨evalueerd door het PDP en een eenduidig response wordt teruggegeven (permit, deny, indeterminate, not applicable).
In figuur 5.2 worden de verschillende componenten van XACML nog eens weergegeven. Hierna worden die componenten overlopen en van elk worden de verantwoordelijkheden besproken. Aanpassingen die nodig waren aan de Sun XACML Implementation, waarvan vertrokken werd, worden extra benadrukt.
Figuur 5.2: XACML component
PAP Het PAP is verantwoordelijk voor het opbouwen van de structuren die later bevraagd kunnen worden om de toegangsrechten van een bepaalde rol te bepalen. De module is zo ontwikkeld dat na de generatie een object met alle policies wordt teruggegeven waarmee dan gewerkt kan worden. Dit is beter voor de prestaties van het systeem dan telkens opnieuw de xml-bestanden in te lezen vooraleer een bevraging kan gebeuren. Uiteraard worden de gegenereerde structuren wel weggeschreven, zodat er geen informatie verloren gaat indien een herstart van het systeem nodig zou zijn.
5.2. RBAC MET XACML
Omdat de Sun XACML Implementation enkel de XACML 1.1 specificaties ondersteunt, is er een soort van PolicyBuilder voorzien, die op basis van de nodige gegevens alle XACML bestanden opbouwt. Op die manier voldoen de gegenereerde policies aan de XACML 2.0 specificaties en kunnen rollen op een zeer eenvoudige wijze worden aangemaakt. Het is ook die laatste specificatie die het gebruik van twee verschillende soorten policies aanbeveelt.
Ten eerste is er de Role PolicySet (RPS). Dergelijke policy beschrijft een rol en linkt deze met de toegangsrechten verbonden aan deze rol. Een voorbeeld van de RPS van de arts (doctor ) wordt hierna getoond.
<Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> doctor <SubjectAttributeDesignator SubjectCategory="urn:oasis:names:tc:xacml:2.0: subject-category:role-enablement-authority" AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/> pps:doctor
41
5.2. RBAC MET XACML
42
Deze RPS is enkel geldig voor Subjects die een rol bezitten waarvan de attribuutwaarde gelijk is aan doctor. Indien dit zo is dan geeft de voorlaatste lijn aan dat de beschrijving van de toegangsrechten van een arts te vinden zijn in de Permission PolicySet van de arts (pps:doctor ).
De tweede soort policy is dus de Permission PolicySet (PPS). Deze policy beschrijft alle toegangsrechten die een bepaalde rol bezit. Om de hi¨erarchische structuur van rollen te ondersteunen verwijst elke PPS ook naar de beschrijving van de rechten van de ondergeschikte rollen. Hierna wordt een voorbeeld gegeven van zo’n PPS, het onderwerp is opnieuw de arts.
AB7_14
5.2. RBAC MET XACML
43
use pps:nurse
Deze PPS bevat slechts ´e´en regel: een arts mag de service AB 7/14 gebruiken. Het Resource deel stelt dat het om de service AB 7/14 gaat en het Action segment definieert dat de actie use toegelaten is. Bovendien garandeert het feit dat deze PPS enkel aangesproken wordt indien ernaar verwezen werd in een toegankelijke RPS, dat enkel artsen deze actie op deze service kunnen uitvoeren. Een andere manier om in deze PPS terecht te komen, is via een verwijzing in een PPS van een rol die hoger staat in de hi¨erarchie. Een voorbeeld van zo’n verwijzing is in het codevoorbeeld hierboven te zien op de voorlaatste lijn. Deze lijn stelt dat een arts ook alle rechten van een verpleegkundige bezit. Het is dus aan de beheerder van het systeem om ervoor te zorgen dat de orde van de rollen eenduidig gedefinieerd is en dat de implementatie ervan correct gebeurt.
De opbouw van alle policies gebeurt door ´e´en methode uit de PEP component die aangeroepen wordt met als argument een lijst van rollen met hun volledige beschrijving. Op die manier is het ontwikkelde systeem volledig voorbereid om te kunnen omgaan met automatische generatie en aanpassingen van de verschillende RPS’en en PPS’en. Het volstaat een gebruikersinterface te voorzien die toelaat rechten op services toe te kennen aan bepaalde rollen en de hi¨erarchie van de rollen te manipuleren op een intu¨ıtieve manier, om de instellingen van het
5.2. RBAC MET XACML
44
systeem door eender wie te laten gebeuren.
PEP De verantwoordelijkheid van het PEP is het aanmaken van een geldige request die dan door het PDP kan ge¨evalueerd worden. Opnieuw is de implementatie zo aangepast dat de gegenereerd request voldoet aan de XACML 2.0 specificaties. Dit uit zich voornamelijk in de gebruikte identifiers, de kernwoorden in de opgebouwde structuren, die toelaten om te gaan met de hi¨erarchische vorm van de rollen.
Het PEP biedt enkel een functie aan die een request teruggeeft. Hiervoor zijn drie argumenten nodig: de naam van een rol, de service waartoe toegang gevraagd wordt en de actie die op de service wil uitgevoerd worden. Binnen deze masterproef is de actie telkens dezelfde: gebruiken. Toch is de mogelijkheid in de implementatie voorzien om andere acties te defini¨eren, dit opnieuw om herbruikbaarheid van de componenten maximaal te ondersteunen.
Hierna staat nog een voorbeeld van dergelijk request. Na het bestuderen van een RPS en een PPS, ligt het voor de hand dat het codefragment hieronder een request betreft die nagaat of een arts de service AB Dose mag gebruiken.
<Subject SubjectCategory="urn:oasis:names:tc:xacml:2.0: subject-category:role-enablement-authority"> doctor
5.2. RBAC MET XACML
ABDose use
PDP De laatste component van het XACML deel ten slotte, is het PDP. Het PDP is de kern van het XACML gebeuren: hier worden de requests losgelaten op de beschikbare RPS’en en PPS’en om zo te beslissen of de gevraagde actie al dan niet mag uitgevoerd worden. Het belangrijkste element van dat PDP is de PolicyFinderModule, dit is een module die alle aangereikte policies verzamelt en beheert. Het is dankzij die module dat requests gemapt kunnen worden op ´e´en of meerder RPS’en (en de bijhorende PPS’en). Het is echter ook zo dat het net die module is in de Sun XACML Implementation die nog niet klaar is voor het omgaan met de hi¨erarchische structuur van de rollen.
Het was dus noodzakelijk een nieuwe implementatie van die module te voorzien om de oplossing voorgesteld in dit boek te laten slagen. Daarom werd de RBACPolicyFinderModule, die een rechtstreekse uitbreiding is van de basis PolicyFinderModule, voorzien. Deze module laat toe policies op te speuren op basis van een referentie. Dit is noodzakelijk aangezien de verschillende RPS’en en PPS’en en de PPS’en onderling gelinkt worden door een referentie naar elkaar. Een voorbeeld van dergelijke referentie staat hierna.
45
5.2. RBAC MET XACML
pps:nurse
De nieuwe module laat dus toe op basis van een referentie (bijvoorbeeld ‘pps:nurse’) de juiste policy op te zoeken en terug te geven, dit is niet mogelijk met de Sun XACML Implementation.
5.2.2
Verantwoordelijkheden RBAC
De XACML component die zonet besproken werd, biedt alle functionaliteiten om na te gaan of een bepaalde gebruiker op een zekere service de gewilde actie mag uitvoeren. In het kader van deze masterproef is er echter nood aan een mechanisme dat toelaat alle services te bepalen die voor de ingelogde gebruiker toegankelijk zijn.
Daarom is er een extra abstractielaag voorzien die het gebruik van XACML regelt. Deze laag, waarvan de functionaliteiten verwerkt zijn in de rbac component, draagt de verantwoordelijkheid de lijst met alle op te starten services samen te stellen. De meest voor de hand liggende methode hiervoor is meteen ook de beste: voor elke beschikbare service wordt onderzocht of de huidige gebruiker toegangsrechten bezit. Hoe de beschikbare services precies worden opgespoord wordt besproken in 5.3.1. In dit deel wordt aangenomen dat die lijst aanwezig en volledig is.
Telkens alle services overlopen lijkt op het eerste zicht een veel te hoge belasting voor het systeem. Dit is echter wel nodig indien gegarandeerd moet worden dat op elk moment alle toegankelijke services getoond worden aan de gebruiker. De mogelijkheid om omgekeerd te werk te gaan bestaat uiteraard ook nog: stel eerst voor elke rol een lijst samen met alle services die moeten geactiveerd worden en bekijk telkens als het nodig is welke van die services ook effectief beschikbaar zijn. Deze methode biedt ook een oplossing voor het gestelde probleem, maar maakt het gebruik van XACML licht overbodig en vraagt een manuele update van de lijst van de te activeren services per rol indien er wijzigingen optreden.
In deze oplossing is er dus voor gekozen te werken met de eerstgenoemde werkwijze. Om de prestaties van het systeem op een aanvaardbaar peil te houden zijn er altijd een aantal mogelijke uitbreidingen beschikbaar.
46
5.3. WERKEN IN EEN OSGI OMGEVING
Lijsten cachen Ten eerste is het mogelijk de twee voorgestelde opties te combineren. Door op geregelde tijdstippen per rol een lijst met te activeren services te genereren op basis van de beschikbare services, is er altijd onmiddellijk een behoorlijk recente lijst met de services die moeten geactiveerd worden aanwezig.
Realtime doorgeven Een tweede mogelijkheid is om de stap waarin een lijst wordt samengesteld over te slaan. In plaats van een lijst te genereren en die dan door te geven naar de wachtende component, is het ook mogelijk om telkens als een service wordt gevonden die geactiveerd moet worden, dit te melden. Op die manier kan verder gezocht worden naar toegankelijke services terwijl een deel reeds wordt geactiveerd.
Prioriteiten toekennen Een derde en laatste voorstel is om prioriteiten toe te kennen aan services. Zo kunnen services met een hoge prioriteit eerst gecontroleerd worden en minder belangrijke services later. Dit systeem in combinatie het realtime doorgeven van informatie, zal vooral in de praktijk als een groot voordeel aangevoeld worden. Theoretisch zal de laatste service die geactiveerd moet worden niet veel later worden aangesproken. In de praktijk zullen de services die het meest gebruikt worden of het belangrijkste zijn wel steeds zo snel als mogelijk werkklaar zijn.
5.3
Werken in een OSGi omgeving
Zoals vermeld in 3.3.3 is er voor gekozen te werken met Apache Felix als OSGi omgeving. Het gebruik van OSGi brengt een aantal punten met zich mee die het vermelden waard zijn in dit boek. Hierna volgen een aantal implementatiedetails die er gekomen zijn door of invloed hebben op het gebruik van een OSGi omgeving.
47
5.3. WERKEN IN EEN OSGI OMGEVING
5.3.1
Beschikbaarheid van services
Binnen een OSGi omgeving kan er niet uitgegaan worden van de beschikbaarheid van services. Het is dus nodig te voorzien dat de ontwikkelde oplossing kan omgaan met het wegvallen en bijkomen van services op willekeurige tijdstippen.
Om een bundel te kunnen gebruiken in een OSGi gebaseerd framework kan er gebruik gemaakt worden van een zogenaamde BundleActivator. Deze component zorgt er voor dat een bundel gestart en gestopt kan worden. Binnen deze twee functies kunnen dan andere componenten in de bundel worden aangesproken zoals in elke andere java applicatie.
Daarnaast wordt er ook gebruik gemaakt van een ServiceTracker, een component die als het ware de gebeurtenissen in de OSGi omgeving bestudeerd. Binnen deze implementatie is gebruik gemaakt van een uitbreiding van de ServiceTracker : de ISCPTracker. Het is de ICSPTracker die het wegvallen of bijkomen van services ondersteund: wijzigingen in de omgeving worden doorgegeven naar de eigenlijke applicatie. Services die wegvallen kunnen zo ook uit de gebruikersomgeving weggehaald worden, voor services die er bijkomen wordt eerst bekeken of de huidige rol er toegang tot heeft en vervolgens geactiveerd indien dit zo is. Het is ook de ICSPTracker die het mogelijk maakt ten alle tijde een lijst met alle beschikbare medische services op te vragen. Dit is mogelijk door alle actieve bundels in de OSGi omgeving op te vragen en daar een filter op toe te passen. Die filter is zodanig ingesteld dat enkel de medische services overgehouden worden. In de oplossing die hier wordt voorgesteld, moeten medische services de ICSPService interface implementeren. De filter zorgt er dus voor dat enkel de bundels die die interface implementeren, weerhouden worden.
5.3.2
Communicatie met de RFID lezer
Door de keuze om het RFID deel niet op het ICSP zelf te implementeren, is er sprake van twee totaal onafhankelijke applicaties. Er is dus nood aan een manier om die met elkaar te laten communiceren. Bovendien zou het interessant zijn om meteen een praktijkgerichte oplossing voor dit probleem te vinden, zodat de verwerking van de data op een centrale plaats kan gebeuren en de bedside pc slechts een terminal is.
48
5.3. WERKEN IN EEN OSGI OMGEVING
Daarom is er voor gekozen om gebruik te maken van het Transmission Control Protocol (TCP). Dit is een connectie-geori¨enteerd protocol dat het mogelijk maakt data uit te wisselen over een netwerk. Uitwisselen van informatie wordt gedaan op aangeven van de client, in deze oplossing is dit dus de RFID abstractie. De server, hier het ICSP, ontvangt de data en kan dan op zijn beurt beginnen met de verwerking ervan.
49
50
Hoofdstuk 6
Evaluatie In dit hoofdstuk wordt eerst aangetoond dat de voorgestelde oplossing aan alle functionele vereisten voldoet, daarna worden een aantal prestatiemetingen uitgevoerd en besproken. Het eerste deel betreft dus een overzicht van de functionele vereisten. In het tweede deel wordt dan meer uitleg gegeven over het doel van de metingen en de omstandigheden waarin deze gebeurd zijn. Het derde deel focust op enkele vaststellingen in verband met het inloggen via RFID. Ten slotte worden in het laatste deel enkele metingen met betrekking tot het RBAC deel gepresenteerd en besproken.
6.1
Functionele vereisten
In dit stuk is het de bedoeling aan de hand van enkele screenshots aan te tonen dat de nodige functionaliteiten aanwezig zijn in de oplossing. Tegelijk kan de lezer zich een praktisch beeld vormen van de applicatie.
6.1.1
RFID abstractie
Aangezien het RFID deel op de lezer zelf wordt ge¨ımplementeerd, heeft dat deel ook een eigen interface meegekregen. Figuur 6.1 toont de eenvoudige gebruikersomgeving van zo een RFID lezer. De enige functies die aangeboden worden, zijn het starten en stoppen van de lezer. Onderaan het scherm wordt nog de status weergegeven.
6.1. FUNCTIONELE VEREISTEN
Figuur 6.1: Screenshot van de RFID abstractie
6.1.2
Cosara
De interface van het ICSP, Cosara genaamd, is weergegeven in figuren 6.2 en 6.3. Deze twee figuren zijn gekozen om zo goed als mogelijk de werking van het systeem weer te geven. Het is immers niet mogelijk de dynamische kant van de oplossing aan te tonen in een boek.
Figuur 6.2 geeft de interface weer op het ogenblik dat er een verpleegkundige is ingelogd in het systeem. Elke geactiveerde service wordt weergegeven in een tabblad. Hier is het duidelijk te zien dat deze gebruiker enkel toegang heeft tot de AB Dose service. Verder is op de figuur te zien dat de mogelijkheid bestaat op elk moment uit te loggen.
Figuur 6.2: Screenshot Cosara als een verpleegkundige is ingelogd
Na het actief uitloggen, of op elk ander moment, is het mogelijk om via een drop-down menu een andere gebruiker aan te duiden. Dit is te zien op figuur 6.3. Bij het klikken op een naam van een potenti¨ele gebruiker, wordt, indien nodig, de huidige gebruiker afgemeld en de geselecteerde gebruiker ingelogd. Deze figuur toont bovendien de gebruikersinterface op het moment dat een hoofdarts is ingelogd. Het is onmiddellijk te zien dat deze ook toegang heeft tot de services AB 7/14 en AB Switch IV/PO. Dit moet aantonen dat de services inderdaad op een rolgebaseerde wijze
51
6.2. TESTOPSTELLING
worden geactiveerd.
Figuur 6.3: Screenshot Cosara tijdens het wijzigen van de gebruiker
6.2
Testopstelling
Het is de bedoeling in de rest van dit hoofdstuk na te gaan of de voorgestelde oplossing voldoet aan alle eisen die besproken zijn in de specificaties. Speciale aandacht wordt besteed aan het aspect schaalbaarheid: er wordt naar gestreefd de prestaties van het systeem bij praktisch gebruik zo goed mogelijk in te schatten. Dit is nodig om een gefundamenteerde beslissing te kunnen nemen betreffende de ingebruikname van het systeem.
Daarom worden in dit deel eerst enkele getallen van de dienst IZ die gebruikt worden tijdens de evaluaties voorgesteld en de specificaties van de gebruikte testomgeving meegegeven.
6.2.1
Dienst IZ
Om realistisch cijfermateriaal te kunnen presenteren werd navraag gedaan naar de huidige grootte van de dienst IZ en de mate waarin het ICSP platform gebruikt wordt. Daarnaast werd ge¨ınformeerd naar de visie over de nabije toekomst. Momenteel staan er 56 bedden in de dienst IZ, dit worden er binnen afzienbare tijd 94. Voor het vervolg van dit hoofdstuk zal aangenomen worden dat er momenteel 50 bedden in gebruik zijn en dat dit er al snel 100 zullen zijn. Deze afronding heeft geen invloed op de gepresenteerde cijfers aangezien het overal schattingen betreft en benadrukt nogmaals het feit dat het in dit hoofdstuk om benaderingen gaat. Daarnaast zijn er op het ICSP platform een tiental medische services in gebruik. De ver-
52
6.3. AUTOMATISCH INLOGGEN
wachting is dat dit er al gauw een honderdtal zullen zijn. Er wordt voorzien dat er in de toekomst enkele honderden services gebruikt zullen worden om de zorg van elke pati¨ent te optimaliseren [30].
6.2.2
Testomgeving
Een belangrijk feit betreffende de testen zijn de specificaties van de machine waarop deze gebeurd zijn. Alle testen die in dit hoofdstuk aan bod komen werden uitgevoerd op ´e´en 64-bit computer met quad core processor1 en 6GB RAM geheugen. Deze gegevens kunnen eventueel mee in rekening gebracht worden om de resultaten te kunnen schetsen in een realistisch kader.
6.3
Automatisch inloggen
In de huidige situatie waarbij elke gebruiker die het systeem wenst te gebruiken een gebruikersnaam en wachtwoord dient op te geven, is er bij elke persoon die probeert in te loggen een connectie met de databank nodig. Die connectie is nodig om na te gaan of de opgegeven combinatie van gebruikersnaam en wachtwoord geldig is en toegang tot het ICSP platform verleend moet worden.
Inloggen via RFID vraagt slechts dezelfde connectie met de databank. Het is nu echter de data die gelezen wordt van de tag die gebruikt wordt om bepaalde informatie uit de databank op te halen. Aan de hand van de data op de tag kan dan gecontroleerd worden of het al dan niet om een rechtmatige gebruiker gaat. Het verschil met de huidige inlogprocedure is dat er meer databankbevragingen zullen zijn aangezien er ook bevragingen zullen plaatsvinden voor mogelijke gebruikers die zich niet zullen inloggen, personen die toevallig passeren of onbekende tags.
6.3.1
Schaalbaarheid
Aangezien de schaalbaarheid van het inlogsysteem dus afhangt van het aantal databankbevragingen, moet onderzocht worden hoeveel extra bevragingen het hier betreft. Omdat een 1
Intel(R) Core(TM)2 Quad CPU Q8200 @2.33GHz
53
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
praktische testopstelling niet haalbaar is binnen het kader van deze masterproef kan enkel geargumenteerd worden, waarom dit geen probleem mag zijn.
Zo is het aantal te lezen tags al beperkt door de keuze van de gebruikte RFID lezer. De standaard lezer ondersteunt slechts het lezen van ´e´en tag tegelijk. Dit betekent dat er bijna geen extra bevragingen zullen zijn in vergelijking met de huidige situatie. Om de functionaliteiten van het voorgestelde systeem ten volle te benutten is er echter nood aan een RFID lezer die meerdere tags tegelijk kan lezen, typisch zijn dit dan vier of zestien tags. Deze lezers zullen wel extra bevragingen genereren aangezien alle bewegingen naast de gebruiker ook zullen geregistreerd worden. In theorie kan zo’n lezer dus vier of zestien databankbevragingen per leesoperatie voortbrengen. Dit wil zeggen dat er dagelijks, met bijvoorbeeld elke twee seconden een leesoperatie, per opgestelde RFID lezer zo’n 172 800 of 691 200 databankbevragingen kunnen gebeuren. In een praktische situatie kan er echter wel vanuit gegaan worden dat deze getallen absolute maxima zijn en nooit zullen gehaald worden: mensen blijven gemiddeld langer dan twee seconden binnen het bereik van een lezer, er zijn niet op elk moment tags te lezen, verzorging gebeurt met ´e´en of twee personen en niet met zestien, ’s nachts is er merkelijk minder beweging te detecteren. Al deze factoren samen met de eenvoud van zo’n databankbevraging zorgen ervoor dat mag aangenomen worden dat de voorgestelde inlogprocedure voldoende schaalbaar is.
6.4
Rolgebaseerde activatie van services
In dit stuk wordt dieper ingegaan op de schaalbaarheid van het RBAC deel. De prestaties van dit deel zijn opgedeeld in twee grote stukken: enerzijds de initialisatie, anderzijds het eigenlijke gebruik. In het laatste stuk van dit deel wordt een algemeen besluit gegeven over de prestaties van het RBAC deel en worden enkele praktische scenario’s aan een prestatiemeting onderworpen.
54
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
6.4.1
Initialisatie
De initialisatie van het systeem wordt apart besproken, omdat bij het eerste gebruik van XACML de RPS’en en PPS’en moeten ingeladen worden in het PDP. Daarenboven moet het PEP ge¨ınitialiseerd worden en kan het zijn dat er nog extra bestanden moeten gebouwd worden door het PAP. Dit betekent dus een relatief lange initialisatieperiode.
Figuur 6.4: Initialisatietijd XACML in functie van het aantal rollen
Figuur 6.4 heeft de initialisatietijd weer van de XACML component in functie van het aantal rollen dat ingeladen wordt. De grafiek geeft het gemiddelde weer van twintig onafhankelijke metingen. Bij elk meetpunt is ook de standaardafwijking weergegeven. De rollen die gedefinieerd werden voor de evaluatiemetingen zijn rollen zonder verantwoordelijkheden. De invloed van het aantal toegankelijke services op de initialisatietijd is het onderwerp van de grafiek in figuur 6.5. Voor het bekomen van die grafiek werd het systeem telkens ge¨ınitialiseerd met tien rollen met een vari¨erend aantal services waarvoor de rollen gebruikersrechten hadden.
55
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
Figuur 6.5: Initialisatietijd XACML in functie van het aantal rechten per rol
Het is duidelijk dat het aantal rollen en de omvang van de toegangsrechten een relatief grote invloed hebben op de initialisatietijd van het systeem. Het betreft hier echter een proces dat slechts ´e´enmaal moet uitgevoerd worden: bij een opstart van het systeem. Daarom moeten deze resultaten niet per se als negatief beschouwd worden: eens het systeem is opgestart, hebben de gedane testen geen invloed meer op de prestaties ervan.
Het is wel belangrijk er steeds rekening mee te houden dat het aantal gedefinieerde rollen en de omvang van elk van die rollen een invloed heeft op de prestaties van de voorgestelde oplossing.
6.4.2
Effectief gebruik
Tijdens het bepalen welke services geactiveerd moeten worden, kunnen twee grote stappen onderscheiden worden: eerst moet de rol van de gebruiker opgezocht worden en vervolgens wordt nagegaan voor welke services deze rol toegangsrechten bezit. De prestatiemetingen in dit deel zijn op eenzelfde wijze opgesplitst. Eerst wordt bestudeerd welke invloed het aantal gedefinieerde rollen heeft op de tijd die nodig is de gezochte rol te vinden. Daarna wordt besproken hoeveel requests er maximaal kunnen afgehandeld worden zodat binnen een aanvaardbare tijd een antwoord kan gegeven worden. De derde en laatste parameter die binnen dit deel bestudeerd wordt, is het aantal toegangsrechten per rol.
56
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
Rollen Eens het systeem ge¨ınitialiseerd is, kunnen er requests op het PDP losgelaten worden. Een eerste feit dat onderzocht wordt, is de invloed van het aantal mogelijke rollen op de tijd nodig om een request te beantwoorden. Aangezien, voor het evalueren van een request, steeds eerst de passende RPS moet gevonden worden, heeft dit zeker een invloed op de totale tijd.
Voor dit experiment werden telkens een aantal rollen voorzien in oplopend aantal van tien tot 200. Tijdens elke iteratie werden drie services voorzien waar geen enkele rol toegang tot heeft. Vervolgens werd voor elke combinatie van een rol en een service een request opgesteld en ge¨evalueerd. Na elke iteratie werd de totale tijd nodig voor de evaluaties berekend en uitgemiddeld over het aantal rollen. Deze procedure werd dertig maal herhaald om zo een zinvol gemiddelde te kunnen bekomen.
De resultaten van deze test zijn af te lezen op de grafiek in figuur 6.6. Het is gemakkelijk af te lezen dat het aantal rollen die beschikbaar zijn inderdaad een invloed heeft op de uitvoeringstijd. Het moet wel extra benadrukt worden dat de tijdseenheid gebruikt in de grafiek nanoseconden is. Dit wil dus zeggen dat het evalueren van drie requests bij het gebruik van 200 rollen minder dan 0,03 seconden duurt. Op de grafiek zijn ook telkens de standaardafwijkingen aangeduid.
Figuur 6.6: Tijd nodig voor het zoeken van een rol in functie van het aantal rollen
57
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
De invloed van het aantal gedefinieerde rollen op de tijd nodig om een evaluatie af te handelen is duidelijk te zien. Een kleine stijging in het aantal rollen brengt een relatief veel langere evaluatietijd met zich mee. De verschillen zijn relatief gezien weliswaar groot, het verschil in absolute waarde moet gerelativeerd worden. Het experiment toont aan dat drie requests kunnen ge¨evalueerd in minder dan 0,005 seconden indien er 70 rollen of minder zijn. In het geval het aantal rollen richting 200 gaat, blijft de evaluatietijd nog altijd minder dan 0,03 seconden. Alhoewel dit zes maal de duur is voor slechts drie keer zoveel rollen, kunnen de resultaten toch als positief beschouwd worden.
Requests Een andere factor die de prestaties van het systeem sterk karakteriseren is de tijd nodig om een aantal requests af te handelen. Per gebruiker die inlogt in het systeem moeten een heleboel requests ge¨evalueerd worden door het PDP. Hoe meer inlogacties er dus gebeuren, hoe langer het zal duren om alle requests af te handelen en bijgevolg alle nodige services te activeren. De grafiek in figuur 6.7 geeft de tijd weer voor het afhandelen van nul tot 20 000 requests. Om deze grafiek te bekomen werd een omgeving gecre¨eerd met ´e´en rol en ´e´en service. Bij elke iteratie werden meer requests gegeneerd die ter evaluatie aan het PDP werden aangeboden. Elke request bevatte hetzelfde onderwerp: mag de gedefinieerde rol toegang krijgen tot de beschikbare service. Opnieuw werd dit experiment dertig maal herhaald en het gemiddelde in de grafiek verwerkt. Ook op deze grafiek zijn de standaardafwijkingen aangeduid. Deze zijn echter zo klein dat ze nauwelijks te zien zijn.
De resultaten die in deze grafiek zijn gebundeld, dienen met enige voorzichtigheid afgelezen worden. De gegevens geven weer dat het elf seconden duurt om 20 000 requests af te handelen. Dit zou betekenen dat een gebruiker elf seconden moet wachten vooraleer alle services geactiveerd zijn. Dit is duidelijk meer dan de vijf seconden waarover sprake in de specificaties. 20 000 requests worden tegelijk gegenereerd indien er ´e´en gebruiker inlogt en er 20 000 beschikbare medische services zijn. Zoals eerder gezegd zijn er momenteel slechts een tiental services, in de nabije toekomst een honderdtal. Indien wordt uitgegaan van het slechtst mogelijk scenario waarbij er in de toekomst tegelijk aan 100 bedden iemand inlogt en er 100 medische
58
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
Figuur 6.7: Tijd nodig voor het afhandelen van x requests
services beschikbaar zijn, dan worden 10 000 requests gegenereerd. Op de grafiek kan afgelezen worden dat zoveel requests kunnen afgehandeld worden in minder dan drie seconden. Het is natuurlijk ook mogelijk dat eenzelfde gebruiker verschillende rollen bezit. Zo is het mogelijk dat een arts ook diensthoofd is, of dat verschillende specialisatiedomeinen als verschillende rollen aanzien worden. Dan is het in theorie zeker mogelijk dat er 20 000 requests tegelijk gegenereerd worden. Daarom dat het belang van het woordje tegelijk in deze paragraaf extra benadrukt moet worden. In de praktijk is de kans dat er aan alle 100 bedden tegelijk iemand inlogt bijzonder klein. Stel dat het realistisch is dat er aan twintig bedden tegelijk iemand inlogt en dat er per nieuwe gebruiker 1000 requests worden gegenereerd, wat hoogst waarschijnlijk een bovengrens is, dan zal het elf seconden duren vooraleer elke gebruiker zijn werkomgeving beschikbaar heeft. Indien tegelijk echter ge¨ınterpreteerd wordt als een duurtijd van drie seconden, wat nog steeds een korte periode is om twintig mensen onafhankelijk van elkaar in te loggen, dan zal elke werkomgeving ook binnen de drie seconden gebruiksklaar zijn.
Het is duidelijk dat er in voorgaande paragraaf veel giswerk gebeurd is. Om alle resultaten correct te interpreteren is een observatieperiode binnen de dienst IZ noodzakelijk. Er mag echter wel besloten worden dat de verkregen resultaten met enige voorzichtigheid moeten benaderd worden en dat er tussen zwart en wit zeker en vast een grote grijze zone is.
59
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
Toegangsrechten De laatste variabele parameter die in dit stuk besproken wordt is het aantal toegangsrechten dat elke rol bezit. Er is al aangetoond dat het aantal toegangsrechten van elke rol een invloed heeft op de initialisatietijd. De verwachting is dus dat dit ook hier een aandeel zal hebben in de prestatiemetingen.
Om dit experiment uit te voeren werd gebruik gemaakt van ´e´en rol en ´e´en service, zodat er telkens ´e´en request werd ge¨evalueerd. Het aantal toegangsrechten van de rol werd opnieuw ge¨ıncrementeerd van nul tot 50. De verticale strepen op de grafiek in figuur 6.8 geven, zoals eerder, de standaardafwijkingen weer.
Figuur 6.8: Tijd nodig voor het afhandelen van ´e´en request in functie van het aantal toegangsrechten
Het experiment toont aan dat de evaluatietijd van een request onafhankelijk is van het aantal toegangsrechten van de rol. Er kan weliswaar een licht stijgende trend gezien worden in de grafiek, maar dit is te verwaarlozen gezien de zeer kleine tijden waarover gesproken wordt. Ook de relatief grote standaardafwijkingen kunnen om dezelfde reden genegeerd worden. Elke storing tijdens de testen zal immers een sterk zichtbare invloed hebben op de gepresenteerde resultaten. De oorzaak van deze onverwachte resultaten kan vooral gevonden worden in het feit dat de vergelijking met de experimenten betreffende de initialisatietijd niet op gaat. Tijdens het
60
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
initialiseren moet er immers voor iedere toegangsrecht een nieuwe regel worden toegevoegd aan het XACML bestand. Bovendien worden alle gegenereerde RPS’en en PPS’en weggeschreven zodat herbruik mogelijk is indien het systeem opnieuw moet opgestart worden.
6.4.3
Besluit
Het is duidelijk dat er een aantal parameters zijn die elk hun invloed hebben op de prestaties van het systeem. Hoewel deze invloeden elk apart niet zo groot zijn, is het toch een uitdaging de inlogtijd van elke gebruiker lager te houden dan de voorgestelde vijf seconden. De combinatie van de verschillende invloeden zou immers nefast kunnen zijn voor het volledige systeem.
Verder is het voldoende benadrukt in dit hoofdstuk dat, voorafgaand aan het eventuele overgaan tot implementatie, een observatiemoment noodzakelijk is. Deze observatie moet er toe leiden dat bepaalde parameters veel beter kunnen ingeschat worden en dat het gewicht van elk van hen kan vastgelegd worden.
Ter afsluiting van dit hoofdstuk en om de lezer een idee te geven over de mogelijke praktische uitvoerinstijden, zijn een drietal scenario’s beschreven en in ´e´en grafiek geplaatst.
Er zijn enkele gegevens die over de verschillende scenario’s heen zullen gebruikt worden. Eerst en vooral is dit het aantal gedefinieerde rollen in de dienst IZ. De beschikbare bronnen spreken elkaar hier wat tegen (ongeveer 140 of ongeveer 170), daarom wordt in dit deel met het gemiddelde daarvan gewerkt: 155. Daarnaast moet er een waarde gekozen worden voor het aantal rollen die elke gebruiker bezit. Opnieuw is hier wat giswerk mee gemoeid. Er wordt verder van uitgegaan dat elke gebruiker gemiddeld twee rollen bezit. Ten slotte gaan we ervan uit dat er aan 20% van de bedden tegelijk iemand inlogt.
61
6.4. ROLGEBASEERDE ACTIVATIE VAN SERVICES
Figuur 6.9: Drie verschillende scenario’s
Het eerste scenario is een schatting van de huidige situatie. Hierbij zijn er dus tien medische services en een 50-tal bedden. Dit betekent dat er 200 (= 10 x (20% x 50) x 2) requests moeten ge¨evalueerd worden vooraleer elke gebruiker volledig is ingelogd. Een tweede fase is bijvoorbeeld het moment waarop het aantal medische services van tien tot 100 is uitgebreid. Het aantal bedden blijft ongewijzigd. In dit geval zullen er dus 2000 requests moeten afgehandeld worden. De laatste voorbeeldsituatie is dan het tijdstip waarop er 100 bedden geplaatst zijn binnen de dienst IZ. Deze verhoging van het aantal bedden betekent dat voor dezelfde aangenomen parameters 4000 requests gegenereerd worden.
Op de grafiek in figuur 6.9 kan afgelezen worden dat in de huidige opstelling (scenario 1) de te activeren services bepaald worden in ongeveer 0,1 seconden. Het tweede scenario, dat beschrijft hoe de dienst IZ er binnen afzienbare tijd zou moeten uitzien, genereert tien maal zoveel requests. De grafiek duidt aan dat de tijd nodig om al die requests te evalueren ook tien maal de tijd van het eerste scenario is. Het derde en laatste scenario heeft nood aan nog eens dubbel zoveel requests. De tijd hiervoor nodig stijgt met eenzelfde factor en is iets minder dan twee seconden. Er kan dus besloten worden dat de tijd nodig om het aantal te activeren services te bepalen een lineaire stijging kent.
62
63
Hoofdstuk 7
Conclusie en verder onderzoek Om deze masterproef af te ronden worden in dit hoofdstuk kort enkele conclusies getrokken en een aanzet gegeven om eventueel in de toekomst het onderwerp verder uit te werken.
7.1
Conclusie
Deze masterproef is al van in het begin opgesplitst in twee delen: enerzijds het automatisch inloggen via RFID en anderzijds het rolgebaseerd activeren van medische services. In een applicatie worden de twee weliswaar als ´e´en geheel ervaren en ge¨evalueerd: voor een gebruiker staat inloggen immers gelijk met het klaarzetten van de werkomgeving. Daarom is het belangrijk zowel conclusies te trekken voor de voorgestelde oplossing als een geheel, als voor de twee delen apart.
Inloggen via RFID biedt zeker en vast een aantal interessante mogelijkheden, zeker als dit zoals in deze masterproef op een volledig passieve manier gebeurt. Enkele aspecten zoals hygi¨ene en gebruiksvriendelijkheid behoeven geen betoog. Daarnaast is het een mooie zaak dat de logica die van de RFID lezer een bruikbaar instrument maakt, op de lezer zelf kan ge¨ımplementeerd worden. Dit betekent dat deze verbetering aan het ICSP platform zo goed als geen invloed heeft op de prestaties van het systeem zelf. Minpunten zijn vooral de hoge kostprijs en de nood tot aanpassing van het gedrag van het personeel. Er moet immers een nieuwe attitude groeien op de werkvloer, want wanneer men binnen het bereik van de lezer komt, is het altijd mogelijk dat men als gebruiker wordt ingelogd.
7.2. TOEKOMSTIG WERK
Het at runtime samenstellen van een lijst van services die moeten geactiveerd worden via XACML, is zeker haalbaar. Vooreerst zijn de resultaten uit het evaluatiehoofdstuk zeer hoopgevend naar een effectief gebruik toe. De korte duur die nodig is om op drukke tijden voldoende bedside pc’s tegelijk te ondersteunen, laat toe aan te nemen dat de voorgestelde oplossing voldoende schaalbaar is. Daarnaast laten de voorziene uitbreidingen in de implementatie toe dat het beheer van de rollen en hun verantwoordelijkheden overgelaten wordt aan niet-informatici. Rollen kunnen dankzij deze uitbreiding immers gedefinieerd worden zonder in aanraking te komen met de XACML structuren.
Samen vormen de twee delen een ijzersterk geheel: het ICSP platform is volledig afgeschermd voor ongewenste gebruikers, terwijl een rechtmatige gebruiker geen enkele actie moet ondernemen om toegang te verkrijgen tot het platform, en de gebruikersinterface integraal afgestemd is op de persoonlijke werknoden van elke gebruiker. Deze eigenschappen moeten ervoor zorgen dat het ICSP platform door iedereen als een onmisbaar gebruiksvoorwerp binnen de dienst IZ wordt beschouwd en dat op die manier alle pati¨enten de best mogelijke zorgen toegediend krijgen.
7.2
Toekomstig werk
Vooraleer kan overgegaan worden tot effectieve ingebruikname van de voorgestelde oplossing, moet er nog veel intensiever getest worden: te beginnen met een uitgebreide observatieperiode binnen de dienst IZ zelf. De observaties moeten er toe leiden de noden van het systeem veel gedetailleerder te kunnen beschrijven en enkele parameters al op voorhand te kunnen vastleggen. Bovendien moeten nog de nodige gebruikersinterfaces worden voorzien zodat de methodes die het defini¨eren van rollen vergemakkelijken, toegankelijk zijn voor de gebruikers.
Het grootste nadeel aan het inloggen via RFID, zeker indien het inloggen zoals in deze masterproef passief gebeurt, is de kostprijs van de lezers. Daarom kan het interessant zijn nog onderzoek te verrichten naar alternatieve mogelijkheden voor de inlogprocedure. Voorbeelden van andere technieken zijn infrarood of vingerscan. Dit kan misschien leiden tot een even effici¨ente, maar veel goedkopere oplossing.
64
7.2. TOEKOMSTIG WERK
Indien er in de nabije toekomst een nieuwe versie van de Sun XACML Implementation verschijnt die wel de nieuwste specificaties van XACML ondersteunt, zou dit een groot voordeel zijn om het, zoals hier, in een rolgebaseerde toepassing te gebruiken. Om echter over een implementatie te beschikken die specifiek aan alle noden van het onderwerp van deze masterproef tegemoet komt, is het misschien nuttig een eigen versie te voorzien. Dan kan die bijvoorbeeld meteen afgesteld worden zodat het mogelijk is dat gebruikers meerdere rollen hebben en dat daar op een correcte en prestatievriendelijke manier mee omgegaan wordt.
Ten slotte kan het interessant zijn ook voor de XACML technologie alternatieven te bestuderen. Er bestaan vast en zeker nog andere mechanismen om op een vlotte wijze na te gaan welke van de beschikbare services voor de gebruiker moeten geactiveerd worden. Maar dat zal dan het onderwerp zijn van een andere masterproef.
65
BIBLIOGRAFIE
Bibliografie [1] R. Want RFID Explained: A Primer On Radio Frequency Identification Technologies Morgan & Claypool (2006); ISBN-10: 1598291092 [2] R. van der Togt, E.J. van Lieshout, R. Hensbroek Electromagnetic Interference From Radio Frequency Indentification Inducing Potentially Hazardous Incidents In Critical Care Medical Eqiupment JAMA (2008); 299(24):2884-2890 [3] E.J. van Lieshout Electronic Supplementary Material to the article:“Effects Of Electromagnetic Interference From Radio Frequency IDentification On Critical Care Eqiupment” http://www.amc.nl/?pid=5266 [4] L. Ilegems, P. De Smet PHI DATA, Auto-ID Solutions http://www.phidata.be/nl/ [5] TAGnology RFID GmbH. RFIDwebshop http://www.rfid-webshop.com/ [6] NXP Semiconductors Austria GmbH Styria MIFARE.net http://mifare.net/
66
BIBLIOGRAFIE
[7] Pramari, LLC Rifidi http://www.rifidi.org/ [8] Sybase Inc RFID Anywhere http://www.sybase.com/products/allproductsa-z/rfidanywhere [9] Sybase Inc. Sybase http://www.sybase.com/ [10] OpenPCD.org OpenPICC http://www.openpcd.org/openpicc.0.html [11] C. Wauman Effici¨ent profielbeheer in het Intensieve Zorgen platform Universiteit Gent (2009) [12] OASIS A brief introduction to XACML http://www.oasis-open.org/committees/download.php/2713/Brief_ Introduction_to_XACML.html(2003) [13] B.J. Garback, A.C. Weaver XACML for RBAC and CaDABRA: Constrained Delegation and Attribute-Based Role Assignment [14] A. Anderson XACML Profile for Role Based Access Control (RBAC) http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf(2004) [15] A. Anderson Core and hierarchical role based access control (RBAC) profile of XACML v2.0 http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2. 0-rbac-profile1-spec-os.pdf (2005)
67
BIBLIOGRAFIE
[16] OASIS OASIS http://www.oasis-open.org [17] D.F. Ferraiolo, D.R. Kuhn Role-Based Access Controls 15th National Computer Security Conference (1992), Baltimore MD pg 554-563 [18] OSGi Alliance About the OSGi Alliance http://www.osgi.org/Main/HomePage [19] OSGi Alliance The OSGi Architecture http://www.osgi.org/About/WhatIsOSGi [20] OSGi Alliance OSGi Technology http://www.osgi.org/About/Technology [21] OSGi Alliance How to get Started with OSGi http://www.nljug.org/pages/events/content/jspring_2004/sessions/osgi/ slides.pdf [22] The Apache Software Foundation Apache Felix http://felix.apache.org/site/index.html [23] The Apache Software Foundation The Apache Software Foundation http://www.apache.org/ [24] The Knopflerfish Project knopflerfish http://www.knopflerfish.org/
68
BIBLIOGRAFIE
[25] Makewave AB. Makewave http://www.makewave.com/site.en/ [26] The Eclipse Foundation Equinox http://www.eclipse.org/equinox/ [27] The Eclipse Foundation Explore the Eclipse universe... http://www.eclipse.org/org/ [28] Universitair Ziekenhuis Gent Intensieve Zorg http://www.icu.be [29] W. Van Isterdael Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken [30] S. Van Hoecke, J. Decruyenaere, C. Danneels, K. Taveirne, K. Colpaert, E. Hoste, B. Dhoedt, F. De Turck Service-oriented Subscription Management of Medical Decision Data in the Intensive Care Unit Schattauer (2008); 9(4):364-380
69
LIJST VAN FIGUREN
70
Lijst van figuren
1.1
Chaos in het huidige systeem . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1
Algemene kijk op het systeem . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1
Typische RFID opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Voorbeeld van RFID tag met geheugen . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Overzicht werking XACML [13] . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.4
Toepassing RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.5
OSGi Architectuur [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1
Normale interactie lezer-software . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2
Aangepaste interactie lezer-software . . . . . . . . . . . . . . . . . . . . . . .
26
4.3
Top view architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4
Interface aangeboden door RFIDAbstraction . . . . . . . . . . . . . . . . . .
27
4.5
Fragment van het ICSP platform . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.6
Architectuur van de Cosara bundel . . . . . . . . . . . . . . . . . . . . . . . .
28
4.7
Interface aangeboden door RBAC . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.8
Interface aangeboden door Users . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.9
Interface ICSPService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
LIJST VAN FIGUREN
71
4.10 Sequentiediagram systeemstart . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.11 Sequentiediagram nieuwe gebruiker . . . . . . . . . . . . . . . . . . . . . . . .
33
5.1
RBAC component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.2
XACML component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.1
Screenshot van de RFID abstractie . . . . . . . . . . . . . . . . . . . . . . . .
51
6.2
Screenshot Cosara als een verpleegkundige is ingelogd . . . . . . . . . . . . .
51
6.3
Screenshot Cosara tijdens het wijzigen van de gebruiker . . . . . . . . . . . .
52
6.4
Initialisatietijd XACML in functie van het aantal rollen . . . . . . . . . . . .
55
6.5
Initialisatietijd XACML in functie van het aantal rechten per rol . . . . . . .
56
6.6
Tijd nodig voor het zoeken van een rol in functie van het aantal rollen . . . .
57
6.7
Tijd nodig voor het afhandelen van x requests . . . . . . . . . . . . . . . . . .
59
6.8
Tijd nodig voor het afhandelen van ´e´en request in functie van het aantal toe-
6.9
gangsrechten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Drie verschillende scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
LIJST VAN TABELLEN
72
Lijst van tabellen
3.1
Gebruikte frequenties, bereik en richtprijs [4, 5] . . . . . . . . . . . . . . . . .
10
