Federated Authentication Benchmarking Framework

Scriptie ingediend tot het behalen van de graad van PROFESSIONELE BACHELOR IN DE ELEKTRONICA-ICT

Federated Authentication Benchmarking Framework Tom Dierckx en Ward Gubbi Departement Wetenschappen en Techniek Opleiding Elektronica-ICT Academiejaar 2014-2015

Interne promotor: Yves Masset Externe promotor: Maarten Wouters

Versie: 11 juni 2015

Dankwoord

Allereerst zouden wij de docenten van de opleiding Elektronica-ICT van de Artesis Plantijn Hogeschool willen bedanken voor de ondersteuning de voorbije jaren. Zonder hun hulp was het tot vorm komen van deze scriptie nooit mogelijk geweest. Ook willen we iedereen bij IS4U bedanken om ons de mogelijkheid te geven stage te lopen in hun bedrijf en voor de goede ondersteuning tijdens het uitwerken en verwezelijken van dit document. Antwerpen, 11 juni 2015 Tom Dierckx en Ward Gubbi

i

Abstract Er bestaan verschillende authenticatie methodes, elk met zijn eigen sterktes en zwaktes. Een groot probleem is het kunnen definiëren welke het snelst en meest performant is. Er is een grote nood naar een framework dat de mogelijkheid geeft om verschillende authenticatietype’s te vergelijken en hier direct feedback op te geven. We kozen ervoor de volledige authenticatieprocedure te simuleren, alsof het in een browser zou uitgevoerd worden. Door de procedure te volgen die een normale gebruiker moet doorgaan kunnen we resultaten verkrijgen die overeenkomen met de realiteit. Daarnaast werken we de trage reactietijd van een gebruiker volledig weg. Elke authenticatie methode is appart geschreven en dan gebundeld in een overkoepelend framework.

ii

Inhoudsopgave

Dankwoord

i

Abstract

ii

1 Inleiding 1.1 Testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 5 5

2 Bespreking 2.1 Authenticatie- en authorisatiemechanismen 2.1.1 Gebruikersnaam en wachtwoord . . 2.1.2 SAML 2.0 . . . . . . . . . . . . . 2.1.3 OAuth 2.0 . . . . . . . . . . . . . 2.1.4 eID . . . . . . . . . . . . . . . . . 2.2 Testomgeving . . . . . . . . . . . . . . . 2.2.1 OpenAM . . . . . . . . . . . . . . 2.2.2 eID . . . . . . . . . . . . . . . . . 2.3 Framework . . . . . . . . . . . . . . . . . 2.3.1 Gebruikers interface . . . . . . . . 2.3.2 Data logging . . . . . . . . . . . . 2.3.3 HTML Extractie . . . . . . . . . . 2.3.4 Gebruikersnaam en wachtwoord . . 2.3.5 SAML 2.0 . . . . . . . . . . . . . 2.3.6 OAuth 2.0 . . . . . . . . . . . . . 2.3.7 eID . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

7 7 8 9 17 20 22 22 30 31 32 34 40 42 44 46 48

3 Resultaten 3.1 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Basisdoelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Extra Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 50 50 50

iii

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

INHOUDSOPGAVE 3.2

Behaalde resultaten . . . . . . . . 3.2.1 Problemen en oplossingen . 3.2.2 Niet behaalde doelstellingen 3.2.3 SAML studie . . . . . . . .

iv . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

50 51 51 51

4 Besluit

53

A Handleiding

54

B eID authenticatie

61

Lijst van figuren

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24

SAML SP-Initiated SSO: POST/POST . SAML SP-Initiated SSO: Redirect/POST . SAML SP-Initiated SSO: POST/Artifact . SAML SP-Initiated SSO: Redirect/Artifact SAML IdP-Initiated SSO: Artifact . . . . . SAML IdP-Initiated SSO: POST . . . . . . SAML Voorbeeld . . . . . . . . . . . . . . OAuth Protocol Flow . . . . . . . . . . . OAuth Voorbeeld . . . . . . . . . . . . . eID Certificate-based authentication . . . . 2-way SSL authentication . . . . . . . . . Policy Agent . . . . . . . . . . . . . . . . SAML: Federation . . . . . . . . . . . . . SAML: WebAgent SSO . . . . . . . . . . OAuth: Authorization Server . . . . . . . OAuth: Client registratie . . . . . . . . . . OAuth: Client Authenticatie Module . . . Gebruikers interface . . . . . . . . . . . . Settings-venster . . . . . . . . . . . . . . Kibana . . . . . . . . . . . . . . . . . . . Kibana: Methodes . . . . . . . . . . . . . Kibana: Bindings . . . . . . . . . . . . . . Kibana: Dashboard . . . . . . . . . . . . Toestemmingspagina . . . . . . . . . . . .

3.1

SAML SP-Initiated SSO: POST/POST

v

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

10 11 12 13 14 15 16 17 19 20 21 23 25 26 27 28 29 32 33 38 38 39 39 47

. . . . . . . . . . . . . . . . . . . .

52

Verklarende woordenlijst

Acroniemen eID Elektronische Identiteitskaart HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IdP Identity Provider OASIS Organization for the Advancement of Structured Information Standards SAML Security Assertion Markup Language SOAP (oorspronkelijk) Simple Object Access Protocol SP Service Provider SSL Secure Sockets Layer SSO Single sign-on SLO Single logout TLS Transport Layer Security

1

LIJST VAN FIGUREN

2

Verklaringen Asymmetrische cryptografie Een overkoepelende term voor codering waarbij gebruik gemaakt wordt van 2 sleutels. Een om te vercijferen (Public Key) en een andere om te oncijferen (Private Key). Certificate authority of certificaatautoriteit (CA) Een instantie (vaak een derde) die digitale certificaten verleent aan verscheidene partijen. Dit met het oog op identiteitsverificatie. eID (soms ook BeID)[1]. Elektronische identiteitskaart voor Belgen. De kaart wordt uitgegeven aan Belgen ouder dan 12 jaar. De kaart bevat naast de identiteitsgegevens een authenticatie- (om je identiteit te kunnen bevestigen) en een handtekeningscertificaat (om een elektronische handtekening te kunnen plaatsen, vanaf 18 jaar), deze zijn beveiligd met een pincode. Er bestaan ook varianten voor kinderen (kids-ID) jonger dan 12 en vreemdelingen (vreemdelingenkaart) die in België verblijven. Federated identity Maakt het mogelijk voor gebruikers om zich op meerdere websites en identity management systemen in te loggen met dezelfde gebruikersgegevens. Dit maakt ook SSO mogelijk. Authenticatie door middel van Federated Identity noemen we Federated Authentication Enkele gebruikte technologieën zijn SAML, OAuth, OpenID, Microsoft Azure Cloud Services en Windows Identity Foundation Enkele bekende implementaties zijn: Microsoft Account, Google, Yahoo!, Twitter, Amazon, Mozilla Persona, PayPal.[3] Fedict Federale Overheidsdienst Informatie- en Communicatietechnologie, verantwoordelijke voor de uitwerking van de ICT-diensten van de federale overheid. Hieronder valt ondermeer de technische ontwikkeling van de eID en bijhorende toepassingen. HTTP Request Binnen HTTP zijn verscheidene request methodes gedefinieerd, deze worden gebruikt voor de communicatie tussen client en server. De meest gebruikte methode’s zijn de GET methode en de POST methode. Ze staan respectievelijk in voor het aanvragen en indienen van data. Key of sleutel Benaming voor de gegevens die nodig zijn om een data te versleutelen en/of een versleutelde boodschap te ontcijferen. Dit geldt zowel voor digitale als analoge encryptie. Keystore Bevat private keys en de certificaten met bijhorende public keys. OAuth Een open IETF-standaard voor autorisatie. De ontwikkeling ligt in handen van een werkgroep binnen de IETF.

LIJST VAN FIGUREN

3

Open standaard Een standaard dat door de ontwikkelaar rechtenvrij aangeboden wordt. Private Key Eén van de twee sleutels gebruikt bij asymmetrische cryptografie. Deze zal niet overgedragen worden naar andere partijen. Public Key Een sleutel die bij cryptografie zal uitgedeeld worden aan alle partijen. SAML Een op XML gebaseerde open OASIS-standaard voor het uitwisselen van authenticatie- en autorisatiegegevens. SOAP Protocol om gestructureerd informatie van webservices uit te wisselen in een computer netwerk, gebruikmakend van het XML Infoset-formaat. Bij SAML wordt het gebruikt om data om SAML assertions over te brengen zonder gebruik te maken van een User Agent. SSO Maakt het mogelijk om met één aanmeldsessie toegang te verkrijgen tot meerdere applicaties en resources. SLO Maakt het mogelijk een SSO sessie stop te zetten en uit te loggen op alle betrokken applicaties. Truststore Bevat certificaten van andere partijen die je vertrouwt, en waarmee je communicatie verwacht. User Agent Computerprogramma dat netwerkfuncties uitvoert voor een gebruiker. Een van de bekendste voorbeelden is een webbrowser.

Hoofdstuk

1

Inleiding Er zijn meerdere tools en software programma’s op de markt die testen kunnen uitvoeren op de performantie van een bepaalde server configuratie en de verwerking van de load op een website. IS4U is een bedrijf gespecialiseerd in Identity & Access Management en Security Services (penetration testing). In het domein van Access Management hadden ze echter geen manier om te testen welke authenticatie het meest performant is. Het is belangrijk dit te weten bij het uitrollen van een authenticatietype op een omgeving. Op de markt zijn er geen of weinig tools te vinden die zich specifiek op dit probleem toespitsen. Dus hier kwam het idee tot een project vandaan. Er is nood aan een framework die verschillende authenticatietypes kan simuleren en hier vergelijkende feedback over kan geven. Deze framework moet ook toespitsen op de uitbreidingen die mogelijk zijn op de verschillende Federated authenticatie mogelijkheden. Het probleem voor IS4U is dat er steeds vaker een snellere response moet zijn van authenticatiemethode. Wat men dus specifiek wenst is een framework dat verschillende authenticaties kan uitvoeren op een server. Dit framework moet hier dan een aantal statistieken over bijhouden en een conclusie weergeven. Dit bijvoorbeeld in grafieken die kunnen weergeven wat de sterktes zijn van iedere authenticatiemethode.

4

HOOFDSTUK 1. INLEIDING

1.1

5

Testomgeving

Uiteraard is het onmogelijk om een framework te schrijven zonder deze praktisch te kunnen testen. Door gebruik te maken van het OpenAM platform is het mogelijk op een korte periode een Federated authenticatie te simuleren, daarnaast was dit ook de voorkeur van stagebedrijf IS4U. We hebben dit ook volledig zelf proberen te doen met af en toe een beetje hulp vanuit IS4U. De voorziende documentatie over OpenAM die online aanwezig was is voldoende om dit grotendeels zelf te doen. Ook is dit voor onze kennis ingaande de authenticatiemechanisme interessanter. OpenAM werd ge¨ınstalleerd op een Apache Tomcat server draaiend in een CentOS Linux distributie (een Red Hat derivaat). Aangezien we meerdere Federated authenticatietypes zullen behandelen hebben we 2 instanties van OpenAM nodig die op elkaar geconfigureerd zijn. Dus 2 servers, een die de Gebruikersauthenticatie zal afhandelen en een die de resources zal aanbieden. We creëren zo het principe van Identity Provider (IdP) en Service Provider (SP). Een gebruiker zal toegang wensen tot een resource, eigendom van de SP, deze zal aan de IdP vragen de persoon te authenticeren. Aangezien wij met log files in standaard JSON formaat werken is het mogelijk deze op verschillende manieren uit te lezen. Vanuit IS4U kwam de opmerking gebruik te maken van een ELK stack. Een combinatie van Elasticsearch, Logstash en Kibana. Het opzetten van deze 3 systemen heeft ons wat tijd gekost. Maar deze geven een duidelijk overzicht. En zijn dus essentieel om onze logging tool duidelijk te maken.

1.2

Framework

Het programmeren volgens de object oriented structuur is voor ons zeer belangrijk. Om hierin een overzicht te bewaren is het framework opgesplitst in de verschillende authenticatiemechanismen die we zullen testen. De authenticatietypes die getest zullen worden, naar wens van het stagebedrijf, zijn de volgende: Gebruikersnaam en wachtwoord SAML 2.0 OAuth 2.0 eID

HOOFDSTUK 1. INLEIDING

6

Deze zullen de core van het framework zijn. Hiernaast is er nog een nood aan een aantal dingen. Een duidelijke user interface die voor de gebruiker de vele aanpasbare parameters makkelijk instelbaar maken. Er moet hier een balans gemaakt worden tussen het automatisch afwerken en wat de gebruiker kan instellen. Een manier om data te vergaren en in een uniforme manier op te slaan. Dit mede om de gebruiker de vrijheid te geven zelf de representatie van de gegevens te kunnen kiezen. Hierboven zijn er nog een aantal extra’s op de authenticatiemethodes die we hebben toegevoegd. Zo is er bij het testen op SAML de mogelijkheid om verschillende bindings toe te voegen. Deze zullen de flow van data tussen de verschillende servers be¨ınvloeden.

Hoofdstuk

2

Bespreking Het komende hoofdstuk zullen alle aspecten van het geschreven framework in diepgang worden bespreken. Ook zal er dieper ingegaan worden op de werking van verschillende authenticatiemethodes. De kennis over het vloeien van pakketten tussen servers tijdens het authenticatieproces is uitermate belangrijk om de simulatie met succes te voltooien.

2.1

Authenticatie- en authorisatiemechanismen

Om een volledige simulatie te bekomen was een diepgaande studie nodig. Dit vooral over de Federated (OAuth en SAML) authenticatie- en authorisatiemechanismen. In de komende punten zullen we de werking van de te gebruiken mechanisme in diepgang bekijken.

7

HOOFDSTUK 2. BESPREKING

2.1.1

8

Gebruikersnaam en wachtwoord

Authenticatie met gebruikersnaam en wachtwoord is een van de meest gebruikte manieren op het internet. In principe is de opzet simpel: controleren of de ingevoerde gebruikersnaam voorkomt in een database en controleren of het bijhorende wachtwoord gelijk is met wat ingegeven is. Gebruikelijk zijn een gebruikersnaam en wachtwoord enkel geldig voor een bepaalde dienst. Wil je op een andere dienst (zoals een andere website van een andere ontwikkelaar) aanmelden, dan zal je een nieuwe gebruikersnaam en wachtwoord kunnen aanmaken. Men kan op verschillende diensten identieke (onafhankelijke) accounts maken (met dezelfde credentials), maar hierdoor is men een makkelijk doelwit voor hackers. De manier waarop omgegaan wordt met de inloggegevens van de gebruiker, is niet gestandaardiseerd. Zodoende zijn er vele verschillende implementaties mogelijk. De uitwerking is bij ons zeer primitief en had ook niet zo een grote prioriteit. In onze testopstelling maken we gebruik van de standaard loginpagina van OpenAM als referentie. Op deze pagina is een form aanwezig die een POST zal uitvoeren met gebruikersnaam en wachtwoord in een form. De server zal de POST ontvangen, controleren of de credentials bij hem gekend zijn en of ze toegang hebben tot de gevraagde resource. Als de credentials toegang geven tot de resource, zal er met een response op de POST gereageerd worden. Deze bevat de gevraagde resource en stelt een cookie in. Deze cookie wordt gebruikt om te voorkomen dat de gebruiker elke keer opnieuw moet aanmelden bij het aanvragen van de resource.


2.1.2

9

SAML 2.0

Security Ayssertion Markup Language (SAML) is een OASIS-standaard [7], gebaseerd op XML, gebruikt voor het uitwisselen van authenticatie- en autorisatiegegevens tussen verschillende partijen (in het bijzonder een Identity Provider (IdP) en een Service Provider (SP)). Er zijn vele mogelijkheden om SAML te implementeren. We bespreken de toegepaste, browsergebaseerde, methodes die beschikbaar zijn in OpenAM 12. We bespreken 4 SP-initiated methodes en 2 IdP-initiated methodes. Dataoverdracht tussen SP en IdP gebeurt door middel van SAML assertions. Deze assertions bevatten authenticatie- en/of autorisatiedata. In het volgende hoofdstuk bespreken we hoe deze assertions kunnen worden doorgegeven. HTTP-POST: de server zal een html pagina genereren met hierop een form en POST die automatisch naar de juiste URL. Zo kunnen er SAML assertions van SP naar IdP (of omgekeerd) gestuurd worden. Deze gaan altijd via de client’s browser. HTTP-REDIRECT: de SAML assertion wordt als parameter toegevoegd aan de redirect URL op SP naar IdP (of omgekeerd). Gebeuren ook via de client’s browser. SOAP: de SAML assertion zal niet passeren via de client maar wordt rechtstreeks uitgewisseld tussen de servers zelf.

2.1.2.1

Service Provider-initiated

Een gebruiker (gebruikmakend van een User Agent) wenst toegang tot een resource op de SP. De SP controleert of de gebruiker reeds geauthenticeerd is. Indien dit niet het geval is, zal er een single sign-on (SSO)-sessie opgezet worden met de IdP. Hoe dat proces verloopt kan variëren. Er zijn meerdere mogelijkheden om de sessie te initiëren naar de IdP en om de autorisatiedata correct naar de SP te sturen. Na het aankomen op de SP zijn er 2 mogelijkheden (bij OpenAM 12) om de SAML Request van SP naar IdP te krijgen. HTTP-POST HTTP-REDIRECT

Hierna komt men toe op de pagina waar men zijn aanmeldingsgegevens kan valideren: de zogenaamde loginpagina. Na het valideren moet de SAML Response terug bij de SP geraken. Hiervoor zijn er de volgende 2 mogelijkheden: HTTP-POST HTTP-ARTIFACT (SOAP)

Deze geven gecombineerd 4 verschillende manieren om de SAML Request en response door te geven via de gebruiker. Al deze combinaties zijn dieper beschreven in de dit hoofdstuk.


10

2.1.2.1.1 HTTP-POST request en response De gebruiker probeert toegang te verkrijgen tot een beveiligde resource van de SP zonder dat hij is ingelogd. De gebruiker heeft geen account op de SP, maar wel een Federated account op de IdP. De SP stuurt een authenticatie request naar de IdP. Zowel de request als de response SAML assertions worden via de browser van de gebruiker verzonden door middel van HTTP-POST.

Figuur 2.1: SP-Initiated SSO: POST/POST [8] 1. De gebruiker doet een GET Request naar een resource op de SP. Hierop draait een webagent. Deze agent controleert of de gebruiker is ingelogd, wanneer dit niet zo blijkt te zijn, zal deze een SAML Request opstellen. 2. De User Agent van de gebruiker krijgt een pagina met een form door. Deze form bevat een SAML Request, gericht aan de IdP. Deze SAML Request bevat de vraag om SSO te initiëren. De User Agent zal deze form met een POST doorgeven aan de IdP. 3. De IdP handelt met de gebruiker de authenticatie af. 4. Er wordt eventueel extra informatie van de gebruiker opgehaald, indien dit in de request gevraagd werd. 5. Eens de authenticatie geslaagd is, zal er wederom een form worden opgesteld, ditmaal gericht aan de SP. Deze bevat een SAML Response. De User Agent POST deze form naar de SP. Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP.


11

2.1.2.1.2 HTTP-REDIRECT request en HTTP-POST response De SP stuurt een HTTP redirect bericht naar de IdP met de authenticatie request. De IdP zal via HTTP POST een SAML response met assertion terugsturen naar de SP.

Figuur 2.2: SP-Initiated SSO: Redirect/POST [8] 1. De gebruiker doet een GET Request naar een resource op de SP hierop draait een webagent. Deze agent controleert of de gebruiker is ingelogd, wanneer dit niet zo blijkt te zijn, zal deze een SAML Request opstellen. 2. De User Agent krijgt een redirect naar de IdP. De redirect URL bevat de SAML request. 3. De IdP handelt met de gebruiker de authenticatie af. 4. Er wordt eventueel extra informatie van de gebruiker opgehaald, indien dit in de request gevraagd werd. 5. Eens de authenticatie geslaagd is, zal er een form worden opgesteld, gericht aan de SP, met de SAML Response. De User Agent POST deze form naar de SP. Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP.

HOOFDSTUK 2. BESPREKING 2.1.2.1.3

12

HTTP-POST request en Artifact response

De SP stuurt via HTTP POST een authenticatie request naar de IdP. De response zal via een redirect van de IdP naar de SP worden gestuurd, deze bevat een SAML artifact.

Figuur 2.3: SP-Initiated SSO: POST/Artifact [8] 1. De gebruiker doet een GET Request naar een resource op de SP hierop draait een webagent. Deze agent controleert of de gebruiker is ingelogd, wanneer dit niet zo blijkt te zijn, zal deze een SAML Request opstellen. 2. De User Agent van de gebruiker krijgt een pagina met een form door. Deze form bevat een SAML Request, gericht aan de IdP. Deze SAML Request bevat de vraag om SSO te initiëren. De User Agent zal deze form met een POST doorgeven aan de IdP. 3. De IdP handelt met de gebruiker de authenticatie af. 4. Er wordt eventueel extra informatie van de gebruiker opgehaald, indien dit in de request gevraagd werd. 5. De IdP stuurt de User Agent terug naar de SP door middel van een redirect en geeft een SAML Artifact mee in de response. 6. De Assertion Consumer Service van de SP gebruikt het artifact om rechtstreeks contact op te nemen met de IdP door middel van een Artifact Resolve. 7. De Artifact Resolution Service van de IdP zoekt de SAML Response die bij het gegeven artifact hoort. Deze wordt rechtstreeks teruggestuurd aan de SP in een Artifact Response door middel van SOAP.


13

Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP. 2.1.2.1.4 HTTP-Redirect request en Artifact response De SP stuurt een HTTP redirect bericht naar de IdP met de authenticatie request. De response zal via een redirect van de IdP naar de SP worden gestuurd, deze bevat een SAML artifact.

Figuur 2.4: SP-Initiated SSO: Redirect/Artifact [8] 1. De gebruiker doet een GET Request naar een resource op de SP hierop draait een webagent. Deze agent controleert of de gebruiker is ingelogd, wanneer dit niet zo blijkt te zijn, zal deze een SAML Request opstellen. 2. De User Agent krijgt een redirect naar de IdP. De redirect URL bevat de SAML request. 3. De IdP handelt met de gebruiker de authenticatie af. 4. Er wordt eventueel extra informatie van de gebruiker opgehaald, indien dit in de request gevraagd werd. 5. De IdP stuurt de User Agent terug naar de SP door middel van een redirect en geeft een SAML Artifact mee in de response. 6. De Assertion Consumer Service van de SP gebruikt het Artifact om rechtstreeks contact op te nemen met de IdP door middel van een Artifact Resolve. 7. De Artifact Resolution Service van de IdP zoekt de SAML Response die bij het gegeven Artifact hoort. Deze wordt rechtstreeks teruggestuurd aan de SP in een Artifact Response. Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP.

HOOFDSTUK 2. BESPREKING 2.1.2.2

14

Identity Provider-initiated

De gebruiker is aangemeld op de IdP en wenst toegang tot de SP. We bespreken de 2 gebruikte methodes. 2.1.2.2.1 Artifact binding De IdP stuurt een SAML artifact naar de SP doormiddel van een HTTP redirect. De SP gebruikt dit artifact om de bijhorende SAML response te bekomen van de IdP.

Figuur 2.5: IdP-Initiated SSO: Artifact [8] 1. De gebruiker logt in op de IdP. 2. De gebruiker wenst toegang tot een beveiligde resource op de SP, maar is daar niet ingelogd. 3. Er wordt eventueel extra informatie van de gebruiker opgehaald. 4. De IdP genereert een assertion en maakt een artifact. Het artifact wordt via de User Agent gestuurd naar de SP door middel van een redirect. 5. De Assertion Consumer Service van de SP gebruikt het Artifact om rechtstreeks contact op te nemen met de IdP door middel van een Artifact Resolve. 6. De Artifact Resolution Service van de IdP zoekt de SAML Response die bij het gegeven Artifact hoort. Deze wordt rechtstreeks teruggestuurd aan de SP in een Artifact Response. Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP.


15

2.1.2.2.2 HTTP-POST binding De IdP stuurt via HTTP POST een SAML assertion naar de SP.

Figuur 2.6: IdP-Initiated SSO: POST [8] 1. De gebruiker logt in op de IdP. 2. De gebruiker wenst toegang tot een beveiligde resource op de SP, maar is daar niet ingelogd. 3. Er wordt eventueel extra informatie van de gebruiker opgehaald. 4. De IdP stelt een form op, gericht aan de SP, met de SAML Response. De User Agent POST deze naar de SP. Eens de SAML uitwisseling geslaagd is, zal de gebruiker toegang krijgen tot de betrokken Resources op de SP.


16

Voorbeeld

Een praktisch voorbeeld is authenticeren met MediaID op de website (in dit geval De Morgen). Dit is een Service Provider Initiated voorbeeld.

Figuur 2.7: Voorbeeld: De Morgen & MediaID


2.1.3

17

OAuth 2.0

OAuth 2.0 (Open Authorization) is een standaard voor autorisatie. De ontwikkeling ligt in handen van een werkgroep binnen de Internet Engineering Task Force (IETF). OAuth geeft gebruikers (de Resource Owner) de mogelijkheid om toegang tot hun privégegevens op een Resource Server veilig te delen met een derde (de Client), zonder hun gebruikersnaam en wachtwoord te moeten delen. Het geeft de mogelijkheid om een Autorisatieserver Access Tokens uit te laten geven aan een Client, met de toestemming van de gebruiker. Met die Access Token krijgt de Client toegang tot de gegevens van de gebruiker. Authenticatie ligt buiten de scope van OAuth, met de gegevens verzameld door middel van de autorisatie kan men echter wel authenticatie opzetten. Hier gaan we echter niet dieper op in aangezien er verscheidene configuraties mogelijk zijn. In de vermelde flow is de gebruiker reeds geauthenticeerd bij de Authorization Server. De meest bekende implementaties zijn die van Google, Facebook en Twitter.

Figuur 2.8: Protocol Flow [6] 2.1.3.1

Client

Onder client verstaan we bij OAuth de dienst die de autorisatie aanvraagt, vergelijkbaar met de SP van SAML. De gebruiker (Resource Owner) zal toegang wensen tot de client, maar de client heeft nood aan authorisatie om bepaalde gegevens te weten te komen over de gebruiker.


18

Resource Owner

De resource owner is dus de gebruiker wiens gegevens vereist zijn. Hij dient zijn toestemming te geven om de autorisatie te laten plaatsvinden. Hij zal een lijst krijgen met gegevens waartoe de client toegang wenst, en dient zijn akkoord te geven om verder te kunnen gaan. 2.1.3.3

Authorization Server

Eens de gebruiker zijn toestemming gegeven heeft, kan de client een acces token ophalen bij de authorization server. Deze deelt Access Tokens uit, welke toegang geven tot de gevraagde gegevens van de gebruiker. 2.1.3.4

Resource Server

Hierbij verstaan we de server waar de gebruikersgegevens staan. Met de verkregen Access Token kan de Client de benodigde gegevens ophalen.


19

Voorbeeld

Een praktisch voorbeeld is het verbinden van een mobiele applicatie, zoals Candy Crush, met Facebook.

Figuur 2.9: Voorbeeld: Candy Crush


2.1.4

20

eID

De elektronische identiteitskaart (eID) uitgereikt door de Belgische overheid kan ook gebruikt worden om je te authenticeren, aangezien het een bewijs is van je identiteit. De effectieve manier van authenticeren is niet gestandaardiseerd, er zijn verscheidene implementaties mogelijk. De manier die wij zullen gebruiken is een 2 way-ssl authenticatie. De client zal de server authenticeren, en hier opvolgend de server de client. 2.1.4.1

eID authenticatie

Op de eID is een certificaat aanwezig en de bijhorende public en private keys. Deze kunnen gebruikt worden in een TLS/SSL verbinding. Transport Layer Security (TLS) zorgt voor de mogelijkheid om een verbinding op te zetten tussen client/server die privacy en data integriteit garandeert. Deze is gebaseerd op de Public Key Infrastructure.

Figuur 2.10: Certificate-based authentication met eID [4] Van de eID wordt via de pincode het certificaat en de public key gehaald. Deze wordt aan de server, die de protected resource bezit, overhandigd. De server zal dit certificaat naar de Validation Authority doorverwijzen waarna deze valideert of dit certificaat correct is. Hierna wordt aan de gebruiker de protected resource getoond.


21

Onze implementatie is gebaseerd op 2 way SSL authenticatie en gaat als volgt te werk:

Figuur 2.11: 2-way SSL authentication [5] 1. Client vraagt toegang de resource 2. Server stuurt zijn certificaat B door naar de client 3. Client verifieert het certificaat 4. Client stuurt eigen certificaat naar de server 5. Server verifieert het certificaat 6. Toegang tot protected resource Als we dit dan toepassen op eID, is het certificaat dat de client aanbiedt vervangen door dat van de eID. De server verifieert dat certificaat met het Belgium Root CA-certificaat[2].


2.2

22

Testomgeving

In het volgende hoofdstuk beschrijven we het opzetten van onze testomgeving en het opzetten van verschillende authenticatiemethodes binnenin OpenAM en Apache Tomcat.

2.2.1

OpenAM

We maken gebruik van OpenAM. De verschillende mogelijkheden in deze tool op vlak van acces management maken het mogelijk snel een testomgeving op te zetten. OpenAM is opensource en te downloaden op de website van ForgeRock. Een werkende instantie van Apache Tomcat moet aanwezig zijn. 2.2.1.1

Installatie

ForgeRock biedt een web applicatie in .war-format aan voor deployment in Apache Tomcat. We plaatsen deze file in de webapp folder van Tomcat. Deze zal automatisch gedeployed worden. Hierna kunnen we via de web UI van OpenAM de basisconfiguratie doen. In onze omgeving hebben we gebruik gemaakt van de eigen OpenAM User Data Store. Deze is voldoende voor onze testopstelling. Dan rest er nog een laatste configuratie om de instantie van OpenAM volledig bruikbaar te maken. OpenAM 12 implementeert een nieuwe UI voor de authenticatie- en profielpagina’s. Deze is gebaseerd op JavaScript. De inhoud van de HTML pagina blijft dan ook beperkt tot “Loading”, de rest wordt opgebouwd met scripts waardoor de broncode niet zichtbaar is. Om de standaard UI te gebruiken, past men het volgende aan: onder Configuration → Core → XUI interface vinken we uit. De OpenAM installatie is nu klaar voor gebruik.


23

Web Policy Agent

De Web Policy Agent draait bovenop de webserver die we willen beschermen. Deze heeft de taak te controleren of de gebruiker toegang heeft tot de gevraagde resource. De flow die dan gecreëerd wordt is de volgende:

Figuur 2.12: Policy Agent 1. Client vraagt toegang de beveiligde resource. 2. Webserver stuurt de request door naar de Agent. 3. Policy Agent vraagt aan OpenAM welke policy het dient toe te passen. 4. Als OpenAM toegang geeft, zal de Agent toegang toestaan. 5. Server geeft toegang tot beveiligde resource.


24

Op OpenAM moet allereerst een Profile voor de Web Policy Agent gemaakt worden. 1. In de OpenAM console Access Control → Realm → Agents → Web, hier klikken we op New. 2. Name en Password worden gebruikt door de agent om zich te valideren bij de OpenAM instantie. Server URL is naar een OpenAM instantie en Agent URL de url die beschermd is door de Agent. De werkelijke installatie van de Agent bovenop de apache HTTP server kan nu beginnen. We maken eerst een bestand aan met het wachtwoord, deze is identiek aan het wachtwoord in het profiel. Hierna kunnen we het “./agentadmin –install” commando gebruiken om de installatie te starten.


25

SAML 2.0

2.2.1.3.1 Identity & Service Provider OpenAM voorziet 4 wizards voor de IdP en SP configuratie. 2 om een hosted IdP of SP te maken (lokaal op de server) en 2 om een remote IdP of SP te registreren (van een andere server). Op de doel IdP maak je dus een Hosted IdP en registreer je een remote SP, en omgekeerd. Anders dan de standaard configuratie hebben we gebruik gemaakt van Transient Users. Dat wil zeggen dat er geen lokaal account aangemaakt wordt voor de gebruiker, hij zal daarentegen als anonieme gebruiker gekend staan op de SP. In onze testomgeving was het immers niet nodig om rekening te houden met identiteitsmanagement. Het is ook mogelijk om de Federation instellingen van de servers bij te werken, daar kunnen we bijvoorbeeld de standaard binding van de SSO en SLO instellen.

Figuur 2.13: Federation


26

2.2.1.3.2 SSO & SLO Aangezien SSO en SLO standaard beschikbaar zijn, dienen we slechts kleine aanpassingen te doen om deze te implementeren. De WebAgent van de SP dient geconfigureerd te worden opdat het de SSO en SLO url’s gebruikt (de zogenaamde Endpoints) en niet langer de standaard OpenAM Login of Logout URL. Bij de instellingen van de betreffende WebAgent kan dit gedaan worden in het tabblad “OpenAM Services”. Daarnaast is het ook mogelijk een Agent Logout URL in te stellen, daarbij zal de WebAgent automatisch een logout sessie starten terwijl de gebruiker naar een normale pagina surft (zoals bijvoorbeeld logout.html).

Figuur 2.14: Federation

HOOFDSTUK 2. BESPREKING 2.2.1.4 2.2.1.4.1

27

OAuth 2.0 Authorization Server

Figuur 2.15: Authorization Server OpenAM voorziet een wizard voor de basisconfiguratie van de Authorization Server. Hierbij kan men enkele instellingen met betrekking tot de levensduur van de tokens aanpassen. Er wordt automatisch een policy opgezet voor de endpoints die gebruik worden voor OAuth.


28

Figuur 2.16: Client registratie Eens voltooid dient er een nieuwe Client geregistreerd te worden op de Authorization Server. Daarbij wordt de scope ingesteld (de data die geautoriseerd dient de worden) en onder andere de weergavenaam die getoond zal worden op de Consent pagina.

HOOFDSTUK 2. BESPREKING 2.2.1.4.2

29

Client

Figuur 2.17: Client Authenticatie Module Vervolgens kunnen we de client zelf instellen. We voegen een OAuth module toe onder de Authenticatie modules. Hierbij dienen we de Client Id en Client Secret in te voeren die we ook ingaven op de Authorization Server. Op basis van deze gegevens kan de client ge¨ıdentificeerd worden. Voor onze installatie maken we gebruik van Anonymous users, ook dit kunnen we hier instellen. Tenslotte kunnen we de WebAgent aanpassen zodat er automatisch aangemeld wordt met behulp van de OAuth module.


2.2.2

30

eID

Voor een volledige uiteenzetting van de installatie verwijzen we naar Bijlage B (pagina 61). Hierin overlopen we in diepgang hoe de certificaten ingesteld moeten worden op server en client niveau, en een hoe een Java client-applicatie hiermee moet werken. In grote lijnen moet het volgende gebeuren. Het certificaat van de CA van de Belgische overheid moet toegevoegd worden aan de truststore van de server. In onze omgeving is dit op een Tomcat instantie, de SSL connectie zal over poort 8443 gaan. Volgende instellingen in Tomcat zijn voor een gewone 2-way TLS/SSL verbinding met authenticatie, zonder eID. Listing 2.1: Tomcat SSL Connector

Het certificaat dat de server zal aanbieden, wordt in de keystore gestoken. Dit is (in ons geval) een zelf gegenereerd certificaat met een eigen selfsigned CA-certificaat. Dit selfsigned CAcertificaat is bij de client in de truststore toegevoegd. Zo herkent de client of de server wel de server is. Het certificaat dat de client naar de server doorstuurt, is het Authentication-certificaat van de eID. Hiervoor is het ingeven van de pin code vereist. Om de server dit certificaat te laten accepteren, moeten we het Root CA-certificaat van de overheid toevoegen aan de truststore. We genereren een keystore met het volgende commando en het gedownloade certificaat “belgiumrca2.crt”. keytool −importcert −alias servertruststore − file belgiumrca2. crt −keystore rootCAtrust. keystore

Het is nu enkel mogelijk met gebruik van een eID toegang te krijgen tot de resources op poort 8443


2.3

31

Framework

Elke authenticatie methode is losstaand geschreven, ieder hebben ze een aantal standaard parameters. Dit maakt het mogelijk de verschillende blokken die gebruikt worden in de framework makkelijker te implementeren zijn. Elk authenticatieblok beschikt over een publieke bool die zal weergeven of de totale authenticatie succesvol voltooid is. Specifiekere fouten en dergelijke worden niet weergegeven in het display. Tijdens het uitvoeren van een authenticatie is er ook een logging instantie die draait. Deze zal een log file aanmaken. Hierin staat meer info over de uitgevoerde authenticatie en hoe die specifiek is uitgevoerd. De DAL klasse die in elke authenticatiemodule aanwezig is, staat in voor de volledige afwerking van de authenticatie. De volgende variabelen moeten altijd bij het aanmaken van een DAL Object aanwezig zijn: De URL van de te bereiken resource Username Password

Dit afgezien van de eID authenticatie. De werking van authenticatie aan de hand van een certificaat is totaal verschillend en wordt later besproken. We hebben gebruik gemaakt van de in Java JDK standaard HttpURLConnection en HttpsURLConnection voor al onze netwerkcalls. Dit gaf een aantal problemen bij het uitvoeren van een POST methode om de SAML data door te geven. De POST gebeurt door een form te laden in een HTML pagina die automatisch een POST naar de juiste URL zal uitvoeren. De methodes die wij gebruikt hebben voor de netwerkcalls, kunnen echter de pagina enkel in string teruggeven. De oplossing die wij hiervoor gebruikt hebben, is het filteren op de webpagina naar de data die aanwezig is in de form. Deze zelf te encoden voor verzending en zelf toe te voegen aan een HTTP-POST met HttpURLConnection. Initieel zal er bij elke authenticatiemethode altijd een GET Request naar de te bereiken resource gedaan worden. De onderlinge werking vanaf hier varieert naargelang de authenticatiemethode. Per methode kunnen er ook een specifiek aantal publieke booleans oegd worden, dit om de correcte werking van onderlinge delen duidelijk te maken.


2.3.1

32

Gebruikers interface

Figuur 2.18: Gebruikers interface De gebruikersinterface werd geschreven in Java. Het basisscherm geeft de gebuiker de kans om snel van start te gaan met de authenticatie specifieke instellingen. De meer specifieke instellingen, die afhankelijk zijn van de aanbieder, zijn terug te vinden in het Settings-venster. Bij het eerste gebruik is het sowieso aan te raden om eerst een configuratie uit te voeren, daarna worden de voorkeuren van de vorige sessie echter opnieuw geladen. Men heeft steeds de mogelijkheid om manueel alle gegevens in te vullen, of om deze automatisch op te roepen vanuit de voorkeuren. Enkele instellingen worden niet opgeslagen: Request Binding, Binding, Logout Binding, threads (aantal simultane uitvoeringen) en thread offset (tijd tussen start van threads). Ook is het gebruik van meerdere accounts standaard uitgeschakeld. Onderaan is een voortgangsbalk en een log terug te vinden, deze geven extra informatie over de voortgang van het proces.


33

Settings

In het Settings-venster kan men (afhankelijk van de methode) de (Logout) URL en gebruikersgegevens invoeren. Bij methodes die in threads kunnen worden uitgevoerd, is het mogelijk meerdere accounts in te voeren. Bij eID kan men de standaard Truststore locatie ingeven. Al deze gegevens zullen, indien de Autofill-optie geactiveerd is, automatisch ingevuld worden in het hoofdscherm. Daarnaast zijn er nog de server gerelateerde instellingen die men binnen een zelfde omgeving niet zal aanpassen. De IDToken’s (gebruikt op de server als veldnamen voor gebruikersnaam en wachtwoord), de Fields (veldnamen van andere elementen die uitgelezen en meegezonden dienen te worden). Voor OAuth zijn er de Consent Fields, dit zijn de veldnamen aanwezig op de consentpagina, en de Consentnaam en de waarde (de optie waarmee men aangeeft al dan niet akkoord te gaan met de autorisatie). Bij gebruikersnaam en wachtwoord dient men aan te geven welke pagina men zal bekomen na het inloggen.

Figuur 2.19: Settings-venster


2.3.2

34

Data logging

Het bijhouden en weergeven van data was een essentieel deel in deze applicatie. Hoe kan een gebruiker conclusies trekken, zonder een duidelijk overzicht te krijgen? We wilden een standaard maken voor de applicatie, die natuurlijk ook op andere manieren bruikbaar is, en die verstaanbaar zou zijn voor verschillende gebruikers. We hebben als oplossing voor dit probleem gekozen voor het aanmaken van log files. Deze zijn opgebouwd in het JSON formaat aangezien wij met Logstash, Elasticsearch en Kibana willen werken, en dat in dit geval het meest compatibel is. Door gebruik te maken van log4j was dit snel te implementeren. Door per module een andere properties file voor de logger te implementeren, kunnen we verschillende directory’s aanmaken. Wanneer we beginnen aan een authenticatie, wordt de juiste properties file aan de logger toegewezen. Dit gebeurt met de volgende lijn code (voor Gebruikersnaam/Wachtwoord): Listing 2.2: PropertyConfigurator: Aanpassen PropertyConfigurator P r o p e r t y C o n f i g u r a t o r . c o n f i g u r e ( A u t h e n t i c a t e . c l a s s . getResourceAsStream ( ”/ login / gui / resources / loggers / userpass . properties ”) ) ;

Er zijn nog overige files aanwezig met properties voor eID, OAuth en SAML. De message bevat de tijd in millis, nodig om de volledige thread af te ronden. De level field is de indicator of de authenticatie succesvol of onsuccesvol is verlopen. Hieronder een voorbeeld van een log: Listing 2.3: PropertyConfigurator: Aanpassen PropertyConfigurator { ” @message ” : ” 2474 ” , ” @timestamp ” : ”2015−05−20T15 : 0 7 : 1 4 . 2 8 7 + 0 2 : 0 0 ” , ” @ s o u r c e h o s t ” : ” LaptopTom ” , ”@fields”: { ” f i l e ” : ” Authenticate . java ” , ” method ” : ” s t a r t ” , ” l e v e l ” : ”DEBUG” , ” l i n e n u m b e r ” : ” 70 ” , ” class ” : ” login . Authenticate ” , ”mdc” : {} } }


35

De volgende levels zijn mogelijk in de log files en hebben een specifieke betekenis: INFO → Authenticatie succesvol afgerond en sessie beëindigd DEBUG → Authenticatie geslaagd maar sessie niet beëindigd WARN → Authenticatie mislukt

Per keer dat er een authenticatie uitgevoerd wordt, zal de log file leeg gemaakt worden en het aantal threads weggeschreven worden naar die file. Als er bijvoorbeeld 5 threads gestart worden, zullen er 5 entry’s aanwezig zijn in de log file. Starten we erna echter 2, dan wordt de log file leeggemaakt en opgevuld met 2 entry’s. Om een duidelijk overzicht te laten maken kwam onze stagementor met het idee om Kibana te gebruiken. Kibana maakt real time data analyse mogelijk. Door gebruik te maken van een zogenaamde ELK stack, is het mogelijk om in realtime data van onze applicatie weer te geven in Kibana. Deze stack is opgebouwd uit Elasticsearch, Logstash en Kibana. Logstash → Systeem voor log verzameling, verwerking en opslag Elasticsearch → Search engine met een RESTful web interface Kibana → Data visualisatie werkende met Elasticsearch


36

Logstash

Logstash heeft de mogelijkheid om de data te verwerken die het toegestuurd kreeg. De configuratiefile ziet er als volgt uit: Input definieert waar de log files aanwezig zijn die geforward moeten worden en in welk formaat deze zijn opgeslagen. Listing 2.4: Logstash Input 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

input { file { p a t h => ”C : / U s e r s /Tom/ Documents / Stage c o d e c => json t y p e => ”SAML” } file { p a t h => ”C : / U s e r s /Tom/ Documents / Stage c o d e c => json t y p e => ” eID ” } file { p a t h => ”C : / U s e r s /Tom/ Documents / Stage c o d e c => json t y p e => ”OAuth” } file { p a t h => ”C : \ U s e r s \Tom\ Documents \ Stage c o d e c => json t y p e => ” G e b r u i k e r s n a a m en Paswoord ” } }

RUN /SAML/ t i m e l o g . l o g ”

RUN / eID / t i m e l o g . l o g ”

RUN /OAuth/ t i m e l o g . l o g ”

RUN \ u s e r p a s s / t i m e l o g . l o g ”

Zoals te zien is in het voorbeeld van een log, is message gedefinieerd als een string. Dit moeten we omvormen naar een integer om bewerkingen hierop door Kibana mogelijk te maken. Dit doen we met de mutate functie die aanwezig is in logstash Listing 2.5: Logstash Filter 1 2 3 4 5

filter { mutate { c o n v e r t => { ” @message ” => ” i n t e g e r ” } } }


37

Definiëren waar de data naartoe moet bij het definiëren van Elasticsearch, zal default waarden gebruiken. Listing 2.6: Logstash Output output { elasticsearch { h o s t => l o c a l h o s t } }

2.3.2.2

Elasticsearch

Deze hebben we in standaard configuratie laten staan. Wanneer er van ondersteunde forwarders (zoals logstash) data aangeboden wordt, zal Elasticsearch automatisch met een template indexes aanmaken. Zoeken gebeurt door een lijst van indexes af te gaan, die verwijzen naar de juiste gegevens. Na het downloaden van Elasticsearch volstaat het om de bat file te runnen van commandline: start elasticsearch.bat 2.3.2.3

Kibana

Als laatste starten we de bat file van Kibana: start kibana.bat. Normaal zouden in de webinterface van Kibana nu de log files moeten verschijnen.


38

Figuur 2.20: Kibana Als we dan valideren dat het message field een integer aanduiding heeft, kunnen we beginnen met het maken van de visuele weergave. De gemakkelijke UI maakt het mogelijk snel blokken te maken die implementeerbaar zijn op een dashboard. Door onder Visualize te werken met de juiste filters, is het mogelijk om te filteren op een specifiek type pakketten. Wij filteren bijvoorbeeld op authenticatie en maken dan het onderscheid tussen succes, fail en half voltooid voor elke methode. Deze slaan we op en voegen we dan toe aan het dashboard.

Figuur 2.21: Methodes Aangezien het message field een integer value heeft, is het mogelijk hier berekeningen op te doen. We gebruiken de standaard AVERAGE berekening om een gemiddelde tijd per


39

authenticatiemethode te berekenen. grootste gemiddelde tijd heeft.

Zodoende kunnen we weergeven welke methode de

Figuur 2.22: Bindings Na het combineren van een aantal grafieken krijgen we een beeld gelijkaardig aan Figuur 2.23 te zien in het live Dashboard. Wanneer we nieuwe authenticaties uitvoeren, zien we dat de grafieken zich aanpassen aan de nieuwe data.

Figuur 2.23: Dashboard


2.3.3

40

HTML Extractie

In de applicatie is het nodig op een flexibele manier om te gaan met webpagina’s en de essentie hieruit te halen. Omdat op zo goed als alle loginpagina’s die we tegenkomen in form formaat zijn die via HTTP-POST verzonden zal worden, moest hiervoor een flexibele oplossing geprogrammeerd worden. De oplossing die wij hebben bedacht, is een klasse die verschillende mogelijkheden biedt. De volgende parameters moeten worden meegegeven: Parameters die uit de form gehaald moeten worden Webpagina in string formaat URL waar de pagina vandaan komt

Er zijn 2 publiek aanroepbare methoden aanwezig: generateForm zal alles uit de webpagina halen extractActionOnly zal alleen de URL nodig voor de POST teruggeven

Voor beide methoden is het nodig de volledige form uit de webpagina te filteren. Dit is altijd de eerste stap. Vanaf hier treden er variaties op. Er is geen implementatie aanwezig voor HTML script tags. Beide werken met een list met hierin alle input tags aanwezig binnenin de form. 2.3.3.1

Volledige extractie

Geeft een LinkedHashmap terug. Er moet een lijst meegegeven worden met hierin de paremeters die moeten worden toegevoegd. Deze worden vergeleken met het “name” field van een inputtag. Als deze overeenkomen, zal deze toegevoegd worden aan een keyvalue in de LinkedHashMap. De bijhorende waarde in het “value” veld zal ook uit deze input gefilterd worden, en tegelijk als bijhorende value van deze key in de Hashmap opgeslagen worden. Onder de standaard key value “BaseURL” zal altijd de URL toegevoegd worden waarnaar de POST uitgevoerd moet worden. Hier is rekening gehouden met een aantal optredende mogelijkheden. Wanneer de POST naar hetzelfde domein gebeurt, wordt het domein niet toegevoegd. Daarom moet de URL toegevoegd worden waar de pagina vandaan komt. Automatisch zal het domein gecombineerd worden met string die erachter gezet moet worden. Wanneer de POST naar dezelfde URL gebeurt als waar de pagina van geladen is, zal deze value leeg gelaten worden. Dan moet de “BaseURL” value ingeladen worden met de URL waar de pagina vandaan komt. Als de POST naar een ander domein gebeurt, zal de URL die hierin staat al volledig in orde zijn en moet deze gewoon in de “BaseURL” value geladen worden.


41

De methode geeft dan een LinkedHashmap terug met alle parameters en value’s. 2.3.3.2

Action extractie

Zal uit de FORM alleen filteren op de “method=post” en de bijhorende URL bij de “action” tag. Bij het extracten van de URL wordt er alsook rekening gehouden met de verschillende mogelijkheden en is het dus nodig een begin URL mee te geven waarmee deze opgebouwd kan worden. Wanneer de POST naar hetzelfde domein gebeurt, wordt het domein niet toegevoegd. Daarom moet de URL toegevoegd worden waar de pagina vandaan komt. Automatisch zal het domein gecombineerd worden met string die erachter gezet moet worden. Wanneer de POST naar dezelfde URL gebeurt als waar de pagina van geladen is, zal deze value leeg gelaten worden. Dan moet de “BaseURL” value ingeladen worden met de URL waar de pagina vandaan komt. Als de POST naar een ander domein gebeurt, zal de URL die hierin staat al volledig in orde zijn en moet deze gewoon in de “BaseURL” value geladen worden. De methode geeft dan een String terug met hierin de opgebouwde URL.


2.3.4

42

Gebruikersnaam en wachtwoord

Deze module is specifiek geschreven om door het posten van login credentials een sessie op te zetten met een server. De data die aan deze module moeten worden meegegeven bestaat uit het volgende: IDTokens: wat is de benaming van het veld, op de HTML pagina, voor gebruikersnaam en passwoord Credentials: De werkelijke logincredentials URL van de loginpagina URL waar we na de login terecht komen URL van de logoutpagina FORM parameters: welke overige parameters die ook nog op de pagina aanwezig kunnen zijn

2.3.4.1

Login

De flow is als volgt: 1. 2. 3. 4. 5.

HTTP GET → Verkrijg de initieel opgevraagde webpagina Verwerking → Form voor POST genereren aan de hand van de webpagina HTTP POST → POST data naar de action URL op de initiële webpagina Volg redirect → Hierna volgen we de redirects naar een finalepagina Controle → Controle met finale URL

Na het starten van deze module zal er een HTTP GET uitgevoerd worden op de URL van de loginpagina. Deze webpagina zal worden verwerkt door de formExtraction klasse. De FormExtraction klasse heeft de mogelijkheid om van een webpagina, waarop een action POST aanwezig is, automatische de data te verzamelen die nodig is. Hier hebben we het over de volgende gegevens: de data die in de form aanwezig moet zijn en de URL waarnaar de POST uitgevoerd moet worden. Alle inputs binnen een form element worden in een LinkedHashmap geplaatst. Het key element is altijd de name en de value in het value veld bij deze Key. Listing 2.7: Gebruikersnaam & Wachtwoord: Form voorbeeld

Zo kan er later over de LinkedHashmap gegaan worden en de key en value elementen in een form opmaak geplaatst worden. Het object van de formExtraction klasse zal de webpagina na de initiële GET verwerken. Hierna zal de data die geëxtract is uit de pagina doorgegeven worden aan het POST object. Deze zal de data voor de form opbouwen en encoderen in een UTF-8 formaat. Dit door middel van een foreach over de meegegeven LinkedHashmap. Wat we uiteindelijk bekomen, is een String met hierin de volledige form. Deze is nu klaar om verzonden


43

te worden. Na het verzenden van de POST en het volgen van de redirect, zal er als check het volgende gebeuren: als de URL waar we terecht moeten komen overeenkomt met de finale redirect URL, dan is de authenticatie geslaagd. 2.3.4.2

Logout

De flow is als volgt: 1. Controle login → Controle of de sessie nog lopende is 2. HTTP GET → De logout procedure starten door de logout URL op te vragen 3. Controle → controleren of sessie bij cookies verwijderd is Door een GET uit te voeren naar de logout pagina en de redirects te volgen zal de sessie uit de cookie store verwijderd worden. Allereerst zal deze methode controleren of de sessie nog werkende is en of de client nog steeds aangemeld is op de server. Hierna kan men beginnen aan de werkelijke logout. Op voorhand slaan we de cookies op. We voeren een GET uit op de logout pagina en volgen alle redirects. Als controle vergelijken we op de cookies. Indien de sessie verwijderd is uit de cookies, is het logout proces geslaagd.


2.3.5

44

SAML 2.0

De SAML module bestaat uit een login en logout gedeelte. De SAML authenticatie heeft een aantal specifieke variabelen nodig: Toevoegen van de bindings voor de login en logout bij het aanmaken van het object is verplicht. De IDTokens zijn optioneel: wanneer deze niet werden toegevoegd, worden ‘IDToken1’ en ‘IDToken2’ als standaard gebruikt. Op Framework niveau is het gebruiken van de logout optioneel. Zo is het mogelijk om ook te testen met een groot aantal openstaande sessies op serverniveau. 2.3.5.1

Login

Na het uitvoeren van de initiële GET, worden de ingestelde bindings aan de URL toegevoegd. Deze be¨ınvloeden de manier waarop de SAML assertions tussen de SP en IdP worden doorgegeven. Als DEFAULT geselecteerd is voor de request en/of response, zal er aan de URL niets toegevoegd worden. Per methode is er ook toegevoegd welke string er specifiek toegevoegd zal worden. Mogelijke instellingen voor de Operation Request Binding: POST zal de SAML request alleen doorgeven via POST van de SP naar de IdP – &reqbinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST REDIRECT alleen via redirect – &reqbinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect DEFAULT automatisch de standaard detecteren en uitvoeren

Instellingen voor de Response Binding: POST SAML response alleen doorgeven via POST – &binding=HTTP-POST ATIFACT verwijzing naar SAML artifact, de eigenlijke response zal via SOAP worden doorgeven van server naar server – &binding=HTTP-Artifact DEFAULT automatisch de standaard detecteren en uitvoeren

Na de GET Request op de URL met de juiste bindings, krijgt men de login pagina. Hier zal er automatisch een login gepost worden en verder gegaan worden met de geselecteerde Response afhandeling. De afhandeling van de 2 POSTs voor Operation en Response is hetzelfde. Opvangen van de webpagina, POST gegevens eruit filteren en data posten naar de juiste URL. Ditzelfde principe wordt ook toegepast bij het posten van de logingegevens. Als check wordt er op de initieel gegeven URL gecontroleerd of deze met de bestaande cookies in de cookiemanager nog een redirect naar een andere pagina uitvoert. Is dit niet het geval, dan is de authenticatie succesvol.


45

Logout

Aan de logout methode moet nog de url van de logout pagina gegeven worden. Eerst test deze of de login geslaagd was, zo niet zal er een error optreden en de logout automatisch falen. Leiden de cookies die aanwezig zijn in de cookiemanager tot een succesvolle login, dan kan de logout starten. Na het uitvoeren van een GET Request op de logout pagina, extracten we hier de redirect URL waar we de binding opties aan kunnen toevoegen. Deze bindings komen bij de SPSLOInit module van OpenAM terecht en zal de juiste afhandeling in gang zetten. Instellingen voor de binding: REDIRECT request doorgeven via redirect in url – &binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect POST request doorgeven via POST – &binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST SOAP request doorgeven van server naar server, geen SAML assertions via client – &binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP

De POST methode gebeurt op dezelfde manier als het opvangen van voorgaande webpagina: data eruithalen en posten naar de juiste url. Voor de overige 2: REDIRECT en SOAP, die beide met redirect werken, hebben we de volgende methode uitgewerkt. HttpURLConnect heeft wel de mogelijkheid om de standaard redirects te volgen. Dit is echter gedeeltelijk uitgeschakeld. Door de redirect niet te volgen en de url uit de location header te halen van de response, kunnen we detecteren welke authenticatie er nu gebruikt wordt.


2.3.6

46

OAuth 2.0

De flow die bij het praktisch uitvoeren van OAuth terug te vinden is als volgt: HTTP GET → Verkrijg de initieel opgevraagde webpagina Redirect → Geen toegang: redirecten naar Authorization Server HTTP GET → Ophalen van de login pagine Verwerking → Form voor POST genereren aan de hand van de webpagina HTTP POST → Post data naar de action URL op de webpagina Volg redirect HTTP GET → Consent pagina: goedkeuring vragen voor de gegevens die worden doorgegeven tussen Client en Resource Server 8. HTTP POST → Consent verwerken en Authorization Code uitdelen. 9. Redirect met Authorization Code 10. Toegang tot resource. 1. 2. 3. 4. 5. 6. 7.

Voordat men deze module kan starten, moeten er een aantal parameters meegegeven worden

URL van protected resource Extra parameters die aanwezig zijn op de loginpagina Naam van de loginvelden op loginpagina Parameters op de goedkeuringspagina Overschrijven van een parameter op toestemmingspagina is mogelijk

Bij het starten van de module wordt er initieel een GET naar de gebruikte start URL gedaan. De response webpagina zal in string formaat worden doorgegeven. Deze webpagina zal worden verwerkt door de formExtraction klasse. De FormExtraction klasse heeft de mogelijkheid om van een webpagina waarop een action POST aanwezig is, automatisch de data te verzamelen die nodig is. Hier hebben we het over de volgende gegevens: de data die in de form aanwezig moet zijn en de URL waarnaar de POST uitgevoerd moet worden. Alle inputs binnen een form element worden in een LinkedHashmap geplaatst. Het key element is altijd de naam en de value zal het value veld bij deze Key zijn. De applicatie verwacht een loginpagina die de user credentials zal posten. We extracten uit de pagina alle inputs die vereist zijn voor de POST. Ook de hidden inputs worden toegevoegd, deze elementen moeten op voorhand meegegeven worden door de gebruiker, anders zal de applicatie deze niet overnemen.


47

Na het extracten van de inputs die nodig zijn voor de POST, zullen deze in het juiste form formaat gezet worden en met een POST naar de action URL gestuurd worden. Het grote verschil met SAML is dat er nu een toestemmingspagina getoond wordt. Deze kunnen we ook door de formextracter laten afhandelen. Aangezien hier een aantal inputs op de webpagina aanwezig zijn die gepost moeten worden. Hieronder ziet men een voorbeeld van onze toestemmingspagina in de testopstelling voor OAuth.

Figuur 2.24: Toestemmingspagina Op deze voorbeeldpagina zijn er nog een aantal verborgen parameters die mee gepost worden. Na het extracten van de action URL en de parameters met hun waarden kunnen we verder gaan. We posten de data naar de meegegeven URL en volgen hierna de redirects tot een finalepagina. Na een controle of de pagina waar we terechtkomen overeenkomt met de initieel opgevraagde resource, bevestigt de module naar buitenaf dat de authenticatie geslaagd is.


2.3.7

48

eID

HttpsUrlConnection laat toe een SSLSocketFactory in te stellen. Als deze correct gemaakt is, zal de manier van posten en getten zoals bij HttpUrlConnection grotendeels hetzelfde blijven. Listing 2.8: eID: Truststore in Java 35 36 37 38 39 40 41 42 43 44

// I n s t e l l e n TrustManager T r u s t M a n a g e r F a c t o r y tmf = T r u s t M a n a g e r F a c t o r y . g e t I n s t a n c e ( ” SunX509 ” ) ; K e y S t o r e t r u s t k s = K e y S t o r e . g e t I n s t a n c e ( ”JKS” ) ; F i l e t r u s t c e r t = new F i l e ( t r u s t d i r ) ; I n p u t S t r e a m t r u s t s t r e a m = new F i l e I n p u t S t r e a m ( t r u s t c e r t ) ; t r u s t k s . load ( truststream , t r u s t p a s s . toCharArray () ) ; truststream . close () ; tmf . i n i t ( t r u s t k s ) ; System . o u t . p r i n t l n ( ” T r u s t S t o r e added ” ) ;

We maken allereerst de objecten van de klasse TrustManagerFactory en keystore met de juiste instanties. Voor tmf nemen we de SunX509 omdat de encoding in x509 is. Voor trustks de JKS (Java KeyStore), door gebruik te maken van de keytool van Java, is deze automatisch in JKS formaat. We laden het certificaat in een File trustcert, waarna we deze via een FileInputStream laden naar stream. Hierna roepen we de load methode aan op het keystore object en geven we stream en het wachtwoord in chararray mee. Initiëren van de TrustManagerFactory met het keystore object en het wachtwoord opnieuw in chararray. Hiermee is de TrustManager volledig ingesteld. Listing 2.9: eID: Keystore in Java 47 48 49 50 51 52 53 54 55 56 57 58

S e c u r i t y . a d d P r o v i d e r ( new B e I D P r o v i d e r ( ) ) ; SSLContext s s l C o n t e x t = SSLContext . g e t I n s t a n c e ( ”SSL” ) ; K e y M a n a g e r F a c t o r y k e y M a n a g e r F a c t o r y = K e y M a n a g e r F a c t o ry . g e t I n s t a n c e ( ” BeID ” ) ; B e I D M a n a g e r F a c t o r y P a r a m e t e r s s p e c = new BeIDManagerFactoryParameters () ; spec . setAutoRecovery ( true ) ; spec . s e t C a r d R e a d e r S t i c k i n e s s ( true ) ; keyManagerFactory . i n i t ( spec ) ; SecureRandom random = SecureRandom . g e t I n s t a n c e ( ” BeID ” ) ;

We wijzen de BeIDProvider aan als bron van de Keystore. Listing 2.10: eID: SLL Socket in Java 60 61 62

// v o l g e n d e commando z a l de eID a a n r o e p e n s s l C o n t e x t . i n i t ( k e y M a n a g e r F a c t o r y . getKeyManagers ( ) , tmf . g e t T r u s t M a n a g e r s ( ) , random ) ;

HOOFDSTUK 2. BESPREKING 63 64 65 66 67 68

49

SSLSocketFactory s s l S o c k e t F a c t o r y = s s l C o n t e x t . getSocketFactory () ; System . o u t . p r i n t l n ( s s l S o c k e t F a c t o r y . t o S t r i n g ( ) ) ; con . s e t S S L S o c k e t F a c t o r y ( s s l S o c k e t F a c t o r y ) ;

Opzetten van een SSL Socket met de Keystore (met het certificaat van de eID) en de TrustStore. Op het moment dat de SSL Socket een connectie maakt, zal er gevraagd worden naar de pincode van de kaart. Wat dan nog over blijft, is het instellen van het SSLSocketFactory bij de HttpsUrlConnection. Hierna kunnen we de standaard werking, zoals bij een niet SSL encrypted URL connectie, toepassen.

Hoofdstuk

3

Resultaten 3.1

Doelstellingen

3.1.1

Basisdoelstellingen

Schrijven Framework in Java Uitvoeren authenticatie/autorisatie Meerdere Authenticatie/autorisatie mechanismen Testomgeving opzetten Feedback user

3.1.2

Extra Doelstellingen

Aangezien de basisfunctionaliteiten vrij snel in een werkend stadium waren, zijn er nog een extra aantal doelstellingen toegevoegd. Deze moesten een diepere studie aangaande de federated authenticatie mechanisme mogelijk maken. En zorgen voor extra gebruikersgemak.

3.2

SAML Bindings Userinterface SAML SLO OAuth met Bearer/SAML token

Behaalde resultaten

Er word voorgesteld dat we het framework in Java zouden schrijven. Dit omwille van de mogelijkheid om deze ook op servers te kunnen runnen. De aanvang van het project ging 50

HOOFDSTUK 3. RESULTATEN

51

aanvankelijk iets moeizamer, omdat we nog in deze omgeving thuis moesten geraken. Java en C# zijn vergelijkbaar op vlak van opbouw en verschillen alleen maar in de kleine details. Maar om de werking met Maven en Sonar in orde te krijgen was er wel wat tweaks nodig. Ook het opzetten van de testomgeving was voor ons een hele uitdaging. Onze kennis over het werken in Linux was redelijk beperkt en hebben we met vallen en opstaan vergroot. Van OpenAM hadden wij ook nog nooit gehoord. Met veel hulp van de documentatie van Forgerock en veel trial & error hebben we dit wel voltooid. Met behulp van OpenAM hebben we SAML 2.0, OAuth 2.0 en gebruikersnaam & wachtwoord kunnen implementeren. Het opzetten van 2 way SSL authenticatie heeft ons ook wel wat tijd gekost. Hier hebben we geen gebruik gemaakt van OpenAM, maar van de standaard SSL mogelijkheid in Apache Tomcat. Even een opsomming van de behaalde delen Mogelijk een authenticatie/autorisatie uit te voeren – SAML 2.0 – OAuth 2.0 – Gebruikersnaam & wachtwoord – eID Multithreading met offset Flow voor authenticatie POST is aanpasbaar door gebruiker Gebruik van logging in JSON voor flexibiliteit Weergave van data in overzichtelijke manier in ELK stack

3.2.1

Problemen en oplossingen

Het grootste probleem was het tekort aan kennis en de nood om onszelf bij te scholen. Ook onderliggende kennis over compatibiliteit tussen verschillende versies van software die onderling moeten samenwerken, heeft ons meerdere malen problemen opgeleverd. OAuth wilde niet werken. Dit kwam door een misconfiguratie en had een herinstallatie nodig van de OAuth instantie.

3.2.2

Niet behaalde doelstellingen

Het beëindigen van een sessie in OAuth hebben we niet tijdig kunnen implementeren. Mede door een gebrekkige documentatie over dit onderwerp door Forgerock.

3.2.3

SAML studie

Omdat we een diepere studie hebben uitgevoerd van SAML 2.0, kunnen we een aantal conclusies trekken. Dit aangaande de snelheid van authenticatie met invloed van de gebruikte bindings.

HOOFDSTUK 3. RESULTATEN

52

In onze testopstelling is het gebruik maken van een ARTIFACT-POST het traagste. Dit was onverwacht en is te wijten aan een trage afhandeling tussen de servers bij het afhandelen van het Artifact. Hierop volgt de verwachte traagste POST-POST, aangezien hier een groter aantal stappen gebeuren.

Figuur 3.1: SP-Initiated SSO: POST/POST

Hoofdstuk

4

Besluit De kennis die wij hebben vergaard, over onder andere het programmeren in Java en het werken in een server Linux omgeving, is groot. Mede door het constant bijleren in de Java omgeving, was het nodig de code dagelijks te vernieuwen en te herschrijven naar nieuw ontdekte methodes. Ook alles wat erbij komt kijken, om een veilige manier van authenticatie op te zetten en dit stap voor stap te doorlopen, was zeer boeiend en leerrijk. We zijn zeer tevreden met het behaalde resultaat, toch is er steeds ruimte voor verbetering. Vooral bij OAuth missen we nog enkele functies: implementeren van zowel Bearer- als SAML tokens intrekken en vernieuwen van tokens logout proces Ook is het niet mogelijk om meerdere eID-authenticaties in threading uit te voeren, dit door de uitwerking binnen de libraries van Fedict. Al bij al denken we dat deze applicatie een meerwaarde kan betekenen bij het testen van verschillende authenticatiemethodes. Ook is het door de uitbreidingen toegevoegd aan SAML, mogelijk om hiervan een diepgaande studie uit te voeren en hiermee een duidelijke beslissing te kunnen maken, gestaafd met de vergaarde data.

53

Bijlage

A

Handleiding Deze handleiding zal u bekend maken met het Federated Authentication Benchmarking Framework programma. U hebt een omgeving waar een authenticatie in gebruikt wordt. Dit framework is specifieker toegericht op federated authenticaties. Maar ook Single Sign on door een POST naar een webpagina is mogelijk. Ook is er een implementatie van eID voorzien. Door de simulatie van wat op applicatie/browser niveau gebeurd zijn de verkregen waarden vergelijkbaar. De verzameling van gegevens maakt het ook direct mogelijk de performantie van een opstelling te kunnen bepalen onder een specifieke load. Wij hopen dat u door deze tool te gebruiken een betere omgeving kan opzetten!

Opstarten De applicatie is in opgebouwd in Java. Het installeren van de laatste Java versie op de computer is verreist. Het opstarten van de jar in een directory waar de gebruiker schrijfrechten op heeft is ook een vereiste. Het programma maakt een aantal file’s aan en zal zonder rechten niet kunnen werken. Indien er geen schrijfrechten zijn op de locatie, zal het programma een foutmelding geven met uitleg.

54

BIJLAGE A. HANDLEIDING

55

Hoofdscherm

Na opstart ziet u het venster waar de meest voorkomende aanpassingen in voorkomen. Specifiek aan de te gebruiken authenticatiemethode zullen verschillende vakken beschikbaar of niet beschikbaar worden. De belangrijkste instellingen zijn die bij Login, deze zijn afhankelijk van de gekozen methode. Onder Method kan je kiezen voor OAuth, SAML, User/Pass en eID. Bij Login dien je een URL in te geven, een Username. Voor eID dien je ook te beschikken over een eID lezer. Bij Advanced kunnen we het aantal Threads instellen en activeren, dit zorgt ervoor dat er meerdere simultane sessies gestart kunnen worden. Die Threads kunnen ook met een tussentijd gestart worden, dit stellen we in bij Thread Offset met een tijd in milliseconden. Voor OAuth, SAML en User/Pass kunnen we ook threads met meerdere accounts uitvoeren door Multiple Accounts te activeren. Tenslotte is het


56

mogelijk om de Binding (IdP naar SP) & Request Binding (SP naar IdP, geen invloed bij IdP initiated) in te stellen. Daarnaast kan je de logout instellingen instellen en aciveren. Voor User/Pass volstaat de URL, bij SAML kan je ook nog een binding aangeven. Indien alles is ingesteld, kan men doormiddel van de Start-knop de sessies starten. Bij het eerste gebruik dienen echter enkele platformspecifieke gegevens toegevoegd te worden. Dit kan bij Settings, te vinden onder Edit.


Settings Onder Settings kan men methode specifieke gegevens instellen.

OAuth

Voor OAuth dient men de IDTokens en de Fields in te geven die op de login pagina staat. Vervolgens kunnen we de Consent Fields en de Consent invullen; die staan op de Consent pagina. De naam waarde van Consent kunnen zelf ingegeven worden, zo kan men zowel met Allow als Deny testen. Tenslotte kan men een standaard URL en een lijst van gebruikers ingeven.

57


SAML

Voor SAML dient men de IDTokens en de Fields in te geven die op de login pagina staat. Vervolgens kunnen we een standaard URL voor zowel login als logout invoeren en een lijst van gebruikers ingeven.

58


Login/Päss

Voor Login/Pass dient men de IDTokens en de Fields in te geven die op de login pagina staat. Daarnaast hebben we ook de Landing URL nodig, dit is de eindpagina van het loginproces. Vervolgens kunnen we een standaard URL voor zowel login als logout invoeren en een lijst van gebruikers ingeven.

59


60

eID

Voor eID zijn er geen verplichte gegevens. We kunnen een standaard URL invoeren, de Trustore Location aanwijzen en bijhorend wachtwoord invoeren.

Bijlage

B

eID authenticatie Volledige beschrijving van het opzetten en programmeren hoe een 2 way ssl authentication te doen met eID. Dit op een apache tomcat server.

Instellen en opzetten SSL/TLS Om een TLS/SSL 2 way authenticatie op te zetten tussen een Java client en een server, hebben we het volgende nodig: op clientside en op serverside een truststore en een keystore.

Aanmaken certificaten Na uitzoeken en testen blijkt het niet mogelijk om een self signed certificaat te gebruiken zonder de truststore op clientzijde volledig uit te schakelen. Er moet dus een chain aangemaakt worden waar de rootCA het certificaat van de server gaat ondertekenen. Hiervoor maken we gebruik van het tooltje XCA. Deze maakt het overzichtelijker. Om te beginnen maken we een nieuwe xdb database aan (na starten tool) File => New Database => geef naam en passwoord. Als eerste stap maken we een 3 tal private keys aan in XCA.

61

BIJLAGE B. EID AUTHENTICATIE

Hierna maken we in het Certificates tabblad een nieuw self signed TestsetupCA certificaat aan. Als CN stellen we CN=TestsetupCA in en Private key gebruiken we de key die we voor de root hebben aangemaakt. Bij “Template for the new certificate” stellen we [default] CA in. In tab “Extensions” bij type “Certificate Authority” Controleren of de Validity tijd voldoende is. We drukken op ok en het root self signed certificate zou gegenereerd moeten worden

62


Hierna gaan we naar het tabblad “Certificate signing requests”. Allereerst zullen we een certificaat aanmaken voor de server. We klikken op New Request. Source => Template for the new certificate => HTTPS_server Subject => commonName (CN) => naam server in onze setup is dat www.testsetup.be => Private key gebruiken we de key die we voor de server hebben aangemaakt. Extensions => Type => End Entity OK Rechterklik op het aangemaakte certificaat => sign Source => Signing => Use this Certificate for signing => selecteer het certificaat dat we hebben aangemaakt hier TestsetupCA => OK Source => Template for the new certificate => HTTPS_server Dan maken we een certificaat voor de client aan. We klikken op New Request. Source => Template for the new certificate => HTTPS_client Subject => commonName (CN) => deze naam is niet belangrijk omdat men hier ClientCert gebruikt => Private key gebruiken we de key die we voor de client hebben aangemaakt.

63

BIJLAGE B. EID AUTHENTICATIE Extensions => Type => End Entity OK Rechterklik op het aangemaakte certificaat => sign Source => Signing => Use this Certificate for signing => selecteer het certificaat dat we hebben aangemaakt hier TestsetupCA => OK

De volgende stap is het exporten van de 3 certificaten die nodig zijn. Allereerst hebben we een trusted certificaat van de rootCA nodig. We selecteren het rootCA certificaat en drukken op Export.

64

BIJLAGE B. EID AUTHENTICATIE We selecteren DER formaat en een directory waar we voorlopig alle certificaten gaan opslaan.

Hierna Exporten we de 2 certificaten die gegenereerd zijn voor de client en server. Deze zetten we in pkcs12 formaat.

Dit doen we voor beide certificaten die gesigned zijn door de rootCA. We hebben nu de 3 certificaten gegenereerd die we nodig hebben voor de setup van de client en tomcat.

65


66

Toevoegen certificaten serverside Om op de Tomcat connector een SSL connectie op te zetten, moeten we hier 2 dingen in configureren. De truststore en de keystore. In de truststore komt het certificaat van de RootCA. In de keystore komt het servercertificaat getekend door de RootCA. Hieronder een voorbeeld van wat wij hebben toegevoegd aan de Server.xml van tomcat in de /conf directory. Als we naar poort 8443 surfen zal er een https connectie gestart worden. Om tomcat deze .keystore files te laten ontvangen, moeten we de server p12 file toevoegen aan een keystore file en de server de der file in een andere .keystore file. Hiervoor gebruiken we het keytoolcommando met de volgende context Genereren keystore van de RootCA keytool -importcert -alias servertruststore -file /root/Desktop/RootCert.der -keystore rootCAtrust.keystore Genereren keystore van de Server zelf keytool -v -importkeystore -srckeystore /root/Desktop/ServerCert.p12 -srcstoretype PKCS12 destkeystore serverKeystore.keystore De wachtwoorden die gebruikt worden bij het genereren van de .keystore files moeten ingevuld worden in de keystorPass en truststorePass velden in de van Tomcat. Ook het aanpassen van de directory bij truststoreFile en keystoreFile, naar de locatie waar we de keystore opslaan, is nodig. We herstarten de Tomcat server. Configuratie van https op de Tomcat server is nu voltooid.

Browser Test HTTPS Voor deze test hebben we gebruik gemaakt van Firefox. De workflow is als volgt. Allereerst moeten we het RootCert.der file toevoegen aan de lijst van Authorities in de browser. Hierna voegen we de ClientCert.p12 toe aan My Certificates.


67

We testen of we verbinding krijgen met https://www.testsetup.be:8443 . Firefox zal dan vragen voor de identificatie met certificaat.

Als alles goed ging, krijg je nu de Tomcat pagina te zien. Als laatste controle dat de rootCA werkelijk werkt, klikken we op het slotje en zien we dat de RootCA het certificaat van de server correct ondertekend heeft.

SSL/TLS is nu correct geïnstalleerd op de apache tomcat server om in de java setup te werken.


68

Client keystore aanmaken Aangezien we om het opzetten van een connectie in Java een Truststore en een Keystore nodig hebben, moeten we nog een Keystore genereren. De Truststore die we op de server hebben aangemaakt, is hier ook te gebruiken. We kunnen deze uiteraard ook nog een 2de keer genereren. Dit doen we met het volgende commando. De passwoorden die we instellen voor deze keystore’s, zullen we later in het java programma nog moeten gebruiken. keytool -importcert -alias servertruststore -file RootCert.der -keystore rootCAtrust.keystore We moeten dan nog een keystore generen voor de client aan de hand van het ClientCert.p12 file. keytool -v -importkeystore -srckeystore ClientCert.p12 -srcstoretype PKCS12 -destkeystore clientKeystore.keystore

Wanneer deze 2 files gegenereerd zijn, is alles volledig klaar om via Java een SSL/TLS verbinding met een server te leggen.

Voorbeeld implementatie in java Voorbeeld project dat werkt op de gebruikte setup. HttpsUrlConnection laat toe een SSLSocketFactory in te stellen. Als deze correct gemaakt is, zal de manier van posten en getten zoals bij HttpUrlConnection grotendeels hetzelfde blijven.

Het opzetten van KeyManager //Instellen KeyManager KeyManagerFactory kmf =KeyManagerFactory.getInstance("SunX509"); KeyStore ks = KeyStore.getInstance("JKS"); File cert =new File(baseDir+keyName); InputStream stream = new FileInputStream(cert); ks.load(stream, "password".toCharArray()); stream.close(); kmf.init(ks, "password".toCharArray()); System.out.println("KeyStore added");

We maken allereerst de objecten van de classes KeyManagerFactory en Keystore met de juiste instanties. Voor kmf nemen we de SunX509 omdat de encoding in x509 is. Voor ks de JKS (Java KeyStore), door gebruik te maken van de keytool van Java is deze automatisch in JKS formaat. We laden het certificaat in een file cert, waarna we deze via een FileInputStream laden naar stream. Hierna roepen we de load methode aan op het keystore object en geven we stream en het passwoord in chararray mee. Initiëren van de keymanagerfactory met het keystore object en het passwoord opnieuw in chararray. Hiermee is de KeyManager volledig in orde.


69

//Instellen TrustManager TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); KeyStore trustks = KeyStore.getInstance("JKS"); File trustcert = new File(baseDir+trustName); InputStream truststream = new FileInputStream(trustcert); trustks.load(truststream, "password".toCharArray()); truststream.close(); tmf.init(trustks); System.out.println("TrustStore added");

Wat dan nog rest is de TrustManager, die we moeten laden in de SSLContext later. Er wordt een instantie ‘’SunX509” geladen in een TrustManagerFactory object. De overige werking is zo goed als hetzelfde als bij de KeyStore. Alleen wordt er nu de trust file geladen in het keystore object. //Key + Trust toevoegen aan SSL socket SSLContext context = SSLContext.getInstance("TLS"); context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom()); SSLSocketFactory factory = context.getSocketFactory();

SSLContext object aanmaken met instance voor TLS. Initialiseren met de trustmanager en de Keymanagers. Uit het context object de SocketFactory halen. con.setSSLSocketFactory(factory);

Wat dan nog overblijft, is het instellen van het SSLSocketFactory bij de HttpsUrlConnection. Hierna kunnen we de standaard werking zo als bij een niet SSL encrypted URL connectie toepassen. Hieronder de volledige code als referentie voor de blokken waar hierboven dieper op ingegaan werd. import java.io.BufferedReader; import java.io.File; import java.io.FileInputStream; import java.io.InputStream; import java.io.InputStreamReader; import java.net.URL; import java.security.KeyStore; import java.security.SecureRandom; import javax.net.ssl.HttpsURLConnection; import javax.net.ssl.KeyManagerFactory; import javax.net.ssl.SSLContext; import javax.net.ssl.SSLSocketFactory; import javax.net.ssl.TrustManagerFactory; public class Connect { private String baseDir, trustName, keyName; public Connect(String basedir,String truststorename, String keystorename) { //truststore and keystore in same directory after generating them with keytool baseDir = basedir; trustName = truststorename; keyName = keystorename; } public void InitiateConnection(String urlString) throws Exception {

BIJLAGE B. EID AUTHENTICATIE URL url = new URL(urlString); HttpsURLConnection con = (HttpsURLConnection) url.openConnection(); con.setDoOutput(false); con.setDoInput(true); //Instellen KeyManager KeyManagerFactory kmf =KeyManagerFactory.getInstance("SunX509"); KeyStore ks = KeyStore.getInstance("JKS"); File cert =new File(baseDir+keyName); InputStream stream = new FileInputStream(cert); ks.load(stream, "password".toCharArray()); stream.close(); kmf.init(ks, "password".toCharArray()); System.out.println("KeyStore added"); //Instellen TrustManager TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509"); KeyStore trustks = KeyStore.getInstance("JKS"); File trustcert = new File(baseDir+trustName); InputStream truststream = new FileInputStream(trustcert); trustks.load(truststream, "password".toCharArray()); truststream.close(); tmf.init(trustks); System.out.println("TrustStore added"); //Key + Trust toevoegen aan SSL socket SSLContext context = SSLContext.getInstance("TLS"); context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom()); SSLSocketFactory factory = context.getSocketFactory(); //Adding factory to con (HttpsUrlConnect) con.setSSLSocketFactory(factory); System.out.println(con.getResponseCode()); //Morgelijk maken van opslaan returnpage BufferedReader in = new BufferedReader(new InputStreamReader( con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); String Webpage = response.toString(); System.out.println(Webpage); } }

70


71

Aanpassing voor eID Serverside Om de mogelijkheid toe te voegen om te authenticeren via eID op de Tomcat server, moet er maar 1 ding aangepast worden. De truststore moet beschikken over de Belgian Root CA. Deze is op het moment van schrijven terug te vinden op http://repository.eid.belgium.be/ . We importeren dit certificaat in de truststore met het volgende commando: keytool -importcert -alias servertruststore -file /root/Desktop/belgiumrca2.crt -keystore rootCAtrust.keystore We vullen het password in dat we hebben ingesteld voor de store en valideren dat we dit certificaat vertrouwen. Na het installeren van de plugin in Firefox van de eID kunnen we het certificaat gebruiken van op de eID om te authenticeren. De testsetup is nu volledig in orde om op browser niveau te testen.

Ondervinding Tijdens het testen hebben we ontdekt dat er tijdens de handshake met de Tomcat server en client een vorm van intelligentie aanwezig is. De server zal tijdens de handshake een aantal delen van zijn truststore meegeven naar de browser toe. Zo kan deze een betere selectie geven uit de lijst van geïnstalleerde certificaten.

Clientside Het testen vanuit de browser werkt op dezelfde manier als op de testsite van eID. Het insteken van de eID voor het openen van https://www.testsetup.be:8443 is wel een vereiste. Firefox zal dan een prompt weergeven met hierin het certificaat van de eID waarna we de pincode moeten ingeven. De authenticatie slaagt, dus kunnen we er van uitgaan dat de opstelling werkt. Opgelet het is belangrijk dat in de lijst van trusted authorities, het certificaat van de Tomcat server blijft staan.


72

Java implementatie In de code maken we gebruik van een aantal dependencie’s en repo’s deze heb zijn toegevoegd aan het pom.xml bestand. Op het moment van schrijven zijn deze nog beschikbaar. e-Contract.be https://www.e-contract.be/maven2/ <enabled>true <dependencyManagement> <dependencies> <dependency> be.fedict.commons-eid <artifactId>commons-eid-bom 0.5.3 pom <scope>import <dependencies> <dependency> be.fedict.commons-eid <artifactId>commons-eid-jca 0.5.3

Hiermee hebben we de volledige commons-jca van eid. Hiermee zullen wij de SSLSocket kunnen opzetten met de eID.

Bibliografie

[1] eID. http://eid.belgium.be/. 2 [2] eID repository. http://repository.eid.belgium.be/index.php?lang=nl. 21 [3] Federated identity - Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/ Federated identity/. 2 [4] Public-Key-Infrastructure.svg - Wikimedia Commons. http://upload.wikimedia.org/ wikipedia/commons/3/34/Public-Key-Infrastructure.svg. 20 [5] The Open Universe: One Way and Two Way SSL and TLS. http://www.ossmentor.com/ 2015/03/one-way-and-two-way-ssl-and-tls.html. 21 [6] D. Hardt Ed. The OAuth 2.0 Authorization Framework. Technical report, Internet Engineering Task Force, oktober 2012. 17 [7] S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 . Technical report, OASIS, maart 2005. 9 [8] Ping Identity Corporation. PingFederate Getting Started, 6.10.1 edition, januari 2013. 10, 11, 12, 13, 14, 15

73

Federated Authentication Benchmarking Framework

Recommend Documents