Koppeling van het elektronisch zorgplan van LISTEL aan ehealth

Transcriptie

1 Koppeling van het elektronisch zorgplan van LISTEL aan ehealth L. Drijkoningen a, b, M. Rymen b a Departement IWT, Katholieke Hogeschool Limburg, 3590 Diepenbeek, Belgium b Faculteit Industrieel Ingenieur, Katholieke Hogeschool Limburg, Xios Hogeschool Limburg, KU Leuven, Universiteit Hasselt, 3590 Diepenbeek, Belgium Abstract Tijdens deze bachelorproef is het huidig authenticatieschema van het e-zorgplan van LISTEL aangepast zodat er via de elektronische identiteitskaart ingelogd kan worden. Hiervoor wordt de connectie gelegd met ehealth, de overheidsinstantie die instaat voor de bevordering van de elektronische dienstverlening in de gezondheidszorg. Om deze connectie op te zetten wordt Shibboleth gebruikt, een service die ontworpen is voor Single-Sign on toepassingen. In dit geval werkt deze service aan de hand van een Service provider bij LISTEL en een Identity provider bij ehealth. 1. Introductie Vanuit de vzw LISTEL kwam de vraag om in hun e-zorgplan een integratie te voorzien met het ehealth-platform. Hierdoor kan er in de achterliggende applicatie worden gecontroleerd of een gebruiker gekend is binnen ehealth en wat zijn precieze rol is (dokter, kinesist, ). Voor de gebruiker zelf betekent dit, dat hij of zij kan aanmelden met behulp van een elektronische identiteitskaart (eid). Zodoende hoeft de gebruiker geen gebruikersnaam en paswoord meer moet onthouden. Voor LISTEL zelf betekent dit een verhoogde veiligheid bij het gebruik van het platform. De moeilijkheid in dit project is in de eerste plaats het leggen van de connectie tussen het LISTEL-platform en het ehealth-platform. Hiervoor moet de authorisatiemethode van het LISTELplatform worden aangepast. Moeilijkheid hierbij is dat de gebruikers niet met hun rijksregisternummer in de database staan. Ook zijn er buitenlandse gebruikers, die geen gebruik kunnen maken van een Belgische eid. 2. LISTEL 2.1. Wat is LISTEL [1] LISTEL vzw is het Limburgs provinciaal overlegplatform. Het Samenwerkingsinitiatief Eerste Lijnsgezondheidzorg (SEL), de Geïntegreerde Dienst voor Thuisverzorging (GDT) zorgregio Genk en zorgregio Hasselt hebben opdrachten die vervuld moeten worden. Zij kunnen voor de realisatie van een aantal opdrachten rekenen op de ondersteuning van de Plaatselijke Overlegplatforms (POP). SEL/GDT Genk en Hasselt waken over de kwaliteit van het overleg rond de patiënt waarbij de patiënt en zijn mantelzorger (mz) samen met de betrokken zorg- en hulpverleners (zvl en hvl) de zorgen op elkaar afstemmen.

2 2.2. Situatieschets Momenteel heeft LISTEL een website waarop aangemeld moet worden met gebruikersnaam en wachtwoord. Om een gebruikersnaam te bemachtigen moet er een aanvraag worden ingediend bij LISTEL. 3. ehealth [2] 3.1. Inleiding ehealth is een overheidsinstantie met als doelen om de onderlinge elektronische dienstverlening en informatie-uitwisseling bevorderen en de informatieveiligheid waarborgen. Elke Belg is geregistreerd bij ehealth. Dit wil zeggen dat ook elke Belg kan inloggen. De manier waarop dit gebeurd is door middel van het Belgische eid Deze manier van inloggen staat ook ter beschikking van partners doormiddel van een Shibboleth verbinding. Het proces is heel eenvoudig. De gebruiker gaat naar de pagina om in te loggen, steekt zijn eid in een kaartlezer die met een pc verbonden is en geeft zijn pincode in. Wat hier achter de schermen gebeurt, is een aanvraag van de gebruiker naar de Service Provider. Deze gaat op zijn beurt een authenticatie-aanvraag sturen naar de Identity Provider en krijgt een antwoord terug. Aan de hand van dit antwoord kan de Service Provider beslissen of de gebruiker al dan niet wordt ingelogd Voordeel voor LISTEL Het hele inloggebeuren vindt plaats achter de schermen en zo heeft de gebruiker er geen last van. Ook is het mogelijk om te verifiëren welke functie een gebruiker heeft want op ehealth worden alle dokters, apothekers en burgers bijgehouden. Dit spaart niet alleen een hoop werk uit voor de LISTEL medewerkers, maar zorgt ook voor een verbeterde veiligheid van het platform. Om deze twee redenen is het de ideale manier om een login te maken voor LISTEL. 4. Shibboleth 4.1. Opzet [3][4] Shibboleth is een open-source project en onderdeel van het Shibboleth Consortium [3]. De hoofddoelen van Shibboleth zijn: - Authenticatie binnen federaties. Federaties zijn verenigingen of organisaties met eenzelfde doel (bv. volksgezondheid); - Toegangscontrole op basis van attributen. Deze attributen kunnen gegevens van de gebruiker bevatten (bv. Naam, voornaam, ); - Privacy management; - Een framework voor meerdere federaties; - Een gestandaardiseerde woordenschat voor attribuutwaarden. Het Shibboleth-gebeuren bestaat uit 2 hoofdonderdelen, namelijk: De Service Provider (SP) en de Identity Provider (IDP) Service Provider De Service Provider (SP) is het onderdeel dat bij de partners staat. Wanneer een gebruiker wenst gebruik te maken van Shibboleth dient er een aanvraag verzonden te worden naar de Service Provider. Van hieruit kan de aanvraag verstuurd worden richting de federatie en dus naar de IDP. Deze aanvraag kan volgens verschillende profielen gebeuren zoals: SAML1.1 en SAML2.0. Wanneer de gebruiker toegang probeert te verkrijgen tot een beschermd deel zal er dus een aanvraag worden verzonden naar de SP. Als er geen sessie bestaat wordt het SSO-proces (Single-Sign On) gestart. Nu wordt er een authenticatieaanvraag, samen met de gebruiker, doorgestuurd naar de IDP. Als de gebruiker terug komt met de respons van de IDP zal de respons gevalideerd worden en er zal een sessie aangemaakt worden. Samen met deze sessie worden er ook een reeks attributen meegegeven, die daarna eventueel kunnen gebruikt worden voor lokale login. Een voorbeeld hiervan is een rijksregisternummer. Dat kan als attribuut worden meegegeven. Op basis hiervan kan dan een lokale authenticatie gebeuren. Meer over attributen is te vinden in hoofdstuk 6.3.

3 4.3. Identity Provider De Identity Provider (IDP) wordt voorzien door de federatie. Deze gaat de aanvraag vanuit de SP ontvangen en de gebruiker authentiseren. De IDP staat direct in verbinding met de database van ehealth en kan dus verifiëren of de gebruiker mag inloggen. Wanneer de gebruiker geauthentiseerd is wordt de aanvraag samen met de gebruiker terug gezonden naar de SP SAML [5][6] SAML staat voor Security Assertion Markup Language en is een, op XML gebaseerd, standaard dataformaat voor uitwisseling van authenticatie en autorisatie tussen domeinen. Eenvoudig gezien is SAML een template om te definiëren hoe data verzonden wordt in bepaalde toepassingen. Er zijn twee standaarden die het meest gebruikt worden voor de gegevensoverdracht, namelijk SAML1.1 en SAML2. De voornaamste toepassing van SAML is het vergemakkelijken van Single-Sign-On procedures zoals Shibboleth. Er zijn 3 hoofdonderdelen in het SAML gebeuren, namelijk: de gebruiker, de Service Provider en de Identity Provider. De gebruiker kan een service aanvragen aan de Service Provider, deze kan dan aan de Identity Provider een identity assertion aanvragen en op basis hiervan de service aan de gebruiker toekennen of niet SAML1.0 Dit is de eerste SAML versie die werd aangenomen als standaard door de OASIS (Organization for the Advancement of Structured Information Standards) in Deze standaard vloeide voort uit de opdracht om een XML framework te definiëren voor de uitwisseling van authenticatie en autorisatie informatie SAML1.1 [7] SAML1.1 is een kleine vernieuwing op SAML1.0 die aangenomen werd in De verandering ten opzichte van SAML1.0 zijn echter niet zo groot en bestaan voornamelijk uit kleine aanpassingen die zorgen voor een efficiëntere werking SAML2.0 [8] SAML2.0 is de opvolger van SAML1.1 maar desondanks zijn ze niet onderling compatibel. Enkele grote verschillen tussen SAML1.1 en SAML2.0 zijn: Ondersteuning voor W3C XML encryptie; Vereenvoudigde terminologie; Nieuwe SAML protocollen. (Single Logout) 4.5. Toegangscontrole op basis van attributen Wanneer er aan authenticatie en/of autorisatie wordt gedaan via Shibboleth wordt er ook een lijst met attributen terug gegeven naar de service provider. Deze attributen kunnen dan worden uitgefilterd en opgevangen door de server waarop de website draait om zo, bijvoorbeeld doormiddel van PHP, gebruikt te worden om de gebruiker lokale rechten toe te kennen. 5. Installatie Een eerste zaak waar rekening mee gehouden moet worden, is dat je Shibboleth niet kan installeren op een standaard web hosting pakket. Er is een Virtual Private Server (VPS), een dedicated server, of een eigen onderhouden server voor nodig zodat de nodige programma s geïnstalleerd kunnen worden. Verder dient de verbinding tussen de eigen server en de externe server beveiligd te gebeuren. Daarvoor is nood aan een SSL-certificaat, hetgene zelf kan worden gemaakt, of kan worden aangekocht bij een externe firma Serverinstallatie [9] Deze serverconfiguratie is uitgewerkt voor het besturingssysteem Ubuntu Server LTS. Dit besturingssysteem kan gratis worden gedownload op de website van Ubuntu Ubuntu installatie Het installeren van Ubuntu op zich is vrij gemakkelijk en verloopt volgens de stappen die men kan vinden op de website van Ubuntu

4 Na de installatie van het Ubuntu-systeem kan de server best een volledige upgrade/update worden gegeven. Dit kan door aan te melden op de server met de gekozen gebruikersnaam en wachtwoord en daarna in de commandoterminal de volgende commando s uit te voeren: sudo apt-get update && sudo apt-get dist-upgrade Deze commando s zullen naar een paswoord vragen, dat onzichtbaar is bij het intypen. Na het uitvoeren van de updates dient het systeem opnieuw opgestart te worden. Dit kan met behulp van het commando: sudo reboot Laat hierna het systeem de volledige reboot doorlopen, de server is nu up-to-date Installatie Apache2, MySQL & PHP Het volgende wat dient te gebeuren is de installatie van de Apache2-server, een MySQLmodule en de installatie van de PHP-module. Dit wordt gedaan met behulp van de volgende commando s: sudo apt-get install apache2 php5-mysql libapache2- mod-php5 mysql-server Tijdens de installatie van de MySQL-server zal om een root-paswoord worden gevraagd. Dit kan worden ingesteld naar keuze. Om deze MySQL-installatie te beheren kan gebruik worden gemaakt van PHPMyAdmin. Dit programma kan worden geïnstalleerd met behulp van volgend commando: sudo apt-get install phpmyadmin Firewall Vervolgens dient er ook een firewall geconfigureerd te worden om de server te beschermen tegen aanvallen van buitenaf. Hiervoor wordt Uncomplicated Firewall gebruikt. [10] Standaard staat deze uitgeschakeld, inschakelen wordt gedaan met behulp van het commando: De firewall staat nu actief. Het volgende wat dient te gebeuren is het openen van poorten die wel gebruikt mogen worden van buitenaf. Dit kan met het volgende commando (hier gebruikt voor de SSH-poort): sudo ufw allow 22 De poorten die dienen worden opengezet zijn: 20 (FTP), 22 (SSH), 80 (HTTP) & 443 (HTTPS) SSH SSH wordt geconfigureerd zodat de server van op afstand kan worden beheerd. Hiervoor wordt openssh Server gebruikt. Deze kan worden geïnstalleerd met behulp van het volgende commando: sudo apt-get install openssh-server De server kan nu van op afstand worden beheerd met behulp van SSH. Op een Windowssysteem heb je hiervoor het programma Putty 3 nodig, op Macintosh OS X en Linux is deze mogelijkheid standaard aanwezig in de terminal HTTPS [11] De HTTPS-service, die dient om de communicatie met de server te versleutelen, wordt toegevoegd aan de Apache-server door de module mod_ssl te activeren. Dit kan worden gedaan met behulp van het volgende commando: sudo a2enmod ssl Om een https-connectie te kunnen opzetten is ook een certificaat en een sleutel nodig. De installatiemethode hiervoor is te vinden in hoofdstuk Om de Apache2 te configureren voor SSL dient het volgende commando te worden uitgevoerd: sudo a2ensite default-ssl sudo ufw enable 3 download.html

5 De standard locaties voor de certificaten en de sleutels zijn respectievelijk: /etc/ssl/certs & /etc/ssl/private Deze certificaten en sleutels kunnen ook in een andere map worden geplaatst. Dit kan door de files SSLCertificateFile & SSLCertificateKeyFile van de Apache2-server juist aan te passen. Nu Apache2 juist is geconfigureerd voor HTTPS moet Apache2 opnieuw worden gestart om de nieuwe instellingen toe te passen. Dit kan met het commando: sudo /etc/init.d/apache2 restart SSL-certificaat [12] Een SSL-certificaat zorgt voor de authenticatie van de server en berust op het principe van asymmetrische cryptografie. Dit principe houdt in dat er wordt gebruikgemaakt van 2 aparte sleutels: een public-key om de informatie te coderen, en een private-key om de informatie te decoderen. Een certificaat is een methode om een publickey en andere informatie over een server en de organisatie achter de server te delen. Twee soorten certificaten zijn mogelijk: een zelf geschreven certificaat en een certificaat ondertekend door een Certification Authority (CA). Een dergelijke CA is een betrouwbare, externe firma die confirmeert dat de informatie in het certificaat accuraat is. Voor deze Bachelorproef is er een zelfondertekend certificaat gebruikt. Het probleem hiermee is dat dit in de meeste gevallen niet wordt herkend door browsers als zijnde betrouwbaar. Daarom wordt in productie-omgevingen best gekozen voor een CA-ondertekend certificaat. Een zelf-ondertekend certificaat kan worden gemaakt door volgend commando uit te voeren: openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt Na het ingeven van het wachtwoord zal het certificaat worden gemaakt en opgeslagen in de file server.crt. Het installeren van een zelf-ondertekend of een certificaat door een CA afgeleverd kan met het uitvoeren van volgend commando: sudo cp server.crt /etc/ssl/certs sudo cp server.key /etc/ssl/private Voor de installatie van een CA-certificaat is een goede handleiding beschikbaar op de website van Ubuntu [12] Installatie LISTEL-platform Om het LISTEL-platform over te plaatsen naar de nieuwe VPS zijn de volgende zaken nodig: - Een back-up van de huidige webpagina s die kan worden teruggeplaatst. - Een back-up van de huidige database. Om te starten, moet de back-up van de webpagina s teruggeplaatst worden. Dit moet gebeuren op de VPS in de map /var/www. Deze map wordt door Apache als default-map voor de websitebestanden aanzien. Daarna moet de back-up van de database worden teruggeplaatst. Hiervoor dient men naar PHPMyAdmin te gaan, alwaar een nieuwe database moet worden aangemaakt. In deze database kan dan de back-up van het origineel worden teruggeplaatst. Als laatste dient dan nog de nieuwe connectie tussen de webpagina s en de database worden ingesteld. Dit kan in de file dbgegevens2.inc.php die zich in de map includes bevindt Installatie van Shibboleth [13] Voor de installatie van Shibboleth is een goede handleiding ter beschikking van SWITCH SWITCH Repository SWITCH host een aangepaste versie van de Shibboleth SP voor Ubuntu 12.04LTS. Om deze repository toe te voegen aan de sources waarmee je Sudo Apt-get kan doen, dien je volgende commando s uit te voeren: 1. Downloaden van Repository Key: 4 SWITCH beheert de.ch en.li top-level domeinen voor Zwitserland en Liechtenstein. SWITCH beheert ook de netwerken tussen universiteiten en researchinstellingen in Zwitserland en de connecties naar buitenlandse universiteitsnetwerken.

6 sudo curl -k -O 2. Controle van de Repository Key gpg --with-fingerprint SWITCHaai-swdistrib.asc Deze moet overeenkomen met: 294E 37D E00 FB96 D7AA 26C3 C469 15B Repository Key aan Ubuntu toevoegen: sudo apt-key add SWITCHaai-swdistrib.asc 4. Repositry toevoegen: Maak het bestand /etc/apt/sources.list.d/switchaaiswdistrib.list aan en voeg op de eerste regel: deb precise main toe. 5. Doe een update van de repository: sudo apt-get update Installatie en controle van Shibboleth SP Na het toevoegen van de repository key kan de Shibboleth SP makkelijk worden geïnstalleerd door het uitvoeren van het commando: sudo apt-get install shibboleth Het resultaat hiervan is dat er een aantal mappen worden aangemaakt: - /etc/shibboleth De configuratiemap van Shibboleth - /var/log/shibboleth De map waarin logs worden weggeschreven - /etc/init.d De map waarin de startscripts zich bevinden. De configuratie van Shibboleth op de server kan worden gecontroleerd met volgend commando: sudo shibd -t De laatste lijn van de output moet dan zijn: overall configuration is loadable, check console for non-fatal problems Daarna kan ook best de Apache2-configuratie worden gecontroleerd met het commando: sudo apache2ctl configtest De output moet dan zijn: Syntax OK Als laatste dient de webserver opnieuw worden opgestart waarna de controle op de Shibbolethmodule kan worden gecontroleerd op het adres Er zou dan een returnpage moeten komen met als inhoud: A valid session was not found. Dit bericht toont aan dat de Shibboleth-module is geladen en kan communiceren met het shibdproces. 6. Configuratie Shibboleth ehealth 6.1. Registratie bij ehealth [14] Om de applicatie bij ehealth te registreren moet de file ehealth I.am Registration.doc, te vinden in de bijlagen, worden ingevuld en teruggezonden naar ehealth. Enkel de hoofdstukken 2. Service Provider en 3.1 IDP zijn belangrijk ter registratie van de applicatie. Onder 2. Service provider moeten de volgende gegevens worden ingevuld: Organisatie Name: naam van de applicatie Homepage: Homepage van de applicatie ContactPerson Name: naam van contactpersoon van contactpersoon Sp Authentication EntityID: moet een unieke naam hebben, die zo kan worden geregistreerd bij ehealth om zich kenbaar te maken. X.509 Certificate: dient om berichten naar de IDP te versleutelen. Als je niet meerdere IDP s gebruikt, kan je dit veld leeg laten.

7 Onder 3.1 IDP moet je de gegevens invullen om de relatie tussen de lokale service provider en de externe identity provider op een veilige manier te doen verlopen SP configuration : hierin moet worden aangegeven welk profiel de service provider gebruikt ter uitwisseling van authenticatie- en autorisatiegegevens tussen de service provider en de identity provider. In het geval van de Shibbolethinstallatie, in deze paper beschreven, dient te worden gekozen voor SAML 2.0-POST, omdat de hele Shibboleth-configuratie op dit profiel is gebaseerd Service 1 : hierin dienen nog een aantal parameters worden ingevuld ter registratie van de LISTEL-service bij ehealth. Identification URN: unieke identificatie voor de applicatie, voor in het centraal user-management van ehealth. AssertionConsumerServiceLocation: URL waar de service provider het antwoord van de IDP verwacht. In deze installatie van de vorm: Authentication Wizard: uitzicht bepalen van de login-module. Login Look & Feel: keuze tussen het ehealth-uitzicht of een embedded type. ServiceName (NL): nederlandstalige servicenaam Languages: Talen voor de loginmodule AuthenticationLevel: Keuze van loginmogelijkheden. Dit kan met de eid, de Fedict Token of een paswoord. Skip choice authenticationmethod: als er slechts kan worden ingelogd met behulp van de eid, kan de keuze voor een authenticatiemethode worden overgeslagen. Profile Options: welke personen kunnen zich aanmelden met behulp van de ehealth-idp. Skip choice profile: als alleen burger kan worden gekozen kan je de profielkeuze overslaan. Attribute resolution Certified Attribute URIs: hoeft niet te worden ingevuld Configuratie Shibboleth [15] Apache-configuratie Eerst en vooral moet de Apacheserver kennis hebben van de aanwezigheid van de Shibbolethinstallatie. Ook dient geweten te zijn dat Shibboleth als authenticatiemethode voor de applicatie moet worden gebruikt. Dit kan door het bestand /etc/apache2/mods-available/shib2.conf aan te maken en daar volgende code in te plaatsen: <Location /> AuthType shibboleth ShibRequestSetting requiresession on ShibUseHeaders On require shibboleth </Location> ShibUseHeaders On zorgt ervoor dat de nodige attributen beschikbaar worden gesteld als http-header, waardoor ze voor authenticatie kunnen gebruikt worden. Van zodra dit in orde is dient de Apacheserver te worden herstart door middel van het commando: /etc/init.d/apache2 restart Daarna dient ook de Shibboleth-service te worden herstart, dit kan door middel van het commando: /etc/init.d/shibd restart 6.3. Attributen Als eerste moet daarvoor \etc\shibboleth\attribute-map.xml worden aangepast. De identiteitsinformatie van de gebruiker zal namelijk worden ingepakt in SAML-attributen. Standaard zal een Shibboleth-SP al deze attributen wegfilteren. Zo moet geen ongewenste/onnodige informatie worden verwerkt. Daarom moeten de attributen die nodig zijn worden gespecifieerd in deze configuratiefile. Een volledig overzicht van alle beschikbare attributen is te vinden in [9].

8 Een voorbeeld van een dergelijke attributenlijst: <Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi=" <Attribute id="shib-person-id" name="urn:be:fgov:person:ssin" /> <Attribute name="urn:be:fgov:person:lastname" id="lname" /> </Attributes> <afp:attributefilterpolicygroup xmlns="urn:mace:shibboleth:2.0:afp:mf:basic" xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml" xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic " xmlns:afp="urn:mace:shibboleth:2.0:afp" Deze attributenlijst zorgt ervoor dat het rijksregisternummer en de achternaam van een persoon beschikbaar worden voor de applicatie. Dit kan gemakkelijk worden aangevuld met andere attributen uit [16]. Het id van een dergelijk attribuut is vrij te kiezen. De SP zal deze gebruiken als namen voor de http-headers. De naam van een attribuut wordt ontvangen door de SP vanuit de IDP. Wanneer er geen match is tussen de namen van de attributen, worden ze niet weergegeven. Nameformat is afhankelijk van het SAMLprofiel dat wordt gebruikt in de Shibbolethinstallatie. Als volgende moet de file \etc\shibboleth\attribute-policy.xml worden aangepast. Dit is een file die ervoor zorgt dat waarden uit attributen, die de SP ontvangt van de IDP, worden gefilterd. Dit mag niet worden verwisseld met het filteren van de attributen zelf. De standaard-file van de installatie mag worden leeggemaakt en worden vervangen door de regels die nodig zijn voor het ehealth-platform: xmlns:xsi=" <afp:attributefilterpolicy> <!-- This policy is in effect in all cases. --> <afp:policyrequirementrule xsi:type="any"/> <!-- Catch-all that passes everything else through unmolested. --> <afp:attributerule attributeid="*"> <afp:permitvaluerule xsi:type="any"/> </afp:attributerule> </afp:attributefilterpolicy> </afp:attributefilterpolicygroup> Deze policy-instelling zorgt ervoor dat geen enkele waarde wordt gefilterd uit de ontvangen attributen. Dit door de instelling ANY bij xsi:types en de wildcard bij de attributeid Shibboleth2.xml Als laatste moet ook nog de hoofdconfiguratie file \etc\shibboleth\shibboleth2.xml worden aangepast. Deze file zorgt samen met de Apacheconfiguratie voor een protectie van de web applicatie. De file begint met een opening van <SpConfig> Hier moet meteen in worden meegegeven welk SAML-profiel wenst gebruikt te worden voor de communicatie tussen de service provider en de identity provider. Daarna wordt de sectie <ApplicationDefaults> geopend. Hierin wordt de configuratie met betrekking tot protocol-gedrag, sessie-policy, foutbehandeling en attribuutbehandeling gedefinieerd. Alle aanvragen naar een server met Shibboleth worden behandeld met de instellingen die in deze <ApplicationDefaults> gebeuren. De meeste standaardinstellingen van deze sectie zijn bruikbaar onder de meeste omstandigheden. Naargelang de identity provider waarmee men wil werken, zijn er vaak specifiekere aanpassingen nodig. De volgende sectie in de file is de <Sessions>sectie. Hierin wordt de sessie-behandeling van de applicatie gedefinieerd en kan ook worden meegegeven hoe lang een sessie mag duren en wanneer een time-out optreedt. Hier moet ook de entity-id van de IDP worden

9 opgegeven zodat de service Provider weet waar hij de identity provider kan vinden. De configuratie van het gewenste SAML-profiel wordt ook meegegeven in de opening van de sectie. Na de <Sessions>-sectie zijn er binnen de <ApplicationDefaults>-sectie nog een aantal belangrijke te configureren secties. Een eerste sectie daarbij is de <Errors>-sectie. Deze geeft aan wat er moet gebeuren wanneer er een fout optreedt bij het gebruik van de Service Provider. Daarnaast is er de <MetadataProvider>. Daarin wordt de metadata-locatie twee keer geconfigureerd. Eén keer online, dit wordt gedaan om gemakkelijk updates in de metadatafile te ontvangen. Eén keer is er een lokale locatie, dit is een backup-optie, voor wanneer de online-service niet blijkt te werken. Het reloadinterval duidt aan om de hoeveel tijd de online metadata moet worden vernieuwd. Daarnaast kan ook nog de <AttributeExtractor> worden gevonden. Die regelt hoe de SAMLresponses moeten worden uitgepakt. De <AttributeResolver> regelt de toegang tot andere databronnen om extra identiteitsinformatie, die niet door de IDP wordt meegegeven, op te halen. Ook kan de <AttributeFilter> worden teruggevonden. Deze regelt welke regels moeten worden toegepast voor de filtering van attribuutinformatie. Als laatste onderdeel van <ApplicationDefaults> kan nog de sectie <CredentialResolver> worden gevonden. Deze configureert de publieke sleutel en het certificaat dat de SP gebruikt om zichzelf kenbaar te maken bij de IDP s. Deze sleutel en certificaat houden echter geen verband met de SSL/TLS support van web servers. Dit paar zorgt ervoor dat de verzender van de berichten kan worden gecontroleerd, alsook voor een verificatie van de data-integriteit. Na de <ApplicationDefaults> staan er nog twee secties in de <SPConfig>. Een eerste sectie is de sectie <SecurityPolicyProvider>. Deze file geeft aan welke beveiligingsregels moeten worden in acht genomen bij de informatie-uitwisseling tussen de ehealth-idp en de LISTEL-SP. Een tweede sectie is de <ProtocolProvider>. Deze geeft de plug-in weer die moet worden gebruikt om de content van het <Sessions>-gedeelte uit te kunnen lezen en om te zetten. De basis-configuratie voor Shibboleth die werd gebruikt voor deze bachelorproef is de volgende: <SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config" xmlns:md="urn:oasis:names:tc:saml:2.0:metadata " clockskew="1800"> <ApplicationDefaults entityid=" REMOTE_USER="urn:be:fgov:person:ssin urn:be:fgov:person:professinoal:type-code urn:be:fgov:person:firstname" <Sessions lifetime="28800" timeout="3600" checkaddress="false" relaystate="ss:mem" handlerssl="false"> <SSO entityid=" <!-- Local-only logout. --> <Logout>Local</Logout> <!-- Extension service that generates "approximate" metadata based on SP configuration. --> <Handler type="metadatagenerator" Location="/Metadata" signing="false"/> <!-- Session diagnostic service. --> <Handler type="session" Location="/Session" showattributevalues="true"/> > <!-- JSON feed of discovery information. -- <Handler type="discoveryfeed" Location="/DiscoFeed"/> </Sessions> <!-- Error pages to display to yourself if

10 something goes horribly wrong. --> <Errors logolocation="/shibboleth-sp/logo.jpg" stylesheet="/shibboleth-sp/main.css"/> De belangrijkste aanpassing die hierin dient te gebeuren voor de uiteindelijke integratie van de LISTEL-applicatie, is het aanpassen van de entityid. Deze zorgt namelijk dat de service provider bij de ehealth-idp kan worden herkend. 7. Herwerking LISTEL-loginprocedure <!-- Loads and trusts a metadata file that describes the ehealth IdP and how to communicate with it. --> <MetadataProvider type="xml" uri=" Metadata/SAML " backingfilepath="bpelo-listelcitizen.xml" reloadinterval="180000"/> <!-- Attribute and trust options, mostly these don't need to be changed --> <AttributeExtractor type="xml" validate="true" path="attribute-map.xml"/> <AttributeResolver type="query" subjectmatch="true"/> <AttributeFilter type="xml" validate="true" path="attribute-policy.xml"/> <!-- Your SP generated these credentials. They're used to talk to the ehealth IdP. --> <CredentialResolver type="file" key="spkey.pem" certificate="sp-cert.pem"/> </ApplicationDefaults> <!-- Security policies you shouldn't change, unless you know what you're doing. --> <SecurityPolicyProvider type="xml" validate="true" path="security-policy.xml"/> <!-- Low-level configuration about protocols and bindings available for use. --> <ProtocolProvider type="xml" validate="true" reloadchanges="false" path="protocols.xml"/> </SPConfig> Figure 1 Flowchart login-procedure Wanneer een gebruiker de pagina van LISTEL laadt, zal er gekeken worden of er een Shibbolethsessie aanwezig is. Als dit niet het geval is, betekent dit dat de gebruiker de pagina voor de eerste keer laadt en dus nog moet inloggen. De gebruiker kan nu kiezen tussen het inloggen met zijn/haar eid of inloggen met zijn/haar gebruikersnaam en paswoord. Als er gekozen wordt voor de methode met het eid dan zal Shibboleth inwerking treden en zal de loginprocedure via ehealth met eid gestart worden. Als deze procedure succesvol is, dan wordt de gebruiker teruggezonden naar de beginpagina van LISTEL. Op dit moment bestaat er wel een Shibboleth sessie, dus er zal een andere weg gevolgd worden. Eerst wordt gekeken of het SSID (rijksregisternummer) gekend is in de database van LISTEL. Als dit het geval is betekent dat, dat de gebruiker gekend is bij LISTEL en dat er dus een sessie mag worden aangemaakt, de gebruiker wordt ingelogd en kan gebruik maken van het LISTEL platform. Wanneer de SSID niet gekend is zal er gevraagd worden om de gebruikersnaam en het paswoord van de gebruiker. Als de gebruiker gekend is bij LISTEL en zijn gegevens correct ingeeft, zal het SSID aan zijn gegevens worden toegevoegd. De volgende keer kan hij/zij dus onmiddellijk ingelogd worden zonder eerst zijn/haar gebruikersnaam en paswoord in te geven.

11 Als de gebruiker echter niet gekend is bij LISTEL en bijgevolg dus ook geen gebruikersnaam heeft, zal de gebruiker worden doorverwezen naar de registratiepagina Praktische uitbouw loginprocedure In de PHP-pagina s moet eerst en vooral een herwerking gebeuren van het moment waarop de SQL-query voor de login mag worden uitgevoerd. Daar er nu wordt gereageerd wordt op de POST-actie van het login-formulier, moet er nu bij het laden van de pagina nagaan of er een Shibboleth sessie bestaat. Dit gaat een if-statement zijn dat gaat controleren of er een Shibboleth-sessie-id aanwezig is in de globale $_SERVER variabele. Als hieraan is voldaan, wordt gecontroleerd of een gebruiker in de database aanwezig is met een SQL-query. Dit alles is mogelijk door de bestaande query te nemen en hierin login en paswoord te vervangen door SSID. if(isset($_session["http_shib_session_id"])) { $ssid = $_SESSION["HTTP_SHIB_PERSON_ID"]; function probeerdezessid($tabel, $ssid) { $query = " SELECT FROM ssid, login, paswoord, logindatum, id, $extrakolommen, voornaam, naam, WHERE $tabel actief = 1 AND ssid ='".$ssid."' $where"; $result = mysql_query($query) or die(mysql_error()); if (mysql_num_rows($result)<>0 ) { { $records= mysql_fetch_array($result); $result = mysql_query(" UPDATE $tabel SET logindatum='$huidiguur', ipadres='".$_server['remote_addr']."' WHERE ssid ='".$ssid."'") or die ("Coundn't execute query."); return true; else { return false; if (probeerdezessid("logins", $ssid)) { $ingelogd = true; else if (probeerdezessid("hulpverleners", $ssid)) $ingelogd = true; De records die uit de database worden gehaald kunnen dan worden gebruikt om te controleren of een persoon gekend is binnen LISTEL en om wie het gaat. Deze controle gebeurt ook aan de hand van een if-statement. Wanneer er echter geen sessie is, en de if dus niet wordt uitgevoerd, zal er gewacht worden op de POST van het login-formulier zoals in de huidige versie. De aanpassing die hier moet gebeuren is het updaten van de SSID in de records van de gebruiker.

12 if(isset($_session["http_shib_session_id"]){ $result = mysql_query(" UPDATE $tabel SET logindatum='$huidiguur', ipadres='".$_server['remote_addr']."', ssid='".$_session["http_shib_person_id"]."' WHERE login='".addslashes(htmlspecialchars($_post['logi n']))."' AND paswoord ='".$paswoord."'") or die ("Coundn't execute query."); else{ $result = mysql_query(" UPDATE $tabel SET logindatum='$huidiguur', ipadres='".$_server['remote_addr']."' WHERE login='".addslashes(htmlspecialchars($_post['logi n']))."' AND paswoord ='".$paswoord."'") or die ("Coundn't execute query."); Dankwoord De resultaten van deze bachelorproef kwam tot stand met de hulp van dhr. Kris Aerts (promotor van deze bachelorproef), dhr. Luc Coenegracht (docent ICT op de KHLim), voor de initiële uitleg over de Shibboleth-technologie, dhr. Joep Driesen (ICTS KU Leuven), die hulp bood met de standard-configuratie van Shibboleth. Een bijzonder woordje van dank gaat uit naar dhr. Frederik Libert (Lead Architect ehealth development), die vanuit ehealth nodige informatie en configuratie bezorgde, en Anick, Kristel en Wendy van LISTEL, om te duiden hoe zij de login-procedure voor het LISTEL-platform zagen. Ten slotte ook graag een dankwoordje aan familie en vrienden voor hun steun tijdens deze periode. 8. Conclusie Mits er gebruik kan worden gemaakt van up-todate handleidingen van de kant van ehealth en de contactgegevens van de verantwoordelijke duidelijk gekend/aangegeven zijn, is het mogelijk om deze integratie op een snelle en vlotte manier af te handelen. Echter in deze proef was dat niet het geval. Nadat de VPS in orde was, verliep de configuratie ervan en de installatie van Shibboleth vrij vlot. Echter, de configuratie voor de link met het ehealthplatform verliep een pak stroever. Dit had niet alleen te maken met het feit dat eerst verouderde handleidingen beschikbaar waren en er een lange tijd verstreek voordat de juiste contactpersoon gekend was. Ook het feit dat ehealth net in een overgangsfase zat door een upgrade van hun IDP, speelde parten. Deze roll-out was nog niet gebeurd en dat was ook de reden waarom de nieuwere handleidingen een tijdje op zich lieten wachten.

13 Referenties [1]Beschrijving en structuur LISTEL ( (Toegang 18 februari 2013). [2] Beschrijving ehealth platform ( (Toegang 18 februari 2013). [3] Shibboleth ( (Toegang 18 februari 2013). [4] SWITCH ( ml). (Toegang 18 februari 2013). [13] Shibboleth Service Provider (SP) 2.5 Installation Guide ( H/2.5/sp/deployment/index.html?os=ubuntu). (Toegang 7 februari 2013). [14] Libert, F. (2013). ehealth I.AM Registration. Brussel, België: ehealth. [15] Libert, F. (2013). ehealth I.AM SP Shibboleth. Brussel, België: ehealth. [16] Libert, F. (2013). ehealth I.AM Federation Attributes. Brussel, België: ehealth. [5] SAML ( rkup_language). (Toegang 16 april 2013). [6] SAML2.0 ( (Toegang 16 april 2013). [7] J. Hughes et al., Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1.OASIS Committee Draft, May Document ID sstc-saml-tech-overview-1.1-cd. ( (Toegang 16 april 2013). [8] Difference between SAML 1.1 & 2.0 ( and-1-1). (Toegang 16 april 2013). [9] How to setup a dedicated web server for free ( (Toegang 6 februari 2013). [10] Firewall ( ml). (Toegang 6 februari 2013). [11] HTTPD Apache2 Web Server ( ml). (Toegang 6 februari 2013). [12] Certificates ( es-and-security.html). (Toegang 6 februari 2013).