Transcriptie

1 FGHIJKLKMJNOMMKPJQKGPJRIMISJITJSGUJROGRSJIQVLUMWGOGR FGHIJKVRQJVRQXHIKVYUJZJIJRH[SGLLJR\VRNMKWGIV[G ;%<=<)<%!"#$%&'())* #>!?E#=-C-B-'2,-3456()(3 %=A>B0CD-65 +,-./01/2,-3456()(3 78%#)9:

2

3 FGHIJKLKMJNOMMKPJQKGPJRIMISJITJSGUJROGRSJIQVLUMWGOGR FGHIJKVRQJVRQXHIKVYUJZJIJRH[SGLLJR\VRNMKWGIV[G ;%<=<)<%!"#$%&'())* #>!?E#=-C-B-'2,-3456()(3 %=A>B0CD-65 +,-./01/2,-3456()(3 78%#)9:

4 Voorwoord In dit voorwoord wil ik de mensen bedanken die mij hebben geholpen in het tot stand brengen van mijn masterproef. Zonder hun hulp was dit groot project niet mogelijk geweest. Als eerste wil ik VASCO, het bedrijf waarmee ik samenwerkte voor mijn masterproef, bedanken voor hun vertrouwen. Meer bepaald wil ik ing. Wim Abraham, director of services en mijn externe promotor, in het bijzonder bedanken. Hij heeft ervoor gezorgd dat ik mijn masterproef kon maken samen met VASCO. Wanneer ik in de zomervakantie van 2013 mailde naar VASCO, kreeg ik heel snel antwoord van een enthousiaste mr. Abraham en werd ik uitgenodigd om een gesprek te hebben om zo meer uitleg te kunnen geven over mijn masterproefproject. Hij was duidelijk geïnteresseerd en gemotiveerd om mij te steunen in mijn project. Na een zakelijk maar hartig gesprek werd er mij een projectvoorstel over de engine gedaan. Matthew van Kuyk, senior integration engineer en mijn begeleider in VASCO, was ook bij de besprekingen aan tafel geschoven en gaf meer uitleg over de technische details van het project. Al snel voelde ik mij gepassioneerd om dit project tot een goed einde te brengen. Een tweede dankwoord gaat uit naar mijn begeleider, Matthew, waar ik altijd bij terecht kon als ik een probleem had, al dan niet project gerelateerd. Ondanks zijn drukke internationale agenda, hielp hij mij direct op een zijn leuke manier. Ook om contacten in het bedrijf aan te spreken, toonde Matthew me the way to go. Aangezien Matthew vaak in het buitenland was voor VASCO, werd ik vaak bijgestaan door Anthony Van Roy, junior integration engineer. Als ik een probleem ondervond dat snel opgelost moest geraken of een second opinion wou over mijn ontwerp of implementatie van het project, kon ik altijd rekenen op zijn onvoorwaardelijke steun. Vervolgens wil ik ook Denis Vanhulle, customer support engineer, bedanken. Hij woont in Gent en ik kon samen met hem altijd meerijden van en naar VASCO. Denis heeft mij enorm geholpen zodat ik zelf niet de verplaatsing naar Wemmel moest ondernemen. De leuke en grappige momenten in de auto zal ik niet snel vergeten. Ook de informatie over het reilen en zeilen binnen VASCO werkte vertrouwend. De mensen in VASCO hebben mij opgenomen als een van hun en vaak werd ik zelfs uitgenodigd om eens mee te gaan bowlen. Daarom ik wil alle mensen bedanken die mij dit warme gevoel gegeven hebben. Het heeft zeker bijgedragen tot de voltooiing van deze masterproef. Mijn interne promotor dr. Germán Hurtado mag ik zeker niet vergeten, voor zijn begeleiding bij mijn masterproef. Bij hem kon ik ook altijd terecht met vragen omtrent de masterproef. Als laatste wil mijn familie bedanken voor hun steun en motivatie. Zonder hen was dit project nooit tot stand gekomen. Bedankt. Wim Verdonck, 28 mei 2014 iv

5 Samenvatting Authenticatie wordt steeds belangrijker, omdat meer en meer producten en diensten vereisen dat gebruikers inloggen. Wanneer dit inloggen online gebeurt, houdt dit een zeker risico in. Om identiteitsdiefstal tegen te gaan heeft VASCO verschillende oplossingen bedacht die voorzien in een sterke authenticatie. Klanten die deze producten gebruiken, moeten deze implementeren en integreren in hun omgeving. Vooral voor kleine klanten met minder softwarematige kennis blijkt dit een moeilijkheid te zijn. Daarom wordt in deze masterproef een oplossing uitgewerkt die de integratie van de belangrijkste twee VASCO producten op zich neemt. De oplossing is de authenticatie engine. De bedoeling is dat de klant deze toevoegt bij zijn bestaande code en uitsluitend met deze engine communiceert via de API om authenticatie uit te voeren. De engine is een multi-platform gebaseerde softwareoplossing die kan werken in een Microsoft Windows omgeving alsook in UNIX omgevingen. De gecompileerde code kan in talloze projecten gebruikt worden, zowel in een C++ omgeving als in.net of zelfs Java. Performantie en een hoge configureerbaarheid werden in rekening gebracht bij het ontwerp en de ontwikkeling van de engine. Aanpassingen via codering zijn tot een minimum herleid. De functionaliteit van de engine is uit te breiden en nieuwe authenticatiemethodes kunnen modulair toegevoegd worden. De engine is dus een totaaloplossing voor de integratie van authenticatieprocedures in clientomgevingen. v

6 Abstract Authentication is becoming more and more important, as more products and services require their users to sign in to get access to the functionality they requested. When this signing in happens online, it involves a certain security risk. To prevent identity theft of users, VASCO has come up with different solutions providing strong authentication. Customers who use these VASCO authentication solutions need to implement and integrate them in their own environment. Smaller businesses that do not have the in-house knowledge in the field of integrating software are experiencing difficulties which act as a threshold to choose for these authentication solutions. Because of this issue, this master thesis offers an authentication engine that takes the integration needs away from customers who want to use the two most important VASCO authentication solutions. The customer simply needs to add this engine to his existing project and run all authentication requests by this engine. The engine offers an API, enabling the customer to call and use the entire engine s functionality. The engine is a multi-platform based software solution which is capable of functioning in a Microsoft Windows environment as on different UNIX platforms. The compiled code can be used in projects in multiple software environments such as the.net platform and even the Java environment. Performance and a high level of configurability have been taken into account while designing and developing the engine. Code modification has been reduced to a minimum. The engine s functionality is also extendible and new authentication methods can be added as a plugin. The engine is therefore the solution for integrations of authentication procedures in client environments. vi

7 Inhoudstafel Voorwoord... iv Samenvatting... v Abstract... vi Inhoudstafel... vii Lijst van Afbeeldingen... x Lijst van Codefragmenten... xi Lijst gebruikte afkortingen... xii Inleiding... 1 Deel 1: Huidige situatie en beschrijving componenten... 2 Hoofdstuk 1 Authenticatie en -methodes Verschil tussen authenticatie en autorisatie Two-factor authenticatie Bedreigingen op het Internet Noodzaak Het Two-Factor Principe VASCO s authenticatiesystemen OTP DIGIPASS Validatie van een OTP Tijdsgebaseerde OTP Eventgebasseerde OTP Two-factor functionaliteit Response Only authenticatiemethode Challenge/Response authenticatiemethodes One-Step challenge/response authenticatiemethode Two-step challenge/response authenticatiemethode Hoofdstuk 2 Entiteiten IDENTIKEY Authentication Server Beschrijving Protocollen SOAP RADIUS SEAL vii

8 2.1.3 Authenticatieproces Stap 1: identificeren van de client Stap 2: identificeren van de policy Stap 3: opzoeken en controleren van de gebruiker Stap 4: Lokale authenticatie Stap 5: back-end authenticatie Stap 6: generatie van een challenge Stap 7: finaliseren Samenvatting DIGIPASS as a Service Beschrijving Gebruikersmethode en authenticatieproces Deel 2: authenticatie engine Hoofdstuk 3 Architectuur engine Ontwerp Eisen Analyse Authenticatie bouwstenen Authenticators IAS DPS Modules en controllers SOAP REST Methodes User interaction Authenticatie Requests Responses Testing Tests Scenario s Results Reports Managers Configuration manager Testing manager Factory Engine API en engine core Hoofdstuk 4 Authenticatieprocedures van de engine Standard methods IAS authenticatie using SOAP Authenticate functie SOAP controller DPS authenticatie using REST Authenticate functie REST controller viii

9 4.2 Custom modules Eigen module Voorbeeld van een custom module Hoofdstuk 5 Integratie van de engine C++ integratie C# integratie Java integratie Hoofdstuk 6 Mogelijke uitbreidingen SSL Multi-threading Encryptie van het configuratiebestand Schedule voor testing Conclusie Bibliografie Interne trainingen (Vasco Data Security NV/SA SEAL trainingen, 79 Boeken Online documentatie en open source code projecten Appendix A: IDENTIKEY Authentication Server Appendix B: DIGIPASS as a Service Appendix C: Engine API Appendix D: Engine documentatie Appendix E: certificaten behaald tijdens de training ix

10 Lijst van Afbeeldingen Figuur 1.1: Bedreigingen op het Internet 5 Figuur 1.2: Authenticatiefactoren 6 Figuur 1.3: Two-factor betalingssysteem 7 Figuur 1.4: DIGIPASS authenticators 8 Figuur 1.5: OTP met DIGIPASS authenticatie: sleutel, tijd en algoritme (3DES, AES) zijn de drie bouwstenen 9 Figuur 1.6: Eerste keer OTP valideren 11 Figuur 1.7: Volgende keren OTP valideren 12 Figuur 1.8: Validatie OTP eventgebasseerd 13 Figuur 1.9: Response only authenticatie 14 Figuur 1.10: Challenge/response One-step authenticatiemethode, met SERVER CHALLENGE 15 Figuur 1.11: Challenge/response Two-step authenticatiemethode 17 Figuur 2.1: Response only authenticatie via soapui 19 Figuur 2.2: Lokale authenticatie 21 Figuur 2.3: Authenticatie met back-end 22 Figuur 2.4: Authenticatie met proxy en IAS als back-end 22 Figuur 2.5: Voorbeelden van producten gelinkt met dp+ (DIGIPASSPLUS) en DIGIPASS 24 Figuur 2.6: DPS authenticatie 25 Figuur 2.7: Authenticatie via REST 26 Figuur 3.1: Use case diagram voor authenticatie 30 Figuur 3.2: Use case diagram voor testen van de engine 31 Figuur 3.3: Class diagram van de authenticators 34 Figuur 3.4: Class diagram van de modules 37 Figuur 3.5: Class diagram van Method 39 Figuur 3.6: Class diagram van Message met afgeleide klassen Request en Response 40 Figuur 3.7: Class diagram van de testen 45 Figuur 3.8: Class diagram van Scenario 46 Figuur 3.9: Class diagram van Result 47 Figuur 3.10: Class diagram van reports 48 Figuur 3.11: UML klassendiagram authenticatie engine 55 Figuur 4.1: One Step gedeelte van de authenticate methode 59 Figuur 4.2: Two Step gedeelte van de authenticate methode 59 x

11 Lijst van Codefragmenten Codefragment 3.1: Authenticator in XML configuratiebestand 32 Codefragment 3.2: IAS authenticator voor Two Step authenticatie 34 Codefragment 3.3: DPS authenticator 35 Codefragment 3.4: de SOAP (bovenaan) en REST (onderaan) module 36 Codefragment 3.5: Declaratie authenticate functie in de SOAP module 36 Codefragment 3.6: Methode m11 met authenticator en module gekoppeld 38 Codefragment 3.7: IASAuthenticatorSTATICPASSWORDID1 authenticator 39 Codefragment 3.8: Engine API functie om een request aan te maken 41 Codefragment 3.9: Client authenticatie aan de hand van methode m22 42 Codefragment 3.10: LOAD test waarbij 20 iteraties uitgevoerd worden via One Step authenticatie 43 Codefragment 3.11: FUNCTION test via Response Only (OTPauth in dit geval) 43 Codefragment 3.12: FUNCTION test via Response Only met static password 44 Codefragment 3.13: LOAD test via One Step authenticatie 44 Codefragment 3.14: Voorbeeld van een scenario 45 Codefragment 3.15: Uitvoeren van een test of scenario en bijhorend report opvragen 48 Codefragment 3.16: Structuur setupmanager van configuration manager 50 Codefragment 3.17: SetFactory methode van de configuration manager 52 Codefragment 3.18: Opslaan van de engine configuratie (bovenaan) en het instellen van de XML (onderaan) 52 Codefragment 3.19: Aanmaak van een custom module, samen met de controller voor custom modules 53 Codefragment 4.1: Functie declaratie authenticate soap module 57 Codefragment 4.2: Begin authenticate en check availability 57 Codefragment 4.3: Implementatie response only authenticatiemethode voor SOAP module 58 Codefragment 4.4: PerformOTPauthentication van SOAP controller 60 Codefragment 4.5: Vervolg performotpauthentication van SOAP controller 61 Codefragment 4.6: Response only implementatie bij REST module in authenticate functie 63 Codefragment 4.7: Implementatie authenticatie rest controller 64 Codefragment 4.8: Header bestand van een custom module 65 Codefragment 4.9: Codebestand van de custom module 66 Codefragment 4.10: Headerbestand ControllerForCustomModules.h 67 Codefragment 4.11: Codebestand ControllerForCustomModules.cpp 67 Codefragment 4.12: Translator.h 68 Codefragment 4.13: CustomEnums.h 68 Codefragment 5.1: Integratie C++ 70 Codefragment 5.2: Codebestand example.cpp 71 Codefragment 5.3: headerbestand example.h 71 Codefragment 5.4: Integratie C# uit runme.cs 72 Codefragment 5.5: Java integratie runme.java 73 Codefragment 5.6: Java integratie runme.java (vervolg) 74 xi

12 Lijst gebruikte afkortingen 3DES AES API DNS IAS IP JVM MITM aanval OTP PIN-code RADIUS REST SaaS SDK SAML SEAL SOAP XML Triple Data Encryption Standard Advanced Encryption Standard Application Programming Interface Domain Name System IDENTIKEY Authentication Server Internet Protocol Java Virtual Machine Man In The Middle (aanval) One Time Password Personal Identification Number code Remote Authentication Dial In User Service Representational state transfer Software As A Service Software Development Kit Security Assertion Markup Language Security Experts and Academy e-learning Simple Object Access Protocol extendible Markup Language xii

13 Inleiding Authenticatie wordt steeds belangrijker in de huidige maatschappij, naarmate meer producten en diensten online worden aangeboden. Gebruikers moeten hun identiteit bewijzen tegenover een dienst of product opdat ze het zouden kunnen gebruiken. Een bekend voorbeeld is PC-banking. Spijtig genoeg zijn er individuen of organisaties die zich bezighouden met identiteitsdiefstal. Ze hopen toegang te verkrijgen tot een systeem, zich voordoend als iemand anders. VASCO probeert deze trend een halt toe te roepen en heeft enkele producten en diensten op de markt die dit tegengaan. Een overzicht van de verschillende authenticatieproducten die betrekking hebben tot deze masterproef worden in het eerste deel van deze scriptie uitgelegd. Het is noodzakelijk voor de lezer van deze scriptie om enkele belangrijke principes over de werking van deze producten te kennen. Met deze kennis kan de lezer vervolgens deel 2 van deze scriptie aanvangen. Klanten die VASCO producten gebruiken, moeten deze implementeren in hard- en software, afhankelijk van het product. Voor twee producten, een authenticatie-softwarepakket dat draait op een server van de klant, en een authenticatieservice, die de klant online kan gebruiken, is integratie vereist in software. Deze twee producten worden vaak samen gebruikt en worden ook in dezelfde clientomgeving geïmplementeerd. Echter, wegens de complexiteit van de integratie in een bestaande omgeving, vormt dit een drempel voor nieuwe klanten of klanten met een minder uitgebreide programmeerkennis. Daarom is er gekozen om een softwarepakket te ontwerpen en te ontwikkelen die helpt bij de integratie van deze twee producten in bestaande clientomgevingen. De authenticatie engine, het onderwerp van deze masterproef en beschreven in het tweede gedeelte van deze scriptie, is een softwarepakket, ontworpen en ontwikkeld in C++ met als functie de integratie van de twee producten hierboven vermeld op zich te nemen. Op deze manier hoeft de klant zich niet meer te bekommeren over implementatiedetails want deze worden achter de schermen geregeld door de engine. De engine is een multi-platform gebaseerde software die op Microsoft Windows en UNIX platformen kan werken. De engine kan gecompileerd worden als een stand-alone software maar kan ook als een library gecompileerd worden, waardoor het kan ingezet worden in allerlei integraties. Dit beperkt zich niet tot enkel C++ omgevingen, maar ook.net en zelfs Java code kan van de engine gebruik maken. Zoals zal blijken kan ook extra functionaliteit aan de engine toegevoegd worden, indien dit later nodig zou zijn. Ik hoop dat deze masterproef u nieuwe inzichten mag verschaffen over authenticatie en dat u geboeid wordt door de vernuftige procedures die hiermee gepaard gaan. Veel leesplezier gewenst! 1

14 Deel 1: Huidige situatie en beschrijving componenten

15 Hoofdstuk 1 Authenticatie en -methodes 1.1 Verschil tussen authenticatie en autorisatie Voor velen zijn authenticatie en autorisatie gelijkwaardig. Hoewel deze beide begrippen vaak samen voorkomen, hebben ze toch een verschillende betekenis. Deze masterproef gaat over authenticatie en daarom is het nuttig het verschil eerst duidelijk te maken. Authenticatie is het proces dat een gebruiker, klant hierna vernoemd, ondergaat om via een identiteitsbewijs toegelaten te worden tot een systeem. Autorisatie is het proces dat de klant ondergaat om bepaalde diensten en bronnen te mogen gebruiken. Een klein voorbeeld situeert beide begrippen. Om bestanden op een fileserver te bekijken, moet de gebruiker zich eerst aanmelden. Dit is het authenticatieproces. Op basis van geldige inloggegevens, zijnde een gebruikersnaam en wachtwoord in dit voorbeeld, wordt door de server beslist of de gebruiker toegelaten is op de fileserver. Nu moet nog bepaald worden welke bestanden de gebruiker kan zien en of de gebruiker bestanden kan aanmaken, aanpassen of verwijderen. Hiervoor is een autorisatieproces nodig. Samenvattend kan er dus gesteld worden dat authenticatie gaat over het bewijzen van een identiteit op een manier zodat de server weet dat de gebruiker effectief diegene is die hij beweert te zijn, terwijl autorisatie gaat over het toegelaten zijn om bepaalde bronnen of diensten te gebruiken. Authenticatie lijkt een eenvoudig proces, maar dit is het allerminst. De bedoeling is dat de server waartoe de gebruiker zich authentiseert effectief weet dat de gebruiker is wie hij beweert te zijn. Een authenticatieproces kan namelijk ondermijnd worden door hackers. De hacker probeert zich hier te authentiseren met een andere identiteit. Om deze aanvallen tegen te gaan, zijn allerlei technologieën en oplossingen ontwikkeld. 1.2 Two-factor authenticatie Bedreigingen op het Internet Het Internet is een globaal wijd verspreid medium dat allerlei toepassingen heeft. Omdat steeds meer mensen toegang hebben tot het Internet, worden ook meer toepassingen ontwikkeld waarbij 3

16 men zich moet authentiseren, bijvoorbeeld s online raadplegen in een browser. Spijtig genoeg is niet iedereen ervan bewust dat er ook mensen zijn met minder goede bedoelingen, die proberen gegevens te bekomen via accounts van anderen. Deze personen worden algemeen omschreven als hackers. Ze proberen iemands online identiteit te stelen, door bijvoorbeeld zich te authentiseren met gegevens van die bepaalde persoon. Een paar voorbeelden van gegevens die hackers proberen te bekomen zijn gebruikersnamen, wachtwoorden en kredietkaartgegevens. In sommige gevallen is er een georganiseerde bende die zich met dergelijke malafide praktijken bezig houdt en is dit big business voor hen. Om een goede beveiliging te voorzien is het belangrijk om een achtergrond te hebben over de verschillende manieren hoe hackers gevoelige gegevens proberen te bekomen. Volgende methodes zijn de meest voorkomende. Ze worden voorgesteld in Figuur 1.1. Phishing: Dit is een techniek waarbij de hacker bijvoorbeeld een namaakt, dit vervolgens stuurt naar zijn slachtoffers en hierbij vraagt om via een link in de zich te authentiseren op een website. Het slachtoffer merkt niets en denkt dat hij zich authentiseert op de echte website. Ondertussen worden de gegevens bekomen van het slachtoffer. De hacker vist als het ware naar het gegevens van het slachtoffer met een e- mail als lokaas. MITM: Dit staat voor Man in the middle, en is een gekende techniek. De hacker stelt zich op tussen zijn slachtoffer en de organisatie waartoe dit slachtoffer zich authentiseert. De hacker bekomt op deze manier de gegevens van het slachtoffer en stuurt deze door naar de naar de organisatie. De hacker heeft de gegevens dus afgetapt. Trojan Horse: Dit is software die op de computer van het slachtoffer geactiveerd is en gegevens opvangt wanneer het slachtoffer zich authentiseert. De opgevangen gegevens kunnen dan naar de hacker gestuurd worden achter de schermen. Pharming: Dit is een techniek die verwant is met phishing. Bij pharming wordt het slachtoffer door de hacker als het ware gedwongen om zich te authentiseren op bijvoorbeeld een nagemaakte website. Op deze manier verkrijgt de hacker ook de gegevens. Het verschil met phishing is dat hier niet actief gevist wordt, maar dat het slachtoffer op een passieve manier benaderd wordt. 4

17 Figuur 1.1: Bedreigingen op het Internet Bij al deze soort aanvallen is het belangrijk om te beseffen dat het slachtoffer niets merkt wanneer er een hacker actief is om de gegevens te ontfutselen. Om te voorkomen dat de hacker hierin effectief slaagt, moet de gebruiker voorzien in sterkere authenticatie. Een manier van een dergelijke sterke authenticatie werkt volgens het Two-Factor principe Noodzaak Het authenticatieproces waarmee de meerderheid van computergebruikers vertrouwd is, verwacht twee parameters, namelijk een gebruikersnaam en een wachtwoord. Beiden zijn geregistreerd in het systeem en wanneer bij een authenticatieproces één van deze parameters niet correct is, faalt het authenticatieproces. Er kan opgemerkt worden dat de gebruikersnaam en het bijhorende wachtwoord niet veranderen. Bij elke authenticatie moet dus dezelfde informatie gebruikt worden. Indien in het systeem beslist wordt om de gebruikersnaam, het wachtwoord of beiden te veranderen, moeten natuurlijk deze vernieuwde inloggegevens gebruikt worden. Bij een standaard authenticatie worden dus telkens dezelfde gebruikersnaam en hetzelfde wachtwoord gebruikt. Dit houdt een beveiligingsrisico in. Aangezien bij een standaard authenticatie telkens dezelfde gegevens gebruikt worden, zouden hackers op het volgende idee kunnen komen. Als men voldoende keer zou proberen om een authenticatie uit te voeren, telkens met andere inloggegevens, dan zou het authenticatieproces uiteindelijk wel eens kunnen lukken. Om dit tegen te gaan, worden tegenwoordig al maatregelen genomen op de meeste systemen, zoals het blokkeren van een gebruiker na herhaaldelijk een verkeerde authenticatie te hebben uitgevoerd. Hoewel dit al een oplossing biedt, kan er nog op een ander gebied extra beveiliging ingebouwd worden. Als de gebruiker meer gegevens zou moeten ingegeven bij een authenticatie, wordt het moeilijker voor een hacker om een authenticatie te simuleren. Die extra gegevens moeten typerend zijn voor de gebruiker, zoals een duimafdruk. De gebruiker moet vanzelfsprekend op een eenvoudige manier een authenticatie kunnen uitvoeren en mag hij dus niet belast worden met veel extra gegevens die hij moet ingeven. Bijvoorbeeld als een gebruiker zijn wil controleren, zou het omslachtig zijn om naast een gebruikersnaam en wachtwoord ook nog een duimafdruk te laten nemen en een oogscan te laten uitvoeren, dit telkens 5

18 opnieuw bij elke authenticatieaanvraag. Gelukkig zijn er gebruiksvriendelijkere methodes bedacht, bijvoorbeeld in de vorm van een kaart met een chip Het Two-Factor Principe Authenticatie waarbij meerdere authenticatiefactoren gebruikt worden, wordt sterke authenticatie genoemd. De drie authenticatiefactoren zijn de volgende: iets wat je weet, iets wat je hebt en iets wat je bent. Dit wordt visueel gemaakt door middel van Figuur 1.2. Figuur 1.2: Authenticatiefactoren Een PIN-code (Personal Identification Number) is iets wat de gebruiker weet maar dat anderen niet weten. Een kaart is een uniek object dat alleen een bepaalde gebruiker bezit. Hierbij kan men denken aan bijvoorbeeld een bankkaart. Een DIGIPASS (zie verder) kan ook als uniek object gebruikt worden. De derde factor is iets wat je bent. Dit is iets uniek dat één bepaalde gebruiker kenmerkt, zoals een duimafdruk. De meest verspreide manier is de One-Factor authenticatie, waarbij slechts één authenticatiefactor gebruikt wordt, namelijk een geheim wachtwoord dat niet verandert. Wanneer twee factoren gecombineerd worden, spreekt men van Two-Factor authenticatie. Zonder er bij stil te staan gebruiken vele mensen dit systeem dagelijks. Het is zodanig ingeburgerd zodat de meesten er niet meer bij stil staan. Volgende paragraaf verduidelijkt met behulp van een voorbeeld. Als een gebruiker met zijn account een betaling wil uitvoeren, dan heeft hij zijn eigen bankkaart nodig. Dit is de bezittende factor. Natuurlijk moet de gebruiker ook de code weten van zijn kaart, wanneer hij een betaling in een betalingsterminal uitvoert. Dit is de wetende factor. Op deze manier heeft de gebruiker zijn identiteit bewezen aan het betalingssysteem en indien deze gelukt is, zal de betaling effectief kunnen doorgaan. Er zijn dus twee factoren die moeten voorzien worden door de gebruiker: de wetende factor en de bezittende factor, respectievelijk een PIN-code van de bankkaart en de bankkaart. Figuur 1.3 toont de 2 authenticatiefactoren in het voorbeeld. 6

19 Figuur 1.3: Two-factor betalingssysteem In het ideale geval doet er echter een Three-factor authenticatie zich voor. Hiervoor is nog een derde factor vereist, namelijk iets wat de gebruiker kenmerkt. Een Three-factor authenticatie is dus nog veiliger, maar aangezien de gebruiksvriendelijkheid ook van belang is, wordt dit in praktijk niet veel gebruikt. 1.3 VASCO s authenticatiesystemen VASCO 1 biedt authenticatieproducten aan die werken op basis van het Two-factor authenticatieprincipe en OTP s. Een OTP is een One Time Password, een wachtwoord dat slechts eenmalig bruikbaar is, gegenereerd door een DIGIPASS. De DIGIPASS is een uniek object dat de gebruiker bezit. De Two-factor authenticatiefactoren zijn dus de wetende en de bezittende factoren, respectievelijk een wachtwoord en de DIGIPASS OTP Een OTP (One Time Password) is een cijfercode, gegenereerd door een VASCO DIGIPASS, die geldt als wachtwoord bij een authenticatie. Eventueel kan deze cijfercode nog gecombineerd worden met een PIN-code. In dit geval is het wachtwoord dus de PIN-code samen met de OTP. Een speciale eigenschap van een OTP is dat dit een éénmalige cijfercode is. Telkens wanneer een OTP opgevraagd wordt, zal dit een andere cijfercode opleveren, elke 32 seconden. De OTP kan slechts één keer gebruikt worden en bij herhaaldelijke aanvragen wordt er om de 32 seconden een nieuw OTP gegenereerd. Wat het verband is tussen deze OTP en de DIGIPASS wordt in de volgende paragraaf uitgelegd. 1 Meer informatie is te vinden op 7

20 1.3.2 DIGIPASS Een DIGIPASS is een object, uniek gelinkt aan een gebruiker. De DIGIPASS kan uitgevoerd zijn in hardware of in software. De softwareversie werkt volledig gelijkaardig als de hardwareversie. Het verschil is dat de gebruiker bij de softwareversie zelf moet voorzien in hardware, bijvoorbeeld een smartphone. Een hardwareversie van een DIGIPASS kan je zien in het bovenste gedeelte van figuur 1.4, namelijk DIGIPASS 260 en DIGIPASS GO8. De softwareversies zijn de figuur zijn de DIGIPASS for Mobile en de Virtual DIGIPASS. Afhankelijk van de authenticatietoepassing wordt een keuze gemaakt tussen een soft- of hardwareversie. Hardware-digipassen bestaan in verschillende uitvoeringen. Er zijn digipassen die een OTP genereren na een druk op de knop. Andere digipassen hebben cijfertoetsen. Nog een andere versie is er in de vorm van de kaartlezer met cijfertoetsen. Deze kaartlezer-digipassen zijn alom tegenwoordig en wijd verspreid bij het brede publiek. Als men vandaag bijvoorbeeld PC-banking gebruikt, moet men inloggen in de bankapplicatie aan de hand van een gebruikersnaam, die men verkrijgt van de bank, en een code, die na een kleine procedure door de DIGIPASS, kaartlezer in dit geval, gegenereerd wordt. Figuur 1.4: DIGIPASS authenticators 2 De OTP die de DIGPASS genereert, is onderhevig aan bepaalde eisen, zoals bepaald door VASCO. Voor de creatie van deze OTP zijn drie bouwstenen vereist: een encryptie algoritme, een geheime sleutel en een variabele parameter, bijvoorbeeld de tijd. Als variabele parameter kan ook een event 2 De Virtual DIGIPASS is een SMS gebaseerde DIGIPASS. DIGIPASS for Mobile is een app die de DIGIPASS-functionaliteit aanbiedt op smartphones. De twee bovenste digipassen zijn hardware-digipassen. 8

21 gebruikt worden, maar in de Enterprise business worden tijd gebaseerde digipassen gebruikt. In Sectie wordt hier verder op ingegaan. Het encryptie algoritme is vereist om te voorzien in encodering van het generatieproces van de OTP. De DIGIPASS ondersteunt zowel 3DES als AES. Deze worden gebruikt omdat ze open standards zijn en een bewezen effectiviteit hebben. De geheime sleutel zit ingebakken in de DIGIPASS. Deze sleutel is uniek per DIGIPASS en heeft een belangrijke rol in het creatieproces van de OTP. De variabele factor tijd wordt geïmplementeerd in de DIGIPASS in de vorm van een real-time klok. Deze is wereldwijd dezelfde en staat ingesteld op de Greenwich Mean Time. Dit initialisatieproces gebeurt tijdens de productie van de DIGIPASS. Bij eventgebasseerde digipassen wordt een teller op nul gezet. Deze teller, de eventcounter, telt het aantal keer dat een OTP werd aangevraagd. Dit is dus het aantal keer dat op de knop van de DIGIPASS gedrukt werd. Wanneer de gebruiker zijn DIGIPASS gebruikt voor een authenticatie is het belangrijk dat deze DIGIPASS en de authentiserende entiteit, een server of service, elkaar verstaan. Daarom is het noodzakelijk dat deze server of service over dezelfde drie bouwstenen beschikt zoals de DIGIPASS, zijnde het algoritme, de geheime sleutel en dezelfde tijd of eventcounter want zoals eerder vermeld zijn deze drie bouwstenen noodzakelijk om een OTP te genereren. Omdat de entiteit de OTP moet kunnen verifiëren maar er geen communicatie tussen de entiteit en de DIGIPASS bestaat, moet dit op een speciale manier gebeuren. Dit wordt in Sectie uitgelegd. Figuur 1.5 beeldt de verschillende authenticatiebouwstenen af en de manier hoe deze op de DIGIPASS en de authentiserende entiteit worden gelinkt. Figuur 1.5: OTP met DIGIPASS authenticatie: sleutel, tijd en algoritme (3DES, AES) zijn de drie bouwstenen 9

22 1.3.3 Validatie van een OTP Een OTP vereist drie bouwstenen. Geheime sleutels en het encryptiealgoritme zijn bekend in de DIGIPASS en op de entiteit. Bij de configuratie van de entiteit kunnen de sleutels, horende bij de digipassen, geïmporteerd worden in de entiteit. Wanneer de klant zijn digipassen aankoopt, wordt een speciaal bestand, een.dpx file, meegeleverd waarin alle sleutels gelinkt zijn aan de betreffende digipassen. Dit bestand is geëncrypteerd met een transportsleutel, die aan de klant wordt meegedeeld, zodat deze de sleutels kan importeren in de entiteit. Tot hiertoe zijn dus al twee bouwstenen op elkaar afgesteld, zowel in de DIGIPASS als op de entiteit. De enige bouwsteen die nog moet gelinkt worden, is de tijd ofwel de eventcounter, gebruikt bij respectievelijk een tijdsgebaseerde of eventgebasseerde DIGIPASS Tijdsgebaseerde OTP De OTP s gegenereerd door een tijdsgebaseerde DIGIPASS hebben als derde bouwsteen de tijd. Een tijdsgebaseerde DIGIPASS bevat een interne klok. De entiteit bevat ook een klok, een systeemklok. Deze twee tijden kunnen verschillend zijn, maar bij de creatie van een OTP wordt slechts 1 tijd gebruikt. Het probleem is dus te herleiden naar de volgende stelling: hoe weet de entiteit welke tijd de DIGIPASS gebruikt heeft om de OTP te genereren. Hiervoor is een inventief synchronisatiesysteem bedacht. Een ander probleem dat ook moet aangepakt worden, is het feit dat de DIGIPASS- klok, ingesteld op moment van fabricage, kan ontregeld geraken. Hiervoor is ook een oplossing voor bedacht. Aan de hand van een voorbeeld zal dit duidelijk worden. Stel de volgende situatie. De gebruiker vraagt een OTP aan. Deze is bijvoorbeeld De interne klok van de DIGIPASS staat op 15u40. Op hetzelfde moment is de systeemklok van de entiteit 16u00. Er is dus een verschil van 20 minuten tussen beide klokken. Dit verschil komt doordat de interne DIGIPASS klok ontregeld is geraakt, door bijvoorbeeld weerkundige invloeden zoals temperatuur. Bij de eerste keer dat een OTP gegenereerd wordt door de DIGIPASS, is er een synchronisation window van 6 uur. Dit is een periode waarin de OTP als geldig wordt verklaard. Opgelet, een geldige OTP impliceert geen succesvolle authenticatie. Dit betekent alleen dat de OTP aanleiding kan geven tot een succesvolle authenticatie. De systeemklok wordt als midden beschouwd in het synchronisation window. De geldige tijd waarmee de OTP berekend werd, is dus het interval tussen 13u00 en 19u00, zoals aangegeven in Figuur 1.6. Aangezien de DIGIPASS-klok op 15u40 stond op het moment van de aanvraag, valt dit binnen het geldig domein. Als gevolg wordt de OTP als geldig verklaard. Als de andere authenticatie-aanvraagparameters ook correct zijn en de gebruiker een OTP genereerde met een DIGIPASS gelinkt aan zijn account, dan zal de authenticatie slagen. 10

23 Figuur 1.6: Eerste keer OTP valideren Bij de volgende validaties van OTP s wordt het synchronisation window van 6 uur verkleind naar een periode van 20 keer 32 seconden (10 minuten 40 seconden). 32 seconden is de tijd van één tijdsstap. Stel de volgende dag doet de gebruiker een OTP aanvraag, opnieuw op 15u40. De DIGIPASSklok is echter ontregeld en staat op 15u38. Dit is weergegeven in Figuur 1.7. De systeemklok is opnieuw 16u00. De geldige periode van OTP s op dat ogenblik is dus van 16u00 minus 5 minuten 20 seconden tot 16u00 plus 5 minuten 20 seconden, omdat het window nu verkleind is tot 10 minuten 40 seconden. Aangezien de DIGIPASS klok op 15u38 stond, valt dit buiten het geldige bereik, en wordt de OTP niet meer als geldig beschouwd. Dit zou natuurlijk een probleem zijn, maar dat wordt opgelost aan de hand van time deviation. Deze time deviation is het verschil in tijd tussen de DIGIPASS klok en de systeemklok. Bij elke aanvraag wordt deze bijgewerkt. Deze time deviation kan positief of negatief zijn en wordt bij de systeemklok opgeteld of afgetrokken. Dit resultaat geldt als de systeemklok die de entiteit moet gebruiken bij de validatie van een OTP. In het voorbeeld is deze time deviation 20 minuten en moet de entiteit dus 16u00 minus 20 minuten gebruiken als systeemklok. De 20 minuten zijn de time deviation van de vorige authenticatie. Op deze nieuwe systeemklok, 15u40 in het voorbeeld, moet dan het window toegepast worden, resulterend in een geldig interval van 15u40 minus 5 minuten 20 seconden tot 15u40 plus 5 minuten 20 seconden. Aangezien de DIGIPASS-klok op 15u38 stond, valt dit dus binnen het geldige bereik en wordt de OTP als geldig verklaard. Dit voorbeeld is visueel weergeven in Figuur

24 Figuur 1.7: Volgende keren OTP valideren Na bepaling van het geldige interval, berekent de entiteit via een brute force methode alle mogelijke tijden in dit interval. Samen met de sleutel van DIGIPASS en het algoritme, beiden gekend op de DIGIPASS en de entiteit, berekent de entiteit alle mogelijke geldige OTP s. Indien de OTP van de DIGIPASS overeenkomt met één van deze OTP s die de entiteit berekende, wordt de authenticatie als succesvol beschouwd Eventgebasseerde OTP De eventgebasseerde OTP werkt gelijkaardig als de tijdsgebaseerde OTP. Het verschil is dat geen tijd maar een eventcounter gebruikt wordt. De eventcounter moet ook gesynchroniseerd worden met de entiteit. De manier waarop dit gebeurt wordt hieronder uitgelegd aan de hand van een voorbeeld. De eventgebaseerde DIGIPASS heeft een eventcounter die bijhoudt hoeveel keer een OTP reeds werd aangevraagd. Om de exacte waarde van de eventcounter te kennen, start de entiteit vanaf een beginwaarde en berekent 10 keer een OTP, telkens met de waarde verhoogd met één. Als de OTP in de authenticatieaanvraag overeenkomt met één van de berekende OTP s door de entiteit, wordt de OTP als geldig beschouwd. Net zoals bij tijdsgebaseerde OTP s betekent dit niet dat de authenticatieaanvraag succesvol is, maar dat de OTP geldig is en aanleiding kan geven tot een succesvolle authenticatie. Het is uiteindelijk de entiteit die op basis van alle authenticatieaanvraagparameters, OTP inclusief, beslist over een succesvolle authenticatie. Figuur 1.8 illustreert de validatie van een eventgebasseerde OTP. 12

25 Figuur 1.8: Validatie OTP eventgebasseerd Two-factor functionaliteit Zoals vermeld in de vorige paragraaf genereert een DIGIPASS een OTP. Dit OTP wordt gebruikt als onderdeel van het wachtwoord bij een authenticatie. De gebruikersnaam blijft hetzelfde. Aangezien een DIGIPASS gelinkt wordt aan één gebruiker, is deze uniek. Dit is de eerste factor, de bezittende factor. De wetende factor heeft te maken met het wachtwoord. Het wachtwoord bestaat uit twee delen: een PIN-code, afhankelijk van de gebruiker, en de OTP van de DIGIPASS van de gebruiker. De PIN-code kan veranderd worden door de gebruiker. Via de DIGIPASS met PIN-code en de OTP kan de gebruiker dus een Two-factor authenticatie uitvoeren. In sommige gevallen bestaat het wachtwoord alleen uit de OTP. Dit is het geval bij een speciale manier van authenticatie, namelijk het challenge/response authenticatiemechanisme, dat besproken wordt in Sectie Response Only authenticatiemethode Met een response only authenticatie wordt een authenticatiemethode bedoeld die net zoals gelijk welk andere authenticatiemethode een gebruikersnaam en wachtwoord vereist. Het authenticatieproces bij deze authenticatiemethode bestaat uit het sturen van een authenticatieboodschap naar de authenticatie-entiteit. Deze entiteit kan zowel een server zijn of een service, die in de cloud 3 draait. Deze beslist of de ontvangen authenticatieaanvraag al dan niet positief geëvalueerd wordt, op basis van de parameters van de aanvraag, zijnde onder andere de gebruikersnaam en wachtwoord. De entiteit antwoordt vervolgens met een bericht naar de aanvrager en uit de meegestuurde parameters van het antwoord kan de aanvrager bepalen of zijn authenticatie-aanvraag effectief een positief resultaat heeft opgeleverd. In Figuur 1.9 wordt een authenticatie uitgevoerd door de user, via een SOAP client, aan de hand van IDENTIKEY, een 3 De cloud service die hier bedoeld wordt is te vinden op deze URL: 13

26 authenticatie-entiteit. Deze entiteit beslist vervolgens over de authenticatie. Via de client wordt het resultaat naar de user gestuurd. Figuur 1.9: Response only authenticatie 1.5 Challenge/Response authenticatiemethodes Bij challenge/response mechanismen wordt een code getoond aan de aanvrager. Deze code, de challenge genoemd, moet de aanvrager in zijn DIGIPASS invoeren. Soms moet de gebruiker zelf een challenge kiezen. De DIGIPASS zal op basis van deze challenge een code genereren, de zogenaamde response. Deze response geldt als wachtwoord in een authenticatieaanvraag. De manier hoe de aanvrager de challenge verkrijgt, is niet uniform. Er zijn echter twee methodes en logischerwijs valt deze challenge/response categorie van authenticatiemethodes uiteen in twee delen, namelijk de Onestep en de Two-step authenticatiemethode One-Step challenge/response authenticatiemethode De One-step authenticatie is de eerste vorm van de twee challenge/response authenticatiemethodes. Bij deze methode wordt net zoals bij de response only authenticatiemethode één aanvraag verstuurd naar de authenticatie-entiteit. Deze gaat na of de authenticatie mag slagen op basis van de 14

27 parameters in de aanvraag, onder andere de gebruikersnaam en het wachtwoord. De entiteit antwoordt ook met één enkel antwoord naar de aanvrager. Zoals bij de response only authenticatiemethode kan de aanvrager afleiden of zijn authenticatie geslaagd is, uit de parameters in het antwoord van de entiteit. Het wachtwoord in de aanvraag is dus een OTP, gegenereerd door de gebruikers DIGIPASS. Deze OTP is in tegenstelling tot de response only authenticatiemethode niet te verkrijgen door een druk op de knop. De OTP is namelijk een response op een challenge. De One-step challenge/response authenticatiemethode vereist dus een challenge die eerst in de DIGIPASS wordt ingevoerd. De DIGIPASS genereert op basis van die ingegeven challenge een response. Die response is de OTP die zal gelden als wachtwoord in de authenticatieaanvraag. Figuur 1.10: Challenge/response One-step authenticatiemethode, met SERVER CHALLENGE De eerste manier hoe deze challenge aan de gebruiker gepresenteerd wordt, is bepaald door de IDENTIKEY 4 authentication server. Samenvattend kan deze ingesteld worden op twee waarden, namelijk ANY CHALLENGE en SERVER CHALLENGE. De eerste waarde, ANY CHALLENGE, geeft aan dat de gebruiker zelf verantwoordelijk is voor een challenge. Dit betekent dat de gebruiker zelf een challenge mag kiezen conform zijn policy 5. Dit kan bijvoorbeeld de volgende waarde zijn: 5463, met een policy die zegt dat het een viercijferige code moet zijn. Deze challenge geeft hij in de DIGIPASS en op deze manier zet hij het One-step challenge/response authenticatiemechanisme in werking. De tweede waarde, SERVER CHALLENGE, geeft aan dat de authenticatie-entiteit verantwoordelijk is om een challenge te produceren en deze te melden aan de gebruiker. Dit kan op verschillende manieren gebeuren, bijvoorbeeld via een webpagina. 4 In Sectie 2.1 wordt IDENTIKEY authentication server uitvoerig beschreven. Dit is een authenticatie-entiteit die authenticatiebeslissingen neemt. 5 Een policy is een set van regels waaraan een gebruiker onderhevig is. Het bepaalt aan welke voorwaarden de parameters in de authenticatie-aanvragen moeten voldoen, zowel op gebied van aanwezigheid als van formatering van de parameterwaarden. 15

28 De tweede manier om een challenge te verkrijgen, is door een challenge-aanvraag te versturen naar de entiteit. Deze antwoordt dan met een challenge parameter in zijn antwoord. Belangrijk om te beseffen is dat deze challenge-aanvraag geen authenticatieaanvraag is. Het is de bedoeling om eerst een challenge te verkrijgen. Deze manier wordt gebruikt door softwareontwikkelaars die een challenge willen tonen op een inlogwebpagina, zoals bij PC banking. Dit principe is te zien in Figuur Hier is er de challenge-aanvraag, die niet getekend is, maar de server vraagt om een challenge te sturen. Bij stap 0 geeft de gebruiker zijn credentials in, samen met de response, gegenereerd door zijn DIGIPASS als reactie op de challenge. Stap 1 is dan de effectieve authenticatie-aanvraag. De volgende stappen handelen de authenticatie zelf af en is de bevoegdheid van de entiteit, IDENTIKEY in de figuur. Stap 7 is dan het antwoord van de entiteit, dat bevat als de gebruiker op basis van de authenticatie-aanvraagparameters al dan niet geauthentiseerd is. De tussenliggende stappen staan niet getekend omdat deze opnieuw betrekking hebben tot de entiteit zelf, en niet relevant zijn voor de werking van de One-step challenge/response authenticatiemethode. Ondanks dat er eerst een challenge-aanvraag is in code, is dit toch een One-step authenticatiemethode, omdat dat de term One-step of Two-step slaat op het aantal acties dat een gebruiker moet verrichten om een authenticatie uit te voeren. De Two-step challenge/response authenticatiemethode wordt hieronder besproken Two-step challenge/response authenticatiemethode De tweede methode van de twee challenge/response authenticatiemethodes is de Two-step challenge/response authenticatiemethode. Net zoals bij de One-step challenge/response authenticatiemethode wordt hier gebruik gemaakt van een challenge. De manier hoe deze challenge verkregen wordt, is fundamenteel verschillend van de One-step variant. Bij de One-step kon de gebruiker zelf een challenge kiezen ofwel een challenge gepresenteerd krijgen, al dan niet via een initiële challenge-aanvraag. Bij de Two-step moet de gebruiker een sleutelwoord hebben, die ook door de authenticatie-entiteit gekend is. Een Two-step authenticatie vereist een extra stap in tegenstelling tot de One-step authenticatie want bij de Two-step authenticatie moet de gebruiker altijd een challenge-aanvraag doen. Deze verschilt van de challenge-aanvraag bij een One-step authenticatie. De challenge-aanvraag bij de Two-step challenge/response authenticatiemethode ziet er identiek uit als een response only authenticatieaanvraag, waar het sleutelwoord als wachtwoord geldt. Het is net alsof een response only authenticatie uitgevoerd wordt, met het sleutelwoord als wachtwoord. De authenticatie-entiteit merkt weliswaar dat dit gaat over een challenge-aanvraag van de Two-step authenticatiemethode en antwoordt dan ook op een passend manier. Dit antwoord bevat de challenge die met de aanvraag wordt gevraagd. Met deze challenge kan de gebruiker nu een response OTP genereren met zijn DIGIPASS. De response OTP geldt dan als wachtwoord in de uiteindelijke authenticatieaanvraag. Deze authenticatieaanvraag is identiek aan de authenticatie-aanvraag bij de One-step variant. In Figuur 1.11 wordt de Two-step challenge/response authenticatiemethode geïllustreerd. In de eerste stap wordt een challenge aangevraagd. In de tweede stap wordt de effectieve authenticatie uitgevoerd, met de response als wachtwoord. 16

29 Figuur 1.11: Challenge/response Two-step authenticatiemethode De Two-step en One-step authenticatiemethodes zijn dus zeer gelijkaardig aan elkaar. Het grote verschil is dat bij de Two-step variant een sleutelwoord vereist is om een challenge te verkrijgen, terwijl bij de One-step een challenge heel eenvoudig verkregen, of zelf gekozen kan worden. De effectieve authenticatieaanvraag is wel gelijk bij zowel de One-step als bij de Two-step. 17

30 Hoofdstuk 2 Entiteiten Met entiteiten wordt de instantie bedoeld die de uiteindelijke authenticatiebeslissing neemt, op basis van de parameters in een ontvangen authenticatieaanvraag. Deze entiteit kan zowel een server zijn met authenticatiesoftware van VASCO ofwel een authenticatieservice in de VASCO cloud. Naargelang de toepassing van de klant kan deze beslissen welke soort entiteit hij wil gebruiken. Dit hoofdstuk is het resultaat van een grondige studie van deze twee authenticatieproducten van VASCO. Tijdens de stageperiode in de zomervakantie van 2013 werd hiervoor een interne training gevolgd met een certificering als resultaat. Deze zijn te vinden in de laatste appendix van deze scriptie, Appendix E. 2.1 IDENTIKEY Authentication Server Beschrijving IDENTKEY Authentication Server (IAS) is een softwareproduct van VASCO. Deze software draait op een server in de infrastructuur van de klant en voert authenticatiebeslissingen uit. De klant is verantwoordelijk voor het beheer van de server en de configuratie van de IDENTIKEY software. VASCO levert wel ondersteuning voor de klant indien hij problemen zou ondervinden bij het gebruik ervan, alsook optionele hulp tijdens de installatie en initiële configuratie van de software. IAS gebruikt een databank waarin alle informatie staat opgeslagen. Deze databank kan ook geïntegreerd worden in de Active Directory databank op een domeincontroller. Via een webinterface kan de administrator de IAS beheren. Er is echter ook een commandtool beschikbaar waarmee operaties in bulk kunnen uitgevoerd worden. Het beheer van IAS omvat het beheer van de gebruikers die worden toegelaten en het beheer van de digipassen. Zoals eerder vermeld is een DIGIPASS uniek gelinkt aan een gebruiker en deze koppeling moet in de IAS geconfigureerd worden. Er is ook de mogelijkheid om policies aan te maken. Een policy is een groep van regels die gebruikers moeten volgen. Een voorbeeld van een regel in een policy kan de volgende zijn: na 5 onsuccesvolle pogingen om zich te authentiseren wordt de gebruikersaccount gelockt en moet deze door de administrator terug unlockt worden. 18

31 De communicatie met IAS, waarvan deze masterproef gebruikmaakt, gebeurt via SOAP. De authenticatieaanvragen aan de IAS moeten correct geformatteerd zijn volgens dit protocol en moeten welbepaalde XML elementen en attributen bevatten. De structuur van de authenticatieaanvragen en de -antwoorden die IAS naar de aanvrager terugstuurt, zijn SOAP berichten, waarvan de XML schema s duidelijk gedefinieerd zijn. Een voorbeeld van een response only authenticatieaanvraag wordt in Figuur 2.1 getoond. In Appendix A zijn twee screenshots te vinden, één van de inlogpagina van de administrator webinterface en één van de homepagina waar de klant terechtkomt na een succesvolle administratorlogin. Omdat deze als illustratie gelden, zitten ze in een appendix. Figuur 2.1: Response only authenticatie via soapui In Figuur 2.1 is een response only authenticatie te zien waar een OTP van een DIGIPASS als wachtwoord werd meegestuurd. Het programma waarvan deze screenshot is genomen, heet soapui. Dit programma kan SOAP berichten versturen en ontvangen. Aangezien het hier over een IAS gaat en de communicatie via SOAP verloopt, werd dit programma gebruikt om het authenticatieverloop aan de tonen. Op de linkerkant van simple otp staat de aanvraag. De rechterkant bevat het antwoord. Zoals af te leiden valt uit de rechterkant, is de authenticatie geslaagd. Dit is merkbaar aan de resultcodes. 19

32 2.1.2 Protocollen Voor de volledigheid worden hier alle protocollen opgesomd met de mogelijkheden die ze aanbieden om te communiceren met IAS. Dit gedeelte is echter informatief bedoeld. Samenvattend zijn er verschillende mogelijkheden om te communiceren met IAS, zo ook om authenticaties en andere administratieve taken uit te voeren SOAP IAS is een SOAP server die 5 webservices aanbiedt: 1. User authentication 2. Signature validation 3. Administration 4. Provisioning 5. Report generation De gebruiker kan deze diensten in de IAS instellen, configureren en op die manier in staat gesteld worden om via de juiste SOAP berichten de bovenstaande diensten te gebruiken RADIUS IAS kan gebruikt worden voor authenticaties in RADIUS (Remote Authentication Dial In User Service) omgevingen. Hij kan ook ingezet worden als proxy en als back-end met een RADIUS server. De gepaste RADIUS attributen kunnen worden meegegeven door IAS. IAS kan ook specifieke RADIUS woordenboeken inladen en ondersteunt ook verschillende protocollen zoals PAP (Password Authentication Protocol) en CHAP (Challenge Handshake Authentication Protocol). Een uitgebreide ondersteuning voor RADIUS samen met IAS is dus voorzien SEAL Dit is een protocol, ontwikkeld door VASCO en staat voor Security Experts Academy & elearning. Communicatie via het SEAL protocol kan gebruikt worden voor onder andere DIGIPASS authentication for Windows Logon. Meer details kan u vinden op webportaal van VASCO Authenticatieproces Het authenticatieproces dat doorlopen wordt nadat IAS een authenticatieaanvraag ontvangen heeft, verloopt in 7 stappen, in de veronderstelling dat de aanvraag correct volgens SOAP geformatteerd is. 1. Identificeren van de client 2. Identificeren van de policy 3. Opzoeken en controleren van de gebruiker 4. Lokale authenticatie 5. Back-end authenticatie 6. Generatie van een challenge 7. Finaliseren 20

33 Stap 1: identificeren van de client Er moet een client record geïdentificeerd worden door IAS. De aanvrager specifieert een type door middel van het soort bericht dat hij stuurt, bijvoorbeeld SOAP, maar dit kan ook een RADIUS client zijn, Citrix Web Interface, Outlook Web Access, etc. De client location is het IP-adres van de client die een aanvraag stuurt. Het type en het IP-adres kenmerken een client record in IAS. Het authenticatieproces gaat verder indien een dergelijk record gevonden wordt Stap 2: identificeren van de policy Een policy, zoals in Sectie vermeld, is een verzameling regels waaraan bepaalde gebruikers zich moeten houden. Ze hebben betrekking tot bijvoorbeeld het authenticatietype dat gebruikt moet worden, welke DIGIPASS applicaties 6 gebruikt kunnen worden, etc Stap 3: opzoeken en controleren van de gebruiker De DIGIPASS gebruiker moet opgezocht worden in de IAS databank. Dit gebeurt via Windows Name Resolution of Simple Name Resolution. Er kan ook gekozen worden om de gebruiker te zoeken via Windows Group Check. Indien de gebruiker niet gevonden wordt, zal de authenticatie falen. Een beschrijving van deze opzoektechnologieën valt buiten het opzet van deze masterproef Stap 4: Lokale authenticatie Een lokale authenticatie wijst op het feit dat de IAS de beslissing zal nemen of de gebruiker geauthentiseerd zal worden of niet. Indien de parameters in de aanvraag niet overeenkomen met de instellingen in de IAS en de databank van de IAS zal de authenticatie niet slagen. Deze authenticatie kan zowel met DIGIPASS en OTP gebeuren als met een statisch wachtwoord, zonder OTP. Hoe deze configuratie gedaan wordt, valt ook buiten het opzet van deze masterproef. Figuur 2.2 verduidelijkt de communicatie met IAS. Er wordt gebruik gemaakt van een RADIUS client. Figuur 2.2: Lokale authenticatie 6 Dit is de soort authenticatiemethode of signaturemethode. Deze masterproef gebruikt echter alleen de authenticatiemethodes. 21

34 Stap 5: back-end authenticatie Back-End authenticatie is het proces waarbij de aanvraagparameters gecontroleerd worden in samenwerking met een ander systeem. Er zijn 4 protocollen die hierbij kunnen gebruikt worden zijnde Windows, LDAP, RADIUS en een custom back-end protocol. Afhankelijk van de configuratie wordt de aanvraag doorgestuurd en neemt IAS een beslissing. Vervolgens kunnen attributen zoals bij RADIUS naar de aanvrager gestuurd worden, na succesvolle authenticatie. IAS kan optreden met een RADIUS back-end of als back-end na een RADIUS proxy. Beide configuraties zijn weergegeven in de Figuur 1.3 en Figuur Figuur 2.3: Authenticatie met back-end Stap 6: generatie van een challenge Figuur 2.4: Authenticatie met proxy en IAS als back-end Een generatie van een challenge wordt uitgevoerd wanneer er een challenge/response authenticatiemechanisme gebruikt wordt. Deze stap is verantwoordelijk voor de generatie van een challenge dat naar de aanvragende gebruiker wordt gestuurd, na een succesvolle procedure vanaf stap 1. 22

35 Stap 7: finaliseren Wanneer alle stappen succesvol zijn doorlopen, betekent dit dat de authenticatie 7 geslaagd is. Indien ergens tijdens de procedure fouten opgeworpen zijn, zal de authenticatie falen. Er wordt altijd geantwoord naar de aanvragen met gedetailleerde informatie over zijn aanvraag Samenvatting IAS is dus een totaaloplossing voor allerlei soorten van authenticaties. Normaal moet de klant zelf een implementatie maken in zijn eigen code om te communiceren met IAS. Deze masterproef biedt hiervoor een oplossing, de engine genaamd, die deze volledige communicatie voor zijn rekening zal nemen, zodat de klant zich hiervan niet hoeft aan te trekken. Dit wordt in deel twee van deze scriptie behandeld. 2.2 DIGIPASS as a Service DPS staat voor DIGIPASS as a Service, een SaaS (Software As A Service) applicatie die in de VASCO cloud 8 draait en aan de klant wordt aangeboden. De web services API kan via SOAP, REST en SAML gebruikt worden. In de vereisten van deze masterproef werd de REST interface aangeduid als communicatiemethode voor DPS en dit is ook de methode die geïmplementeerd werd. Communicatie via SOAP en SAML werd niet geïmplementeerd. Dit kan later nog voorzien worden in de oplossing die de masterproef aanbiedt, de engine, wegens de modulaire opbouw van de engine Beschrijving DPS is een SaaS applicatie (Software as a Service). Er moet dus geen software of infrastructuur aan de kant van de klant voorzien worden op gebied van authenticatie. De klant is wel verantwoordelijk voor de correcte informatie in de cloud-applicatie maar het beheer van de applicatie ligt in de handen van VASCO. De bedoeling van deze service is dat de klant zijn authenticatiefunctionaliteit kan outsourcen naar dit DPS platform. Het platform voorziet in een centraal serversysteem om gebruikers te authentiseren. Om dit platform te gebruiken, is een DIGIPASS vereist. DPS, zelf een SaaS applicatie, beveiligt SaaS applicaties. Enkele voorbeelden van deze te beveiligen SaaS applicaties zijn de volgende: Gmail, Facebook, PayPal, maar ook applicaties zoals World of Warcraft bijvoorbeeld. DPS voorziet ook in een functie dat federated authentication wordt genoemd. Dit stelt de gebruiker in staat zich te authentiseren voor meerdere webapplicaties met slechts één DIGIPASS. Federated 7 Als een challenge-aanvraag behandeld werd, wordt ook aangegeven of de generatie van een challenge gelukt is of niet. In dit geval gaat het dus niet over een authenticatie-aanvraag. 8 Het portaal waar DPS wordt gehost is te vinden op deze URL: Het draait in de VASCO cloud. 23

36 authentication is ontstaan uit het besef dat al deze webapplicaties authenticatie vereisen en dat een slimme gebruiker verschillende wachtwoorden hiervoor zal gebruiken. Dit is natuurlijk een veilige gedachte maar onhandig in praktijk, zeker indien het gaat over een tiental accounts met elk verschillende complexe 9 wachtwoorden. Een ander detail is het besef dat de gebruiker ongewild soms meer informatie deelt dan hij effectief wil delen. Om het gebruikerscomfort te verhogen en de authenticatie-informatie op een veilige manier te beheren, werd de federated authentication functionaliteit uitgewerkt. Om de extra functionaliteit te gebruiken die federated authentication biedt, heeft de gebruiker weliswaar een DIGIPASS nodig die dit ondersteunt, een DIGIPASSPLUS. De federated authentication functionaliteit is typisch te situeren in de B2C (Business to Consumer) markt. In de B2B (Business to Business) wordt het standaard DPS meer gebruikt. In Figuur 2.5 worden acht voorbeelden gegeven, telkens vier voor respectievelijk dp+ (DIGIPASSPLUS) en DIGIPASS. Figuur 2.5: Voorbeelden van producten gelinkt met dp+ (DIGIPASSPLUS) en DIGIPASS Gebruikersmethode en authenticatieproces De gebruiker van het DPS platform wil zich authentiseren voor een applicatie, zoals hij deze eerder heeft gelinkt en geconfigureerd in zijn DPS account. Hij stelt een authenticatieaanvraag op en stuurt deze naar de authenticatieservice van VASCO, het DPS platform. Het platform handelt de authenticatie af en de gebruiker krijgt een antwoord van deze DPS terug. Aan de hand van de parameters in het antwoord van de DPS kan de gebruiker afleiden of een authenticatie al dan niet geslaagd is. Een belangrijke factor bij deze authenticaties is de configuratie in de account van de gebruiker op het DPS platform. Deze configuratie van gegevens in de DPS cloud-applicatie gebeurt via een webinterface. Net zoals bij IAS is de klant verantwoordelijk voor de ingave van de correcte gebruikersinformatie en de informatie van de bijhorende digipassen. Ook de verschillende toepassingen waarvoor de klant zich wilt authentiseren moet hij beheren. Indien deze configuratie niet correct is uitgevoerd, zullen authenticaties die hiervan gebruik maken vanzelfsprekend falen. 9 Onder een complex wachtwoord wordt een wachtwoord verstaan dat buiten letters ook cijfers en speciale tekens bevat zoals &, # en $. 24

37 Figuur 2.6: DPS authenticatie In Figuur 2.6 is een voorbeeld uitgewerkt hoe DPS authenticatie precies in zijn werk gaat. In stap 1 surft de gebruiker naar zijn applicatie, in dit geval Google Apps. In een voorbeeld zonder DPS vult de gebruiker hier zijn gegevens in en wordt hij door de applicatie geauthentiseerd. Bij DPS wordt de gebruiker in stap 2 achter de schermen doorgestuurd naar het DPS platform en komt hij terecht op de loginpagina van DPS. Dit platform vraagt in stap 3 naar de inloggegevens van de gebruiker voor het DPS platform. In stap 4 worden deze authenticatiegegevens ingegeven. De single sign on service stuurt in stap 5 het gesigneerde HTML-antwoord terug naar de applicatie, Google Apps, aan de hand van een POST boodschap. Indien de gebruiker de correcte gegevens heeft ingevoerd voor de authenticatie, verkrijgt deze toegang tot de applicatie die de gebruiker wil gebruiken. In stap 7 worden de resources ter beschikking gesteld van de gebruiker. De API die DIGIPASS as a Service aanbiedt, voorziet in administratieve taken en authenticaties. Gebruikers kunnen geregistreerd worden, digipassen kunnen in het systeem ingegeven worden en kunnen vervolgens gelinkt worden aan gebruikers. De administrator heeft echter nog meer mogelijkheden. Hij kan gebruikers beheren en rapporten laten samenstellen over de status van de VASCO s cloud-applicatie. 25

38 De communicatie met het DPS platform, geïmplementeerd in deze masterproef, verloopt via REST. De authenticatieaanvragen die DPS verwacht, moeten de correcte XML elementen en attributen bevatten, zo niet antwoordt DPS met een foutbericht. Ook het antwoord op een authenticatieaanvraag is geformatteerd in XML en hieruit kan de klant afleiden of zijn authenticatieaanvraag al dan niet geslaagd is. Hieronder een voorbeeld van een RESTauthenticatieaanvraag. In Appendix B zijn twee screenshots te vinden, één van de inlogpagina en één van de homepagina waar de klant terechtkomt na een succesvolle login. Opnieuw is gekozen om deze in een appendix onder te brengen, om ze slechts van illustratieve waarde zijn. Figuur 2.7: Authenticatie via REST In Figuur 2.7 is te zien hoe een REST call uitgevoerd wordt en wat het antwoord is van het DPS platform. Het gaat om een HTTP POST bericht dat wordt verstuurd aan de van curl. Dit is een library waarmee HTTP berichten verstuurd kunnen worden. Hier werd echter een gecompileerde versie van curl gebruikt. De inhoud van het auth.xml bestand geldt als body voor het bericht. Uit het antwoord is te zien dat de authenticatie geslaagd is. Uit veiligheidsredenen werden rode lijnen aangebracht in Figuur

39 Deel 2: authenticatie engine 27

40 Hoofdstuk 3 Architectuur engine In dit hoofdstuk wordt de architectuur van de authenticatie engine beschreven. Het behandelt de ontwerpeisen waaraan de engine moet voldoen. De analyse van de eisen en het bepalen van de verschillende taken worden weergegeven op twee use case diagrammen. Vervolgens worden de verschillende bouwstenen van de engine en de manier waarop de gebruiker met de engine interageert, beschreven. Hierbij wordt telkens aangegeven hoe de code in elkaar zit, op basis van de analyse, en welke libraries gebruikt werden. Ontwerpkeuzes worden hier ook gemotiveerd. De verschillende onderdelen worden elk apart besproken, zowel voor het authenticatiegedeelte als voor het testgedeelte. Daarna worden twee essentiële onderdelen van de engine, de managers en de factory nader toegelicht, ook met analyses en codefragmenten. Als laatste onderdeel van de architectuur wordt de API overlopen en de link met de engine core toegelicht. Het volledige class diagram wordt ten slotte weergegeven, zodat de logische samenhang tussen alle componenten van de engine duidelijk wordt. 3.1 Ontwerp Eisen De authenticatie engine die deze masterproef uitwerkte, is onderhevig aan bepaalde ontwerpeisen, bepaald door VASCO. Een eerste vereiste is de modulariteit van de engine. Deze heeft betrekking op twee onderdelen, namelijk het modulair zijn van de authenticatiemethodes en van de authenticatie-entiteiten, zijnde servers of services. Omdat de engine hieraan voldoet, is het mogelijk om later nieuwe authenticatiemethodes te ontwikkelen en deze toe te voegen aan de bestaande engine als plug-in. Ook nieuwe authenticatieservers en services kunnen op deze manier efficiënt toegevoegd worden. Een volledige herwerking van de broncode is dus niet aan de orde. Een tweede vereiste is dat de engine kan functioneren op meerdere platformen. In de masterproefomschrijving werden Microsoft Windows en Linux gespecifieerd. De engine voorziet hierin en kan uitgevoerd worden op beide platformen. 28

41 Verder werd er ook gekozen om zoveel mogelijk configuratie op te vangen door protocolaanpassingen in de vorm van een configuratiebestand. Wijzigingen in de codering van de engine moesten tot een strikt minimum herleid worden. Zoals verder in deze scriptie beschreven staat, maakt de engine gebruik van een configuratiebestand dat wordt ingeladen tijdens het opstartproces van de engine. Aanpassingen kan de client doen rechtstreeks in dit bestand ofwel via de API van de engine. Wegens integriteit is het aangewezen aanpassingen te doen via de engine. Alle acties die de engine uitvoert en de commando s die de client via de API van de engine verricht, worden minutieus gelogd in een logbestand. Zo is het mogelijk te voorzien in de nodige auditing, logging en tracing. Op deze manier worden troubleshooting en debugging van code waarin de engine geïntegreerd wordt een stuk eenvoudiger. Een laatste vereiste is het gebruik van de standaard protocollen SOAP en REST. Er werd bepaald dat er communicatie mogelijk moest zijn met een IAS, uitgelegd in Sectie 2.1, op basis van SOAP en met een DPS, uitgelegd in Sectie 2.2, op basis van REST. In de implementatie van de engine is hierin voorzien. Wegens de modulaire eigenschap van de engine is het natuurlijk mogelijk om ook een communicatiemanier te voorzien met een DPS op basis van SOAP. In de masterproef omschrijving werd in de tekst aangehaald dat er een plug-in zou komen die een authenticatieaanvraag van een IAS naar een DPS zou forwarden. Na analyse hiervan werd afgesproken om dit geen onderwerp te laten uitmaken van deze masterproef. Het kan later echter nog geïmplementeerd worden. Aangezien ook een testapplicatie ontwikkeld moest worden om de engine te testen, is er gekozen om een API te voorzien die de engine kan testen. Dit testen is integraal onderdeel van de engine en kan volledig geautomatiseerd verlopen. Resultaten van de testen worden automatisch gegenereerd en de client kan deze eenvoudig opvragen, via dezelfde API. Bij een bepaald type testen moet er ook informatie zijn over de omgeving waarin de engine opereert en hierin is ook voorzien. In de omschrijving werd aangegeven dat de engine bij voorkeur in C++ zou geïmplementeerd worden. Dit is ook gebeurd en de geproduceerde software kan ook aangeroepen worden in andere omgevingen, zoals een Java of.net omgeving. Via de API die de engine aanbiedt, is de functionaliteit te gebruiken in andere omgevingen. Een laatste vereiste door VASCO verwacht is het bestaan van documentatie over de authenticatie engine. Deze is integraal opgenomen in deze scriptie, als Appendix D Analyse Na het analyseren van de eisen waaraan de engine moet voldoen, werd het duidelijk dat de engine een tweeledige functionaliteit heeft, een authenticatie gedeelte en een test gedeelte. Daarom werden er twee use case diagrammen opgesteld waarop de taken staan die de client moet kunnen uitvoeren aan de hand van de engine. Op Figuur 3.1 staat het authenticatiegedeelte afgebeeld. Zoals uit de figuur af te leiden is, zijn er vijf acties die de client moet kunnen ondernemen. Van boven naar beneden zijn de vijf taken de volgende: configuratie van nieuwe servers en services; beheer van authenticatiemethodes; 29

42 authenticaties uitvoeren: o authenticatie naar een IAS via SOAP; o authenticatie naar een DPS via REST; de engine configureren; documentatie over de engine opvragen. Deze vijf taken zijn essentieel voor het authenticatiegedeelte van de engine en verderop in deze scriptie zal uitgelegd worden hoe deze taken vertaald werden in het ontwerp van de engine. Figuur 3.1: Use case diagram voor authenticatie Het tweede gedeelte van de engine s functionaliteit gaat over het testen van de engine. Ook hier werd een use case diagram opgesteld, op basis van de eisen waaraan het ontwerp van engine moet voldoen. Zoals op Figuur 3.2 afgebeeld is, zijn de taken deze vier: maken van testen: o maken van perfomantietesten; o maken van functionele testen; uitvoeren van testen: o uitvoeren van performantietesten; o uitvoeren van functionele testen; maken van testscenario's uitvoeren van testscenario s Hier wordt verder ingegaan in de volgende paragrafen hoe dit in het ontwerp van de engine werd vertaald. Zoals zal blijken uit het ontwerp is de tweedeling van functionaliteit behouden. Op 30

43 deze manier kan het testgedeelte op een onafhankelijke manier de engine testen. Het enige dat de client zal moeten doen is het definiëren van testen en eventuele scenario s, die op een geautomatiseerde en zelfstandige manier het authenticatiegedeelte uitvoerig zullen testen. Hoe dit gebeurt, worden Sectie toegelicht. Figuur 3.2: Use case diagram voor testen van de engine 3.2 Authenticatie bouwstenen Om een authenticatieaanvraag door de engine te laten afhandelen, werden drie bouwstenen ontworpen. Na analyse van de huidige situatie en de verschillende manieren van authentiseren, werd duidelijk dat authenticators de eerste bouwsteen zijn. Deze authenticators in het ontwerp van de engine stellen de authenticatie-entiteiten voor die de effectieve authenticatie uitvoeren. Modules vormen de tweede bouwsteen in het ontwerp. Deze zijn verantwoordelijk voor de correcte formatering van de authenticatieaanvraag en bevatten alle logica omtrent de gebruikte protocollen en authenticatiemethodes. De derde bouwsteen zijn de methodes. Een methode in het ontwerp stelt een authenticator voor, gekoppeld met een module. In de specificaties werd bijvoorbeeld een IAS authenticatie bepaald via SOAP. De IAS in kwestie zal een authenticator zijn in het ontwerp en het SOAP gedeelte zal worden geïmplementeerd door een specifieke module. In deze paragraaf worden alle bouwstenen apart besproken, samen met de ontwerpkeuzes die gemaakt werden. De class diagrammen en codefragmenten illustreren de werking en implementatie in de engine. 31

44 3.2.1 Authenticators Een authenticator is essentieel voor de engine om een authenticatieaanvraag te verwerken. Het bevat gegevens die noodzakelijk zijn voor de engine om een correcte authenticatieaanvraag op te stellen en door te sturen naar de correcte authenticatie-entiteit. Een voorbeeld van een authenticator in het configuratiebestand vindt u hieronder in Codefragment 3.1. <Authenticator id="iasauthenticator1stepid1" type="server"> <Location header="iasauthenticator.h" source="default"/> <Network dns="" ip=" :8888" use="ip"/> <AuthenticationType type="onestepauth"> <AuthenticationParameter name="askchallenge" value="no"/> <AuthenticationParameter name="challenge" value="9876"/> </AuthenticationType> </Authenticator> Codefragment 3.1: Authenticator in XML configuratiebestand De ID van de authenticator is belangrijk voor de engine want dit is de identifier waarmee de betreffende authenticator geregistreerd wordt bij de engine. Daarom moet het een unieke waarde zijn. Het type attribuut geeft aan of de authenticator een server of een service is, respectievelijk IAS of DPS. Afhankelijk van deze parameter worden andere authenticatieparameters verwacht verder in de configuratie van de authenticator. Het location element geeft aan waar de bronbestanden staan. Standaard is dit op de default 10 locatie, in het project zelf. In het network element wordt het IP-adres of de DNS-naam van de server of service opgeslagen. Het use attribuut geeft aan of een IP-adres gebruikt wordt of een DNS-naam. Het kan bijgevolg maar twee waarden aannemen, IP of DNS. Er zijn verschillende authenticationtypes mogelijk. Deze zijn OTPauth, OneSTEPauth en TwoSTEPauth en geven weer welke authenticatiemethode de authenticator ondersteunt. Een authenticator kan maar één type ondersteunen, maar omdat er meerdere authenticators mogelijk zijn met hetzelfde netwerkadres, kan een authenticatie-entiteit toch meerdere authenticatievormen aanbieden. In de volgende paragrafen wordt telkens een van de drie verschillende authenticatietypes besproken. Het eerste type dat mogelijk is bij een authenticator is OTPauth. Dit type wordt ondersteund door zowel server als service authenticators. Indien OTPauth gekozen wordt, mogen geen andere parameters in de configuratie meer voorkomen. Indien dit toch gebeurt, wordt er een fout gelogd en wordt de authenticator niet geregistreerd bij de engine. OTPauth is te gebruiken voor de response only authenticatiemethodes. Dit kan zowel authenticatie zijn aan de hand van een statisch wachtwoord als authenticatie met een DIGIPASS die een OTP genereert met een druk op de knop. Het tweede mogelijke type is OneSTEPauth. Een voorbeeld hiervan is te zien in codefragment 3.1. Dit type wordt ook ondersteund door zowel IAS als DPS, maar voor deze masterproef moest IAS alleen deze ondersteunen. OneSTEPauth is het type voor One Step challenge/response authenticaties. Bij deze vorm van authentiseren wordt afhankelijk van het askchallenge attribuut nog een extra authenticatieparameter verwacht. Indien de waarde op no ingesteld staat, is het noodzakelijk voor de engine om de challenge af te leiden uit het configuratiebestand. Het askchallenge attribuut geeft 10 Andere waarden worden niet ondersteund, maar de functionaliteit is wel al voorzien. Zie hoofdstuk 6 voor meer details. 32

45 weer of de challenge aan de client gevraagd moet worden tijdens de authenticatieprocedure. Indien askchallenge de waarde yes heeft, dan mag de authenticatieparameter met naam challenge niet voorkomen. Indien dit toch gebeurt, wordt opnieuw een fout gelogd en wordt de authenticator niet opgenomen door de engine tijdens het laden van het configuratiebestand door de engine. De volgende opmerking moet gemaakt worden want als de askchallenge authenticatieparameter yes als waarde heeft, dan is de client verantwoordelijk voor de challenge. Deze challenge kan hij zelf kiezen naar gelang de policy in de IAS waaraan de client moet voldoen voor authenticaties ofwel kan hij ook een challenge vragen aan de IAS. Hoewel de client een challenge vraagt, is dit toch geen Two Step challenge/response authenticatiemethode, want dit kan geïntegreerd worden in software van de client en, zoals uitgelegd in Sectie 1.5, slaat de term Two Step op het aantal acties dat de gebruiker van de client software moet uitvoeren voor een authenticatie. Voor deze vorm van One Step authenticatie is een methode voorzien in de API van de engine. Het derde en laatste mogelijke type is TwoSTEPauth. Ook hier wordt in deze masterproef TwoSTEPauth alleen ondersteund voor authenticaties met een IAS back-end. Net zoals er een authenticatieparameter askchallenge was bij de OneSTEPauth is er hier een authenticatieparameter askkeyword. Deze paramater moet ook altijd aanwezig zijn in de configuratie en kan tevens de waarden yes en no aannemen. Bij no moet het keyword in de configuratie zijn opgenomen via de authenticatieparameter keyword. Bij yes moet de client zelf het keyword ingeven. Hier bestaat geen alternatief om het keyword aan te vragen, omdat bij een Two Step challenge/response methode de client altijd het keyword zelf moet voorzien en dit niet zoals een challenge kan vragen aan een IAS. In Figuur 3.3 wordt het class diagram weergegeven van de authenticators. Authenticator is een abstracte klasse die een aantal membervariabelen bevat. Deze zijn de parameters die in het XML configuratiebestand van de engine aangegeven zijn. Tijdens de initialisatie van de engine, wordt op basis dan de parameters in het configuratiebestand de juiste authenticator aangemaakt. Omdat er twee mogelijke entiteiten zijn, werden in het ontwerp twee afgeleide klassen gemaakt. Deze keuze lag voor de hand, wegens de eis voor modulariteit. Indien later nog een derde entiteit zou ontwikkeld worden, kan eenvoudig een nieuwe klasse afgeleid worden. Program to an interface werd hier als ontwerpprincipe in het achterhoofd gehouden. Zoals uit het de XML codefragmenten zal blijken, is de authenticator ook aanpasbaar bij wijzigingen in het protocol. Nieuwe authenticatieparameters kunnen eenvoudig in de XML worden toegevoegd, zonder dat een nieuw type gedefinieerd moet worden. Het enige aanpassing in code dat moet voorzien worden, is het testen op de ingegeven waarde. Door deze ontwerpkeuze wordt rekening gehouden met de eis om zo weinig mogelijk codeaanpassingen te hoeven doen bij een wijziging in het authenticatieprotocol. Voor DPS werd DPSauthenticator ontworpen en voor IAS de IASauthenticator klasse. Beiden worden in het volgende secties besproken. 33

46 Figuur 3.3: Class diagram van de authenticators IAS IAS is een authenticatie entiteit, voorgesteld door een authenticator in de engine, die een IDENTIKEY Authentication Server voorstelt. Indien de client zich wilt authentiseren met behulp van een IAS, moet hij een IAS authenticator voorzien in het configuratiebestand. Hierbij moet hij de juiste authenticatieparameters instellen conform zijn wensen van authentiseren en de manier waarmee hij wilt authentiseren. Bij het instellen van het authenticatietype moet de client ook zorgen dat de configuratie in de IAS op een correcte manier gebeurd is. Wanneer bijvoorbeeld de client een Two Step authenticatie wilt uitvoeren via de engine, de authenticator in het configuratiebestand correct heeft ingesteld maar de IAS niet geconfigureerd heeft voor Two Step authenticaties, dan zal elke authenticatieaanvraag met op een Two Step manier natuurlijk falen. Daarom is het belangrijk om tijdens het instellen van de engine over een correcte IAS-configuratie te beschikken. Zoals hierboven vermeld, kan authenticatie met een IAS met alle authenticatietypes. Hieronder is Codefragment 3.2 waarop een authenticator in het configuratiebestand van de engine te zien is, weergegeven. In het voorbeeld wordt een Two Step authenticator weergegeven waar het keyword in het configuratiebestand wordt voorzien. <Authenticator id="iasauthenticator2stepid2" type="server"> <Location header="iasauthenticator.h" source="default"/> <Network dns="" ip=" :8888" use="ip"/> <AuthenticationType type="twostepauth"> <AuthenticationParameter name="keyword" value="keyword"/> <AuthenticationParameter name="askkeyword" value="no"/> </AuthenticationType> </Authenticator> Codefragment 3.2: IAS authenticator voor Two Step authenticatie 34

47 DPS DPS is de tweede mogelijk authenticator waaruit de client kan kiezen om zich te authentiseren. Net zoals bij IAS moet ook hier de client zorgen voor een correct geconfigureerde DPS. Anders zullen alle authenticaties met dit type authenticator niet lukken. Bij authenticators van het type DPS kan de client enkel kiezen voor het OTPauth authenticatietype. Hoewel DPS ook andere soorten authenticaties ondersteunt, werd voor deze masterproef bepaald dat enkel de response only authenticaties ondersteund zouden worden. Hieronder vindt u in Codefragment 3.3 uit het configuratiebestand van de engine waarin een DPS authenticator geconfigureerd is. Uit veiligheidsoverwegingen werden hier de API en de AID afgekort. Deze parameters zijn nodig voor het DPS platform om users te authentiseren. Voor een beschrijving over hoe authenticaties werken bij het DPS platform wordt u verwezen naar het eerst gedeelte van deze scriptie. De parameters API, AID, URI_START, URI_END en protocol zijn noodzakelijk indien het type van de authenticator SERVICE is. Ook de header moet de opgegeven waarde hebben. Indien besloten wordt om later nog een andere implementatie te maken voor DPS, kan dit aangepast worden in de toelatingstesten die de engine uitvoert, alvorens een authenticator toe te voegen. Bij protocol wordt voorlopig alleen de waarde https geaccepteerd. Dit voorbeeld geeft aan dat wijzigingen in het protocol hier ook opgevangen kunnen worden. Dit was ook een van de ontwerpeisen waaraan de engine moest voldoen. <Authenticator id="dpsauthenticatorid1" type="service"> <Location header="dpsauthenticator.h" source="default"/> <Network dns="aspi.dpp.vasco.com" ip="" use="dns"/> <AuthenticationType type="otpauth"> <AuthenticationParameter name="api" value="ri_yhz9x8aa-a..."/> <AuthenticationParameter name="aid" value="60e68de5926e6..."/> <AuthenticationParameter name="uri_start" value="api/applications"/> <AuthenticationParameter name="uri_end" value="authentications"/> <AuthenticationParameter name="protocol" value="https"/> </AuthenticationType> </Authenticator> Codefragment 3.3: DPS authenticator Modules en controllers De engine bevat naast authenticators ook modules en enkele vaste controllers. De modules staan elk in voor de implementatie van de verschillende authenticatiemethodes: de response only en de challenge/response authenticatiemethodes. De controllers worden gebruikt door deze modules voor de effectieve afhandeling van de authenticatielogica. De controllers zullen de SOAP en REST calls uitvoeren in praktijk, op basis van de informatie die de respectievelijke SOAP en REST module zullen doorgeven. Standaard zijn er twee modules aanwezig in de engine, maar er kunnen altijd nog extra modules toegevoegd worden aan de engine. De twee standaard modules zijn de SOAP-module en de RESTmodule. Beiden implementeren ze de authenticatiemethodes die respectievelijk gebruik maken van SOAP of het REST principe. 35

48 <Module id="soapmoduleid1" type="soap"> <Location header="soapmodule.h" source="default"/> </Module> <Module id="restmoduleid1" type="rest"> <Location header="restmodule.h" source="default"/> </Module> Codefragment 3.4: de SOAP (bovenaan) en REST (onderaan) module In Codefragment 3.4 is een voorbeeld weergeven van twee modules, zoals ze in het configuratiebestand van de engine gedefinieerd zijn. Een module heeft een aantal kenmerkende eigenschappen. Een eerste is de ID. Deze moet uniek zijn binnen de engine. De module houdt ook bij welk type module het is, een SOAP of REST module, of nog een ander type. Dit ander type kan een zelf gedefinieerd type zijn indien een nieuwe module ontwikkeld zou worden. Een voorbeeld hiervan volgt later in deze scriptie, in Sectie 4.2. Een variabele in de Module-klasse geeft aan of de module een standaard module is of een extra toegevoegde module is. Dit speelt een rol bij de uitvoer van informatie over authenticaties of over testen die uitgevoerd werden (zie later). Het zoals bij authenticators is hier ook een location 11 element aanwezig. Dit heeft dezelfde functie als het location element bij de authenticators De belangrijkste functie van een module is de authenticate functie. Deze authenticate functie is verplicht aanwezig in elke module, afgeleid van de abstracte klasse Module. De functie wordt opgeroepen indien een authenticatie wordt uitgevoerd, gebruik makend van die bepaalde module. Als belangrijkste parameters worden de authenticator, de request en de response meegegeven. De authenticate functie moet namelijk weten welke authenticator gebruikt moet worden. De requestafhankelijke parameters zoals username en password moeten gekend zijn. Een verwijzing naar het response object is ook vereist, omdat de authenticate functie de parameters in dit object zal aanpassen, afhankelijk van het resultaat van de authenticatie. De laatste parameter geeft aan of de functie opgeroepen is als tweede deel in een Two Step authenticatiemethode. In Codefragment 3.5 is de declaratie weergeven van de authenticate functie in de SOAP module. void EngineSpace::SoapModule::authenticate( EngineSpace::Authenticator* authenticator_, EngineSpace::Request* request_, EngineSpace::Response* response_, bool executesecondpartoftwostep_); Codefragment 3.5: Declaratie authenticate functie in de SOAP module Een module implementeert de authenticatiemethodes die het ondersteunt. Zo is er functionaliteit bij de SOAP module ingebouwd voor alle authenticatiemethodes, terwijl er bij de REST module alleen ondersteuning is voor de response only authenticatiemethodes. Indien er meer 11 Ook hier wordt nog geen rekening gehouden in de configuratie van de engine, zoals bij authenticators. De functionaliteit is echter wel al voorzien. 36

49 authenticatiemethodes in de toekomst via REST zouden moeten ondersteund worden, zijn deze eenvoudig toe te voegen aan de module, via een uitbreiding van de authenticate functie. Alle standaard modules maken gebruik van twee controllers. Deze twee controllers zijn de SOAP controller en de REST controller. De methodes die ze aanbieden zijn statische functies en dus aanroepbaar vanuit elke klasse in de namespace EngineSpace. De functie van deze controllers is het implementeren van de effectieve SOAP of REST call naar de authenticator. Als een authenticatie wordt uitgevoerd, is de module het element dat alle acties controleert. Zo zal het alle nodige parameters vergaren zoals username en password bijvoorbeeld, hierop controles uitvoeren en vervolgens de correcte controller aanspreken indien zijn functionaliteit vereist is. Voor de modules werken de controllers dus als blackboxen. Als bijvoorbeeld bij de Two Step challenge/response methode een challenge moet aangevraagd worden, handelt de SOAP module de authenticatieprocedure af en vraagt tijdens de afhandeling de SOAP controller om een challenge. Deze controller doet dan niets anders dan het vragen van een challenge aan de IAS en geeft deze terug aan de SOAP module. Vervolgens kan de module hier nog iets mee doen indien dit nodig zou zijn. In het geval van de Two Step challenge/response methode wordt de challenge terug naar de client gestuurd. De client kan dan het vervolg van de authenticatieprocedure aanvangen, zoals eerder beschreven werd. In Figuur 3.4 is het class diagram van de modulestructuur weergegeven. Zoals te zien is, zijn beide standaardmodules afgeleid van de abstracte klasse Module. Beiden implementeren ze de abstracte functie authenticate. Door het principe van overerving wordt het eenvoudig voor de engine om verschillende types van modules te gebruiken. Opnieuw werd het principe Program to an interface gebruikt. De modulariteit van modules werd hiermee bekomen. Figuur 3.4: Class diagram van de modules In de volgende twee secties worden respectievelijk de SOAP en de REST module nader toegelicht. 37

50 SOAP De SOAP module is een van de twee modules die de engine standaard aanbiedt. Deze module ondersteunt alle authenticatiemethodes en kan gebruikt worden voor authenticaties met een IAS authenticator. In het volgende hoofdstuk worden de authenticatieprocedures besproken. De authenticate functie zal daar uitvoerig behandeld worden aan de hand van codefragmenten om zo een inzicht te krijgen in de implementatie van de verschillende authenticatiemethodes en de samenwerking met de SOAP controller REST De REST module is de tweede van de twee standaard aanwezige modules. Deze module ondersteunt voorlopig alleen de Response Only authenticatiemethodes voor authenticaties met een DPS authenticator. Omdat bij een REST API geen gebruik gemaakt wordt van een standaard formaat, zoals bij SOAP waar een gestructureerde enveloppe gebruikt wordt, is er een structuur voorzien die de nodige parameters bundelt en omvormt tot een correct geformatteerde body voor de HTTP POST call. Meer details worden ook in het volgende hoofdstuk toegelicht, alsook de samenwerking met de REST controller Methodes Samen met de modules en authenticators zijn de methodes de derde essentiële bouwsteen voor authenticaties. Methodes zijn namelijk de verschillende manieren waaruit de client kan kiezen om een authenticatie uit te voeren aan de hand van de engine. Met methode wordt dus niet een authenticatiemethode zoals Two Step challenge/response bedoeld. <Method id="m11" usingauthenticatorid="iasauthenticatorstaticpasswordid1" usingmoduleid="soapmoduleid1" /> Codefragment 3.6: Methode m11 met authenticator en module gekoppeld Een methode heeft net zoals een authenticator en een module een uniek ID. Zo is de methode uniek te identificeren door de client. De functie van een methode is het koppelen van een bepaalde authenticator met een bepaalde module. Als de client nu een methode kiest die hij wil gebruiken om een authenticatie uit te voeren, is daar een bepaalde authenticator en module aan gekoppeld. Zo kan er bijvoorbeeld een methode zijn, m11, die voorziet in authenticaties met IAS authenticator IASAuthenticatorSTATICPASSWORDID1 met IP adres en poortnummer 8888, via de SOAP module SoapModuleID1. Zie codefragmenten 3.6, 3.7 en 3.4 bovenaan. 38

51 <Authenticator id="iasauthenticatorstaticpasswordid1" type="server"> <Location header="iasauthenticator.h" source="default"/> <Network dns="" ip=" :8888" use="ip"/> <AuthenticationType type="otpauth"/> </Authenticator> Codefragment 3.7: IASAuthenticatorSTATICPASSWORDID1 authenticator De implementatie van de Method klasse is weergegeven in Figuur De membervariabelen en de verschillende functies spreken voor zich. Figuur 3.5: Class diagram van Method 3.3 User interaction In Sectie 3.2 werden de verschillende bouwstenen besproken die nodig zijn opdat de engine authenticaties zou kunnen uitvoeren met een IAS via SOAP of met een DPS via REST. De samenwerking tussen deze bouwstenen werd er besproken. In deze sectie wordt dieper ingegaan op hoe de client deze bouwstenen nu gebruikt om effectief een authenticatie uit te voeren. Ook de manier hoe de client de engine kan testen via deze bouwstenen wordt hier behandeld Authenticatie De eerste van de twee mogelijkheden die de gebruiker heeft is het uitvoeren van authenticaties. Bij deze acties zijn twee extra objecten betrokken, namelijk een request en een response object. Op Figuur 3.6 is het klassenontwerp te zien van deze twee klassen. 39

52 Figuur 3.6: Class diagram van Message met afgeleide klassen Request en Response Zowel Request als Response zijn afgeleide klassen van de abstracte klasse Message. Opnieuw wegens het ontwerpprincipe Program to an interface werd hiervoor gekozen. Met deze twee klassen is het mogelijk voor de client om alle soorten authenticatiemethodes uit te voeren. Dit zijn dus de response only en de challenge/response authenticatiemethodes. Indien later andere authenticatiemethodes ontwikkeld zouden worden die andere attributen zou vereisen, is het altijd mogelijk een nieuwe klasse te maken die deze functionaliteit implementeert. De authenticate functie kan altijd uitgebreid worden met deze nieuwe objecten als parameter. Ook voor opslag van andere gegevens in verband met authenticaties kunnen er nieuwe klassen afgeleid worden. Door deze ontwerpbeslissing werd opnieuw tegemoet gekomen aan de modulariteitseis. De aandachtige lezer heeft gemerkt dat er attributen zijn in de Request klasse die alle authenticatiemethodes ondersteunen. Deze zijn echter niet allemaal tegelijk nodig. Zo is een response only methode niet nodig om het challenge attribuut te gebruiken. In de API functie, zoals hieronder beschreven, kan dus een lege string meegegeven worden. Tijdens het ontwerpen werd gekozen om één enkele constructor te voorzien die alle authenticatiemethodes ondersteund, dit om volledige flexibiliteit in één enkele API aanroep te voorzien. Dit vereenvoudigt het gebruik van de engine voor de klant. Een API functie om een request aan te maken is een duidelijk voor de client, ongeacht de authenticatiemethode de client zal kiezen. In de twee volgende paragrafen worden de twee afgeleide klassen besproken en wordt ook uitgelegd hoe de client deze twee klassen moet gebruiken, samen met een methode, beschreven in Sectie 3.2.3, om een authenticatie uit te voeren. 40

53 Requests Alvorens een authenticatie te kunnen uitvoeren, is het noodzakelijk voor een client om een request op te stellen. Hiervoor biedt de engine een API functie aan, die kan opgeroepen worden door de client. De client moet de correcte parameters meegeven aan de functie, afhankelijk van het soort authenticatie die hij wil uitvoeren. De parameters in een request zijn dus afhankelijk van de authenticatiemethode die de client wil gebruiken. Zoals vermeld is er dus één enkele API functie die requesten aanmaakt op vraag van de client. int EngineSpace::Engine::createRequest( std::string usingmethodid, std::string username_, std::string domainname_, std::string password_, std::string challenge_, std::string response_, std::string componenttype_, std::string passwordformat_, std::string serial_ ); Codefragment 3.8: Engine API functie om een request aan te maken De createrequest functie van de engine geeft altijd een uniek request ID terug aan de client. Deze ID moet de client zelf bijhouden en is een aanduiding naar de request die hij aanmaakte in de engine. Samen met een methode ID moet de client deze request ID opgeven als parameter bij de authenticate functie van die engine. In de volgende Sectie wordt dit duidelijk Responses Een response is het resultaat van een uitgevoerde authenticatie en is gekoppeld aan een request. Tijdens de uitvoering van een authenticatie van een eerder gemaakt request aan de hand van een bepaalde methode, wordt een response door de engine gegenereerd. Het ID van deze response wordt aan de client terug gegeven, als resultaat van de authenticate functie. In Codefragment 3.9 wordt geïllustreerd hoe een authenticatie verloopt in het geval van een response only authenticatiemethode. Er wordt verondersteld dat de gebruikte methode bestaat, samen met de authenticator en de module die in de methode gekoppeld werden. Ook het bestaan van de pointer engine wordt als correct geïnitialiseerd verondersteld in het codefragment. Er wordt ook gecontroleerd of de authenticatie gelukt is. Afhankelijk van deze het lukken van de authenticatie wordt een andere boodschap naar de console geschreven. 41

54 int requestnr = -1; std::string serial = ""; std::cout << "Enter methodid: "; std::string methodid; std::cin >> methodid; //suppose m22 as input std::string OTP = ""; if(methodid == "m22"){ std::cout << "Module m22: " << std::endl; std::cout << "Enter username: "; std::string username; std::cin >> username; std::cout << std::endl << "Enter OTP: "; std::cin >> OTP; requestnr = engine->createrequest("m22",username,"",otp,"","","testags","0",""); int responsenr = engine->authenticate(methodid,requestnr); if(engine->isauthenticated(responsenr)){ std::cout << "authentication SUCCEEDED" << std::endl; else { std::cout << "authentication FAILED" << std::endl; Codefragment 3.9: Client authenticatie aan de hand van methode m Testing Naast de authenticatiemogelijkheid die de engine aanbiedt, kan er ook testing gebeuren die de engine test op verschillende gebieden. Indien authenticaties herhaaldelijk zouden falen, kan op deze manier nagegaan worden waar er problemen zouden kunnen zijn. Ook voor het testen als alles nog operationeel is, kan de testing functionaliteit ingezet worden. Uit de analyse van de ontwerpeisen werd bepaald dat de client zowel testen als scenario s moet kunnen uitvoeren. Daarom werden beiden ontworpen. Ook een verschil in testfunctionaliteit werd aangegeven. Dit werd opgevangen door twee type testen te ontwerpen. In de komende secties wordt dit uitgelegd. De resultaten van zowel testen als scenario s werden ontworpen op dezelfde manier, omdat een scenario een opeenvolging is van verschillende testen. Afhankelijk of een test of scenario uitgevoerd werd, is er een verschillend type report beschikbaar. Modulariteit en Program to an interface zijn opnieuw te basisprincipes die hier gebruikt werden Tests Testen worden net zoals de verschillende authenticatiebouwstenen geconfigureerd in de engine en staan ook gespecifieerd in het configuratiebestand van de engine. De client kan twee soorten testen configureren in de engine met elk een apart doel. De eerste soort test is de LOAD test. Deze test is gemaakt om de engine op performantie te testen. Zo kan een test bijvoorbeeld bestaan uit het uitvoeren van 100 authenticaties, die alleen moeten slagen. De tweede soort test is de FUNCTION test. Deze test is ontworpen om te testen of de engine 42

55 effectief reageert en handelt zoals er verwacht wordt. Zo moet een authenticatie met correcte parameters slagen en met foutieve parameters falen. De test kan dus testen op zowel positieve scenario s die moeten slagen en negatieve scenario s die moeten falen. Indien bij een negatief scenario toch een positief authenticatieresultaat wordt bekomen, heeft de test gefaald. De volgende opmerking moet weliswaar gemaakt worden. Een falende test wijst niet altijd op het feit dat er iets verkeerd is met een authenticator of met de engine, want als er verkeerde testparameters worden ingegeven bij het uitvoeren van de test, zal de test vanzelfsprekend falen. Het is belangrijk dat een test correct geconfigureerd is, alvorens deze uitgevoerd wordt. In Codefragment 3.10 en Codefragment 3.11 worden respectievelijk een LOAD en een FUNCTION test weergegeven. <Test id="onestepload1" method="m31" type="load"> <TestingParameter name="username" value="testuser"/> <TestingParameter name="domain" value=""/> <TestingParameter name="componenttype" value="testags"/> <TestingParameter name="passwordformat" value="0"/> <TestingParameter name="numberofexecutions" value="20"/> </Test> Codefragment 3.10: LOAD test waarbij 20 iteraties uitgevoerd worden via One Step authenticatie <Test id="responseonlyfunctionfail1" method="m22" type="function"> <TestingParameter name="username" value="testusser"/> <TestingParameter name="domain" value=""/> <TestingParameter name="componenttype" value="testags"/> <TestingParameter name="passwordformat" value="0"/> <TestingParameter name="result" value="fail"/> </Test> Codefragment 3.11: FUNCTION test via Response Only (OTPauth in dit geval) Zoals uit codefragment 3.10 blijkt, worden een aantal iteraties doorlopen voor de test. De aandachtige lezer heeft gemerkt dat ID van de test onestepload1 is. Bij deze test wordt gebruik gemaakt van een One Step challenge/response authenticatiemethode. In methode m31 werd namelijk een authenticator gebruikt die de One Step challenge/response authenticatiemethode gebruikt. Hoewel een challenge en een response daarbij vereist zijn, is het niet nodig dat de client deze opgeeft. Bij het testen van authenticatiemethodes hoeft er op geen enkel ogenblik userinput gegeven worden. Indien er een response of een OTP verwacht wordt van de client, wordt deze automatisch gehaald van de demo-website 12 van VASCO. Deze twee URL s, voor een OTP en voor een response, staan beide gespecifieerd in het engine configuratiebestand. Natuurlijk zijn ook nog challenges nodig. Deze worden random door de engine bepaald en gebruikt bij de One Step testing methode. Hieruit is dus duidelijk dat alle testen volledig geautomatiseerd verlopen. Wegens deze reden 13 is het ook niet mogelijk om een Two Step challenge/response authenticatiemethode te gebruiken voor testing. 12 Zie 13 Bij de Two Step challenge/response authenticatiemethode wordt er in de tweede stap userinput verwacht, namelijk de response, gegenereerd door de DIGIPASS, op basis van de ingegeven challenge. 43

56 Het automatiseren van de testing functionaliteit is een belangrijk gegeven. Vooral bij LOAD testing is dit cruciaal. Indien de client een test met honderden authenticaties wilt uitvoeren, wil hij zeker niet manueel iedere keer bijvoorbeeld een OTP invoeren. De bedoeling is dat de client op een efficiënte manier een report kan verkrijgen over de performantie van de engine en het authentiseren. In het ontwerp werd hier rekening mee gehouden en werd in de REST controller 14 de nodige functionaliteit toegevoegd om zoals hierboven aangehaald automatisch OTP s en responses te verkrijgen via URL s die VASCO voorziet. Zoals vermeldt is userinput dus niet nodig. In Codefragment 3.12 wordt er vanuit gegaan dat de user met username testusser een onbekende user is. Er wordt gebruik gemaakt van een Response Only authenticatiemethode en omdat er geen password gespecifieerd is, gaat het om een OTPauth authenticatie. In codefragment 3.13 wordt wel een password opgegeven. Hier wordt dus geen OTP achter de schermen aangevraagd. <Test id="staticpasswordfunctionsuccess1" method="m11" type="function"> <TestingParameter name="username" value="testinguser"/> <TestingParameter name="domain" value=""/> <TestingParameter name="password" value="haha1234"/> <TestingParameter name="componenttype" value="testags"/> <TestingParameter name="passwordformat" value="0"/> <TestingParameter name="result" value="success"/> </Test> Codefragment 3.12: FUNCTION test via Response Only met static password Bij het testen via de One Step authenticatiemethode is er een opmerking die moet gemaakt worden. In Codefragment 3.13 wordt dit verduidelijkt. Hierbij moeten meerdere users geauthentiseerd worden, maar aangezien een OTP voor 32 seconden hetzelfde blijft, kan men de user maar slechts om de 32 seconden opnieuw authentiseren. Om te voorzien in een LOAD test is het dus nodig dat die wordt uitgevoerd met verschillende users. Omdat verschillende digipassen hiervoor vereist zijn, wordt ook de viercijferige PIN-code meegegeven. Aangezien dit demo digipassen zijn, vormt dit geen beveiligingsrisico en kan dit in het configuratiebestand opgenomen worden. De precieze syntax valt af te leiden uit het codefragment. <Test id="responseonlyload1" method="m22" type="load"> <TestingParameter name="username" value="testuser00001:9999,testuser00002:9999"/> <TestingParameter name="domain" value=""/> <TestingParameter name="componenttype" value="testags"/> <TestingParameter name="passwordformat" value="0"/> <TestingParameter name="numberofexecutions" value="2"/> </Test> Codefragment 3.13: LOAD test via One Step authenticatie Als laatste element over de soorten testen is in Figuur 3.7 het class diagram weergeven van de twee soorten testen. Beiden zijn afgeleid van een abstract klasse Test. Omdat de engine op een 14 De REST controller wordt uitvoerig besproken in Sectie

57 uniforme manier testen zou kunnen uitvoeren, werd voor dit ontwerp gekozen. Nieuwe testen kunnen dus eenvoudig ontworpen worden voor de engine via dit principe. Figuur 3.7: Class diagram van de testen Scenario s In de vorige sectie werd al even het begrip scenario vermeld. Een scenario is een bundeling van testen die achtereenvolgens worden uitgevoerd in een bepaalde volgorde. Een scenario heeft geen resultaat in de zin van een geslaagd scenario of een gefaald scenario. Het zijn de testen die elk een testresultaat hebben. De functie van scenario s is dus louter voor het gebruiksgemak zodat meerdere testen uitgevoerd kunnen worden met een enkele user interactie. Van een uitgevoerd scenario kan ook handig een rapport, besproken in Sectie , opgevraagd worden, waar allerlei informatie te vinden is over de testen die het scenario uitgevoerd heeft. Voor alle duidelijkheid kan ook en rapport opgevraagd worden van een losstaande test. In Codefragment 3.14 is een voorbeeld gegeven van een scenario uit het configuratiebestand van de engine. Alle testen worden verondersteld te bestaan. <Scenario description="loadtests to execute" id="scenarioload1"> <ScenarioItem linked="staticpasswordload1" order="1"/> <ScenarioItem linked="responseonlyload1" order="2"/> <ScenarioItem linked="onestepload1" order="3"/> <ScenarioItem linked="onestepload2" order="4"/> </Scenario> Codefragment 3.14: Voorbeeld van een scenario Net zoals bij testen de parameters en eigenschappen gecontroleerd worden alvorens ze worden toegevoegd, is dit ook zo bij scenario s. Zo moeten alle testen bestaan, en moeten ze in een strikte volgorde voorkomen, startend vanaf 1 en aaneensluitend. Elke inbreuk hiertegen resulteert in een fout en in het niet toevoegen van het scenario aan de engine. 45

58 In Figuur 3.8 is het class diagram van de klasse Scenario weergegeven. Zoals blijkt uit het diagram heeft elk scenario een ID, dat uniek moet zijn. De description geeft een omschrijving van het scenario weer. Dit is nodig omdat een opeenvolging van verschillende testen altijd uitgevoerd worden met een bepaald doel. Het is eenvoudiger voor de client om achteraf via een description te achterhalen waarvoor het scenario dient. De membervariabele executionorder houdt ten slotte bij in welke volgorde de testen uitgevoerd moeten worden. Zoals uit de figuur blijkt, kan deze volgende aangepast worden. Alleen een geldige volgorde zal aanvaard worden. Hiervoor is het noodzakelijk dat de eerste test nummer 1 toegewezen krijgt en dat de testnummers opeenvolgend oplopen. Indien deze condities niet voldaan zijn, wordt een fout gelogd en wordt de volgorde niet aangepast. Wanneer testen worden toegevoegd of verwijderd wordt de volgende navenant aangepast. Figuur 3.8: Class diagram van Scenario Results De uitvoering van een test resulteert in een Result. De resultaten van een test kunnen opgevraagd worden in de vorm van een Report, zie Sectie Bij een result van een test wordt bijgehouden welke test uitgevoerd werd en hoelang de uitvoering van de test geduurd heeft. Een result wordt pas aangemaakt wanneer een test gestart wordt. Dan wordt ook de starttijd geregistreerd. Wanneer de test afgelopen is, wordt opnieuw de tijd opgevraagd via de statische klasse EngineTime en wordt dit bij het resultaat van de test toegevoegd. Naast deze tijdsinformatie worden de testparameters opgeslagen zodat later kan nagegaan worden met welke parameters de test werd uitgevoerd. Als laatste worden ook eigenschappen van het systeem opgeslagen bij elke test, zodat vooral bij performantie testen ook informatie van het systeem waar de engine op werkt in rekening kan gebracht worden. Dit is belangrijk voor een correcte analyse en interpretatie van de testresultaten. Er zijn ook twee membervariabelen genaamd standardstatuscode en errormessage, zoals weergegeven in Figuur 3.8. Deze zijn bedoeld om na te gaan of de test succesvol is uitgevoerd en geven extra foutinformatie indien fouten zouden opgetreden zijn. De andere eigenschappen van een result werden beschreven en zijn eenduidig terug te vinden in het klassendiagram uit Figuur

59 Figuur 3.9: Class diagram van Result Reports Wanneer de client een test of een scenario uitvoert, worden hiervan resultaten door de engine bijgehouden. Om deze op een duidelijke manier te presenteren naar de client, wordt er in het ontwerp van de engine gebruikgemaakt van reports. Er werden twee soorten reports ontwikkeld, namelijk een test report en een scenario report. Omdat het voor de client niet uitmaakt of hij resultaten krijgt van een uitgevoerde test of een uitgevoerd scenario, werd bij het ontwerpen van de reportfunctionaliteit gekozen voor één functie createreport. Dit was ook zo bij createrequest. Een enkele functie is voor de client veel duidelijker dan verschillende functies met een klein verschil. De engine moet zo eenvoudig mogelijk te gebruiken zijn en moet op een flexibele manier toch zijn volledige functionaliteit aanbieden. Dit heeft ervoor gezorgd dat er dit ontwerp verkozen werd. Bij een scenario kunnen geen aparte testreports opgevraagd worden, omdat deze samen horen bij het scenario en apart weinig waarde hebben. De resultaten worden altijd samen gebundeld tot een enkel scenarioreport. Wanneer echter een enkelvoudige test uitgevoerd wordt, kan wel een testreport opgevraagd worden. Het spreekt voor zich dat in dit geval geen scenarioreport kan gemaakt worden, aanzien er maar een enkele test uitgevoerd werd. Wanneer een test of scenario uitgevoerd wordt, resulteert dit altijd in een reportnummer. Deze report ID is een identificatie die de client moet gebruiken om het report van de uitgevoerde test of scenario op te vragen. Het systeem is vergelijkbaar met de response ID die de client ontvangt na het uitvoeren van de authenticate functie uit de engine API. In het Codefragment 3.15 wordt het verloop gegeven van stappen voor de uitvoering van een test en het opvragen van de resultaten in de vorm van een report. Eerst werd aan de client gevraagd een waarde voor keuze in te geven, afhankelijk of hij een test of een scenario wou uitvoeren. Opnieuw wordt het bestaan van de testen en scenario s verondersteld, alsook de pointer engine, die wijst naar een het engine object. In Figuur 3.10 wordt het klassendiagram van de verschillende reporten afgebeeld. Het is duidelijk dat beide types nauw verbonden zijn met elkaar. Zo bezit een scenarioreport verschillende pointers naar testreporten. Dit is mogelijk wegens de modulaire eigenschap van de reporten. De getdata functie 47

60 presenteert de resultaten uit het report in de vorm van een standaard string, dit zodat de client de gegevens als een stream kan verwerken. Figuur 3.10: Class diagram van reports int reportnr = 0; if(keuze == 1){ std::cout << "Enter testid: "; std::string testid; std::cin >> testid; reportnr = engine->executetest(testid); else if(keuze == 2){ std::cout << "Enter scenarioid: "; std::string scenarioid; std::cin >> scenarioid; reportnr = engine->executescenario(scenarioid); if(reportnr == 0){ std::cout << "test or scenario not executed" << std::endl; else { std::cout << "test or scenario executed" << std::endl; std::string report = ""; engine->createreport(reportnr,report); std::cout << "REPORT: " << std::endl; std::cout << report << std::endl; Codefragment 3.15: Uitvoeren van een test of scenario en bijhorend report opvragen 48

61 3.4 Managers De engine bezit twee managers, elk met een eigen bevoegdheid. De twee managers zijn de configuration manager en de testing manager. De eerste is verantwoordelijk voor de correcte configuratie van de engine, op gebied van authenticators, modules en methodes. Alles betreffende deze authenticatiebouwstenen wordt hier bijgehouden. De tweede manager regelt alles wat te maken heeft met de testing functionaliteit van de engine, van configuratie tot uitvoering. Beiden hebben ze een methode setupmanager, die de managers configureert. Ze maken ook allebei gebruik van de factory, beschreven in Sectie Configuration manager De eerste manager die de engine heeft is de configuratie manager. Deze is verantwoordelijk voor de configuratie van het authenticatie gedeelde van de engine en wordt als eerste opgeroepen bij het opstarten van de engine. De manager houdt alle authenticators, modules en methodes bij die de engine bezit. De initialisatie van deze manager is dan ook cruciaal voor de werking van de engine en gebeurt als eerste. De functie die eerst aangesproken moet worden in de constructor van de engine is de setupmanager van de configuration manager. Deze geeft een logische waarde terug of de initialisatie van de configuratie manager gelukt is. De setupmanager functie stelt alle authenticatiebouwstenen in en registreert deze zodat de engine er gebruik van kan maken. Het eerste wat deze functie doet is het instellen van de authenticators. Het overloopt alle authenticators in het configuratiebestand, haalt alle parameters op van deze authenticators en probeert de authenticator toe te voegen aan de engine. Na het ophalen van de parameters wordt eerst gecontroleerd of de authenticator wel voldoet aan alle configuratieregels. Wanneer deze uitgebreide test succesvol voltooid is, wordt de authenticator toegevoegd aan de manager. Na de authenticators worden alle modules overlopen. Ook hier worden alle configuratieparameters overlopen en gecontroleerd. Indien alles goed is, wordt de module toegevoegd aan de engine. Als laatste worden alle methodes overlopen. Net zoals bij de authenticators en de modules worden controles uitgevoerd en wordt de methode aan de manager toegevoegd bij een correcte configuratie. De aandachtige lezer heeft gemerkt dat een methode bestaat uit een authenticator ID en een module ID. Opdat de methodetest niet zou falen, moeten de authenticators en modules waarvan methodes gebruik maken eerst toegevoegd zijn aan de manager. Indien deze later toegevoegd zouden worden, zou een methode toegevoegd worden terwijl de verwijzingen naar de authenticator en module misschien niet bestaan. Dit zou resulteren in fouten. Daarom werd er besloten tijdens het ontwerp van de configuratie manager om methodes pas als laatste te overlopen om zo aan de manager toegevoegd te worden. In Codefragment 3.16 wordt de structuur aangegeven van deze setupmanager functie. Enkele veronderstellingen moeten wel gemaakt worden bij het bekijken van deze code. Ten eerst is er de parameter c. Dit is een parameter van de klasse Configuration_t, een klasse geconstrueerd op basis van het configuratiebestand van de engine, die alle informatie bevat van de configuration tag. Ook de andere klassen zijn zo gemaakt. De xsd library van Code synthesis heeft hiervoor gezorgd. De statische klasse Logger komt later nog aan bod in Sectie 3.6. Ook de returnvalue is belangrijk. Deze staat standaard op true, maar indien er een fout optreedt in de functie, verandert die naar false. Die code is weggelaten in dit fragment voor de leesbaarheid. De bedoeling van het codefragment is om de algemene structuur van de functie weer te geven. 49

62 bool EngineSpace::ConfigurationManager::setupManager(Configuration_t c){ EngineSpace::Logger_ACTOR actor = EngineSpace::Logger_ACTOR::_INIT; bool returnvalue = true; EngineSpace::Logger::Log(Logger_LEVEL::_INFO,"CONFIGURATION MANAGER: start of configuring...", actor ); // load authenticators Authenticators_t::Authenticator_sequence authenticator_sequence = c.authenticators().authenticator(); // iterate over all authenticators in engine xml file for(authenticators_t::authenticator_iterator i(authenticator_sequence.begin()) ; i!= authenticator_sequence.end() ; ++i){ // get all the info out of the xml for the authenticator... Authenticator_t authenticator (*i);... // end of load authenticators // load modules Modules_t::Module_sequence modules_sequence = c.modules().module(); // iterate over all modules in engine xml file for(modules_t::module_iterator i(modules_sequence.begin()) ; i!= modules_sequence.end() ; ++i){ // get all the info out of the xml for the module... Module_t module (*i);... // end of load modules // load methods Methods_t::Method_sequence methods_sequence = c.methods().method(); // iterate over all methods in engine xml file for(methods_t::method_iterator i(methods_sequence.begin()) ; i!= methods_sequence.end() ; ++i){ // get all the info out of the xml for the method... Method_t method (*i);... // end of load methods Logger::Log(Logger_LEVEL::_INFO,"CONFIGURATION MANAGER: end of configuring", actor ); if(returnvalue){ Logger::Log(Logger_LEVEL::_INFO,"CONFIGURATION MANAGER: configuration succeeded", actor ); return true; else { Logger::Log(Logger_LEVEL::_FATAL,"CONFIGURATION MANAGER: configuration not succeeded, check for errors", actor); return false; Codefragment 3.16: Structuur setupmanager van configuration manager 50

63 Omdat de client in staat is zelf methodes, modules en authenticators toe te voegen en te verwijderen, zijn de gelijknamige API functies in de engine gedefinieerd. Wanneer deze functies gebruikt worden, zullen die intern de functies oproepen die de configuration manager gebruikt. Het configuratiebestand van de engine moet natuurlijk ook worden aangepast indien er aanpassingen zouden zijn aan deze bouwstenen. Dit wordt allemaal geregeld door de configuratiemanager. Ook hier is er een engine API functie beschikbaar voor de client. Intern wordt het opslaan van de engine afgehandeld door de factory. Dit wordt toegelicht in Sectie 3.5. Net omdat de client de configuratie kan aanpassen zou het kunnen dat er bijvoorbeeld een authenticator verwijderd wordt die niet meer gebruikt wordt. Indien er nog een methode zou blijven staan die van deze authenticator gebruik maakte, wordt deze ook onbruikbaar. Daarom is er een functie voorzien die automatisch opgeroepen worden bij elke opslagoperatie van de engine, die cleanupmethods noemt. Deze functie in de configuration manager zal de configuratie van de manager controleren en methodes verwijderen die gebruikmaken van onbestaande authenticators of modules. De client is tevens op elk moment in staat om de engine API functie cleanupmethodsandscenarios op te roepen om de integriteit van de volledige engine te bewaren Testing manager De testing manager is de tweede manager die de engine bezit. Deze manager handelt alles af op gebied van testen. Net zoals bij de configuation manager is de eerste functie die opgeroepen wordt setupmanager. Deze functie overloopt alle testen en scenario s in het configuratiebestand op een analoge manier zoals de configuration manager dit doet voor de authenticatiebouwstenen. Alvorens een test of scenario wordt toegevoegd aan de testing manager, wordt er eerst met hulpfuncties gecontroleerd of de configuratie ervan wel volgens de regels is. Indien deze succesvol zijn, worden ze aan de manager toegevoegd. Net zoals bij de configuration manager zijn er engine API functies voorzien om dynamisch testen en scenario s toe te voegen en te verwijderen. Ook hier gebeuren er eerst controles alvorens de gewenste actie uit te voeren. Zo kan men geen test meer verwijderen die niet meer bestaat. Deze actie zal dus resulteren in een fout. Wanneer de client de configuratie van de volledige wil opslaan, wordt de cleanupmethods methode van de configuration manager opgeroepen, maar ook de cleanupscenarios van de testing manager. Deze laatste methode verwijdert scenario s waarin verwijzingen staan naar onbestaande testen, om zo de integriteit van de engine te bewaren. De testing manager is verantwoordelijk voor de configuratie van de testen en scenario s die engine bezit, maar ook voor het uitvoeren ervan. Daarom zijn er twee functies voorzien hierin voorzien: executetest en executescenario. Er kunnen ook reports opgevraagd worden na de uitvoering van testen en scenario s. Hoe deze functies door de client gebruikt kunnen worden werd reeds in Codefragment 3.15 geïllustreerd. 51

64 3.5 Factory De factory is een centraal element voor de engine. De twee managers maken er gebruik van voor de aanmaak authenticators, modules, methodes, testen en scenario s. Ook de synchronisatie met een configuratiebestand wordt hier afgehandeld. Het factory object wordt in de constructor van de engine aangemaakt en wordt als referentie ingesteld in beide managers via de methode setfactory. In Codefragement 3.17 wordt de setfactory methode van de configuration manager weergegeven. void EngineSpace::ConfigurationManager::setFactory( Factory* factory_){ this->factory = factory_; Codefragment 3.17: SetFactory methode van de configuration manager De factory houdt een XML object bij dat het volledige configuratiebestand voorstelt. Als er aanpassingen gebeuren aan de configuratie van de engine, worden die hierin ook aangepast. Wanneer de client dan kiest om de configuratie op te slaan, wordt dit XML object weggeschreven naar het configuratiebestand via de functie savecurrentengine. Een voorbeeld is te zien in Codefragment bool EngineSpace::Factory::saveCurrentEngine(){ Logger_ACTOR actor = Logger_ACTOR::_SYSTEM; std::ofstream ofs("engineconfiguration.xml"); if(ofs.fail()){ Logger::Log(Logger_LEVEL::_ERROR, "FACTORY:engineconfiguration.xml: unable to open", actor ); return false; xml_schema::namespace_infomap map; map[""].name = ""; map[""].schema = "engineconfiguration.xsd"; AuthenticationEngine (ofs, *xml, map); if(ofs.fail()){ Logger::Log(Logger_LEVEL::_ERROR, "FACTORY: engineconfiguration.xml: write error", actor ); return false; Logger::Log(Logger_LEVEL::_INFO, "FACTORY: SAVEengineconfiguration.xml: saving process successful", actor ); ofs.close(); return true; void EngineSpace::Factory::setXML( auto_ptr<authenticationengine_t> xml){ this->xml = xml; Codefragment 3.18: Opslaan van de engine configuratie (bovenaan) en het instellen van de XML (onderaan) 52

65 Een ander belangrijk element van de factory is de controller voor custom modules, ControllerForCustomModules genaamd. Deze controller is verantwoordelijk voor de aanmaak van custom modules. Dit zijn modules die de client zelf kan toevoegen aan de engine. In de header en cpp bestand van deze controller moeten op de juiste plaatsen aanpassingen gebeuren. Hoe dit precies uitgevoerd moet worden, wordt verder beschreven. In Codefragment 3.19 wordt getoond hoe een custom module door de factory precies wordt gemaakt. EngineSpace::Module* EngineSpace::Factory::createCustomModule( std::string type, std::string ID_){ EngineSpace::Module *module; module = controllerforcustommodules->outsourcemodule(type,id_); return module; Codefragment 3.19: Aanmaak van een custom module, samen met de controller voor custom modules Bij het ontwerpen van de factory, werd er rekening gehouden met een aantal principes. Eerst en vooral werd Program to an interface gebruikt. Zo kan er aan de factory gevraagd worden om een IAS authenticator te creëren. Dit gebeurt ook, maar de factory zal een referentie teruggeven aan de aanvrager, zijnde de configuration manager, naar een Authenticator object. Hierdoor is opnieuw de modulariteit van de engine bewaard en is het mogelijk om later nieuwe types te ontwerpen. Bij het ontwerp is zelfs nog een stap verder gegaan. Het fungeert volgens het Abstract Factory design pattern. Dit pattern is gebaseerd op Dependency Inversion wat bepaalt dat high-levelcomponenten niet afhankelijk mogen zijn van low-levelcomponenten. Programmacode moet afhankelijk zijn van abstracties en niet van concrete klassen. De factory houdt hier perfect rekening mee zodat in de toekomst bijvoorbeeld nieuwe moduletypes heel eenvoudig door factory kunnen aangemaakt worden en zo in de engine gebruikt kunnen worden. 3.6 Engine API en engine core Tot nu werd een beschrijving gegeven van de verschillende elementen van de engine, maar over een belangrijk element, al dan niet het belangrijkste, werd nog niets gezegd, namelijk de engine core. Zoals de naam al aangeeft, is dit het effectieve hart van de engine. Hier worden de requesten en responses bijgehouden. Alle functionaliteit met betrekking tot het uitvoeren van authenticaties, zit hier gebundeld. De core maakt requesten en voert deze uit met responses als resultaat. Zoals vermeld worden request ID s en response ID s teruggegeven naar de client via de engine API. Om de nodige informatie te voorzien bij authenticaties is het nodig dat de core informatie van de configuration manager kan halen en met een referentie is hierin voorzien. Bij het ontwerp van de Engine klasse werden twee belangrijke ontwerpbeslissingen genomen. Beiden worden voorgesteld als design patterns. Het gaat over het façade pattern en over het singleton pattern. Het façade pattern werd gebruikt met als doel dat de engine een API aanbiedt. De client wil zich niet bezighouden met verschillende objecten aan te maken om een simpele authenticatie uit te voeren. Hij verwacht een lijst van functies, die hij kan gebruiken voor welbepaalde functies die hij 53

66 bij zijn integratie nodig heeft. De interne structuur van de engine is uiteindelijke voor de client niet van belang. Het feit dat een façade gecreëerd wordt dat het interne subsysteem van de engine afschermt, maakt het gebruik van de functionaliteit een stuk eenvoudiger voor de client. Ook vanuit het standpunt van integratie, is dit handig. Net omdat integratie het grote probleem is bij klanten, werd de engine ontworpen. Een eenvoudige integratie van de engine in clientcode is dus een vereiste. Het principe van kennisabstractie is hier duidelijk toepasbaar. Het geeft aan dat met hoe minder objecten je moet interageren om een functionaliteit te gebruiken, hoe beter het is. In het geval van de engine is er dus maar één object waarmee de client moet communiceren. De tweede ontwerpbeslissing is gebaseerd op het singleton pattern. Kort samengevat geeft het aan dat er van een bepaalde klasse maar één object kan bestaan. Tijdens het ontwerpen van de engine werd er gedacht over hoe de client de engine precies wilt gebruiken. Daarbij is tot de conclusie gekomen dat wanneer meerdere objecten zouden bestaan, het niet meer duidelijk is dat het over de engine gaat. Aanpassingen kunnen namelijk gemaakt worden in de verschillende objecten wat in ieder geval tot inconsistentieproblemen leidt. Hierdoor werd gekozen om één enkel object van de engine toe te staan, zodat alle acties op dit éne object zouden plaatsvinden. Hoewel de client op meerdere plaatsen in zijn project de engine kan gebruiken, wordt toch altijd dezelfde instantie teruggegeven aan de klant. Twee kenmerkende eigenschappen van een API zijn dat het op een eenvoudige en eenduidige manier al zijn functionaliteit aanbiedt zodat de client deze heel gemakkelijk en flexibel kan integreren en dat een API effect heeft op één enkel object. Indien dit laatste niet voldaan is, ontstaan zoals hierboven beschreven consistentieproblemen en is de integriteit van de engine niet langer gevrijwaard. Daarom werd bij het ontwerpen van de engine met de twee beschreven design patterns rekening gehouden. Belangrijk om te beseffen is dat alle communicatie met de engine verloopt via de engine API. De beschrijving die hierboven gegeven werd, geeft een inzicht in de werking van de engine en de verschillende elementen die het bezit. De client kan echter geen operaties rechtstreeks op deze elementen uitvoeren. Het enige wat de client kan, is via de engine API functies aanroepen. Ze geven een controleerde toegang tot de vele mogelijkheden die de engine aanbiedt. In Appendix C vindt u de API van de engine. Om de volledige samenhang van de authenticatie engine te illustreren is op de volgende pagina het volledige klassendiagram weergegeven in Figuur Specifieke klassen gegenereerd door en xsd Code synthesis [13] en gsoap [14] werden niet weergegeven. Ook de klasse die instaat voor logging en tijdsbepaling werden niet weergegeven omdat de figuur niet meer overzichtelijk zou zijn. Deze twee klassen zijn ook zelfgeschreven klassen. Bestaande libraries zoals glog [16] boden na onderzoek te weinig flexibiliteit in het formaat hoe berichten precies gelogd zouden worden. Daarom werd een eigen statische Logger klasse geschreven. Het design en de implementatie zijn triviaal en werden daarom niet beschreven met een codevoorbeeld. Wel kan er vermeld worden dat deze klasse een statische functie Log heeft, die een boodschap, aangevuld met de tijd, gebruiker en prioriteit heeft. Met gebruiker wordt hier de client, of de engine zelf bedoeld. Een tweede statische klasse die heel even vermeld werd is EngineTime. Deze zorgt ervoor dat dat de tijd, cross platform, kan opgevraagd worden. Tijdsopvragingen wordt gebruikt door de logger bij elke log actie en door de testmanager, om de uitvoeringstijden van testen en scenario s te bepalen. 54

67 Figuur 3.11: UML klassendiagram authenticatie engine 55

68 Hoofdstuk 4 Authenticatieprocedures van de engine In dit hoofdstuk wordt er dieper ingegaan op de implementatie van de authenticatieprocedures die de engine heeft. De standaard methodes worden besproken aan de hand van de geproduceerde code. Er wordt ook een voorbeeld gegeven van een custom module. Dit is een module die de client zelf kan ontwikkelen en toevoegen aan de functionaliteit van de engine. 4.1 Standard methods In de specificaties van deze masterproef werd gesteld dat er standaard twee methodes aanwezig moeten zijn. Deze zijn IAS authenticatie aan de hand van SOAP en DPS authenticatie aan de hand van REST. Hoe deze geïmplementeerd zijn, wordt in de volgende secties beschreven IAS authenticatie using SOAP IAS authenticatie via SOAP is een methode die gebruik maakt van een IAS authenticator en de SOAP module. Eerst zal besproken worden hoe de authenticate functie werkt van de SOAP module. Vervolgens zal in detail worden gegaan over hoe de SOAP call gevormd wordt en hoe het resultaat van de IAS geïnterpreteerd wordt Authenticate functie Bij een SOAP authenticatie wordt de authenticate functie van de SOAP module opgeroepen, met de authenticator, request en response als parameter. In Codefragment 4.1 wordt dit geïllustreerd. Dit zijn echter allemaal verwijzingen. De vierde parameter geeft aan of de authenticatie het tweede deel is van een Two Step challenge/response authenticatie. De logging functie is overal weggelaten in de komende codefragmenten, dit opnieuw om de structuur duidelijker aan te tonen. 56

69 void EngineSpace::SoapModule::authenticate( EngineSpace::Authenticator* authenticator_, EngineSpace::Request* request_, EngineSpace::Response* response_, bool executesecondpartoftwostep); Codefragment 4.1: Functie declaratie authenticate soap module Het eerste wat in de authenticate functie gebeurt, is het bepalen van het authenticatietype, bijvoorbeeld OTPauth. Vervolgens worden de authenticatieparameters en de URL gehaald. In het geval van IAS authenticatie via SOAP is dit een IP adres. Daarna wordt in het antwoord de authenticatie als gefaald aangeduid. Indien de authenticatie lukt, zal die verder in de methode als geslaagd aangeduid worden. Na het ophalen van alle nodige informatie, wordt er nagegaan of de authenticator wel bereikbaar is. Indien deze niet bereikbaar is, wordt de methode direct beëindigd. Omdat in het begin de authenticatie als gefaald werd aangeduid, is dit geen probleem. Als deze wel bereikbaar is, wordt er verder gegaan. In Codefragment 4.2 wordt dit aangegeven. response_->setstandardstatuscode(standardstatuscode::in_progress); response_->seterrormessage(errormessage::no_error); std::string authenticationtype = authenticator_->getauthenticationtype(); map<std::string,std::string>options = authenticator_->getoptions(); std::string url = authenticator_->geturi(); response_->setisauthenticated(false); if(!authenticator_->checkavailability()){ response_->setstandardstatuscode( StandardStatusCode::EXECUTED_ERROR); response_->seterrormessage(errormessage::unreachable_authenticator); else { // continue Codefragment 4.2: Begin authenticate en check availability Nu wordt afhankelijk van het authenticatietype de bijhorende if-structuur uitgevoerd. In dit geval worden alle authenticatietypes ondersteund. Na het bepalen en vergaren van de nodige informatie wordt de correcte methode van de soapcontroller aangeroepen. Deze heeft in sommige gevallen uitvoerparameters, voor bijvoorbeeld de aanvraag van een challenge. Alle methodes van de SOAP controller geven echter een logische waarde terug, zodat op een eenvoudige manier kan nagegaan worden of de functie effectief correct uitgevoerd werd. Indien er fouten optraden, zal dit via een false aangegeven worden. Wanneer de authenticatie uiteindelijk slaagt, wordt in de response de authenticatie als geslaagd aangegeven. In het geval van een response only authenticatie is de implementatie relatief eenvoudig. De parameters voor de authenticatie worden opgehaald en slechts één enkele SOAP call is vereist van de SOAP controller. De belangrijkste stappen in code zijn weergegeven in het Codefragment

70 // start of otp if(authenticationtype == "OTPAUTH"){ std::string un = request_->getusername(); std::string dn = request_->getdomainname(); std::string p = request_->getpassword(); std::string ct = request_->getcomponenttype(); std::string pf = request_->getpasswordformat(); if(enginespace::soapcontroller::performotpauthentication( url,un,dn,p,ct,atoi(pf.c_str()))){ std::cout << "SOAPMODULE: authentication succeeded" << std::endl; response_->setstandardstatuscode( StandardStatusCode::EXECUTED_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); response_->setisauthenticated(true); else { std::cout << "SOAPMODULE: authentication failed " << std::endl; response_->setstandardstatuscode( StandardStatusCode::EXECUTED_NOT_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); std::cout << std::endl << "end of performing authentication procedure of SoapModule " << this->getmoduleid() << endl; std::cout << std::endl << authenticationtype << " authentication finished" << endl; // end of otp Codefragment 4.3: Implementatie response only authenticatiemethode voor SOAP module Voor de challenge/response authenticatiemethodes gebeuren er meer complexe stappen. Bij de One Step worden alle nodige parameters al opgegeven bij de creatie van de request. Indien de challenge echter in het configuratiebestand wordt aangegeven, moet deze niet meer meegegeven worden bij een request. Indien dit toch gebeurt, wordt hiermee geen rekening gehouden, omdat de authenticator geconfigureerd is om de challenge te gebruiken uit het configuratiebestand. Bij de Two Step methode gebeurt de authenticatie in twee stappen. De authenticate methode wordt dus twee keer opgeroepen. Daarom wordt er eerst bepaald in welke fase men zich bevindt. In de eerste fase wordt namelijk een challenge opgevraagd aan de IAS via de SOAP controller. Indien dit niet lukt, wordt hier de methode afgebroken en wordt de authenticatie als gefaald aangeduid. Het is dus niet zinvol om nog verder te gaan met het tweede luik van de authenticatie. Omdat het overzicht verloren zou gaan bij een codefragment, is er gekozen voor een diagram om het verloop van de One Step en de Two Step te illustreren, respectievelijk in Figuur 4.2 en Figuur 4.3. Een opmerking bij beide figuren moet gemaakt worden. Er is één functie authenticatie, die op basis van het authenticationtype, ONESTEPAUTH of TWOSTEPAUTH een ander pad volgt. In beide figuren is deze functionaliteit echter visueel opgesplitst voor de duidelijkheid. 58

71 Figuur 4.1: One Step gedeelte van de authenticate methode Figuur 4.2: Two Step gedeelte van de authenticate methode 59

72 SOAP controller De SOAP controller biedt 5 functies aan, voor authenticaties van response only methodes, voor authenticaties van challenge/response methodes en om challenges op te vragen. Er is voor gekozen om de authenticatie functie voor response only authenticatie te bespreken. Een beschrijving van de andere methodes is analoog. Om het overzicht niet te verliezen worden de andere complexe methodes niet in detail beschreven. De functionaliteit is uiteraard analoog. Om de correcte attributen mee te geven aan de SOAP call, werden de klassen waarvan de attributen objecten zijn, gegenereerd via de gsoap library, op basis van een wsdl-file. Ook een SOAP proxy werd op die manier gegenereerd. Het uitvoeren van een authenticatie wordt op die manier een stuk eenvoudiger. Eerst worden alle attributen geïnitialiseerd aan de hand van de parameters die de functie binnenkrijgt. Wanneer dit gebeurt is, wordt de authuser functie op de proxy uitgevoerd en wordt een SOAP_OK teruggegeven wanneer de SOAP call geslaagd is. Aan de hand van de attributen uit het antwoord van de IAS, kan afgeleid worden of de authenticatie gelukt is. Wanneer die mislukt is, zal de functie van de SOAP controller een false teruggegeven. Zo kan op een handige manier in de SOAP module nagegaan worden of de authenticatie al dan niet geslaagd is. Het volgend codefragment geeft in detail weer hoe dit via de gsoap klassen geïmplementeerd is. Opnieuw is de logger achterwege gelaten. Aanvankelijk werd gewerkt met de tinyxml [10] en tinybind [11] libraries gewerkt, want hier kan de XML mapping volledig gemanipuleerd worden. Dit was handig tijdens het experimenteren om XML elementen in C++ om te zetten. Later werd echter gsoap gebruikt, omdat hier de mapping naar C++ objecten dynamisch gebeurt. De klassen worden automatisch gegenereerd op basis van de wsdlfile. Hoe deze klassen precies gegenereerd worden, is uitvoerig beschreven op de website, terug te vinden de bibliografie. bool EngineSpace::SoapController::performOTPAuthentication( std::string url_, std::string param_username_, std::string param_domain_, std::string param_password_, std::string param_componenttype_, int param_passwordformat_){ AuthenticationProxy proxy; _ns2 authuser authuser; _ns2 authuserresponse response; ns3 CredentialAttribute userid; ns3 CredentialAttribute domain; ns3 CredentialAttribute password; ns3 CredentialAttribute componenttype; ns3 CredentialAttribute passwordformat; userid.attributeid = ns3 CredentialAttributeIDEnum::ns3 CredentialAttributeIDEnum CREDFLD_U SCOREUSERID; domain.attributeid = ns3 CredentialAttributeIDEnum::ns3 CredentialAttributeIDEnum CREDFLD_U SCOREDOMAIN; password.attributeid = ns3 CredentialAttributeIDEnum::ns3 CredentialAttributeIDEnum CREDFLD_U SCOREPASSWORD; componenttype.attributeid = ns3 CredentialAttributeIDEnum::ns3 CredentialAttributeIDEnum CREDFLD_U SCORECOMPONENT_USCORETYPE; passwordformat.attributeid = ns3 CredentialAttributeIDEnum::ns3 CredentialAttributeIDEnum CREDFLD_U SCOREPASSWORD_USCOREFORMAT; Codefragment 4.4: PerformOTPauthentication van SOAP controller 60

73 std::string content_userid = param_username_; std::string content_domain = param_domain_; std::string content_password = param_password_; std::string content_componenttype = param_componenttype_; int content_passwordformat = param_passwordformat_; xsd string xsd_string_userid; xsd string xsd_string_domain; xsd string xsd_string_password; xsd string xsd_string_componenttype; xsd int xsd_int_passwordformat; xsd_string_userid. item = content_userid; xsd_string_domain. item = content_domain; xsd_string_password. item = content_password; xsd_string_componenttype. item = content_componenttype; xsd_int_passwordformat. item = content_passwordformat; userid.value = &xsd_string_userid; domain.value = &xsd_string_domain; password.value = &xsd_string_password; componenttype.value = &xsd_string_componenttype; passwordformat.value = &xsd_int_passwordformat; vector<ns3 CredentialAttribute*>v; v.push_back(&userid); v.push_back(&domain); v.push_back(&password); v.push_back(&componenttype); v.push_back(&passwordformat); ns3 CredentialAttributeSet set; set.attributes = v; authuser.credentialattributeset = &set; if(proxy.authuser(url_.c_str(),0,&authuser,&response) == SOAP_OK){ std::cout << "...soap call success " << std::endl; ns5 ResultCodes *codes = response.authuserresults->results->resultcodes; if(codes->returncode == 0 && codes->statuscode == 0 && codes->returncodeenum == ns5 ReturnCodeEnum::ns5 ReturnCodeEnum RET_USCORESUCCESS && codes->statuscodeenum == ns5 StatusCodeEnum::ns5 StatusCodeEnum STAT_USCORESUCCESS){ cout << ">>> authenticated" << endl; return true; else { cout << ">>> not authenticated" << endl; return false; else { cout << "...soap call error" << endl; return false; Codefragment 4.5: Vervolg performotpauthentication van SOAP controller 61

74 4.1.2 DPS authenticatie using REST DPS authenticatie via REST is een methode die gebruik maakt van een DPS authenticator en de REST module. Zoals bij IAS authenticatie zal besproken worden hoe de authenticate functie werkt van de REST module. Vervolgens zal in detail worden gegaan over hoe de REST call gevormd wordt en hoe het resultaat van de DPS geïnterpreteerd wordt Authenticate functie Net zoals bij de voorgaande authenticatiemanier, worden hier ook eerst alle parameters opgehaald en wordt nagegaan of de authenticator bereikbaar is. Indien deze niet bereikbaar is, wordt de authenticate methode van de REST module afgebroken. Daarom wordt ook als eerste in het antwoord de authenticatie als mislukt aangeduid. Omdat deze code analoog is aan codefragment 4.2 zal de code in het geval van REST niet getoond worden. Wanneer alles in orde is, wordt er verder gegaan. Bij DPS authenticatie is alleen authenticatie nodig voor response only methodes. Challenge/response authenticatiemethodes worden dan ook niet ondersteund, maar kunnen eenvoudig toegevoegd worden in de authenticatiefunctie. Als REST gebruikt zou worden, zal de REST controller ook uitgebreid moeten worden, want deze ondersteund voorlopig ook alleen authenticaties via de response only authenticatiemethodes. Na het ophalen van alle parameters wordt een RestForm gemaakt. Dit is een structuur waarin alle nodige parameters in een correcte formatering in vervat zitten. Het wordt als parameters meegegeven aan de REST controller, samen met het authenticatietype, voor de authenticatiefunctie. In Codefragment 4.6 kunt u de logica volgen vanaf de start van de OTPauth selectie in de authenticate functie bij de REST module REST controller De REST controller biedt 3 publieke functies aan, namelijk een functie voor authenticaties uit te voeren, en twee andere voor de response only en One Step testing methodes. Voor deze laatste methode haalt de functie een challenge op. Voor de response only methode haalt de methode een OTP op. Deze functies zijn in de REST controller geïmplementeerd omdat ze gebruik maken van dezelfde achterliggende functionaliteit zoals REST calls. De REST calls worden uitgevoerd door de libcurl library van het curl [9] platform. Via de library kunnen HTTP GET en POST methodes uitgevoerd, en dat is net wat nodig is om de REST calls uit te voeren. Voor SOAP bestaat er zoals aangegeven de gsoap library, maar voor REST calls is dit niet te vinden. Daarom is er gekozen voor libcurl. Er werd weliswaar wel onderzocht of Casablanca C++ REST SDK [15] een oplossing zou bieden, maar na analyse van de mogelijkheden blijkt deze geen HTTPS te ondersteunen. Indien dit in latere versies wel beschikbaar zou zijn, kan geopteerd worden om een nieuwe REST module te implementeren. De RestForm die werd meegegeven als parameters wordt als eerste geanalyseerd en een correcte XML body wordt gegenereerd, met deze parameters incluis. Vervolgens wordt de URL geconstrueerd voor authenticaties naar het juiste DPS platform, voor de juiste applicatie. Hiervoor dienen de AID en de API parameters. Daarna worden via het curl framework de juiste headers ingesteld in het HTTP POST bericht en wordt het bericht gestuurd. De response van het DPS platform wordt opgevangen en indien het een positief antwoord bevat in de response-xml, dan geeft de authenticatiefunctie van de REST controller een true terug. Op die manier wordt het voor de REST 62

75 module eenvoudig om te checken als een authenticatie effectief gelukt is. Deze procedure staat afgebeeld in Codefragment 4.6. Codefragment 4.7 geeft de effectieve authenticatiefunctie weer. // start of otp if(authenticationtype == "OTPAUTH"){ // get OTPauth parameters std::string API = options.find("api")->second; std::string AID = options.find("aid")->second; std::string URI_START = options.find("uri_start")->second; std::string URI_END = options.find("uri_end")->second; std::string PROTOCOL = options.find("protocol")->second; std::string USINGURL = PROTOCOL + "://" + URI; // fill in XML REST form from request std::string username = request_->getusername(); std::string passwordotp = request_->getpassword(); std::string serial = request_->getserial(); map<std::string,std::string>parameters; parameters.insert(pair<std::string,std::string> ("username",username)); parameters.insert(pair<std::string,std::string> ("passwordotp",passwordotp)); parameters.insert(pair<std::string,std::string> ("serial",serial)); parameters.insert(pair<std::string,std::string> ("AID",AID)); parameters.insert(pair<std::string,std::string> ("API",API)); parameters.insert(pair<std::string,std::string> ("USINGURL",USINGURL)); parameters.insert(pair<std::string,std::string> ("URI_START",URI_START)); parameters.insert(pair<std::string,std::string> ("URI_END",URI_END)); RestForm form_(parameters); if(restcontroller::performdpsauthentication( form_, authenticationtype)){ std::cout << "RESTMODULE: authentication succeeded" << std::endl; response_->setstandardstatuscode( StandardStatusCode::EXECUTED_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); response_->setisauthenticated(true); else { std::cout << "RESTMODULE: authentication failed " << std::endl; response_->setstandardstatuscode( StandardStatusCode::EXECUTED_NOT_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); else { response_->setstandardstatuscode(standardstatuscode::executed_error); response_->seterrormessage( ErrorMessage::UNKNOWN_AUTHENTICATIONTYPE_FOR_USED_MODULE); Codefragment 4.6: Response only implementatie bij REST module in authenticate functie 63

76 bool EngineSpace::RestController::curlDPSfunc( RestForm form_, std::string authenticationtype_ ){ bool returnvalue = false; std::string USINGURL = form_.getparameters()-> find("usingurl")->second; std::string URI_START = form_.getparameters()-> find("uri_start")->second; std::string URI_END = form_.getparameters()-> find("uri_end")->second; std::string AID = form_.getparameters()-> find("aid")->second; std::string API = form_.getparameters()-> find("api")->second; std::string url; url.append(usingurl); url.append("/"+uri_start); url.append("/"+aid); url.append("/"+uri_end); char *uri = (char*)url.c_str(); CURL *curl; curl = curl_easy_init(); std::string readbuffer = ""; if(curl) { std::string xml = makedpsloginxml(form_, authenticationtype_ ); char *xmlp = (char*)xml.c_str(); /* configure curl parameters */ curl_easy_setopt(curl, CURLOPT_URL, uri); curl_easy_setopt(curl, CURLOPT_POST, 1); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, WriteCallback); curl_easy_setopt(curl, CURLOPT_WRITEDATA, &readbuffer); curl_easy_setopt(curl, CURLOPT_USERNAME, API.c_str()); //curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, FALSE); // W curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0); curl_easy_setopt(curl, CURLOPT_POSTFIELDS, xml.c_str()); curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, xml.length()); struct curl_slist *slist = curl_slist_append( NULL, "Content-Type: application/xml; charset=utf-8"); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, slist); /* perform http call */ curl_easy_perform(curl); /* clean up curl */ curl_slist_free_all(slist); curl_easy_cleanup(curl); curl_global_cleanup(); if(readbuffer!= ""){... std::string sub = readbuffer.substr(found_start,keyword.size() + LONGESTVALUE.size()+1); if(sub.find("true")==std::string::npos){returnvalue = false; else {returnvalue = true; std::cout << "Rest controller: authenticated" << endl; else {... // error messaging return returnvalue; Codefragment 4.7: Implementatie authenticatie rest controller 64

77 4.2 Custom modules Zoals eerder al aangegeven is het mogelijk om meerdere authenticatiemethodes toe te voegen aan de engine. Met de bestaande of nieuwe authenticators kunnen nieuwe methodieken uitgewerkt worden, bijvoorbeeld een module die een RADIUS authenticatie zou doen. Hieronder is een simpel voorbeeld uitgewerkt van een custom module. Ook de integratie in de engine wordt aangegeven Eigen module In deze paragraaf wordt beschreven welke stappen ondernomen moeten worden om een eigen module aan te maken en toe te voegen aan de engine. Een eigen module kan gemaakt worden door een nieuwe moduleklasse te schrijven, die afgeleid is van de klasse Module. Naast een constructor moet de abstracte functie authenticate geïmplementeerd worden, zoals in codefragmenten hierboven al besproken werd. De implementatie en de declaraties moeten in twee aparte bestanden gebeuren, respectievelijk een header en een cpp bestand. Een voorbeeld van een custom module header bestand is te vinden Codefragment 4.8. #ifndef CUSTOMMODULE_H #define CUSTOMMODULE_H #include "Module.h" #include "customenums.h" #include "Authenticator.h" namespace EngineSpace { /* This class is a custom module */ class CustomModule : public Module { public: // constructor CustomModule(std::string ID_); ; // authentication function void authenticate( EngineSpace::Authenticator* a, EngineSpace::Request* req, EngineSpace::Response* rep); private: #endif /* CUSTOMMODULE */ Codefragment 4.8: Header bestand van een custom module Opdat de engine de custom module zou kunnen gebruiken, moet hij geregistreerd zijn bij de engine. Dit kan aan de hand van de engine API, maar alvorens dit kan, moeten de ControllerForCustomModules op de hoogte zijn dat deze klasse bestaat. Hiervoor is het noodzakelijk dat er enkele aanpassingen gebeuren in deze klasse. 65

78 Ten eerste moet de juiste header geïncludeerd worden. Vervolgens moet er een nieuwe ifstructuur toegevoegd worden in het outsourcemodule functie. Daarna moet een nieuw record aangemaakt worden in de custummoduledictionary in de translator header. Deze header bevat de statische klasse Translator en doet alle opzoekingen in verband met enums voor de engine. Hiervan een codevoorbeeld geven draagt niet bij tot het begrijpen van de functionaliteit en wordt daarom dus niet gedaan. Het aan te passen stuk wordt wel getoond in Codefragment XXX. Als laatste moet de nieuwe module ook nog toegevoegd worden aan de enum ENGINESPACE_Custom_Module_TYPE in het headerbestand customenums. In Sectie wordt een concreet voorbeeld gegeven van een module CustomModule die wordt toegevoegd. Het headerbestand is te zien in Codefragment Voorbeeld van een custom module Hier wordt een concreet voorbeeld uitgewerkt van een module. In Sectie werd aangegeven hoe deze geïntegreerd moet worden. De code van het voorbeeld is Codefragment 4.9 te vinden. Zoals uit het voorbeeld duidelijk blijkt, controleert deze module louter de gelijkenis tussen de username en het password. Wanneer beiden gelijk zijn, is de client geauthentiseerd. Een authenticator is hier zelfs niet nodig. In praktijk zal bij een custom module dit echter wel nodig zijn. #include "CustomModule.h" EngineSpace::CustomModule::CustomModule(std::string ID_) : Module(EngineSpace::CustomModule_TYPE::CustomModuleMODULE, ID_){ void EngineSpace::CustomModule::authenticate( Authenticator *authenticator_, Request *request_, Response *response_, Bool *notused_){ // authenticator is not used here, since that's a server of service for a real authentication response_->setisauthenticated(false); response_->setstandardstatuscode(standardstatuscode::in_progress); response_->seterrormessage(errormessage::no_error); std::string username = request_->getusername(); std::string password = request_->getpassword(); std::string authenticatorid = authenticator_->getauthenticatorid(); std::cout << " --ATTENTION: This custom module is part of a method where that method doesn't use an authenticator. " << std::endl; if(username==password){ // success response_->setstandardstatuscode( StandardStatusCode::EXECUTED_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); response_->setisauthenticated(true); else { // no success response_->setstandardstatuscode( StandardStatusCode::EXECUTED_NOT_AUTHENTICATED); response_->seterrormessage(errormessage::no_error); response_->setisauthenticated(false); Codefragment 4.9: Codebestand van de custom module 66

79 Vervolgens moet de ControllerForCustomModules op de hoogte zijn van de nieuwe module. In Codefragment 4.10 en Codefragment 4.11 ziet u het headerbestand en het codebestand en hoe dit moet gedaan worden. #ifndef CONTROLLERFORCUSTOMMODULES_H #define CONTROLLERFORCUSTOMMODULES_H /* important: only add/change/remove code where it says in comment */ #include <iostream> #include <map> #include <string> #include <cassert> #include "Module.h" #include "customenums.h" /* header files of new modules need to be added here*/ #include "CustomModule.h" namespace EngineSpace { class ControllerForCustomModules {... ; #endif /* CONTROLLERFORCUSTOMMODULES */ Codefragment 4.10: Headerbestand ControllerForCustomModules.h #include "ControllerForCustomModules.h" EngineSpace::ControllerForCustomModules::ControllerForCustomModules(){ EngineSpace::Module* EngineSpace::ControllerForCustomModules::outsourceModule( std::string type, std::string ID_){ EngineSpace::Module *m = 0; if(enginespace::translator::isvalidcustommoduletype(moduletype_)){ /* if(moduletype_ == EngineSpace::ENGINESPACE_Custom_Module_TYPE::EXAMPLEMODULE){ m = new ExampleModule( ID_); */ /* add the custom models here, like the example above shows */ if(moduletype_ == EngineSpace::ENGINESPACE_Custom_Module_TYPE::CUSTOMMODULE){ m = new CustomModule( ID_); else { std::cout << " the custom module " << ID_ << " not found in the correct header and source files" << std::endl; Codefragment 4.11: Codebestand ControllerForCustomModules.cpp 67

80 Daarna moet er een record bijkomen in de Translator. In Codefragment 4.12 wordt getoond hoe dit de gebruiker dit moet doen. #ifndef TRANSLATOR_H #define TRANSLATOR_H... namespace EngineSpace { class Translator {... static void init(... ){... custommoduledictionary.insert( pair<enginespace_custom_module_type,std::string>( ENGINESPACE_Custom_Module_TYPE::CUSTOM_MODULE_TYPE_FAULT,"FAULT")); ; /* add your custom records below like the one above */ custommoduledictionary.insert( pair<enginespace_custom_module_type,std::string>( ENGINESPACE_Custom_Module_TYPE::CUSTOMMODULE,"CUSTOM")); #endif /* TRANSLATOR_H */ Codefragment 4.12: Translator.h Als laatste stap moet het klasse nog toegevoegd worden aan de ENGINESPACE_Custom_Module_TYPE enum. Hoe dit gebeurt, is weergegeven in Codefragment #ifndef CUSTOMENUMS_H #define CUSTOMENUMS_H namespace EngineSpace { enum ENGINESPACE_Custom_Module_TYPE { CUSTOM_MODULE_TYPE_FAULT ; /* add your type here and do not touch the first one CUSTOM_MODULE_TYPE_FAULT */,CUSTOMMODULE #endif /* CUSTOMENUMS_H */ Codefragment 4.13: CustomEnums.h 68

81 Hoofdstuk 5 Integratie van de engine In dit korte hoofdstuk wordt besproken hoe de engine kan ingezet worden in andere programmeeromgevingen. Er zijn verschillende mogelijkheden. Zo kan de code naar een executable gecompileerd worden. Er kan ook worden gebruikgemaakt van een library, die C++ code aanroepbaar maakt vanop allerlei programmeerplatformen, van Java tot.net omgevingen en zelfs php bijvoorbeeld. De integratiemogelijkheden die hier zullen besproken worden maken gebruik van deze library, de Swig library [17]. Omdat dit gedeelte eigenlijk een uitbreiding is van deze masterproef en wegens de beperkte tijd, werden drie voorbeelden uitgewerkt hoe C++ code in deze omgevingen kan geïntegreerd worden. Met de geïllustreerde werkwijzen moet het mogelijk zijn de engine aan te roepen vanuit deze omgevingen. 5.1 C++ integratie In deze scriptie werden al voorbeelden geven van het gebruik van de engine. In bijlage D wordt in Hoofdstuk 4 van de Authenticatie Engine Documentatie een groter Codefragment getoond, zoals deze in realiteit kan geïntegreerd worden. Er is een client programma gemaakt waarin de gebruiker zich kan authentiseren, testen en scenario s kan uitvoeren en de configuratie opslaan, na een aantal voor gedefinieerde bewerkingen. Om het overzicht te bewaren wordt hier alleen het opzetten van de engine getoond, samen met een authenticatie-uitvoering. 69

82 #include "Engine.h" #include <iostream> using namespace std; using namespace EngineSpace; int main(){ cout << "create engine pointer" << endl; Engine* engine; cout << "set logging" << endl; #ifdef _WIN32 Engine::setLoggingPathAndFilename( "C:\\temp","authentication_engine_log.txt"); #elif unix Engine::setLoggingPathAndFilename( "/home/wim","authentication_engine_log3.txt"); #endif engine = Engine::getInstance(); assert(engine!= NULL); performauthentication(engine); return 0; void performauthentication(engine* engine){ int requestnr = -1; std::string serial = ""; cout << "Enter methodid: "; std::string methodid; cin >> methodid; std::string OTP = ""; if(methodid == "m22"){ cout << "Enter username: "; std::string username; cin >> username; cout << endl << "Enter OTP: "; cin >> OTP; requestnr = engine->createrequest( "m22",username,"",otp,"","","testags","0",""); int responsenr = engine->authenticate(methodid,requestnr); if(methodid == "m41" methodid =="m42"){ std::string challenge = ""; if(engine->getchallengefromtwostepauthenticationinprogress( responsenr, challenge)){ cout <<"Enter response on challenge='"<<challenge<<"' : "; std::string response; cin >> response; if(engine->provideresponsefortwostepauthentication( responsenr,response)) cout << "MAIN: provideresponse gelukt" << endl; if(engine->isauthenticated(responsenr)) cout << endl << "MAIN: authenticatie GELUKT" << endl; else cout << endl << "MAIN: authenticatie GEFAALD" << endl; engine->checkresponseinformation(responsenr); Codefragment 5.1: Integratie C++ 70

83 5.2 C# integratie In deze sectie wordt getoond hoe een C++ klasse gebruikt kan worden in een.net C# omgeving. Lidfuncties en membervariabelen van objecten van deze klasse kunnen aangeroepen worden en gemanipuleerd worden. De codefragmenten komen uit de Swig documentatie. #include "example.h" #define M_PI /* Move the shape to a new location */ void Shape::move(double dx, double dy) { x += dx; y += dy; int Shape::nshapes = 0; double Circle::area(void) { return M_PI*radius*radius; double Circle::perimeter(void) { return 2*M_PI*radius; double Square::area(void) { return width*width; double Square::perimeter(void) { return 4*width; Codefragment 5.2: Codebestand example.cpp [17] class Shape { public: Shape() { nshapes++; virtual ~Shape() { nshapes--; double x, y; void move(double dx, double dy); virtual double area() = 0; virtual double perimeter() = 0; static int nshapes; ; class Circle : public Shape { private: double radius; public: Circle(double r) : radius(r) { virtual double area(); virtual double perimeter(); ; class Square : public Shape { private: double width; public: Square(double w) : width(w) { virtual double area(); virtual double perimeter(); ; Codefragment 5.3: headerbestand example.h [17] 71

84 In Codefragment 5.2 en Codefragment 5.3 worden respectievelijk het codebestand en het headerbestand getoond van de te integreren klasse. Hieronder in Codefragment 5.4 wordt de uiteindelijke implementatie getoond in C#. Dit komt ook uit de documentatie van Swig. // This example illustrates how C++ classes can be used from C# using SWIG. // The C# class gets mapped onto the C++ class and behaves as if it is a C# class. using System; public class runme { static void Main() { // Object creation Console.WriteLine( "Creating some objects:" ); using (Square s = new Square(10)) using (Circle c = new Circle(10)) { Console.WriteLine( " Created circle " + c ); Console.WriteLine( " Created square " + s ); // Access a static member Console.WriteLine( "\na total of " + Shape.nshapes + " shapes were created" ); // Member data access c.x = 20; c.y = 30; // Now use the same functions in the base class Shape shape = s; shape.x = -10; shape.y = 5; // Call some methods Shape[] shapes = {c,s; // for (int i=0; i<shapes.size; i++) for (int i=0; i<2; i++) { Console.WriteLine( " " + shapes[i].tostring() ); Console.WriteLine( " area = " + shapes[i].area() ); Console.WriteLine( " perimeter = " + shapes[i].perimeter() ); // Note: when this using scope is exited the C# Dispose() methods // are called which in turn call the C++ destructors Codefragment 5.4: Integratie C# uit runme.cs [17] 72

85 5.3 Java integratie Dit is een belangrijke integratie, omdat Java een programmeertaal is die steeds meer aan belang wint. Wegens de JVM (Java Virtual Machine) is het mogelijk dezelfde code te gebruiken op verschillende platformen zoals UNIX en Microsoft Windows, zonder de moeilijkheden van platformafhankelijke dependencies. Ook hier is het mogelijk om de C++ authenticatie engine aan te roepen vanuit Java. Opnieuw werd een simpel voorbeeld uitwerkt van een C++ klasse in Java. Via deze werkwijze moet het ook hier mogelijk deze toe te passen op de code van de engine, met als doel de engine te gebruiken in Java-omgevingen. Zoals in Sectie 5.2 komt de code in het voorbeeld ook uit de Swig documentatie. Codefragment 5.2 en Codefragment 5.3 worden hier gebruikt. Codefragment 5.5 en Codefragment 5.6 geven de Java implementatie weer. // This example illustrates how C++ classes can be used from Java using SWIG. // The Java class gets mapped onto the C++ class and behaves as if it is a Java class. public class runme { static { try { System.loadLibrary("example"); catch (UnsatisfiedLinkError e) { System.err.println("Native code library failed to load. See the chapter on Dynamic Linking Problems in the SWIG Java documentation for help.\n" + e); System.exit(1); public static void main(string argv[]) { // Object creation System.out.println( "Creating some objects:" ); Circle c = new Circle(10); System.out.println( " Created circle " + c ); Square s = new Square(10); System.out.println( " Created square " + s ); // Access a static member System.out.println( "\na total of " + Shape.getNshapes() + " shapes were created" ); // Member data access // Notice how we can do this using functions specific to // the 'Circle' class. c.setx(20); c.sety(30); Codefragment 5.5: Java integratie runme.java [17] 73

86 // Now use the same functions in the base class Shape shape = s; shape.setx(-10); shape.sety(5); System.out.println( "\nhere is their current position:" ); System.out.println( " Circle = (" + c.getx() + " " + c.gety() + ")" ); System.out.println( " Square = (" + s.getx() + " " + s.gety() + ")" ); // Call some methods System.out.println( "\nhere are some properties of the shapes:" ); Shape[] shapes = {c,s; for (int i=0; i<shapes.length; i++) { System.out.println( " " + shapes[i].tostring() ); System.out.println( " area = " + shapes[i].area() ); System.out.println( " perimeter = " + shapes[i].perimeter() ); // Notice how the area() and perimeter() functions really // invoke the appropriate virtual method on each object. // Delete everything System.out.println( "\nguess I'll clean up now" ); // Note: this invokes the virtual destructor // You could leave this to the garbage collector c.delete(); s.delete(); System.out.println( Shape.getNshapes() + " shapes remain" ); System.out.println( "Goodbye" ); Codefragment 5.6: Java integratie runme.java (vervolg) [17] 74

87 Hoofdstuk 6 Mogelijke uitbreidingen 6.1 SSL Een mogelijke uitbreiding voor de engine kan de ondersteuning zijn voor SSL bij de communicatie voor SOAP naar IAS. Ook bij REST naar DPS is dit mogelijk. Omdat bij SSL libraries opnieuw moesten gecompileerd worden, is geopteerd om dit als uitbreiding te beschouwen. Het gsoap framework, waarvan gebruikgemaakt werd om de SOAP klassen te genereren, ondersteunt SSL dus als het gewenst is, kunnen deze SSL compatibel gemaakt wordt. Ook het curl framework ondersteunt SSL. Enkele libraries moeten dan toegevoegd aan de code van de engine, zodat certificaten kunnen gebruikt worden. Meer informatie kan gevonden op onderstaande links. Voor gsoap [14]: Voor curl [9]: Multi-threading Bij het ontwerp is gekozen om geen multi-threading te ondersteunen. De reden hiervoor is dat de code moet kunnen worden toegevoegd aan een bestaand softwareproject. Om de eenvoud te bewaren, werd gekozen om multi-threading niet te gebruiken. Een van de redenen voor het bestaan van de engine is net om de implementatie te vereenvoudigen voor klanten. Indien er toch in de toekomst geopteerd zou worden om de engine meerdere threads te laten gebruiken, dan hoeven er geen ingrijpende aanpassingen gebeuren aan de engine. Aangezien de authenticatiefunctionaliteit geïsoleerd werd door middel van de Engine Core, kan deze in een aparte thread uitgevoerd worden. Telkens wanneer een authenticatieaanvraag afgehandeld zou worden, kan een nieuwe thread dit voor zijn rekening nemen. 75

88 6.3 Encryptie van het configuratiebestand Het configuratiebestand is nu in plain text opgesteld en kan manueel aangepast worden. Wegens veiligheidsredenen kan dit later geëncrypteerd worden. Aangezien het configuratie volledig ingelezen wordt bij het opstarten van de engine, kan hier een decryptie gebeuren. Daarenboven is er ook maar één functie verantwoordelijk voor de opslag van de configuratie van de engine naar het configuratiebestand. Dit is dus ook ideaal om een eventuele encryptie uit te voeren. 6.4 Schedule voor testing Een laatste mogelijke uitbreiding situeert zich op het gebied van testing van de authentication engine. Zoals vermeld in Hoofdstuk 3 is er een testfunctionaliteit ingebouwd in de engine dat volledig geautomatiseerd testen en scenario s kan uitvoeren. Natuurlijk is het nog altijd nodig dat de client de test of scenario laat uitvoeren via een API call. Ook de resultaten moet hij nog opvragen via een functie uit de engine API. Daarom zou een mogelijke uitbreiding het volgende kunnen inhouden. De scenario s zouden ingekapseld kunnen worden in een groter object, dat ook een soort planning kan bijhouden, een schedule. Met behulp van de systeemklok zou de engine dan in staat zijn zelf testen of scenario s uit te voeren en resultaten te melden aan de client, via de reportfunctie. Gecombineerd met een automatische mailingfunctie zou dit het beheer van de engine nog een stap verder drijven in een geautomatiseerde software. In dit geval zou het handiger zijn als de engine software als een standalone softwarepakket gecompileerd zou worden. 76

89 Conclusie De authenticatie engine voldoet aan alle specificaties zoals voor deze masterproef bepaald. Aan de eis van modulariteit van de engine werd tegemoet gekomen op meerdere gebieden. Zo wordt er vele plaatsen gebruik gemaakt van het principe Program to an interface. Een voorbeeld is de authenticate functie. Er worden telkens authenticator-pointers meegegeven en niet specifiek een IAS of een DPS. Een ander voorbeeld zijn de modules. Afhankelijk van het type bepaald in het configuratiebestand wordt de correcte module ingeladen. Zoals aangetoond werd, kunnen nieuwe modules eenvoudig toegevoegd worden aan de engine. Na een paar kleine aanpassingen kan de nieuwe module gebruikt worden zoals een standaard module. Er is ook voor gezorgd dat de code van de engine cross platform werkt. Door op de correcte plaatsen het onderscheid te maken tussen de verschillende operating systems kan de code eenvoudig gecompileerd worden op de platforms waar het ondersteund wordt. Dit zijn de UNIX omgevingen en ook het Microsoft Windows platform. Dankzij het gebruik van standaard bibliotheken werd rekening gehouden met de kwaliteit van de geproduceerde code. De gebruikte bibliotheken gsoap, curl en XSD Code Synthesis worden goed onderhouden en zijn onderhevig aan welbepaalde kwaliteitseisen. Omdat de engine voor deze functionaliteit hierop steunt, werd ook de kwaliteit van de code van de engine gewaarborgd. Vanuit design standpunt werd een uitgebreide analyse gemaakt om zo efficiënt mogelijk de code te laten werken en te onderhouden. Verschillende design patterns werden gebruikt om de structuur van de engine zo overzichtelijk mogelijk te houden. Dit resulteert in een strakke authenticatie engine, die nog mogelijkheden biedt voor extra ontwikkeling. Uitbreidingen zijn mogelijk zonder ingrijpende codeveranderingen. De bestaande structuur kan behouden worden en met de nodige refactoring kan de API van de engine nog verder uitgebreid worden in de toekomst. Een ander belangrijk element is de uitvoerige studie van de twee authenticatieproducten van VASCO waardoor rekening kon gehouden worden met details bij de implementatie van de engine. Zo lijkt het niet mogelijk bij een One Step authenticatiemethode een challenge eerst aan te vragen, hoewel dit wel degelijk mogelijk is. De lezer heeft misschien al gemerkt dat de API van de engine veel uitgebreider is dan alleen een authenticatiefunctie. Dit komt omdat de engine een zo volledig mogelijke API aan de klant wil bieden. Net omdat de engine het enige element hoort te zijn waarmee client-software communiceert, is dat een belangrijk aspect aan de engine. Als laatste voordeel aan de engine kan de testing functionaliteit aangestipt worden. Wanneer authenticaties falen of om de performantie te testen van de engine, hoeft geen additionele software ontwikkeld worden. De API van de engine biedt functies aan die de klant kan aanwenden voor zowel load als function testing. Dit vereenvoudigt het beheer en onderhoud van de engine en de connecties met de IAS en het DPS platform. 77

90 Samenvattend kan er dus besloten worden dat de engine een samenhangend geheel is dat de integratie bij klanten van IDENTIKEY Authentication Server en DIGIPASS as a Service sterk vereenvoudigt. Gebruikerscomfort en integratie-eenvoud werden niet uit het oog verloren tijdens het ontwerpen en ontwikkelen van de engine dankzij de uitgebreide analyse en literatuurstudie. Een belangrijke opmerking blijft dat de klant natuurlijk op de hoogte moet zijn van de principes waarop de engine steunt, bijvoorbeeld Two Factor authentication en de verschillende authenticatiemethodes, zijnde de response only methodes en de challenge/response methodes. Alleen zo kan de functionaliteit van de authentication engine tot zijn volle recht komen. Wanneer de klant hiervan kennis heeft, kan hij de engine aanwenden in zijn bestaande softwareomgeving en kan hij authenticaties efficiënt en performant uitvoeren via de engine. 78

91 Bibliografie Interne trainingen (Vasco Data Security NV/SA SEAL trainingen, [1] VASCO SEAL, VASCO IDENTIKEY Server 3.5 Curriculum, intern trainingsprogramma door VASCO SEAL, voltooid tijdens stageperiode in September 2013 [2] VASCO SEAL, VASCO DIGIPASS as a Service B2E Curriculum, intern trainingsprogramma door VASCO SEAL, voltooid tijdens stageperiode in September 2013 [3] VASCO SEAL, VASCO DIGIPASS for ENTERPRISE Security, intern trainingsprogramma door VASCO SEAL, voltooid tijdens stageperiode in September 2013 Boeken [4] S. Lippman, J. Jajoie en B. Moo, C++ Primer Fifth Edition, Boston: Pearson Addison-Wesley, 2013 [5] J. Cnops, Programmaontwerp en realisatie, Tielt: Lannoo, 2005 [6] E. Freeman en E. Freeman, Train je hersenen in design patterns, Leuven: Lannoo, 2007 [7] L. Pollefliet, Schrijven: van verslag tot eindwerk, Gent: Academia Press, 2013 Online documentatie en open source code projecten [8] Gvanem, Codevoorbeeld httpput.c, geraadpleegd op 12 september 2013 [9] curl, Documentation Stuff to Read, geraadpleegd op 12 september 2013 [10] L. Thomason, TinyXML Tutorial, geraadpleegd op 18 februari 2014 [11] Eries, tinybind sourceforge project, geraadpleegd op 18 februari 2014 [12] SMARTBEAR, SoapUI, geraadpleegd op 27 Februari 2014 [13] Code Synthesis, C++/Tree Mapping Getting Started Guide, geraadpleegd op 10 april 2014 [14] Engelen (engelen@acm.org), The gsoap Toolkit for SOAP and REST Web Services and XML-Based Applications, geraadpleegd op 17 april

92 [15] Microsoft Garage, C++ REST SDK (codename Casablanca), geraadpleegd op 29 april 2014 [16] Shinichi et al., google-glog logging library for C++, geraadpleegd op 6 mei 2014 [17] Swig, SWIG-3.0 Documentation, geraadpleegd op 22 mei 2014 [18] baremetalsoft.com, BareTail, geraadpleegd op 6 mei 2014 [19] Microsoft, Developer Network website, geraadpleegd gedurende de volledige masterproefperiode (September 2013 Juni 2014) 80

93 Appendix A: IDENTIKEY Authentication Server Screenshot inlogpagina IAS Screenshot homepagina IAS 81

94 Appendix B: DIGIPASS as a Service Screenshot inlogpagina DPS Screenshot homepagina DPS 82

95 Appendix C: Engine API // sets the logging path bool setloggingpathandfilename( std::string directory, std::string filename); // constructor Engine(); // destructor ~Engine(); // get report with report ID bool createreport( int reportid, std::string &report); // execute a test and returns a report ID int executetest( std::string testid); // execute a scenario and returns a report ID int executescenario( std::string scenarioid); // creates a new request for the user and returns the ID linked with the // new request int createrequest( std::string usingmethodid, std::string username_, std::string domainname_, std::string password_, std::string challenge_, std::string response_, std::string componenttype_, std::string passwordformat_, std::string serial_); // perform an authentication and returns the ID of the response linked to // the authentication process int authenticate( std::string methodid, int requestid); // provide the response to the engine while being in a two step // authentication process bool provideresponsefortwostepauthentication( int responseid, std::string response); // gets the challenge from an authentication in process bool getchallengefromtwostepauthenticationinprogress( int responsenr, std::string &challenge); 83

96 // gets a challenge from server to perform an one step authentication bool getchallengeforonestepauthentication( std::string methodid_, std::string username, std::string componenttype, std::string &challenge); // checks if the response contains a successful answer bool isauthenticated( int responseid); // gets detailled response information std::string checkresponseinformation( int responseid); // first function to be called bool init(); // saves the current engine configuration bool savecurrentengine(); // adds a module to the engine and in xml bool addmoduledynamic( std::string ID_, std::string headername_); // adds an authenticator to the engine and in xml bool addauthenticatordynamic( std::string ID_, std::string TYPE_, std::string headername_, std::string use_, std::string URI_, std::string authenticationtype_, map<std::string,std::string>keywords); // adds a method to the engine and in xml bool addmethoddynamic( std::string methodid_, std::string usingmoduleid_, std::string usingauthenticationid_); // adds a test to the engine and in xml bool addtestdynamic( std::string ID_, std::string type_, std::string method_, map<std::string,std::string>keywords_); // adds a scenario to the engine and in xml bool addscenariodynamic( std::string ID_, std::string description_, multimap<std::string,std::string> linkedtests_); // removes a module to the engine and in xml bool removemoduledynamic( std::string ID_); // removes an authenticator to the engine and in xml bool removeauthenticatordynamic( std::string ID_); // removes a method to the engine and in xml bool removemethoddynamic( std::string ID_); // removes a test to the engine and in xml bool removetestdynamic( std::string ID_); 84

97 Appendix D: Engine documentatie Op de volgende pagina s wordt de integrale Authentication Engine documentatie weergegeven. De paginanummers rechts onderaan van deze scriptie zijn hier weggelaten voor de duidelijkheid. 85

98 DOCUMENTATIE - HANDLEIDING Auteur: Wim Verdonck Authenticatie Engine