net web services en security voor...

Faculteit Toegepaste Wetenschappen

Vakgroep informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

.NET Web Services en security voor

E-procurement

door

Matthias DE RIDDER

Promotoren: Prof. Dr. Ir. E. LAERMANS, Prof. Dr. Ir. F. GIELEN

Scriptiebegeleiders: Ir. W. HAERICK, Ir. S. VAN HOECKE

Scriptie ingediend tot het behalen van de academische graad van

licentiaat in de informatica

Academiejaar 2004 – 2005

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van

de scriptie te kopiëren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met

betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van

resultaten uit deze scriptie.”

Matthias De Ridder, mei 2005.

Dankwoord

Eerst en vooral wil ik mijn ouders vanuit de grond van mijn hart bedanken voor de mogelijkheid die ze

mij geboden hebben om deze studies te volgen, en voor de constante steun en aanmoediging die ze mij

hebben gegeven. Zij – en ook mijn zus en broer – hebben ervoor gezorgd dat ik ondanks vele

moeilijke perioden steeds in mezelf bleef geloven, waardoor ik ook ben blijven doorzetten.

Mijn oprechte dank gaat ook uit naar Prof. Dr. Ir. Eric Laermans en Prof. Dr. Ir. Frank Gielen voor het

promoten van deze thesis en de geboden ondersteuning.

Ook mijn scriptiebegeleiders, Ir. Wouter Haerick en Ir. Sofie Van Hoecke, wil ik van harte bedanken.

Ondanks mijn niet aflatende stroom van vragen en e-mails, hebben zij mij steeds bijgestaan en verder

geholpen – waarschijnlijk zelfs tot vervelends toe. Dank u wel! Zonder jullie zou ik er zeker niet zijn

geraakt.

Verder wil ik ook mijn medestudenten bedanken, die ook steeds klaar stonden met hun mening en

suggesties. In het bijzonder wil ik de volgende personen bedanken: Wim, Xavier, Dieter DM., Dieter

F., Wala en Alexander. We hebben vaak ook samen gewerkt als projectpartners, waarvoor ook mijn

dank.

Ook mijn familie verdient een blijk van dank. Nonkel William, bedankt voor uw blijvende

belangstelling en aanmoediging. Oma, opa en bobonne, bedankt voor jullie steun en het geloof in mijn

kunnen. Ik zou hier nog vele namen kunnen opnoemen: nonkel Kamiel, tante Katrien, nonkel David,

tante Hilde, … Ik wil iedereen van harte bedanken.

Kristof wil ik bedanken voor het opofferen van zijn vrije tijd om mij door de wiskunde examens te

helpen, en Sarah voor de aanmoedigingen en de verzekering dat het me wel zou lukken.

Mijn dank gaat ook uit naar de vele vrienden die mij door dik en dun hebben gesteund, en mij steeds

hebben blijven aanmoedigen. In het bijzonder: Pedro, Jan, Paul, Lieveke, Kenneth, Evy, Eefje, Léon,

René, Sophie-Ann, Katy, André, Belinda, Marina, …

Er zijn nog vele anderen die ik zou moeten bedanken, maar dat zou een boek op zich vormen. Ook aan

hen: een welgemeend: ‘Dank u wel!’

In gedachte voor Parein.

Matthias De Ridder, mei 2005.

.NET Web Services en security voor e-procurement

door

Matthias DE RIDDER

Academiejaar 2004 – 2005

Promotoren: Prof. Dr. Ir. E. LAERMANS, Prof. Dr. Ir. F. GIELEN

Scriptiebegeleiders: Ir. W. HAERICK, Ir. S. VAN HOECKE

Faculteit Toegepaste Wetenschappen

Universiteit Gent

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting

Heden ten dage maken ziekenhuizen gebruik van manuele reverse auctioning om

aanbestedingen te plaatsen. Dit betekent dat meerdere verkopers of aanbieders trachten om

een klant of koper voor zich te winnen door deel te nemen aan een biedingproces.

Het nadeel van dit systeem is dat het zeer tijdsrovend is en gelimiteerd. Doordat alles

telefonisch of via briefwisseling gebeurt, gaat veel tijd verloren met het wachten op een

reactie. Bovendien is dit systeem niet winstgevend.

E-procurement zou een oplossing kunnen zijn. Hierbij wordt een Web Service framework

aangeboden die in Web Service interfaces voorzien die gebruik maken van een achterliggende

business logic en database acces om aanvragen te verwerken. Voor de gebruiker wordt een

thick client geïmplementeerd die hem of haar in staat stelt te interageren met het Web Service

framework.

De aandacht ligt vooral op het security aspect. De integriteit van berichten moet kunnen

gegarandeerd worden, enkel geautoriseerde en geauthenticeerde gebruikers mogen toegang

krijgen tot de diensten. Er wordt een grondig onderzoek gedaan naar de mogelijke security

threats en de technologieën die kunnen gebruikt worden om de threats te voorkomen.

Trefwoorden

Web Services, security, e-procurement, .NET, SSL, WSS, WSE, reverse auctioning.

INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1

2 Web Services 4

2.1 Wat zijn Web Services? 4

2.2 Web Services en XML 6

3 Onderzoek en technologie 8

3.1 Security threats 8

3.2 SSL versus WSS 17

3.3 MySQL 19

4 Specificatie 20

4.1 Use cases 20

4.1.1 Gebruiker Use cases 20

4.1.2 Security Use case 24

4.2 Sequentiediagrammen 26

5 Architectuur 29

5.1 Algemeen ontwerp 29

5.2 UML diagrammen 31

5.3 Interfaces 34

5.4 Sequentiediagrammen 37

5.5 Toevoegen Digital Signatures 40

6 Implementatie 43

6.1 Client GUI’s 43

6.1.1 Hospital Client GUI 43

6.1.2 Supplier Client GUI 46

6.1.3 UserCreator 47

6.2 Web service framework 48

7 Besluit 51

7.1 Conclusie 51

7.2 Verdere ontwikkelingen 52

Appendices 55

Bibliografie 60

INLEIDING 1

Hoofdstuk 1

Inleiding

Wanneer ziekenhuizen vandaag de dag een aanbesteding wensen te plaatsen om producten

aan te schaffen, maken ze gebruik van manuele reverse auctioning.

Reverse auctioning houdt in dat meerdere verkopers of aanbieders trachten een klant of koper

voor zich te winnen door deel te nemen aan een biedingproces. Zoals reeds vermeld, gebeurt

dit nu nog manueel.

In de situatie die hier behandeld wordt, is de klant of koper een ziekenhuis, en de verkoper of

aanbieder een leverancier. Wanneer een ziekenhuis een aanbesteding wenst te plaatsen, zal dit

meestal gebeuren door middel van een rondschrijven naar de leveranciers. Daarop moet het

ziekenhuis wachten totdat het een antwoord heeft ontvangen van de betrokken leveranciers.

Het ziekenhuis moet dan de verschillende prijzen van de geboden offertes met elkaar

vergelijken, en kan dan nog de leveranciers bijvoorbeeld telefonisch contacteren om eventueel

nog een betere prijs te verkrijgen.

Dit proces is zeer tijdrovend. Ten eerste moet het ziekenhuis wachten tot zij alle offertes heeft

ontvangen. Ten tweede moet het ziekenhuis dan nog de leveranciers opnieuw contacteren

willen ze een nog betere prijs verkrijgen. Dit systeem is dut niet winstgevend.

Het automatiseren van dit proces kan gebeuren door gebruik te maken van E-procurement.

Om de diensten aan te bieden die vereist zijn, zal een Web Service framework worden

aangeboden. Dit framework bestaat uit een aantal Web Service interfaces, die gebruik maken

van een achterliggende business logic om de aanvragen van gebruikers af te handelen. De

business logic maakt op zijn beurt gebruik van database access componenten om gegevens in

de databank op te slaan of op te halen.

INLEIDING 2

Voor een gebruiker wordt er een thick client voorzien, waarmee hij of zij kan interageren met

de Web Service interfaces.

De nadruk van deze thesis ligt vooral bij het security aspect wanneer het E-procurement

framework wordt uitgewerkt. Het is namelijk van het grootste belang dat er aan de gebruiker

gegarandeerd kan worden dat de aanbesteding die hij of zij heeft geplaatst, niet door een

derde kan aangepast worden. Dit zou kunnen gebeuren indien een derde in staat zou zijn om

berichten die verstuurd worden tussen de thick client en de Web Service interfaces, te

onderscheppen. Een andere security threat zou kunnen zijn dat een onbevoegd persoon de

centrale databank infecteert met niet toegelaten SQL queries, om op die manier data te

verkrijgen of te verwijderen. Een ander belangrijk aspect is dat de bieders garanties moeten

hebben dat de ziekenhuizen de offertes die geplaatst worden, op een eerlijke manier

behandelen.

In het verdere verloop van dit boek zal er een studie gemaakt worden van de voornaamste

security threats, en besproken worden op welke manier die kunnen voorkomen worden. Het

uiteindelijke doel van de thesis is om tot een proof of concept applicatie te komen die voldoet

aan de belangrijkste security eisen.

Er zal ook aandacht besteed worden aan de verschillende beschikbare security technologieën

die gebruikt kunnen worden in de uiteindelijke applicatie. Het security concept van die

technologieën wordt bestudeerd, alsook de performantie.

Het afleveren van een component gebaseerde applicatie is een vereiste, zodat het eenvoudig is

om extra features toe te voegen of de applicatie in bestaande systemen te integreren.

INLEIDING 3

De volgende punten zullen in dit boek worden behandeld:

Hoofdstuk 1 biedt een korte uiteenzetting van het onderwerp dat deze thesis behandeld

Hoofdstuk 2 tracht een bondig inzicht te verschaffen in wat Web Services inhouden.

Hoofdstuk 3 geeft een overzicht van de belangrijkste security threats en de gebruikte

technologieën.

Hoofdstuk 4 en 5 schetsen een beeld van de manier waarop de uiteindelijke applicatie zal

opgebouwd zijn, en zal het component gebaseerd ontwerp van de applicatie trachten

aan te tonen.

Hoofdstuk 6 bespreekt de implementatie van de applicatie.

Hoofdstuk 7 bevat de conclusie van deze thesis en belicht enkele mogelijke verdere

ontwikkelingen.

WEB SERVICES 4

Hoofdstuk 2

Web Services

Dit hoofdstuk heeft tot doel een globaal inzicht te verschaffen in de structuur en de

specificaties van Web Services.

2.1 Wat zijn Web Services?

Voor veel applicaties bestaat de noodzaak om een gedistribueerd systeem aan te bieden

waarvan de onderdelen over het internet verspreid zijn, zoals databases, veiligheidsdiensten,

financiële componenten en nog meer. Web Services bieden deze mogelijkheid.

Een XML-webservice is een component die een faciliteit biedt aan clients of afnemers. Een

XML-webservice is niets anders dan een component met een wereldwijd bereik. Het is een

applicatie of een stuk uitvoerbare code die op een webserver wordt gehost, en wiens

methoden opgeroepen kunnen worden door middel van XML protocollen. Het voordeel van

Web Services is dat ze niet sterk gebonden zijn aan een specifieke technologie voor security,

management of transport, waardoor ze in praktisch elk development scenario gebruikt kunnen

worden.

In tegenstelling tot DCOM, RMI, IIOP of een van de andere veel gebruikte protocollen,

maakt een XML-webservice gebruik van een gestandaardiseerd, geaccepteerd en

goedbegrepen protocol, namelijk HTTP, en een evenzeer gestandaardiseerde

gegevensindeling, gebaseerd op XML.

WAT ZIJN WEB SERVICES? 5

Het idee achter Web Services is dat een XML-webservice de basiselementen voor systemen

aanbiedt en het web als medium gebruikt wordt om er toegang tot te krijgen. XML-

webservices kunnen toepassingsspecifiek zijn, maar kunnen evengoed tot een algemeen nut

dienen.

Om een verzoek naar een XML-webservice te verzenden en een antwoord te ontvangen,

wordt er gebruik gemaakt van het Simple Object Access Protocol (SOAP).

SOAP is een lichtgewicht protocol dat op HTTP is gebouwd. Het is mogelijk SOAP-

berichten tussen verschillende protocollen uit te wisselen, maar op dit moment is SOAP alleen

voor HTTP gedefinieerd. SOAP definieert een XML-grammatica om de namen op te geven

van de methoden die een afnemer via een XML-webservice wil aanroepen, voor het

definiëren van de parameters en return-waarden en om de typen van de parameters en return-

waarden te beschrijven. Roept een client een XML-webservice aan, dan moeten de methode

en parameters opgeven worden die door deze XML-grammatica worden voorgeschreven.

SOAP is geaccepteerd als een industriestandaard. Het heeft als taak de samenwerking tussen

verschillende platformen te verbeteren. De kracht van SOAP is de eenvoud, naast het feit dat

SOAP gebaseerd is op andere industriestandaarden: HTTP en XML.

De SOAP specificatie definieert een aantal zaken. De belangrijkste zijn:

• de indeling van een SOAP-bericht;

• hoe gegevens gecodeerd moeten worden;

• hoe berichten moeten verzonden worden;

• hoe antwoorden ontvangen worden.

In Appendix C wordt er een SOAP bericht weergegeven. De body van een SOAP bericht staat

in XML. De webserver verwacht dat de client een aantal tags gebruikt om de parameters voor

een methode die hij of zij oproept, te coderen. Een XML-webservice zal een beschrijving van

zichzelf geven, zodat de client weet welk schema er gebruikt moet worden om de webserver

aan te spreken.

Het schema heet Web Services Description Language (WSDL). Deze omschrijving biedt voor

een client genoeg informatie om een SOAP-bericht in te dienen in een indeling die de

webserver kan begrijpen.

WEB SERVICES EN XML 6

Een XML- webservice wordt van andere Web Services onderscheiden door een unieke

namespace te identificeren, zodat een client zich tot de juiste Web Service kan richten. Web

Services kunnen ook gebruik maken van een DISCO bestand, dat een lijst van Web Services

en hun respectievelijke links bevat, gespecificeerd in een speciaal XML formaat. Door van

DISCO gebruik te maken, kan een webserver automatisch doorzocht worden op Web Service

bestanden.

Tabel 2.1: Web Service terminologie

Technologie Omschrijving

WSDL Een op XML gebaseerd formaat dat een Web Service beschrijft, een

lijst bevat van de methoden, de data types van de parameters en

return waarden, alsook de ondersteunde communicatiemethoden.

HTTP Het communicatieprotocol dat gebruikt wordt om verzoeken en

antwoorden over het Internet naar de Web Service te verzenden.

SOAP Een op XML gebaseerd formaat dat gebruikt wordt om de informatie

in een Web Service verzoek of antwoord te coderen voordat het via

het Internet naar de Web Service wordt gestuurd.

DISCO Een optionele Microsoft specificatie dat clients in staat stelt om Web

Services te “ontdekken” (discover).

UDDI Een directory dat client in staat stelt om Web Services te vinden die

door een specifiek bedrijf werden ontwikkeld.

Om informatie met betrekking tot een Web Service vrij te geven, maakt men gebruik van

Universal Description, Discovery, and Integration (UDDI). Een UDDI register bevat

informatie over bedrijven, de services die zij verlenen, het type van elke service, en links naar

informatie en specificaties betreffende deze services. De interface van UDDI is zelf een Web

Service.

Tabel 2.1 bevat een korte omschrijving van de belangrijkste Web Service technologieën.

2.2 Web Services en XML

Wanneer er gebruik gemaakt wordt van Web Services, moet er rekening mee gehouden

worden dat Web Services niet alle types als parameters aanvaarden, of als return value terug

geven. Aangezien binnen onze applicatie klassen zullen moeten gedefinieerd worden die

WEB SERVICES EN XML 7

aanbestedingen, offertes, orders enz. voorstellen, zal er voor een probleem ontstaan om die

gegevens te versturen tussen de thick clients en de Web Service Interfaces.

Xml kan gebruikt worden om dit probleem op te lossen. Er kan namelijk een XML schema

gedefinieerd worden, waarna de gegevens uit een aanbesteding en offertes kunnen geparsed

worden naar een XML bestand. Dit bestand kan dan als XmlNode naar de Web

Service of de thick client verstuurd worden. De gebruikte XML schema’s worden in Appendix

A weergegeven.

ONDERZOEK EN TECHNOLOGIE 8

Hoofdstuk 3

Onderzoek en technologie

In dit hoofdstuk worden de belangrijkste security threats onderzocht waarmee het Web

Service framework mee geconfronteerd kan worden, en wordt er nagegaan op welke manier

ze kunnen voorkomen worden. Verder worden de technologieën besproken die in de

applicatie gebruikt worden, vermeld.

3.1 Security threats

Iedereen is het er mee eens dat een goede beveiliging van een applicatie absoluut

noodzakelijk is. Hoewel er nooit een volledig waterdichte beveiliging gegarandeerd kan

worden, is het toch noodzakelijk dat er aan het security aspect de nodige aandacht wordt

besteed.

Door de komst van het internet, zijn er heel wat security threats opgedoken, en wordt er veel

tijd en moeite gedaan om die threats tegen te gaan, al dan niet succesvol! Aanvallen kunnen

tegen verschillende componenten van de applicatie gericht zijn, zoals blijkt uit fig. 3.1. Zo

zou de aanval gericht kunnen zijn tegen het netwerk (fig. 3.1, punt 1).

Een netwerk structuur bestaat voornamelijk uit routers, firewalls en switches. Deze devices

zorgen voor de beveiliging van de servers en applicaties tegen aanvallen en infiltraties in het

systeem. Een aanvaller kan dan ook zwak geconfigureerde network devices misbruiken. De

meest kwetsbare factoren omvatten zwakke default installatie settings en componenten die

niet up-to-date zijn met de laatste security patches.

SECURITY THREATS 9

Anderzijds kan een aanval ook tot doel hebben om de client (fig. 3.1, punt 3) te infiltreren.

Tot slot kan ook de applicatie (fig. 3.1, punt 2) zelf het mikpunt van een aanval zijn.

Figuur 3.1: Security threats zones

In wat volgt worden de meest voorkomende aanvallen onderzocht, vermeld op welk niveau ze

kunnen voorkomen, en ook worden de maatregelen besproken die er tegen kunnen genomen

worden.

Information Gathering:

Niveau: netwerk

Network devices kunnen op dezelfde manier ontdekt worden als andere types van systemen.

Een aanvaller start meestal met port scanning, of footprinting. Nadat een aanvaller de niet-

gebruikte poorten geïdentificeerd heeft, probeert hij of zij het type van de devices te

achterhalen, alsook het gebruikte operating system en de versies van de applicaties. Wanneer

een aanvaller over zulke informatie beschikt, kan hij of zij bekende zwakheden gebruiken om

een aanval uit te voeren.

1.

2.

3.

SECURITY THREATS 10

Maatregelingen:

• Routers zo configureren dat ze footprinting verzoeken negeren.

• Het operating system zo configureren dat ze footprinting verhinderen door niet-

gebruikte protocollen en onnodige poorten uit te schakelen.

Eavesdropping

Niveau: netwerk

Eavesdropping houdt in dat men de data trafiek op het netwerk onderzoekt, met de bedoeling

om paswoorden of configuratie informatie te achterhalen. Met een simpele packet sniffer kan

de aanvaller op een gemakkelijke manier plaintext trafiek lezen. De aanvaller kan eveneens

pakketten die met een eenvoudige hashing algoritme gecodeerd zijn, kraken. Op die manier

komt hij of zij informatie te weten waarvan gedacht werd dat ze beveiligd was.

Maatregelingen:

• Hanteer een sterke beveiliging over je netwerk.

• Encrypteer de communicatie volledig. SSL kan hiervoor gebruikt worden.

Spoofing

Niveau: netwerk

Spoofing wordt gebruikt om de ware identiteit te verbergen over het netwerk. Om een

spoofed identiteit te verkrijgen, zal de aanvaller een vals bron adres gebruiken, die niet het

actuele adres van het packet bevat. Spoofing kan gebruikt worden om de bron van een aanval

te verbergen of om network access control lists (ACL’s) te omzeilen, die gebruikt worden om

client access te limiteren via source adres regels.

Deze aanval is moeilijk tegen te gaan. Wanneer de aanvaller zorgvuldig gebruik maakt van

spoofed packets, is de kans groot dan de oorspronkelijke zender nooit achterhaald kan

worden. Er kan wel gebruik gemaakt worden van filtering regels die spoofed pakketten

afkomstig zijn uit het eigen netwerk blokkeren.

SECURITY THREATS 11

Maatregelingen:

• Ingaande pakketten filteren die afkomstig zijn van een intern IP adres binnen het

netwerk.

• Uitgaande pakketten filteren die afkomstig zijn van een ongeldig lokaal IP adres.

Man in the middle attack

Niveau: netwerk

Deze aanval tracht een server of een client te misleiden, zodat het een aanvaller als een

legitieme gebruiker beschouwt. De aanvaller kan dan het netwerk manipuleren.

Maatregelingen:

• Gebruik geëncrypteerde negotiation.

• Gebruik geëncrypteerde communicatie kanalen.

• Zorg voor recente security patches die TCP/IP gebreken oplossen, zoals voorspelbare

packet sequences.

Denial of Service

Niveau: netwerk, client

Deze aanval verhindert toegang tot de server of de services voor legitieme gebruikers. De

SYN flood aanval is een vaak voorkomend voorbeeld van een DoS aanval. Het is eenvoudig

om het te laten lanceren, maar moeilijk om het tegen te gaan. Het doel van de aanval is om

meer aanvragen naar de server te versturen dan het aankan. De aanval maakt misbruik van een

mogelijke zwakheid in de TCP/IP connectie en overspoelt de server met een te behandelen

connection queue.

Maatregelingen:

• Wees up-to-date met de laatste service packs.

• Beveilig de TCP/IP stack door het toevoegen van de noodzakelijke registry settings

die de grootte van de TCP connection queue vergroot, de connection establishment

SECURITY THREATS 12

periode vermindert en maak gebruik van log mechanismen om te verzekeren dat de

connection queue niet wordt overbelast.

• Gebruik een network Intrusion Detection System (IDS), die automatisch SYN

aanvallen ontdekt en beantwoordt.

Virussen, Trojan Horses en Wormen

Niveau: client

Een virus is een programma dat ontwikkeld werd met de bedoeling om schade en storingen te

veroorzaken aan je operating system of je applicaties. Een Trojan horse kan ook als een virus

beschouwd worden, alleen wordt de schadelijke code verborgen in een data bestand of een

uitvoerbaar bestand die er onschadelijk uitziet. Een worm kan dan weer vergeleken worden

met een Trojan Horse, met dat verschil dat het zich zelf verspreidt van server naar server.

Deze aanvallen zijn wellicht de meest voorkomende. De reden hiervoor ligt bij zwakke

default configuraties, software bugs en zwakheden in Internet protocols.

Maatregelingen:

• Installeer steeds de laatste service packs en patches voor je operating system en je

applicaties.

• Zorg voor een firewall, die alle niet-gebruikte poorten blokkeert.

• Schakel niet-gebruikte protocollen en services uit.

• Verander de default configuraties, en maak ze moeilijker te omzeilen.

Footprinting

Niveau: client

Voorbeelden van footprinting zijn het scannen van poorten en pingen, waardoor aanvallers

belangrijke informatie over je systeem te weten kunnen komen om dan een grotere aanval te

plannen. Informatie die aanvallers op die manier kunnen verkrijgen kan gaan van account

informatie, het gebruikte operating system en software versies tot server namen en database

schema informatie.

SECURITY THREATS 13

Maatregelingen:

• Schakel niet-gebruikte protocollen uit.

• Zorg voor een firewall, die alle niet-gebruikte poorten blokkeert.

• Gebruik TCP/IP en IPSec filters, om meer beveiliging te waarborgen.

• Gebruik een IDS die footprinting patronen kan opsporen en verdachte trafiek

blokkeren.

Paswoord Cracking

Niveau: client

Wanneer een aanvaller geen anonieme connectie met de server kan opzetten, zal hij of zij een

geldige connectie trachten op te zetten. Hiervoor moet de aanvaller een geldige login en

paswoord kennen. Daarom is de keuze van je account naam en je paswoord van groot belang.

Maatregelingen:

• Gebruik paswoorden die niet eenvoudig te achterhalen zijn.

• Zorg ervoor dat je slechts een beperkt aantal keer kan proberen een wachtwoord in te

geven.

• Gebruik geen default login en paswoord namen.

• Hou eventueel een log bij van falende login pogingen om een patroon te kunnen

herkennen.

Arbitrary Code Execution

Niveau: client

Wanneer een aanvaller er in slaagt om kwaadaardige code op een systeem uit te voeren, kan

de aanvaller de resources verder aanvallen of nieuwe aanvallen uitvoeren om het systeem nog

dieper te infiltreren.

SECURITY THREATS 14

Maatregelingen:

• Wees up-to-date met patches en updates die mogelijke buffer overflows verhelpen.

Unauthorized Access

Niveau: client

Wanneer de connection instellingen slecht geconfigureerd zijn, kan een aanvaller gemakkelijk

toegang krijgen tot informatie of services die gelimiteerd zijn tot binnen het systeem gekende

gebruikers.

Maatregelingen:

• Configureer veilige Web permissies.

Input Validation

Niveau: applicatie

Input validatie wordt een security issue wanneer een aanvaller ontdekt dat binnen de

applicatie ongefundeerde veronderstellingen worden gemaakt over het type, de lengte, het

formaat of de omvang van de input data. Zorgvuldig gekozen input data kan er dan de

oorzaak van zijn dat je applicatie wordt misbruikt.

Buffer overflows kan hiervan een oorzaak zijn, en leidt vaak tot DoS aanvallen. Een aanvaller

zou een buffer overflow kunnen misbruiken om zijn code in de stack toe te voegen. Die code

zou dan de program stack kunnen overschrijven, en het return adres van een functie naar de

code van de aanvaller laten wijzen.

Uit dit voorbeeld blijkt al het belang van een krachtige input validatie.

SQL Injection is een volgende aanval die kan voorkomen wanneer er niet voldoende validatie

wordt aangeboden. Deze aanval tracht dynamisch gedeclareerde SQL statements te

misbruiken om toegang te verkrijgen tot de databank. De aanvaller is dan in staat om data te

bekijken, manipuleren of zelfs verwijderen.

SECURITY THREATS 15

Authentication

Niveau: applicatie

Wanneer authenticatie vereist is voor een applicatie, wordt er best gebruik gemaakt van een

systeem die het onnodig maakt om paswoorden over het netwerk te versturen, zoals Kerberos,

of een systeem die de trafiek codeert, zoals SSL.

Wanneer hier geen aandacht aan wordt besteed, zou de aanvaller bijvoorbeeld via Network

Eavesdropping zeer gemakkelijk de trafiek kunnen afluisteren en op deze manier aan een

geldige login en paswoord geraken.

Wanneer de paswoorden niet goed gekozen worden, kan een aanvaller ook via Brute Force

Attacks trachten om het paswoord te kraken. Daarom is het gebruik van zogenaamde sterke

paswoorden van een groot belang.

Veel security implementaties slaan enkel de hashwaarden op van de gebruikte paswoorden.

Wanneer deze methode gebruikt wordt, wordt een applicatie kwetsbaar voor een Dictionary

Attack. Wanneer de aanvaller aan die hashwaardentabel kan geraken, kan hij de woorden uit

een woordenboek hashen, en die laten vergelijken met de waarden uit de hashtabel. Op die

manier kunnen zwakke paswoorden eenvoudig gekraakt worden. Bovendien kan dit offline

gebeuren. Een oplossing voor deze aanval bestaat erin om een sterk random waarde aan het

paswoord toe te voegen, en de hashwaarde hiervan op te slaan.

Ook Cookie replay Attacks kunnen we tot de Authentication categorie beschouwen. Deze

aanval houdt in dat de aanvaller de authentication cookie van een gebruiker kan bemachtigen,

en zich zo een valse identiteit kan aanmeten. Deze aanval kan voorkomen worden door SSL te

gebruiken bij het verzenden van de cookie, of een cookie timeout te gebruiken.

Authorization

Niveau: applicatie

Authorization is van groot belang om ervoor te zorgen dat niet iedereen gebruik kan maken

van functies die een bepaalde positie of verantwoordelijkheid vereisen om ze te mogen

uitvoeren. Om dit te kunnen garanderen moet er dan ook aandacht besteed worden aan de

aanvallen die dit zouden kunnen omzeilen.

SECURITY THREATS 16

Elevation of privilege is een aanval waarbij men probeert de rechten van een member, proces

of service over te zetten naar een andere member. Bijvoorbeeld kan er geprobeerd worden om

de rechten van de administrator over te zetten naar een account van een “gewone” member.

Deze aanval kan tegengegaan worden door processen en services te gebruiken die weinig

rechten hebben, alsook user accounts met beperkte rechten.

Disclosure of Confidential Data komt voor wanneer sensitive data gelezen kan worden door

niet-geautoriseerde gebruikers. Dit kan gaan van specifieke data van de applicatie, zoals credit

card nummers, werknemersgegevens en financiële rapporten tot configuratiedetails van

applicaties, zoals database connection strings. De noodzaak is dan ook om zulke data veilig

op te slaan in databanken en dergelijke. Zorg er ook voor dat er steeds een controle gebeurt

wanneer er toegang tot zulke informatie wordt gegeven, en encrypteer steeds zulke

informatie, en dat zeker wanneer het over een netwerk wordt verstuurd.

Data Tampering is het manipuleren van data, terwijl de persoon er niet toe bevoegd is. Bouw

een strenge controle in die enkel aan geautoriseerde gebruikers toelaat om data te

manipuleren.

Luring Attacks komen voor wanneer een gebruiker met weinig rechten in staat is om een

gebruiker met veel rechten data te laten lezen of manipuleren in zijn voordeel. Om dit te

voorkomen moet er terug een strenge controle voorzien worden wanneer data gemanipuleerd

wordt.

Session Management

Niveau: applicatie

Session security is een vereiste om een veilige applicatie te kunnen garanderen. Session

Hijacking treedt op wanneer een aanvaller in staat is om bijvoorbeeld de authenticatie cookie

die een representatie vormt van een sessie van een andere gebruiker, te bemachtigen. Op deze

manier krijgt de aanvaller toegang tot de applicatie, en heeft hij of zij ook dezelfde rechten als

de gebruiker. Door SSL te gebruiken om de authenticatie te laten verrichten, een logout

functionaliteit te implementeren en de periode dat een cookie geldig blijft te beperken, kan

deze aanval voorkomen worden.

Session Replay gebeurt wanneer een aanvaller de session token van een gebruiker onderschept

en dit gebruikt om de authenticatie te omzeilen. Dit kan tegengegaan worden door een nieuwe

SSL VERSUS WSS 17

authenticatie te eisen wanneer er kritieke functionaliteiten worden gebruikt. Zorg ook voor

een beperkte geldigheidsperiode van session tokens, en zorg ervoor dat gebruikersspecifieke

data kan verwijderd worden van het systeem.

Man in the Middle Attacks komen voor wanneer een aanvaller een bericht onderschept tussen

een gebruiker en zijn bestemmeling. De aanvaller kan dan de inhoud veranderen en het

doorsturen naar de bestemmeling. De bestemmeling handelt het bericht dan af als kwam het

van de oorspronkelijke gebruiker. Wanneer de bestemmeling het bericht beantwoordt, kan de

aanvaller opnieuw het bericht onderscheppen en aanpassen. De gebruiker en de bestemmeling

zullen niet weten dat ze het slachtoffer waren van deze aanval.

3.2 SSL versus WSS

Zoals in de vorige sectie uitvoerig werd aangetoond, zijn er vele security threats waar

rekening mee gehouden moet worden. Vele threats kunnen door de gebruikers zelf opgelost

worden, door het goed configureren van hun client en netwerk, maar er zijn ook een aantal

threats die de applicatie zelf zal moeten trachten te voorkomen.

De applicatie is in wezen een Web Service framework. Er kunnen hoofdzakelijk twee

mechanismen gebruikt worden om secure Web Services aan te bieden, namelijk Secure Socket

Layer (SSL) of Web Service Security (WSS).

SSL is een protocol die aanwezig is in de transportlaag. SSL zorgt ervoor dat een plain-text

bericht verstuurd wordt door een beveiligd kanaal.

WSS echter is een protocol aanwezig in de message- en applicatielaag. Hierbij wordt een

beveiligd bericht verzonden door een niet beveiligd kanaal. De beveiliging wordt dan

gegarandeerd door gebruik te maken van XML Signature en XML Encryption.

Aangezien beide security mechanismen gebruik maken van een verschillend protocol, bieden

ze beide ook een verschillende security context aan.

SSL VERSUS WSS 18

Tabel 3.1: Security threats en oplossingen

Security threat Niveau Oplossing

Authentication Applicatie Paswoord en login

Authorization Applicatie Gekoppeld aan paswoord en

login

Eavesdropping Netwerk SSL

Replay attack Netwerk SSL

Man in the middle attack Netwerk SSL

SQL injection Applicatie Authorisatie

Dictionary attack Applicatie Paswoorden uitbreiden en

hashen

Proof of transaction Client - Applicatie WSS

SSL maakt gebruik van een beveiligd kanaal om een bericht te verzenden, maar eenmaal het

bericht het kanaal verlaten heeft, is het niet langer secure. SSL vormt dus een goede keuze

voor point-to-point communicatie.

WSS zorgt er dan weer voor dat het SOAP bericht dat verstuurd wordt, geëncrypteerd wordt.

Dit heeft zijn voordeel wanneer we gebruik maken van een multi-hop topologie. Op die

manier kan een tussenliggende component enkel die data uit het SOAP bericht halen dat voor

hem van belang is, terwijl de rest van het bericht geëncrypteerd blijft. Op die manier blijft het

bericht op elk moment beschermd tegen onbevoegde toegang.

Wanneer we gebruik wensen te maken van WSS, kunnen we een beroep doen op de Web

Service Enhancements (WSE) 2.0 filters en klassen. WSE zal er dan voor zorgen dat het

SOAP bericht dat verstuurd wordt, geëncrypeerd wordt.

De extra beveiliging en voordelen die WSS biedt, brengt echter ook overhead met zich mee.

Wanneer we gebruik maken van een WSE proxy, dan moeten alle berichten door input en

output filters gestuurd worden, die meer overhead en SOAP tags genereren dan moest er

gebruik gemaakt worden van een normale proxy. De overhead die gegenereerd wordt, is

aanzienlijk hoger dan wanneer er SSL encryptie gebruikt wordt.

Daarom zal er binnen de E-procurement proof of concept gebruik gemaakt worden van SSL.

In [1] wordt aangetoond dat wanneer er beveiligde Web Services vereist zijn, die het best

presteren met SSL. De proof of concept is een typische point-to-point applicatie, waarbij

hopping niet vereist is. Bovendien is SSL een gekende, bewezen en performante oplossing.

MYSQL 19

Echter, het gebruik van SSL alleen is niet voldoende. Wanneer SSL gebruikt wordt, kan er

nog geen Proof of transaction gegarandeerd worden. Door Proof of transaction aan te bieden

kan een ziekenhuis of een leverancier achteraf niet meer ontkennen dat hij of zij een

aanbesteding of offerte heeft geplaatst.

Wanneer we Proof of transaction willen aanbieden, moeten we het SOAP bericht die naar de

Web Service interfaces wordt verstuurd, digitaal ondertekenen. Hiervoor zullen we Web

Service Security (WSS) gebruiken.

Het is dus duidelijk dat er een trade-off moet gemaakt worden tussen de performantie (SSL)

en de security functionaliteit (WSS). De beste resultaten kunnen bereikt worden door SSL –

het encrypteren – te combineren met WSS – het digitaal ondertekenen.

Tot slot wordt in tabel 3.1 als samenvatting een opsomming gegeven van de voornaamste

security threats die binnen de applicatie worden behandeld, en de oplossing die ervoor wordt

gebruikt.

3.3 MySQL

In de E-procurement applicatie wordt er ook een database voorzien. De database technologie

waarvan in de uiteindelijke applicatie gebruik van wordt gemaakt, is MySQL.

MySQL is een veel gebruikte en bewezen open source database technologie, die bekend staat

voor zijn betrouwbaarheid en performantie. Bovendien is MySQL eenvoudig te gebruiken, en

worden er heel wat handige tools voorzien om MySQL in je applicatie te integreren.

Binnen de applicatie werd gebruik gemaakt van MySQL Database Server 4.1, MySQL Control

Center voor het aanmaken van de tabellen, en MySQL Connector/NET 1.0 API voor het

communiceren binnen de applicatie met de database.

SPECIFICATIE 20

Hoofdstuk 4

Specificatie

Use cases bieden de mogelijkheid aan de ontwikkelaar van een applicatie om de manieren

waarop de applicatie zal kunnen gebruikt worden, aan te tonen. Met andere woorden, het geeft

de functionaliteit weer die de applicatie de gebruiker zal aanbieden. De manier waarop het die

functionaliteit beschrijft, is vanuit het gezichtspunt van de gebruiker zelf. Bij het beschrijven

van de use cases is aandacht besteed aan de interactie tussen de gebruiker en de applicatie, en

niet aan de interne activiteiten van de applicatie.

4.1 Use cases

4.1.1 Gebruiker use cases

Algemeen

De uiteindelijke gebruikers van de E-procurement applicatie zijn voornamelijk de

ziekenhuisgebruiker en de leveranciergebruiker. Er zal hiervoor dan ook een onderscheid

gemaakt worden in de use cases. Maar eerst wordt er in fig. 4.1 een gemeenschappelijke use

case voor het inloggen van de gebruikers besproken.

Uiteraard moet een gebruiker gekend zijn bij het systeem, voordat hij of zij gebruik zal

kunnen maken van de features die de Web Service aanbiedt. Dit gebeurt door het invoeren

van een login en password.

GEBRUIKER USE CASES 21

Figuur 4.1: Gemeenschappelijke use case: inloggen

Zoals fig. 4.2 aantoont, verwacht een ziekenhuisgebruiker van de applicatie dat hij of zij in

staat is om aanbestedingen te plaatsen, en dat hij of zij in staat is het verloop van de offertes

op te volgen.

Gelijklopend met de algemene use case van de ziekenhuisgebruiker, toont fig. 4.3 dat het voor

de leveranciergebruiker vooral van belang is dat de applicatie hem of haar in staat stelt om

aanbestedingen te ontvangen, hierop een offerte te plaatsen, een offerte aan te passen en het

bieden kan opvolgen.

Gedetailleerd

Zoals in fig. 4.1 getoond wordt, moet de gebruiker steeds inloggen voor hij of zij gebruik mag

maken van de features die de gebruiker aangeboden wordt.

Scenario’s:

1. Inloggen.

Preconditions:

1. De gebruiker moet geconnecteerd zijn met het Web Service framework.

2. De gebruiker moet gekend zijn in het Web Service framework.

Postconditions:

1. De gebruiker krijgt toegang tot de features van de Web Service.

Inloggen.

Gebruiker


Subscenario’s:

1. Er kan geen connectie gemaakt worden met het Web Service framework.: de gebruiker

wordt gevraagd op een later tijdstip opnieuw te proberen.

2. De gebruiker is niet gekend in het Web Service framework.: dit wordt aan de

gebruiker kenbaar gemaakt, en de gebruiker krijgt geen verdere toegang tot het

systeem.

Zoals er uit fig. 4.2 opgemaakt kan worden, zal de ziekenhuisgebruiker, na ingelogd te zijn,

gebruik maken van de features van de Web service. De gebruiker kan beslissen om een

aanbesteding te verzenden naar de leveranciers en/of het verloop van de offertes rond een

geplaatste aanbesteding op te volgen.

Scenario’s:

1. Aanbesteding verzenden.

2. Offertes opvolgen.

Figuur 4.2: Algemene use case: ziekenhuisgebruiker

Preconditions:

1. De gebruiker moet ingelogd zijn.

2. De gebruiker moet geautoriseerd zijn om de feature te gebruiken.

Aanbesteding

plaatsen.

Offertes opvolgen.

Ziekenhuisgebruiker

Inloggen.

<< include >>

<< include >>


Postconditions:

1. De gebruiker keert terug naar het main screen, waar hij of zij opnieuw kan kiezen om

een aanbesteding te plaatsen of de offertes op te volgen.

Subscenario’s:

1. De gebruiker is niet geautoriseerd om een aanbesteding te plaatsen: dit wordt aan de

gebruiker kenbaar gemaakt, en de aanbesteding wordt niet verzonden.

Figuur 4.3: Algemene use case: leveranciergebruiker

In fig. 4.3 wordt duidelijk gemaakt dat de leveranciergebruiker in staat moet zijn om

aanbestedingen te ontvangen en op een ontvangen aanbesteding moet kunnen reageren met

een offerte. Bovendien zal hij of zij de offerte moeten kunnen aanpassen en het biedingproces

moeten kunnen opvolgen.

Scenario’s:

1. Aanbesteding ontvangen.

2. Offerte aanbieden.

3. Offerte updaten.

4. Bieden opvolgen.

Preconditions:

1. De gebruiker moet geautoriseerd zijn om een offerte te plaatsen.

2. De gebruiker moet geautoriseerd zijn om een offerte aan te passen.

Aanbesteding

ontvangen.

Offertes aanbieden.

Leveranciergebruiker

Offerte updaten.

Bieden opvolgen.

Inloggen.

<< include >>

<< include >>

<< include >>

<< include >>

SECURITY USE CASE 24

Postconditions:

1. De gebruiker keert terug naar het main screen, waar hij of zij opnieuw de keuze heeft

offertes te versturen, het bieden op te volgen en zijn offertes aan te passen.

Subscenario’s:

1. De gebruiker is niet geautoriseerd om een offerte te plaatsen: dit wordt aan de

gebruiker kenbaar gemaakt, en de offerte wordt niet verzonden.

2. De gebruiker is niet geautoriseerd om een offerte te updaten: dit wordt aan de

gebruiker kenbaar gemaakt, en de offerte wordt niet verzonden.

4.1.2 Security use case

Om de functionaliteit van de security controle te bespreken wordt er gebruik gemaakt van een

Security use case die uit 6 delen bestaat:

1. de source: stelt een entiteit voor.

2. de stimilus: vormt een conditie waaraan voldaan moet worden.

3. de environment: is de conditie waaraan de stimilus voldoet.

4. de artifact: kan de gehele applicatie zijn, of slechts een specifiek deel ervan.

5. de response: is de activiteit dat volgt na de stimilus.

6. de response measure: geeft aan wanneer de response gebeurt.

Wanneer een gebruiker (source) gebruik wenst te maken van een functionaliteit die de

applicatie aanbied (stimilus), moet er eerst aan een aantal security eisen voldaan worden,

namelijk:

- authenticatie: dit komt erop neer dat er nagegaan wordt of de identiteit van de

gebruiker overeenkomt met wie de gebruiker beweerd te zijn.

- autorisatie: dit komt erop neer dat gecontroleerd wordt of een geauthenticeerde

gebruiker gemachtigd is de functionaliteit die de applicatie aanbiedt, te gebruiken.

Wanneer aan deze voorwaarden voldaan werd, zal onder normale omstandigheden

(environment) het Web Service framework aangesproken worden (artifact), en zal de

gevraagde functionaliteit uitgevoerd worden (response + response measure).

SECURITY USE CASE 25

Figuur 4.4: Security use case

Tijdens het uitvoeren van de response komt nog een derde security aspect kijken, namelijk:

- data geheimhouding: dit komt erop neer dat de uitwisseling van data gevrijwaard

wordt van niet-geautoriseerde toegang.

Preconditions:

1. De gebruiker moet geconnecteerd zijn met het Web Service framework.

Postconditions:

1. De gebruiker krijgt toegang tot het hoofdscherm, waar hij of zij de keuze krijgt van de

features van de applicatie gebruik te maken.

Subscenario’s:

1. Er kan geen connectie gemaakt worden met het Web Service framework: de gebruiker

wordt gevraagd op een later tijdstip opnieuw te proberen.

2. De gebruiker is niet gekend in het centrale punt (authenticatie): dit wordt aan de

gebruiker kenbaar gemaakt, en de gebruiker krijgt geen verdere toegang tot het

systeem.

3. De gebruiker is niet geauthoriseerd om een feature te gebruiken(authorisatie): dit

wordt aan de gebruiker kenbaar gemaakt, en de feature wordt niet uitgevoerd.

4. Man in the middle attack: om dit te voorkomen worden alle boodschappen die

verstuurd worden geëncrypteerd.

Source:

Correct

geïdentificeerde

gebruiker

Artifact:

Data in Web Service

framework. Stimulus:

Probeert van

functionaliteit gebruik te

maken Environment: Onder normale

omstandigheden

Response:

Uitvoeren gevraagde

functionaliteit. Response measure:

Op het moment.

12

6

3 9

SEQUENTIEDIAGRAMMEN 26

4.2 Sequentiediagrammen

In deze sectie vertalen we de use cases die we besproken hebben in de figuren 4.1 tot en met

4.4 naar sequentiediagrammen.

De handelingen die vereist zijn om een gebruiker te authenticeren worden in fig. 4.5

afgebeeld. Hiervoor wordt het paswoord en de login van de gebruiker naar het Web Service

framework verstuurd. Wanneer de gebruiker geauthenticeerd is, zal de gebruiker toegelaten

worden, anders wordt er een error boodschap aan de gebruiker getoond, en wordt er gevraagd

om opnieuw in te loggen.

Figuur 4.5: Sequentiediagram: inloggen

Figuur 4.6 toont de verschillende stappen die vooraf gaan aan het plaatsen van een

aanbesteding door een ziekenhuisgebruiker. Eerst wordt er nagegaan of de gebruiker

geautoriseerd is om de aanbesteding te plaatsen. Indien dit het geval was, zal het Web Service

framework de aanbesteding behandelen, anders wordt de aanvraag van de gebruiker

geweigerd.

Figuur 4.6: Sequentiediagram: Aanbesteding plaatsen

Gebruiker Web Service

framework

1: Paswoord en login (secure)

2a: Niet geauthenticeerd: error

2b: Wel geauthenticeerd: acces granted Authenticatie

controle

Ziekenhuis

gebruiker

1: Vraag om aanbesteding te plaatsen

2a: Niet geautoriseerd: error

2b: Wel geautoriseerd

3: Aanbesteding plaatsen

4: Bevestiging plaatsing aanbesteding

Autorisatie

controle

Web Service

framework


Figuur 4.7 toont het sequentiediagram van een ziekenhuisgebruiker die de offertes wenst op te

volgen. De gebruiker zal hier enkel tot in staat zijn als hij of zij aan de juiste autorisatie

vereisten voldoet.

Figuur 4.8 toont de vraag van een leveranciergebruiker om de aanbestedingen te ontvangen.

Het Web Service framework zal die aanbestedingen enkel verzenden wanneer de gebruiker

geautoriseerd is om de aanbestedingen te ontvangen.

Figuur 4.7: Sequentiediagram: offertes opvolgen

Figuur 4.9 behandelt het plaatsen van een nieuwe offerte. Wanneer de gebruiker geautoriseerd

is, zal het Web Service framework de offerte behandelen en de gebruiker op de hoogte stellen

of de offerte al dan niet correct kon behandeld worden.

Figuur 4.8: Sequentiediagram: Aanbestedingen ontvangen

Figuur 4.10 toont de sequenties die vereist zijn om het bieden op een aanbesteding op te

volgen, en fig. 4.11 toont de sequenties voor het updaten van een offerte. Terug wordt steeds

door het Web Service framework nagegaan of het gaat om geautoriseerde verzoeken.

1: Vraag om aanbestedingen te ontvangen



3: Aanbestedingen verzenden

Autorisatie

controle

Leverancier

gebruiker Web Service

framework

1: Vraag om offertes op te volgen



3: Verloop offertes verzenden

Autorisatie

controle

Ziekenhuis


framework


Figuur 4.9: Sequentiediagram: offerte plaatsen

Figuur 4.10: Sequentiediagram: Bieden opvolgen

Figuur 4.11: Sequentiediagram: Offerte updaten

1: Vraag om offerte updaten



3: Offerte updaten

4: Bevestiging update

Autorisatie

controle

Leverancier


framework

1: Vraag om bieden op te volgen



3: Verloop bieden verzenden

Autorisatie

controle

Leverancier


framework

1: Vraag om offerte te plaatsen



3: Offerte plaatsen

4: Bevestiging plaatsing offerte

Autorisatie

controle

Leverancier


framework

ARCHITECTUUR 29

Hoofdstuk 5

Architectuur

In dit hoofdstuk wordt de structuur van het E-procurement web service framework wat dieper

ontleed. Eerst en vooral wordt het algemeen ontwerp ervan besproken. Ten slotte worden ook

nog enkele uitgebreide sequentie diagrammen bekeken.

5.1 Algemeen ontwerp

Figuur 5.1 toont een voorstelling van het algemene ontwerp van de E-procurement web

service framework. Er worden duidelijk twee grote gehelen opgemerkt.

Het eerste geheel omvat de client zijde. De belangrijkste component hiervan is uiteraard de

ClientGUI, die de gebruiker toelaat om aanbestedingen (Engels: tender) en orders te plaatsen,

op te zoeken, enzovoort.

De ClientGUI op zich maakt gebruik van onderliggende componenten die voor de gebruiker

niet zichtbaar zijn. Deze componenten omvatten klassen die een voorstelling geven van

producten, orders en aanbestedingen, kortom, die zaken die voor de gebruiker van de E-

procurement web service framework van belang zijn.

Verder omvatten die componenten ook enkele Handler klassen die instaan voor de

bewerkingen op de producten, orders en aanbestedingen, alsook methoden voorzien om de

web service aan te spreken. Deze componenten werden met het oog op herbruikbaarheid

ontworpen, waardoor zowel de leverancier als de ziekenhuis GUI van deze componenten

kunnen gebruik maken.

ALGEMEEN ONTWERP 30

Ten slotte bevat de ClientGUI ook twee security componenten, SoapSigner en

SecurityHandler, die een betrouwbare gegevensoverdracht moet garanderen. De

SecurityHandler is de enige component die verschillend is in de leverancier GUI en de

ziekenhuis GUI. De reden ligt in het feit dat de beide GUI’s een verschillende context

aanbieden, en die ook verschillende security eisen vereisen.

De server zijde vormt het tweede geheel. Aan de server zijde zijn Service interfaces voorzien,

die het voor een client mogelijk maakt om de vereiste web service methoden aan te spreken.

Figuur 5.1: Algemeen ontwerp E-procurement web service framework

UML DIAGRAMMEN 31

Onderliggend zijn er ook klassen voorzien die de business logic voor het E-procurement web

service framework definiëren. Het voordeel van dit ontwerp is dat de business logic niet

rechtstreeks geïmplementeerd is in de Service interfaces, wat het mogelijk maakt om een

component gebaseerd ontwerp na te streven.

Verder moet er aan de server zijde ook een databank aanwezig zijn die alle nuttige

gegevensoverdracht tussen een ziekenhuis en een leverancier bijhoudt. Hiervoor is dan ook

een databank access klasse voorzien.

5.2 UML diagrammen

Nu wordt het ontwerp dat in de vorige sectie besproken werd, bekeken.

Figuur 5.2 toont het UML diagram voor de client zijde. Zoals reeds aangetoond laat de

ClientGUI de gebruiker toe om op de producten, orders en aanbestedingen in te werken.

De ClientGUI component maakt dan ook hiervoor gebruik van de TenderHandler en

OfferHandler componenten. In deze klassen worden de methoden gespecificeerd die op

orders en aanbestedingen kunnen worden verricht.

Bovendien maakt de ClientGUI component nog gebruik van een SecurityHandler

component, die het security aspect voor zijn rekening neemt, zoals authenticatie en

autorisatie.

Een Tender bevat minstens een Product, die een representatie vormt van het product

waarvoor een aanbesteding werd geplaatst. Aan de Tender kunnen geen of meerdere

Offers toegevoegd worden, die de verschillende offertes van de leverancier voorstellen.

Wanneer er door de ziekenhuisgebruiker een offerte (Offer) wordt aanvaard voor een

aanbesteding (Tender), wordt die aanbesteding niet langer als een Tender beschouwd,

maar als een Order. De producten (Product) die tot de Tender behoorden, worden

binnen de Order dan als HandledProducts bijgehouden. Een Order heeft maximum

één offerte, die als een HandledOffer wordt bijgehouden binnen het Order object.

Wanneer het biedingproces ten einde is, en de ziekenhuisgebruiker geen Offer heeft

aanvaard binnen een dag na het verstrijken van de biedinglimiet, dan wordt er geen

HandledOffer aan het object Order toegekend.

UML DIAGRAMMEN 32

Figuur 5.2: UML diagram client zijde

De reden waarom er een onderscheid gemaakt wordt tussen een Tender, Order en de

overige klassen, is om binnen de applicatie gemakkelijk onderscheid te kunnen maken tussen

objecten die nog veranderd kunnen worden, of niet. Zo kan aan een Tender tijdens het

bieden meerdere Offers toegevoegd worden, of kan een Offer aangepast worden. De

gegevens die zich in het Order of HandledOffer object bevinden, kunnen op geen

enkele manier meer aangepast worden.

De TenderHandler staat in voor het aanmaken van aanbestedingen, het versturen ervan,

en het opvragen van aanbestedingen en orders. De OfferHandler doet dit voor het

aanmaken, versturen en opvragen van offertes.

UML DIAGRAMMEN 33

Verder is er nog een klasse XmlHandler gedefinieerd, waar de klassen OfferHandler en

TenderHandler van gebruik maken om de aanbestedingen en dergelijke naar de Web

Service te versturen of te ontvangen. De XmlHandler maakt een XmlDocument van deze

objecten, en verstuurt dan dit document naar de Web Service. De reden hiervoor is omdat

Web Services de zelf gedefinieerde types niet als paramater of return waarde aanvaarden.

Figuur 5.3 toont het UML diagram voor de server zijde.

Aan de server zijde worden er drie Server interfaces, TenderWS, OfferWS en

LoginWS, voorzien. Deze componenten worden door de client aangeroepen wanneer hij

offertes of aanbestedingen wenst te versturen, opvragen, … Hierbij dienen de OfferWS en

de TenderWS voor het afhandelen van alles wat te maken heeft met respectievelijk offertes

en aanbestedingen. De LoginWS is de component die aangesproken wordt om een gebruiker

te authenticeren.

Achterliggend maken de TenderWS en de OfferWS gebruik van de TenderLogic en de

OfferLogic, die de business logic binnen het E-procurement web service framework

definieert.

Wanneer deze business logic componenten aangesproken worden, wordt eerst in de

ServerSecurity component nagegaan of de aanvraag van een geauthenticeerde gebruiker

afkomstig is, en eveneens of de gebruiker geautoriseerd is om die aanvraag te doen.

De klassen TenderLogic, OfferLogic en ServerSecurity maken gebruik van de

klasse DatabaseConnection om toegang tot de databank te krijgen.

INTERFACES 34

Figuur 5.3: UML diagram server zijde

5.3 Interfaces In deze sectie worden de belangrijkste interfaces aan de server en client zijde eens onder de

loep genomen. De volgende methoden behoren tot de ITenderHandler interface aan de

client zijde.

CreateTender(string name, string surname, string hospital, DateTime

date, DateTime dateLimit, string tenderID, ArrayList

productList);

SendTenders(string user, string password);

ValidateOffer(string user, string password, string tenderID, string

offerID);

GetData(string user, string password);

INTERFACES 35

De methode CreateTender zorgt ervoor dat er een nieuw Tender object wordt

aangemaakt. Een Tender object bevat steeds de naam en de voornaam van de persoon die de

aanbesteding aanmaakte, het ziekenhuis waarvoor hij of zij werkt, de datum waarop de

aanbesteding werd geplaatst (date), de datum waarop het bieden afgesloten wordt (dateLimit),

een ID voor de aanbesteding en een lijst met alle producten die besteld moeten worden.

Met de methode SendTenders kunnen nieuwe aanbestedingen naar de Web Service

verzonden worden. Hierbij worden het paswoord en de login van de gebruiker opnieuw

meegegeven, zodat de server in staat is om de authenticiteit en de autorisatie van de gebruiker

na te gaan.

Met de ValidateOffer methode kan een ziekenhuisgebruiker een offerte die op een

aanbesteding is geplaatst, aanvaarden. Hiervoor wordt opnieuw het paswoord en login

meegegeven, aangezien het hier gaat om een belangrijke beslissing. Het ID van de

aanbesteding en de offerte worden eveneens meegegeven, zodat de gegevens correct in de

databank kunnen worden aangepast.

Met de methode GetData kan de gebruiker de aanbestedingen opvragen die hij of zij heeft

geplaatst, alsook de orders.

De volgende methoden behoren tot de IOfferHandler interface.

CreateOffer(string name, string surname, string company, string

offerID, double price, string tenderID, DateTime date);

SendOffers(string user, string password);

UpdatePlacedOffer(string user, string password, string tenderID,

string offerID, double price);

GetData(string user, string password);

GetLowestOffer(string tenderID);

Deze methoden zijn gelijkaardig aan de methoden uit de ITenderHandler interface.

De methode CreateOffer maakt een nieuwe offerte aan, waarbij de naam en voornaam,

alsook het bedrijf waar de persoon voor werkt, worden bijgehouden. Verder wordt er een ID

INTERFACES 36

voor de offerte meegegeven, de aangeboden prijs, het ID van de aanbesteding waarvoor de

offerte bedoeld is en de datum waarop de offerte werd geplaatst.

De methoden SendOffers en GetData zijn volledig gelijklopend met de methoden uit de

ITenderHandler, alleen worden er nu Offer en HandledOffer objecten verstuurd.

UpdatePlacedOffer laat toe om de oorspronkelijke prijs die aan een offerte werd

meegegeven, aan te passen. Wanneer een gebruiker deelneemt aan het bieden, en een nieuw

bod plaatst, wordt er van deze methode gebruik gemaakt. De parameters die dienen

meegegeven te worden zijn de gegevens van de gebruiker, het ID van de aanbesteding en de

offerte, en uiteraard de nieuwe prijs.

Met de methode GetLowestOffer wordt er opgevraagd wat het laagste bod is die reeds

geplaatst werd op een aanbesteding. Die aanbesteding wordt gespecificeerd door de

tenderID.

De interfaces die nu besproken werden, bevinden zich aan de client zijde. De volgende

interfaces bevinden zich aan de server zijde.

GetTenders(string [] userinfo);

GetOrders(string [] userinfo);

AddTenders(string user, ArrayList tenders);

ValidateOffer(string user, string tenderID, string offerID);

Dit zijn de interface methoden uit de ITenderLogic methoden. De methoden in de

interface laten toe om aanbestedingen van de gebruiker op te vragen, waarbij de gegevens van

de gebruiker uit de string array userinfo worden gehaald. Gelijkaardig is er ook een

methode die de orders van de gebruiker teruggeeft.

De methode AddTenders zal alle aanbestedingen die zich in de ArrayList bevindt,

toevoegen voor de gespecificeerde gebruiker.

Tot slot zal de methode ValidateOffer er voor zorgen dat een offerte wordt aanvaard

voor een aanbesteding.


GetOffers(string [] userinfo);

GetHandledOffers(string [] userinfo);

AddOffers(string user, ArrayList offers);

LowestOffer(string tenderID);

UpdateOffer(string user, string tenderID, string offerID, double

price);

Deze methoden behoren tot de IOfferLogic interface. Het bevat methoden om de

Offers en HandledOffers op te vragen van een gebruiker, alsook een methode om

offertes toe te voegen.

De methode LowestOffer geeft het laagste bod terug voor de aanbesteding met ID

tenderID, en de methode UpdateOffer zal ervoor zorgen dat de prijs van de offerte met

offerID zal aangepast worden naar de meegegeven price value.

In Appendix B werden eveneens de interfaces opgenomen voor de ServerSecurity klasse

en de DatabaseConnection.

5.4 Sequentiediagrammen

In de vorige secties werd er door middel van UML diagrammen en interfaces inzicht

verkregen in de manier waarop de applicatie opgebouwd is. Nu zullen de verschillende

relaties tussen de klassen duidelijk gemaakt worden aan de hand van een uitgebreide

sequentiediagram.

De situatie is die van een ziekenhuisgebruiker die zijn orders opvraagt aan de Web Service.

Hiervoor moet de gebruiker echter eerst ingelogd zijn.

De beginsituatie wordt getoond in fig. 5.4. Wanneer de gebruiker wenst in te loggen (1), zal

de GUI die aanvraag doorspelen naar de SecurityHandler (2). De SecurityHandler

zal dan via de LoginWS de gegevens opvragen van de gebruiker (3). Hiertoe zal de

LoginWS de aanvraag doorspelen aan de ServerSecurity (4), die de gegevens van de

gebruiker zal opvragen via de DatabaseConnection klasse (5). Als antwoord zal er dan

een string array met de gegevens van de gebruiker worden teruggestuurd naar de


SecurityHandler aan de client kant (6-8). Wanneer de string array niet null is, dan

gaat het om een geauthenticeerde gebruiker en wordt die tot de applicatie toegelaten (9a &

10a). Indien dit niet het geval is, zal aan de gebruiker gevraagd worden om opnieuw in te

loggen (9b & 10b).

Figuur 5.4: Uitgebreide sequentiediagram: inloggen

Wanneer de gebruiker toegelaten is tot het systeem, worden zijn of haar orders opgevraagd.

Dit wordt afgebeeld in fig. 5.5. De GUI zal die aanvraag terug doorsturen naar de

SecurityHandler (2). Die zal nagaan of de gebruiker geautoriseerd is om de aanvraag te

doen (3). Indien dit het geval is, zal de SecurityHandler aan de gebruiker vragen om

opnieuw zijn paswoord in te geven (4). Nadat de gebruiker dit heeft gedaan, zal de

SecurityHandler aan de TenderHandler vragen om de orders op te vragen (6). Die

zal daarvoor de TenderWS aanspreken (7). De TenderWS op zijn beurt zal de aanvraag

doorgeven aan de ServerSecurity (8). Die zal opnieuw via het paswoord en de login van

de gebruiker de authenticiteit (9 & 10) en de autorisatie (10 & 11) van de gebruiker nagaan.

Deze acties kunnen wellicht enkele vragen oproepen. Waarom zowel aan client als aan server

zijde de autorisatie van de gebruiker controleren?

De reden waarom dit aan de client zijde gebeurt, is om de trafiek naar de Web Services zo

veel mogelijk te vrijwaren van ongeldige aanvragen. Wanneer een niet-geautoriseerde

aanvraag al aan de client zijde kan ontedekt worden, wordt de Web Service minder belast.


Figuur 5.5: Uitgebreide sequentiediagram: autorisatie nagaan

Waarom de authenticiteit en de autorisatie ook aan de server zijde gecontroleerd wordt, is om

te voorkomen dat een aanvaller die zelf een GUI zou geschreven hebben waar er geen

authenticatie en autorisatie wordt verricht, geen aanbestedingen of offertes zou kunnen

plaatsen. Wanneer er immers van uitgegaan wordt dat elke aanvraag al aan de client zijde

gecontroleerd werd, dan zou in dit geval ongeldige aanvragen behandeld kunnen worden.

Figuur 5.6: Uitgebreide sequentiediagram: orders opvragen

Wanneer blijkt dat de aanvraag afkomstig is van een geauthenticeerde en geautoriseerde

gebruiker (fig. 5.6), zal de ServerSecurity de TenderLogic vragen om de aanvraag

TOEVOEGEN DIGITAL SIGNATURES 40

verder af te handelen (1). Die zal gebruik maken van de DatabaseConnection om de

gewenste gegevens op te vragen (2 & 3). Voordat deze gegevens naar de client worden

teruggestuurd, zal de TenderLogic de gegevens door de XmlHandler laten parsen naar

een XmlDocument (4 & 5). Dat XmlDocument zal dan naar de TenderHandler

worden teruggestuurd (6 – 8).

Dan zal de TenderHandler aan de XmlHandler vragen om uit het XmlDocument

terug de complexe datatypes te genereren (9 & 10), waarna de orders aan de gebruiker zullen

worden getoond (11 – 13).

5.5 Toevoegen Digital Signatures

Figuur 5.7: Aangepast UML diagram


Momenteel worden er nu security features aangeboden via SSL en login en paswoord. Er

wordt echter nog geen proof of transaction aangeboden. In deze sectie zal de implementatie

van de digital signatures besproken worden, en aan de hand van de minimale aanpassingen die

dit vereist, zal ook aangetoond worden dat de applicatie getuigt van een component gebaseerd

ontwerp.

Om digital signatures te implementeren, moet er een extra methode toegevoegd worden in elke

Web service interface. De methode wordt in fig. 5.8 weergegeven, en zal nagaan of de

binnenkomende berichten digitaal ondertekend werden of niet.

Verder is er ook nog een extra klasse vereist aan de client zijde, namelijk SoapSigner. Deze

klasse bevat een enkele methode die een SecurityToken teruggeeft waarmee een SOAP

bericht ondertekend kan worden.

Figuur 5.7 toont het nieuwe UML diagram voor de client zijde. Elke klasse die een Web

Service Interface methode oproept, maakt nu gebruik van de klasse SoapSigner om de

SOAP messages die verstuurd worden digitaal te ondertekenen

private bool IsMessageSigned(SoapContext context)

{

foreach (ISecurityElement element in context.Security.Elements)

{

if (element is MessageSignature)

{

MessageSignature sig = element as MessageSignature;

if((sig.SignatureOptions &

SignatureOptions.IncludeSoapBody) != 0)

{

return true;

}

}

}

return false;

}

Figuur 5.8: Extra methode in Web Service Interfaces

Het bekijken van de eenvoudigste use case, namelijk een gebruiker die wenst in te loggen, zal

de relatie tussen de nieuwe componenten duidelijk maken. Figuur 5.9 toont het uitgebreide

sequentiediagram hiervoor.


Figuur 5.9: Uitgebreide sequentiediagram: inloggen

Wanneer de gebruiker nu wenst in te loggen (1), zal de GUI nog steeds de aanvraag

doorsturen naar de SecurityHandler (2). Voordat de SecurityHandler nu de

LoginWS zal aanspreken, zal het eerst aan de SoapSigner het SecurityToken

aanvragen (3 & 4) waarmee de SecurityHandler het SOAP bericht kan ondertekenen.

Pas hierna zal de SecurityHandler een aanvraag naar de LoginWS versturen (5). De

LoginWS zal dan eerst nagaan of het bericht digitaal ondertekend is (6). Indien dit het geval

is, zal de aanvraag doorgestuurd worden naar de ServerSecurity (7), die via de

DatabaseConnection de gegevens van de gebruiker zal opvragen (8 & 9) en die naar de

SecurityHandler zal terugsturen (10 & 11). Die zal nagaan of het gaat om een

geauthenticeerde gebruiker (12a & 13a) of een niet-geauthenticeerde gebruiker (12b & 13b).

In Appendix C wordt er een extract van een SOAP bericht getoond, dat bewijst dat de SOAP

berichten effectief digitaal ondertekend worden.

IMPLEMENTATIE 43

Hoofdstuk 6

Implementatie

In dit hoofdstuk worden de implementatiedetails van de applicatie besproken. Er wordt

aandacht besteed aan de Hospital Client GUI, de Supplier Client GUI, de UserCreator en de

E-procurement Web Service.

6.1 Client GUI’s

6.1.1 Hospital Client GUI

Voordat een gebruiker toegang krijgt tot de Hospital Client GUI, wordt er steeds gevraagd

aan de gebruiker om in te loggen met behulp van een paswoord en een login. Dit scherm

wordt weergegeven in fig. 6.1.

Figuur 6.1: Login screen

Eenmaal de gebruiker succesvol ingelogd is, krijgt hij of zij het hoofdscherm te zien. Bij het

implementeren van de Client GUI werd er gestreefd naar een zo bekend mogelijke ‘look-and-

HOSPITAL CLIENT GUI 44

feel’. Aangezien er gebruik werd gemaakt van Visual Studio .NET, werd de layout van de

GUI gebaseerd op de Windows Verkenner structuur.

Aan de linkerkant van het hoofdscherm kan de gebruiker via een treeview een keuze maken

tussen de lopende aanbestedingen en de afgehandelde orders, die allen gerangschikt zijn op

datum. De Pending tenders zijn de aanbestedingen waarvoor het bieden nog steeds aan de

gang is, en de Handled orders zijn die aanbestedingen waarvoor er reeds een offerte werd

aanvaard, of waarvoor het bieden afgelopen is.

Aan de rechterkant van het scherm kan de gebruiker de belangrijkste gegevens van de

aanbesteding bekijken. Er wordt afgebeeld wie de aanbesteding heeft geplaatst, wanneer het

werd geplaatst, wanneer het bieden eindigt, hoeveel offertes er reeds op geplaatst werden en

hoeveel producten er besteld werden.

Het hoofdscherm voorziet in een toolbar en menuschermen om de gebruiker de mogelijkheid

te geven aanbestedingen te plaatsen, bekijken, … Dit alles wordt getoond in fig. 6.2.

Figuur 6.2: Main screen

De gebruiker kan – wanneer hij of zij geautoriseerd is – zoveel aanbestedingen plaatsen als

gewenst. Figuur 6.3 toont het scherm waarin de gebruiker een nieuwe aanbesteding kan

plaatsen. Door in het menu View – Unsend tenders… te selecteren, of op de verrekijker te

klikken op de toolbar, krijgt de gebruiker een overzicht van alle aanbestedingen die hij of zij

heeft geplaatst, maar nog niet heeft verzonden (fig. 6.4).

HOSPITAL CLIENT GUI 45

Figuur 6.3: Nieuwe aanbesteding plaatsen

Wanneer de Hospital Client GUI afgesloten wordt, zal er melding gemaakt worden dat de

aanbestedingen nog niet werden verzonden, en dat die gegevens verloren zullen gaan wanneer

de GUI afgesloten wordt.

De gebruiker kan via het scherm waar de niet verzonden aanbestedingen getoond worden nog

beslissen om aanpassingen te verrichten of eventueel aanbestedingen te verwijderen. Het

scherm biedt de mogelijkheid om de aanbestedingen te verzenden, waarna er geen

aanpassingen meer aan kunnen verricht worden.

Wanneer de gebruiker een offerte wenst te aanvaarden, dan kan dat via het scherm onder

Tools – Validate offer… Dan krijgt de gebruiker fig. 6.5 te zien. De gebruiker kan dan via de

combobox een aanbesteding selecteren, waarna de gegevens van die aanbesteding getoond

worden, alsook de offertes die ervoor werden geplaatst. De gebruiker kan dan een van die

offertes kiezen en valideren. Op de aanbesteding die in fig. 6.5 wordt getoond, werd nog geen

offerte geplaatst.

Een keuze die gemaakt werd bij het implementeren van de Client GUI’s, was om het

paswoord van een gebruiker niet bij te houden binnen de applicatie. Hierdoor wordt de

situatie vermeden dat een gebruiker eventjes zijn computer verlaat, en een ander persoon via

zijn login en paswoord verrichtingen kan doen. Daarom zal bij het plaatsen van nieuwe

SUPPLIER CLIENT GUI 46

aanbestedingen en het valideren van een offerte steeds opnieuw gevraagd worden aan de

gebruiker om zijn paswoord in te geven.

Figuur 6.4: Niet verzonden aanbestedingen

6.1.2 Supplier Client GUI

Ook van de leveranciergebruiker wordt er steeds verwacht dat er een paswoord en login

combinatie wordt ingegeven. Wanneer de gebruiker geauthenticeerd is, wordt er een

gelijkaardig hoofdscherm getoond als voor de ziekenhuisgebruiker. Verschillend is wel dat bij

de lopende aanbestedingen alle geplaatste aanbestedingen van alle ziekenhuisgebruikers

weergegeven wordt, en bij de afgehandelde orders zijn het die orders die getoond worden

waarvoor de offerte van de gebruiker werd aanvaard.

Figuur 6.6 toont de manier waarop de informatie van een aanbesteding wordt getoond die de

leverancier heeft ontvangen. De belangrijkste data – wie plaatste de aanbesteding, wanneer

stopt het bieden, … – wordt overzichtelijk weergegeven. Bovendien kan de gebruiker steeds

snel zien wat het laagste bod is die momenteel op de aanbesteding werd geboden. In fig. 6.6

heeft de gebruiker nog geen offerte geplaatst. Indien dit wel het geval was, heeft de gebruiker

de mogelijkheid om via Update… zijn bod aan te passen.

USERCREATOR 47

Figuur 6.5: Offerte aanvaarden

Figuur 6.7 toont het scherm waar de gebruiker een nieuwe aanbesteding kan plaatsen. Terug

worden alle gegevens overzichtelijk weergegeven, en indien gewenst kan de gebruiker via de

combobox andere aanbestedingen selecteren, om er een offerte op te plaatsen.

Bovendien wordt er steeds gebruik gemaakt van input validatie, zodat er geen ongeldige data

naar de Web Service verstuurd kan worden.

6.1.3 UserCreator

Omdat er voor het opslaan van de paswoorden in de databank gebruik gemaakt wordt van

strings die uitgebreid werden met een sterke random waarde en gehasht worden, is het niet zo

eenvoudig om voor testdoeleinden nieuwe gebruikers toe te voegen.

Daarom werd er nog een kleine applicatie – UserCreator – geïmplementeerd die het toelaat

om een gebruiker toe te voegen.

WEB SERVICE FRAMEWORK 48

Figuur 6.6: Aanbesteding bekijken

Het programmaatje bestaat uit een enkel scherm (fig. 6.8), waarop gevraagd wordt een login

en paswoord in te geven, alsook de gegevens van de gebruiker. Ook de autorisatiegraad kan

ingesteld worden. Wanneer alle velden correct werden ingevuld, zal er een nieuwe gebruiker

aan de databank worden toegevoegd met de ingegeven data.

6.2 Web Service framework

In deze sectie worden de implementatiedetails en –beslissingen besproken die genomen

werden om de E-procurement Web Service te implementeren.

Naar de buitenwereld toe worden er drie Web Service Interfaces geboden. De aanvragen die

bij die interfaces toekomen, moeten digitaal ondertekend zijn, anders wordt de aanvraag

genegeerd. Elk SOAP bericht dat bij de Web Service Interfaces toekomt, wordt opgeslagen in

een log file. Op die manier kan er effectief nagegaan worden of bepaalde aanbestedingen of

offertes geplaatst werden.


Dit brengt wel een mogelijk gevaar met zich mee, namelijk Denial of Service. Wanneer een

aanvaller op de hoogte is van het feit dat de SOAP berichten opgeslagen worden, zou hij of zij

hiervan misbruik van kunnen maken om de server over te belasten.

Er wordt echter nog geen backup van de logfile gemaakt. Dit zou eventueel kunnen door een

script.

Figuur 6.7: Offerte plaatsen

Om de achterliggende business logic voor de buitenwereld verborgen te houden, wordt elke

aanvraag doorgegeven aan de ServerSecurity. Die zal in de databank nagaan of de

aanvraag afkomstig is van een gekende gebruiker. Hierna zal de ServerSecurity ook de

autorisatiegraad van de gebruiker onderzoeken. Aan de hand van de autorisatiegraad, zal de

gebruiker een verschillend paswoord en login toegewezen krijgen om mee te connecteren naar

de databank. Op die manier kan er steeds gegarandeerd worden dat er alleen geldige acties op

de databank ondernomen worden.

Bij het opvragen van de gegevens van de gebruiker, wordt er gebruik gemaakt van een

gehasht paswoord. De sterke random waarde die aan de paswoorden worden toegevoegd,


werd in de code opgenomen. Beter zou zijn om die waarde in een file op te slaan op de server

zelf, en die file te encrypteren, zodat een aanvaller veel moeilijker aan die waarde kan komen.

Figuur 6.8: UserCreator

In de E-procurement Web Service werd ook een methode geïmplementeerd die nagaat of de

ID’s die met de aanbestedingen en offertes worden meegegeven, uniek zijn. Indien dit niet het

geval is, wordt de aanbesteding of offerte genegeerd, en wordt dit aan de gebruiker kenbaar

gemaakt.

Wanneer de ziekenhuisgebruiker inlogt en zijn gegevens opvraagt, zal de server voor elke

aanbesteding nagaan of de limiet voor het bieden al afgelopen is of niet. Indien dit het geval

is, wordt de aanbesteding niet langer als een aanbesteding beschouwd, maar als een order.

Voor testdoeleinden werd alles zo geïmplementeerd dat de ziekenhuisgebruiker dan nog een

dag de tijd heeft om een offerte te aanvaarden. Wanneer dit niet gebeurt binnen de

vastgestelde tijd, dan worden de order en de offertes als ongeldig beschouwd, en kan de

ziekenhuisgebruiker zich niet beroepen op een offerte. Dit kan echter zeer eenvoudig

aangepast worden naar een beslissingsperiode van 30 dagen.

Wanneer een leveranciergebruiker een offerte plaatst, of wanneer hij of zij zijn of haar bod

wenst aan te passen, wordt er ook nagegaan of dit nog geldig is binnen de limietdatum voor

het bieden.

BESLUIT 51

Hoofdstuk 7

Besluit

7.1 Conclusie

Uit datgene wat er in de vorige hoofdstukken behandeld werd, kan er besloten worden dat E-

procurement een oplossing vormt voor het manuele reverse auctioning probleem.

De applicatie die afgeleverd wordt, voldoet aan de vereiste security eisen. Er kan

gegarandeerd worden dat enkel geauthenticeerde en geautoriseerde gebruikers gebruik kunnen

maken van het E-procurement Web Service framework.

Bovendien kan de integriteit van de verstuurde berichten gegarandeerd worden door SSL.

Door gebruik te maken van een beveiligd kanaal waardoor de berichten verzonden worden,

worden replay, man in the middle en eavesdropping attacks voorkomen.

Door de autorisatie die zowel in de applicatie als in de databank wordt voorzien, wordt er

voorkomen dat aanvallen op de databank slagen.

Tot slot wordt er ook via Digital Signatures, en een logfile, een systeem voorzien waarmee de

geldigheid van geplaatste aanbestedingen en offertes kan worden aangetoond.

Door gebruik te maken van het E-procurement framework kunnen aanbestedingen en offertes

veel sneller aangeboden en afgehandeld worden. Alle belangrijke informatie wordt steeds

VERDERE ONTWIKKELINGEN 52

overzichtelijk op het scherm weergegeven. Bovendien kan zeer snel op datum opgezocht

worden welke orders er reeds geplaatst of behandeld werden. Dit alles brengt een hogere

tijdswinst met zich mee. Bovendien kan door de overzichtelijke informatie zeer snel de meest

winstgevende offerte gekozen worden.

De ontwikkelingen in de informatica zorgen ervoor dat vele tijdsrovende problemen

eenvoudig kunnen opgelost worden. De keerzijde echter is de beveiliging die bij het gebruik

van computers en vooral het internet vereist worden. Een volledige beveiliging kan namelijk

nooit gegarandeerd worden.

Indien een gebruiker van een zwak paswoord en login gebruik maakt, dan kan er niet

voorkomen worden dat een onbevoegd persoon handelingen verricht die niet geautoriseerd

zijn.

Bovendien moet er steeds een keuze gemaakt worden tussen de aangeboden security en de

performantie:

WSS kan diepgaandere beveiliging aanbieden, maar zorgt dan weer voor een grote overhead.

Door middel van digital signatures en een log systeem wordt er proof of transaction

aangeboden, maar hierdoor wordt de kans groter dat de Denial of Service aanval voorkomt.

Tot slot werd er ook aangetoond dat de applicatie op een component gebaseerde manier werd

ontworpen, en dat het extra toevoegen van nieuwe features op een eenvoudige manier kan

gebeuren.

7.2 Verdere ontwikkelingen

Welke aanpassingen kunnen nog aan de applicatie worden toegevoegd, en in welke

toepassingen zou deze applicatie gebruikt kunnen worden?

• Momenteel wordt er steeds aan de gebruiker gevraagd om een ID aan zijn

aanbesteding of offerte toe te voegen. Wanneer de ID niet geldig is, werd de aanvraag

wel al verstuurd naar de Web Service en behandeld. Het zou dus gebruiksvriendelijker

en performanter zijn wanneer de applicatie zelf een ID aan een aanbesteding en offerte

toevoegt.


• Het inloggen gebeurt met een paswoord en een login. Een andere mogelijkheid zou

kunnen zijn om de authenticatie via certificaten te laten verrichten. Op die manier

vermindert het risico dat er een login en paswoord bekend wordt.

• De sterke random waarde die gebruikt wordt om de paswoorden mee uit te breiden,

wordt momenteel in de code zelf bijgehouden. Beter zou zijn om die waarde op de

server op te slaan, en die waarde ook te versleutelen.

• De E-procurement Web Service applicatie bevat nog geen verdediging tegen een

Dictionary attack aan de client zijde. Wanneer een aanvaller verschillende

paswoorden probeert, zullen die aan de server zijde uitgebreid worden met de sterke

random waarde, en op die manier zou er ook een paswoord en login combinatie

ontdekt kunnen worden. Dit kan voorkomen worden door bijvoorbeeld op te leggen

dat slechts drie keer kan geprobeerd worden in te loggen met dezelfde login binnen

een periode. Een log systeem is hierbij ook aangeraden zodat aanvalpogingen op tijd

ontdekt kunnen worden.

• Wanneer er een aanbesteding wordt geplaatst, wordt die aanbesteding verstuurd naar

alle leveranciers. Het zou gebruiksvriendelijker zijn om de gebruiker te laten beslissen

naar welke leveranciers de aanbesteding verzonden moet worden. Zo kunnen er

categorieën aangemaakt worden van leveranciers die enkel in medicijnen, spuiten, …

handelen. Bij het plaatsen van de aanbesteding kan dan gespecificeerd worden wie de

aanbesteding mag ontvangen, zodat leveranciers die de materialen van een

aanbesteding niet kunnen leveren, geen aanbestedingen ontvangen.

• De applicatie kan eenvoudig geïntegreerd worden in reeds bestaande systemen.

Wanneer er bijvoorbeeld reeds een databank voorhanden is in een ziekenhuis, moet

enkel de klasse DatabaseConnection op die databank afgestemd worden om de

applicatie te kunnen gebruiken.

• Een mogelijke ontwikkeling zou er kunnen in bestaan om het E-procurement

framework te integreren in een stock beheer systeem. Zo zou de applicatie door het

stock beheer op de hoogte kunnen worden gebracht dat een product bijna opgebruikt

is, en dan zelf een aanbesteding voorstellen. Er zouden zelfs regels kunnen

gedeclareerd worden waaruit kan beslist worden dat het programma automatisch een


aanbesteding plaatst, of dat de aanbesteding of eerst nog moet goedgekeurd worden

door een geauthenticeerde gebruiker.

APPENDICES 55

Appendices

APPENDIX A 56

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema id="Tenders" targetNamespace="http://tempuri.org/Tenders.xsd"

elementFormDefault="qualified"

xmlns="http://tempuri.org/Tenders.xsd" xmlns:mstns="http://tempuri.org/Tenders.xsd"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="Product">

<xs:sequence>

<xs:element name="Name" type="xs:string" />

<xs:element name="Count" type="xs:double" />

<xs:element name="Description" type="xs:string" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="Tender">

<xs:sequence>


<xs:element name="Surname" type="xs:string" />

<xs:element name="Hospital" type="xs:string" />

<xs:element name="TenderID" type="xs:string" />

<xs:element name="Date" type="xs:string" />

<xs:element name="DateLimit" type="xs:string" />

<xs:element name="Products" type="ProductList" />

<xs:element name="Offers" type="OfferList" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="ProductList">

<xs:sequence>

<xs:sequence>

<xs:element name="Product" type="Product" minOccurs="1" />

</xs:sequence>

</xs:sequence>

</xs:complexType>

<xs:complexType name="TenderList">

<xs:sequence>

<xs:sequence>

<xs:element name="Tender" type="Tender" />

</xs:sequence>

</xs:sequence>

</xs:complexType>

<xs:element name="Tenders" type="TenderList"></xs:element>

<xs:complexType name="Offer">

<xs:sequence>



<xs:element name="Company" type="xs:string" />

<xs:element name="OfferID" type="xs:string" />

<xs:element name="Offer" type="xs:double" />

<xs:element name="TenderID" type="xs:string" />


</xs:sequence>

</xs:complexType>

<xs:complexType name="OfferList">

<xs:sequence>

<xs:sequence>

<xs:element name="Offer" type="Offer" />

</xs:sequence>

</xs:sequence>

</xs:complexType>

</xs:schema>

Figuur A.1: XML schema voor Tenders

APPENDIX A 57

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema id="Orders" targetNamespace="http://tempuri.org/Orders.xsd"

elementFormDefault="qualified"

xmlns="http://tempuri.org/Orders.xsd" xmlns:mstns="http://tempuri.org/Orders.xsd"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="HandledProduct">

<xs:sequence>


<xs:element name="Count" type="xs:double" />

<xs:element name="Description" type="xs:string" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="HandledOffer">

<xs:sequence>



<xs:element name="Company" type="xs:string" />

<xs:element name="OfferID" type="xs:string" />

<xs:element name="Offer" type="xs:double" />

<xs:element name="OrderID" type="xs:string" />


<xs:element name="Status" type="xs:string" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="HandledProductList">

<xs:sequence>

<xs:sequence>

<xs:element name="HandledProduct" type="HandledProduct"

minOccurs="1" />

</xs:sequence>

</xs:sequence>

</xs:complexType>

<xs:complexType name="Order">

<xs:sequence>



<xs:element name="Hospital" type="xs:string" />

<xs:element name="OrderID" type="xs:string" />


<xs:element name="DateLimit" type="xs:string" />

<xs:element name="HandledProducts" type="HandledProductList"

maxOccurs="1" />

<xs:element name="HandledOffer" type="HandledOffer" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="OrderList">

<xs:sequence>

<xs:sequence>

<xs:element name="Order" type="Order" />

</xs:sequence>

</xs:sequence>

</xs:complexType>

<xs:element name="Orders" type="OrderList"></xs:element>

</xs:schema>

Figuur A.2: XML schema voor Orders

APPENDIX B 58

CheckUser(string user, string password);

GetOffers(string user, string password);

GetHandledOffers(string user, string password);

AddOffers(string user, string password, XmlNode offers);

LowestOffer(string tenderID);

GetTenders(string user, string password);

GetOrders(string user, string password);

GetOrders(string user, string password, string [] orderIDs);

AddTenders(string user, string password, XmlNode tenders);

ValidateOffer(string user, string password, string tenderID, string

offerID);

UpdateOffer(string user, string password, string tenderID, string

offerID, double price);

B.1: ISecurityServer interface methodes

CheckUser(string user, string password);

GetUser(string name, string surname, string company);

DeleteOffers(string tenderID);

DeleteProducts(string tenderID);

DeleteTender(string tenderID);

InsertTender(string user, Tender tender);

InsertOrder(string user, Tender tender);

InsertOffer(string user, Offer offer);

InsertHandledOffer(string user, Offer offer);

InsertProduct(string tenderID, Product product);

InsertHandledProduct(string tenderID, Product product);

ValidateOffer(string offerId);

GetOffers(string [] userinfo, string tenderID);

GetHandledOffers(string [] userinfo);

GetAllTenders();

GetTenders(string [] userinfo);

GetOrders(string [] userinfo);

GetProducts(string tenderID);

GetOrderProducts(string orderID);

GetOffersByTenderID(string tenderID);

GetTenderByID(string tenderID);

GetOrderByID(string orderID);

GetOfferByID(string offerID);

GetHandledOfferByOrderID(string orderID);

GetHandledOfferByOfferID(string offerID);

GetLowestOffer(string tenderID);

B.1: IDatabaseConnection interface methodes

APPENDIX C 59

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<soap:Header>

<wsa:Action wsu:Id="Id-1226b6dc-8f99-4950-97be-2f4fe900f618">http://tempuri.org/LogIn</wsa:Action>

<wsa:MessageID wsu:Id="Id-aa0cc677-5947-4e0b-8b39-e68545bef68b">uuid:ccfb2fe7-e243-403b-828d-

36aed017d895</wsa:MessageID>

<wsa:ReplyTo wsu:Id="Id-814ba0bf-0273-4082-ab4f-58c10945e640">

<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>

</wsa:ReplyTo>

<wsa:To wsu:Id="Id-1355fcc1-a6b1-449a-a72e-f33a26ed9377">http://digicamm/E-

ProcWebService/LoginHandler.asmx</wsa:To>

<wsse:Security soap:mustUnderstand="1">

<wsu:Timestamp wsu:Id="Timestamp-4a144464-515a-46b9-978e-dd7441e64c16">

<wsu:Created>2005-05-12T19:22:30Z</wsu:Created>

<wsu:Expires>2005-05-12T19:23:30Z</wsu:Expires>

</wsu:Timestamp>

<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-

profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-

1.0#Base64Binary" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

wsu:Id="SecurityToken-d2cf6bc8-6aec-4d08-bca2-

d3c8262eac3c">MIIBxDCCAW6gAwIBAgIQxUSXFzWJYYtOZnmmuOMKkjANBgkqhkiG9w0BAQQFADAWMRQwEgYDVQQDEwtSb290IEFnZW5jeTAeFw0wMz

A3MDgxODQ3NTlaFw0zOTEyMzEyMzU5NTlaMB8xHTAbBgNVBAMTFFdTRTJRdWlja1N0YXJ0Q2xpZW50MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ

C+L6aB9x928noY4+0QBsXnxkQE4quJl7c3PUPdVu7k9A02hRG481XIfWhrDY5i7OEB7KGW7qFJotLLeMec/UkKUwCgv3VvJrs2nE9xO3SSWIdNzADukY

h+Cxt+FUU6tUkDeqg7dqwivOXhuOTRyOI3HqbWTbumaLdc8jufz2LhaQIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNYSHcFmRjoRgwFjEUMB

IGA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwDQYJKoZIhvcNAQEEBQADQQAfIbnMPVYkNNfX1tG1F+qfLhHwJdfDUZuPyRPucWF5qk

h6sSdWVBY5sT/txBnVJGziyO8DPYdu2fPMER8ajJfl</wsse:BinarySecurityToken>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#" />

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

<Reference URI="#Id-1226b6dc-8f99-4950-97be-2f4fe900f618">

<Transforms>

<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

<DigestValue>hLono1bFQ/HYqWuIn1zzoYlkueA=</DigestValue>

</Reference>

<Reference URI="#Id-aa0cc677-5947-4e0b-8b39-e68545bef68b">

<Transforms>


</Transforms>


<DigestValue>V3EDfk9V52LEXVUPxiMw0LJ47AQ=</DigestValue>

</Reference>

<Reference URI="#Id-814ba0bf-0273-4082-ab4f-58c10945e640">

<Transforms>


</Transforms>


<DigestValue>vzZetaUdNBDOfE7UjTcqYG/8tyk=</DigestValue>

</Reference>

<Reference URI="#Id-1355fcc1-a6b1-449a-a72e-f33a26ed9377">

<Transforms>


</Transforms>


<DigestValue>15gTJ9N2hGdgO9L6wzCGk/UHUVI=</DigestValue>

</Reference>

<Reference URI="#Timestamp-4a144464-515a-46b9-978e-dd7441e64c16">

<Transforms>


</Transforms>


<DigestValue>heHhYt9ILHXiE16vZDTwLGz+JC8=</DigestValue>

</Reference>

<Reference URI="#Id-a68d2813-29c0-4bdf-a3ee-41c25f314285">

<Transforms>


</Transforms>


<DigestValue>DsV7Bsx7QPwfeovK38hgBHsJ2w0=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>s959OrGDE+5JoIN1mrRS0bhBWeYEdT4pXqAos4GS3ClVdVEloE+tZ7HQ5LhC9rjd22ocdDBx4VBG4sCbjpB1FE2abqUeyq0qQpEw

YSrU0wtPzB+tHB/Cpo7IWcewga8FK1y5eJrl+a8U4B9GhUrrTGYZkor8VWaIqVTiXHMzlUQ=</SignatureValue>

<KeyInfo>

<wsse:SecurityTokenReference>

<wsse:Reference URI="#SecurityToken-d2cf6bc8-6aec-4d08-bca2-d3c8262eac3c"

ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />

</wsse:SecurityTokenReference>

</KeyInfo>

</Signature>

</wsse:Security>

</soap:Header>

<soap:Body wsu:Id="Id-a68d2813-29c0-4bdf-a3ee-41c25f314285">

<LogIn xmlns="http://tempuri.org/">

<username>madridde</username>

<password>INTEC</password>

</LogIn>

</soap:Body>

</soap:Envelope>

C.1: Ondertekend SOAP bericht

BIBLIOGRAFIE 60

Bibliografie [1] S. Van Hoecke, W. Haerick, G. De Jans, F. De Turck, E. Laermans, B. Dhoedt, P.

Demeester. Design and Implementation of a Secure Media Content Delivery Broker

Architecture. 2005.

[2] J. Jagger and J. Sharp. Programmeercursus Microsoft Visual C# .NET. Academic

Service, 2002.

[3] A. Ferrara and M. MacDonald. Programming .NET Web Services. O’Reilly, first

edition, 2002.

[4] M. Telles. C# Grand Cru. Easy Computing, eerste druk, 2002.

[5] M. Fowler. UML Distilled. Addison-Wesley, third edition, 2004.

[6] MSDN Community. http://www.msdn.com

[7] MySQL. http://www.mysql.com

LIJST VAN FIGUREN 61

Lijst van figuren

Figuur 3.1: Security threats zones 9

Figuur 4.1: Gemeenschappelijke use case: inloggen 21

Figuur 4.2: Algemene use case: ziekenhuisgebruiker 22

Figuur 4.3: Algemene use case: leveranciergebruiker 23

Figuur 4.4: Security use case 25

Figuur 4.5: Sequentiediagram: inloggen 26

Figuur 4.6: Sequentiediagram: Aanbesteding plaatsen 26

Figuur 4.7: Sequentiediagram: offertes opvolgen 27

Figuur 4.8: Sequentiediagram: Aanbestedingen ontvangen 27

Figuur 4.9: Sequentiediagram: offerte plaatsen 28

Figuur 4.10: Sequentiediagram: Bieden opvolgen 28

Figuur 4.11: Sequentiediagram: Offerte updaten 28

Figuur 5.1: Algemeen ontwerp E-procurement web service framework 30

Figuur 5.2: UML diagram client zijde 32

Figuur 5.3: UML diagram server zijde 34

Figuur 5.4: Uitgebreide sequentiediagram: inloggen 38

Figuur 5.5: Uitgebreide sequentiediagram: autorisatie nagaan 39

Figuur 5.6: Uitgebreide sequentiediagram: orders opvragen 39

Figuur 5.7: Aangepast UML diagram 40

Figuur 5.8: Extra methode in Web Service Interfaces 41

Figuur 5.9: Uitgebreide sequentiediagram: inloggen 42

Figuur 6.1: Login screen 43

Figuur 6.2: Main screen 44

Figuur 6.3: Nieuwe aanbesteding plaatsen 45

Figuur 6.4: Niet verzonden aanbestedingen 46

Figuur 6.5: Offerte aanvaarden 47

Figuur 6.6: Aanbesteding bekijken 48

Figuur 6.7: Offerte plaatsen 49

Figuur 6.8: UserCreator 50

net web services en security voor...

Documents