Automatisch inloggen via RFID en rolgebaseerde activatie van medische services

Transcriptie

1 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

2

3 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

4 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 één 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.

5 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

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

7 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 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ëvalueerd. Dit platform heeft een service georiënteerde 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ële 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ënte 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

8 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. INTRODUCTION THE 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). Fig. 1. Chaos in the current system II. SOLUTION 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

9 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. 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). 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. IMPLEMENTATION The implementation of the proposed solution has some important features. Two of them are described below. A. PolicyBuilder The PolicyBuilder offers the opportunity to automatically generate the XACML files, needed for a correct evaluation. Existing XACML implementations usually demand plain text policies 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 Policy- Builder 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. FUTURE WORK 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. CONCLUSIONS 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. REFERENCES [1] 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 [2] Universitair Ziekenhuis Gent Intensieve Zorg [3] R. Want RFID Explained: A Primer On Radio Frequency Identification Technologies Morgan & Claypool (2006); ISBN-10: [4] OASIS A brief introduction to XACML Introduction to XACML.html (2003) [5] A. Anderson Core and hierarchical role based access control (RBAC) profile of XACML v2.0 control xacml 2.0 rbac profile1 spec os.pdf(2005) [6] D.F. Ferraiolo, D.R. Kuhn Role-Based Access Controls 15th National Computer Security Conference (1992), Baltimore MD pg [7] OSGi Alliance The OSGi Architecture

10 INHOUDSOPGAVE x Inhoudsopgave 1 Inleiding Probleemstelling Oplossing Use Case Overzicht boek Specificatie Functionele analyse Kwalitatieve vereisten Aanpasbaarheid Beveiliging Gebruiksvriendelijkheid Performantie Schaalbaarheid Technologie RFID Radio Frequency IDentification Een RFID systeem kiezen RFID emulatoren XACML extensible Access Control Markup Language XACML Profile for RBAC

11 INHOUDSOPGAVE xi 3.3 OSGi OSGi Architectuur Implementaties Architectuur Top view RFID Abstractie Het ICSP platform Cosara ABDose, AB7/14, ABSwitch IV/PO DB, API Interactie Systeemstart Nieuwe gebruiker Implementatie Gebruik van RFID Passief inloggen Passief uitloggen RBAC met XACML Standaardgebruik XACML Verantwoordelijkheden RBAC Werken in een OSGi omgeving Beschikbaarheid van services Communicatie met de RFID lezer Evaluatie Functionele vereisten RFID abstractie Cosara

12 INHOUDSOPGAVE xii 6.2 Testopstelling Dienst IZ Testomgeving Automatisch inloggen Schaalbaarheid Rolgebaseerde activatie van services Initialisatie Effectief gebruik Besluit Conclusie en verder onderzoek Conclusie Toekomstig werk Bibliografie 66

13 INHOUDSOPGAVE xiii Gebruikte afkortingen µw Microgolf AB ASF CDC CLDC EMI FIFO GUI HF ICSP IV IZ J2SE LF LIFO MVC OASIS OSGi PAP PDP PEP PIP PO PPS Antibiotica Apache Software Foundation Connected Device Configuration Connected Limited Device Configuration Elektromagnetische Interferentie First In, First Out Graphical User Interface Hoge Frequentie Intensive Care Sercive Platform Intraveneus Intensieve Zorgen Java 2 Platform, Standard Edition Lage Frequentie Last In, First Out Model-View-Controller Organization for the Advancement of Structured Information Standards letterwoord (vroeger: Open Services Gateway initiative) Policy Administration Point Policy Decision Point Policy Enforcement Point Policy Information Point Peroraal Permission PolicySet

14 INHOUDSOPGAVE xiv RAP RBAC RFID RPS SAML TCP UHF XACML XML XSPA Role Assignment Policy (of PolicySet) Role Based Access Control Radio Frequency IDentification Role PolicySet Security Assertion Markup Language Transmission Control Protocol Ultra Hoge Frequentie extensible Access Control Markup Language extensible Markup Language Cross-Enterprise Security and Privacy Authorization

15 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ënten, 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ëvalueerd. 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ënt 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

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

17 1.3. USE CASE 3 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ërarchisch 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 één 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ënt 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:

18 1.4. OVERZICHT BOEK 4 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ën. 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.

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

20 2.2. KWALITATIEVE VEREISTEN 6 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 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.

21 2.2. KWALITATIEVE VEREISTEN Beveiliging Eén 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ënt aangetoond worden dat gebruikers enkel toegang krijgen tot de services die de voor hen toegewezen rol beschikbaar gesteld worden 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 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.

22 2.2. KWALITATIEVE VEREISTEN 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.

23 9 Hoofdstuk 3 Technologie Dit hoofdstuk biedt een overzicht van de gebruikte technologieën 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ëren. 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 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

24 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 à 100 hoge frequentie (HF) 13.56MHz 10cm - 90cm 500 à 1000 ultra hoge frequentie (UHF) 868 tot 956MHz 3m - 10m microgolf (µw) 2.45GHz of 5.8GHz 3m -? Tabel 3.1: Gebruikte frequenties, bereik en richtprijs [4, 5]

25 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 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ëren van onbelangrijk

26 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ëren 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.

27 3.1. RFID 13 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 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ële oplossing om RFID hardware te emuleren. De ianywhere producten bestaan sinds mei 2000 en kennen momenteel meer dan klanten. De onderneming belooft gratis gebruik van hun programma voor ontwikkelaars en onderzoekers na registratie,

28 3.2. XACML 14 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 één profiel meer in detail besproken 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ëren. 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:

29 3.2. XACML 15 ˆ 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ëren 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. bijkomstig nog zes profielen gedefinieerd [11]: In deze standaard zijn Core and hierarchical RBAC is een profiel dat toelaat policies te definiëren 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ërarchisch georganiseerd zijn. Resources kunnen dan gerepresenteerd worden

30 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ërarchie kan dan een policie gespecifieerd worden. Multiple resource is een profiel dat het mogelijk maakt met één response, respectievelijk request, toegang te verlenen, respectievelijk te vragen, tot verschillende resources. Privacy policy beschrijft hoe men privacy policies dient te definiëren. 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.

31 3.2. XACML 17 XSPA XSPA of Cross-Enterprise Security and Privacy Authorization beschrijft hoe security en privacy policies uitgewisseld, consent directives geëvalueerd 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 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ërarchisch 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-

32 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ërarchische 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.

33 3.3. OSGI 19 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 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.

34 3.3. OSGI 20 OSGi is een java-gebaseerde, service georiënteerde 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 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

35 3.3. OSGI 21 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 één 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ëren 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.

36 3.3. OSGI 22 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 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 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 en dateert van 12 oktober 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ële 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.

37 3.3. OSGI 23 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 en gebeurde op 17 september 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.

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

39 4.1. TOP VIEW 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).

40 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

41 4.2. HET ICSP PLATFORM 27 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 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)

42 4.2. HET ICSP PLATFORM 28 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çade, 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çades 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çades