Web Services och säkerhet

School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI Web Services och säkerhet - en studie i tekniker för att säkra Web Services Michael Schwarz Nov 2006 MSI Report 06159 Växjö University ISSN 1650-2647 SE-351 95 VÄXJÖ ISRN VXU/MSI/IV/E/--06159/--SE

Växjö Universitet Matematiska och systemtekniska instutionen IVD 730: Examensarbete Handledare: Per Flensburg Examinator: Per Flensburg Web Services och säkerhet - en studie i tekniker för att säkra Web Services Författare: Michael Schwarz 2

Språk: Svenska Uppsatstyp: Magister År: 2006 Titel: Web Services och säkerhet en studie i tekniker för att säkra Web Services Författare: Handledare: Examinator: Skola, utbildning: Michael Schwarz Per Flensburg Per Flensburg Växjö University, System Science Abstrakt Användandet av Web Services har ökat de senaste åren, det är relativt lätt att utveckla dessa tjänster och de kan användas i de allra flesta miljöer. Ett bekymmer är dock säkerhetsfrågan. Denna uppsats studerar de vanligaste teknikerna för att säkra Web Services, beskriver hur de kan användas samtidigt diskuterar fördelar och nackdelar med flera av dem. Till sist ges förslag på hur Web Services i olika typer av miljöer kan säkras. 3

Language: Swedish Essay-type: Master Year: 2006 Title: Web Services and security a study in techniques used to secure Web Services Author: Tutor: Examiner: School, Education: Michael Schwarz Per Flensburg Per Flensburg Växjö University, System Science Abstract The usage of Web Services has increased during recent years, its relatively easy to develop and can be used in almost any environment. One concern however is the security aspect. This essay studies the most common techniques for securing Web Services and describes how they can be used. It also discusses some pros and cons about them. Finally this paper suggests some ways to secure Web Services used in different environment. 4

Innehåll 1. INLEDNING... 7 1.1 BAKGRUND... 7 1.2 PROBLEMBESKRIVNING... 7 2. METOD... 9 2.1 ANGREPPSSÄTT... 9 2.2 LITTERATURSTUDIE... 9 3. SOA OCH WEB SERVICES... 11 3.1 VAD ÄR SOA?... 11 3.2 WEB SERVICES... 11 3.3 SÄKERHETSOMRÅDEN KRING WEB SERVICES... 13 4 AUTENTISERING... 14 4.1 OM AUTENTISERING... 14 4.2 ANDRA MÖJLIGHETER FÖR AUTENTISERING... 15 5 DATAINTEGRITET... 17 5.1 OM DATAINTEGRITET... 17 5.1 XML DIGITALA SIGNATURER (XMLDS)... 17 5.1.1 Uppbyggnaden av en XML Signatur... 18 6 KONFIDENTIALITET... 20 6.1 XML KRYPTERING... 20 6.2 SECURE SOCKETS LAYER... 22 6.3 VIRTUELLA PRIVATA NÄTVERK... 25 7 ICKE-FÖRNEKANDE... 27 7.1 INTRODUKTION TILL PROBLEMET MED ICKE-FÖRNEKANDE... 27 7.2 METODER FÖR ATT SÄKERHETSKÄLLA ICKE-FÖRNEKANDE... 27 8 BEHÖRIGHET... 29 8.1 SECURITY ASSERTIONS MARKUP LANGUAGE... 29 8.2 EXTENSIBLE ACCESS CONTROL MARKUP LANGUAGE... 30 8.3 BEHÖRIGHETSKONTROLL VIA UDDI... 32 9 TILLGÄNGLIGHET... 36 9.1 OM TILLGÄNGLIGHET... 36 9.2 VANLIGA SÅRBARHETER... 36 9.3 XML BRANDVÄGGAR... 37 11 RESULTAT... 40 11.1 FÖRSLAG PÅ SÄKRING AV WEB SERVICES... 40 11.2 EXEMPEL PÅ SÄKRING AV WEB SERVICE SJUKHUSMILJÖ... 40 11.2.1 Förutsättningar... 40 11.2.2 Förslag på säkring... 41 11.3 EXEMPEL PÅ SÄKRING AV EN WEB SERVICE ETT B2B, B2C NÄTVERK... 43 11.3.1 Förutsättningar... 43 11.3.2 Förslag på säkring... 43 13 DISKUSSION... 47 13.1 Många standarder... 47 13.2 Reflektion... 47 14 REFERENSER... 48 5

15 BILAGOR... 51 15.1 FIGURFÖRTECKNING... 51 6

1. Inledning I detta avsnitt ges en bakgrund till min problemformulering, en diskussion kring problemet och slutligen mitt syfte och eventuella avgränsningar. 1.1 Bakgrund I dagens samhälle får tekniken allt större utrymme och förtroende, datorer används i så gott som alla sektorer i samhället som t.ex. sjukvård, elförsörjning, flygledning m.m. För att all denna teknik ska fungera måste olika system ha möjlighet att byta information med varandra och det är här som denna uppsats ämnesval kommer in i bilden. En teknik som vuxit sig allt större är Web Services, denna teknologi bygger på en standard för dataöverföring som gör informationen tillgänglig över Internet oberoende vilket system klienten kör. 1.2 Problembeskrivning Webbaserad teknologi börjar bli en universell standard, denna teknologi används i så skiljda miljöer som sjukvård, inom finanssektorn, övervakning av diverse system som t.ex. elförsörjning. Den teknik som kanske är på snabbast frammarsch är Web Services som följer den tjänsteorienterade modellen, den s.k. SOA-modellen (Service Oriented Architecture). Skillnaderna mellan dessa olika begrepp behandlas senare i kapitel 3. Att utveckla en Web Service är enkelt gjort med dagens utvecklingsplattformar och vi kan förmodligen vänta oss en kraftig ökning av denna teknik. Men i takt med att antalet Web Services ökar så ökar också riskerna, vi blir mer beroende av att tekniken fungerar och när väl tekniken fallerar riskerar effekterna att bli stora. Ett exempel är det stora strömavbrott som drabbade USA:s östkust 2003, orsaken till strömavbrottet var ett nedfallet träd över kraftledningen men effekterna blir mångt större eftersom övervakningssystemet inte fungerade. Ett annat problem som kan tänkas uppstå när antalet Web Services ökar är pålitligheten hos dem som tillhandahåller tjänsten, hur kan klienten som mottar information veta att avsändaren samt information är pålitlig? Allvarlighetsgraden i detta problem kan tänkas variera kraftigt, exempelvis alltifrån att fel prisuppgift ges från en s.k. prisagent till att en patient får fel sorts medicin Eftersom en publik Web Service är åtkomstbar över Internet innebär detta ytterligare risker, Internet är en betydligt opålitligare plats än exempelvis ett internt nätverk hos ett företag. Genom att en Web Service i princip kan nås från överallt i världen bjuder den in hackare som kan försöka komma åt information, manipulera information eller 7

försöka utföra attacker med mål att krascha Web Servicen. Detta gör att det ställs högre krav på säkerheten än vid användandet av t ex ett intranät. Uppsatsen som ska skrivas i anknytning till denna rapport har som mål att diskutera följande område: Sätt att säkra Web Services. Syftet med denna uppsats är att göra en sammanställning av olika sätt och tekniker att säkra en Web Service, redovisa dess olika fördelar respektive nackdelar och slutligen diskutera vilka sätt som passar bäst vid säkring av Web Services beroende på miljön den ska befinna sig i. I uppsatsen kommer inte några plattformars för eller nackdelar säkerhetsmässigt att diskuteras. Uppsatsen fördjupar sig inte heller i hur krypteringstekniker rent tekniskt sätt fungerar. 8

2. Metod I detta avsnitt beskrivs val av metod och tillvägagångssättet som användes i denna uppsats. 2.1 Angreppssätt För arbetet med min uppsats valde jag det konceptuell-analytiska angreppssättet Järvinen (2001), anledningen till detta är jag har för avsikt att studera flera tidigare teorier avseende mitt problemområde och sedan sammanställa dessa till en förhoppningsvis förbättrad teori. Detta tycker jag det konceptuell analytiska angreppssättet passar utmärkt in på. Järvinen (2001) föreslår en lämplig disposition för en deduktiv konceptuell analytisk forskning och med hänsyn att denna känns lättapplicerad på min uppsats anser jag att detta är den rätta metoden för mitt arbete. Vid användandet av denna disposition på mitt arbete skulle den få följande utseende: 1. Introduktion där SOA och Web Services förklaras 2. Grundprinciper och antaganden om Web Services och säkerhet insamling av data 3. Härledning av ny teori om Web Services och säkerhet från grundprinciper och antaganden 4. Diskussion 2.2 Litteraturstudie Metoden som kommer att användas i arbetet med denna uppsats är en litteraturstudie, vilket innebär studier av litteratur, artiklar och tidskrifter. En sådan studie ger anvisningar om vad som är gjort på området, presenterar teorier och hjälper till att definiera begrepp 1. Några problem som dock kan uppstå i samband med litteraturstudier är att det kan vara svårt att hitta relevant litteratur, inom denna uppsats ämne finns dock mycket litteratur så detta problem är inte speciellt stort. Ett annat problem som dock kan uppstå i samband med litteraturstudier är att det kan vara svårt att välja ut lämpliga teorier ur litteraturen eftersom forskarens problem oftast ej överensstämmer med litteraturens. Till sist är det svårt att veta om forskarens egen studie kommer att tillföra något som inte redan är gjort på området. För att hitta lämplig litteratur har jag bl.a. använt mig av Växjö Universitets bibliotek, sökningar i ELIN Electronic Library Information Navigator som är ett verktyg för att söka igenom flera informationskällor samtidigt. Ett annat sätt att hitta lämplig litteratur är att titta på litteraturförteckningarna i de artiklar och böcker man funnit 1 Metodboken (Conny Svenning, 1999), s35 9

som behandlar ämnet. Användningen av sökmotorer på Internet som t.ex. Google gör också att det går enkelt att hitta intressant artiklar. Ett problem med att söka efter källor på Internet är att den vetenskapliga relevansen ibland kan vara tveksam, för att säkerhetsställa att källan är pålitlig finns det några olika kriterier som kan tas hänsyn till 2. Ett av dem är att göra en trovärdighetsbedömning, dvs. vem eller vilka är det som står bakom förklaringen/fakta. Är det en forskare och vid vilket universitet eller är det en privat hemsida, företag osv. Dessa trovärdighetsbedömningar kan vara svåra att göra speciellt om man inte är särskilt insatt i frågan, det kan då vara ett alternativ att ha kontakt med en person som är det. En annan detalj som bör tas hänsyn till är tiden, när publicerades denna information eller när uppdaterades den senast, har det gått en avsevärd tid sen källan uppdaterades är det inte säkert den är pålitlig längre. Ytterligare ett kriterie som kan kontrolleras är om källan där informationen anges är primärkällan eller om informationen har hämtats från en annan källa. Det är en stor fördel ur källkritisk synvinkel om det är primärkällan eftersom detaljer kan plockas bort och läggas till allteftersom informationen kopieras mellan källor. 2 Göran Leth och Torsten Thurén, Källkritik För Internet, Styrelsen för psykologiskt försvar, 2000, s23 10

3. SOA och Web Services I detta kapitel förklaras utförligare vad begreppen SOA, Web Services innebär samt en förklaring på tekniken bakom. 3.1 Vad är SOA? SOA är en engelsk förkortning av Service Oriented Architecture som översatt till svenska blir tjänstebaserad arkitektur. Det går att säga att SOA är en samling tjänster i ett nätverk som alla kan kommunicera med varandra, helt utan att känna till de tekniska detaljerna om varandra. Dessa tjänster är avgränsade gentemot varandra och har ett helt plattformsoberoende standardgränssnitt vilket gör att det inte spelar någon som helst roll för klienten oavsett hur avancerad teknik som ligger bakom tjänsten. Detta kallas på engelska för loose coupling vilket på svenska betyder ungefär lösa kopplingar och det är just det som är SOA: s mål, att uppnå lösa kopplingar mellan system. Att system har lösa kopplingar till varandra innebär t ex att om ett system byter databasleverantör eller liknande så ska detta inte innebära att det andra systemet behöver göra förändringar i sitt system för att bibehålla funktionaliteten. På senare tid har intresset för SOA tagit allt mer fart men vissa personer hävdar att de grundläggande principerna lades redan på 1970-talet när utvecklarna insåg att användarna kunde söka information i systemen enklare om de fick tillgång till viss information via väl definierade gränssnitt vilket på denna tid kallades för inkapsling 3. Inkapsling innebär att en tjänst/service kapslar in all data och gör det inte tillgängligt utifrån på något annat sätt än genom att skicka ett meddelande till tjänsten/servicen om en begäran att få data 4. Meddelandet som skickas till tjänsten/servicen når aldrig själva datan utan endast logiken som används för att kapsla in, skicka data m.m. 3.2 Web Services En teknik som är en s.k. SOA är Web Services som blivit allt vanligare, och det är denna teknik som detta examensarbete kommer att fokusera på. Vad definierar då en Web Service? En typisk Web Service består av tre element: En klient som utför en begäran av en Web Service En mellanhand som fungerar som förvaringsplats där ägaren till Web Servicen kan publicera sin tjänst. 3 CIO Sweden, 2004 4 Microsoft AB, 2004 11

Ett företag eller organisation som tillhandahåller själva Web Servicen Förutom att kriterierna som nämns ovan ska en Web Service använda sig av följande teknik 5 : Gränssnittet ska baseras på något av följande internetprotokoll. o HTTP (HyperText Transfer Protocol ) ett begäran/svars protokoll mellan klienter och servrar en typisk klient för detta protokoll är en webbläsare 6. o FTP (File Transfer Protocol) ett protokoll för överföring av filer mellan server-klient över Internet/intranät 7. o SMTP (Simple Mail Transfer Protocol) en standard för e-post överföringar över Internet. 8 Alla protokoll ovan är olika standarder för att föra över data över Internet/intranät vilket gör att klienterna som ansluter till en Web Service inte behöver ta någon hänsyn till tekniken bakom så länge som gränssnittet följer någon av dessa protokoll. Informationen som överförs mellan klient/server ska vara i XML-format, undantaget för binärfiler. Web Services kan sägas vara uppbyggd kring tre olika standarder: SOAP, Simple Object Access Protocol, som talar om hur meddelanden skall skickas till Web Services WSDL, Web Service Description Language, som används för att beskriva gränssnittet för och de olika metoderna för en webbtjänst UDDI, Universal Description, Discovery, and Integration, en standard för att skapa register över tillgängliga Web Services publikt eller internt Gemensamt för dessa tre standarder är att de är baserade på XML. Vad dessah olika standarder innebär för användningen av Web Services kommer att återkommas till. 5 XML.COM 6 WIKIPEDIA, 2006 7 WIKIPEDIA, 2006 8 WIKIPEDIA, 2006 12

3.3 Säkerhetsområden kring Web Services För att lättare få en överblick över de olika delarna som behöver säkras i Web Services har jag valt att dela upp kapitlet i följande delar (med stöd av OSI Security Model 7498-2), så som det ofta görs gällande informationssäkerhet. Denna modell är skapad för att identifiera de olika säkerhetsaspekterna som kan tas hänsyn till vid en anslutning mellan system. De olika aspekterna är valda utifrån tanken att de ska kunna refereras till OSI-modellen som beskriver de sju olika nätverkslagren - i figuren nedan kan detta tankesätt ses. Figur 1 - De olika säkerhetsaspekterna i referens till de olika nätverkslagren (Källa: Stergiou, T.; Leeson, M.S.; Green, R.J, An alternative architectural framework to the OSI security model Computers & Security, 2005, s3) En fördel som nämns med denna tanke är att det ska bli enklare för utvecklare att finna vilka specifika säkerhetsåtgärder som bör göras beroende på vilken nivå applikationen som utvecklas befinner sig på. Ytterligare en fördel som nämns är att denna modell/ramverk tillåter att de olika lagren och säkerheten tillåts utvecklas individuellt utan att det påverkar de övriga nätverkslagrens säkerhetsaspekter. Autentisering innebär att användaren måste verifiera sin identitet för att få åtkomst till Web Servicen. Data integritet innebär att informationen inte ska kunna manipuleras av obehöriga under transport. Konfidentialitet innebär att informationen inte ska kunna avlyssnas under transport. Icke-förnekande innebär att varken sändare eller mottagare av ett meddelande ska kunna förneka sin delaktighet i kommunikationen. Behörighet innebär att en autentiserad klient endast ska ha behörighet till nödvändigt information. Tillgänglighet innebär att Web Servicen alltid ska vara tillgänglig för autentiserade och behöriga klienter. 13

4 Autentisering I detta kapitel beskrivs vad autentisering innebär samt tekniker som finns att tillgång för att autentisera användare i en Web Service. 4.1 Om autentisering Genom användandet av olika autentiseringstekniker är det tänkt att både klienten och servern ska verifieras gentemot varandra, servern är säker på att klienten är behörig och klienten ska kunna vara säker på att servern är den som den utger sig för att vara. Autentisering är en process där en person eller dator verifieras vara den som den utger sig för att vara, ett typexempel på detta är när det krävs användarnamn och lösenord för att använda en tjänst. Men i informationssamhällets och Web Services värld kan det vara minst lika viktigt att även värden (servern som klienten ansluter sig till) kan visa att den är den som den utger sig för att vara. På senare tid har de s.k. phishing-försöken blivit allt vanligare, phishing innebär att någon maskerar en webbsida att likna ett välkänt och pålitligt företag och på så sätt lurar av besökarna exempelvis personliga uppgifter, lösenord eller kontokortsnummer 9. Ett exempel på detta är det phishing-försök som drabbade kunder till banken Nordea, pga. av dåligt språkbruk blev effekterna dock små 10. Det finns många olika sätt att autentisera klienter, från enkla användarnamn/lösenord som skickas i klarttext till krypterade varianter, certifikat och användning av biometriska tekniker som exempelvis fingeravtryck eller ögonskanning. I samband med autentiseringen måste den server som tillhandahåller Web Services ta hänsyn till både direkta och indirekta klienter. En direkt klient är en klient som ansluter sig direkt till en Web Service, medan en indirekt klient istället är en klient som ansluter sig via en annan Web Service, något som ofta sker i en SOA-miljö. I figuren nedan visas ett exempel på detta. Den direkta klienten ansluter sig direkt till ett flygbolags Web Service för att söka efter lediga platser via exempelvis flygbolagets webbsida. Den indirekta klienten går istället vägen via ett resebolags Web Service för att söka efter en resa, i detta fall kan detta tänkas vara via resebolagets webbsida. 9 WIKIPEDIA, 2006 10 Säkerhet&Sekretess, 2004 14

Direkt klient Indirekt klient Autentisieringsdata Autentisieringsdata Ett flygbolags Web Service Autentisieringsdata Ett resebolags Web Service Figur 2 - Direkta och indirekta klienter För att åstadkomma en autentisering av indirekta klienter specificeras i Web Services hur autentiserings-data kan hämtas och verifieras. Detta är inte bara till nytta för autentiseringen utan krävs för att klienten och servern ska kunna kommunicera dvs. att klienten måste skicka information ett sådant format att servern kan tolka detta. För att kunna definiera den ovan nämnda informationen används WSDL (Web Service Description Language) som ursprungligen skapades av Ariba, IBM och Microsoft. 4.2 Andra möjligheter för autentisering Eftersom en klient som anropar en Web Services i sin tur kan bli vidareskickad till en annan Web Service krävs att servern hela tiden kan verifiera att klienten är behörig att anropa den. Detta problem kan lösas genom att Web Servicen använder sig av ett transport-specifikt verktyg för att hämta identiteten hos klienten. Är inte klienten autentiserad hos detta underliggande system kan detta då ske genom att exempelvis hämta användarnamn och lösenord från HTTP-huvudet. För att detta ska vara säkert krävs dock att kommunikationen är krypterad, trafik i HTTP-protokollet skickas oftast i klartext. Ytterligare en möjlighet är att skicka med användarinformation i själva meddelandet, i detta fall kan även de anropas och verifieras. I vissa fall som t ex i en sjukhusmiljö där personalen uppdaterar journaler via tunna klienter krävs det mer än att bara mjukvaruklienten kan verifiera sin identitet för servern, hur kan t.ex. Web Servicen vara säker på att rätt användare sitter bakom klienten koderna kan vara stulna osv. För detta problem finns det olika metoder att använda sig av, i exemplet ovan där läkare och sköterskor uppdaterar patienternas 15

journaler via tunna klienter kan det vara en möjlighet att använda identifiering via fingeravtryck 11 eller liknande. Det är inte bara viktigt att klienten ska kunna verifiera sin identitet för servern, i vissa fall är det lämpligt att servern kan visa för klienten att den verkligen är den som den utger sig för att vara. Ett exempel på detta kan tänkas vara när en användare (klient) ska besöka sin internetbank, klienten måste kunna vara säker på att det är den rätta Web Servicen för att inte riskera att koder, kontonummer eller liknande hamnar i fel händer. Ytterligare ett exempel kan tänkas vara ett sjukhus där patientuppgifter hanteras via en Web Service, hur kan läkaren (klienten) vara säker på att det är rätt Web Service och inte en falsk som hämtar in känslig information? För att kunna verifiera att en Web Service verkligen är den som den utger sig för att vara finns några olika tekniker, exempelvis digitala signaturer och certifikat. I nästa kapitel av denna uppsats följer beskrivningar på dessa. 11 Enforcing Distributed Data Security via Web Services, Alfred C. Weaver, Factory Communication Systems, 2004, s2 16

5 Dataintegritet I detta kapitel beskrivs vad begreppet dataintegritet innebär samt tekniker för att åstadkomma detta i Web Services. 5.1 Om dataintegritet Dataintegritet innebär att data som skickas är oförändrad från att den skickas till den tas emot. Att uppnå fullständig dataintegritet är självklart en mycket viktig aspekt i Web Service miljöer, sändaren måste vara säker på att informationen som skickas är exakt densamma som mottas i andra änden. 5.1 XML Digitala Signaturer (XMLDS) Digitala signaturer kan vara mycket användbara i två avseenden, de kan både autentisiera användare och verifiera dataintegriteten 12. XMLDS har utvecklats av W3C och IETF tillsammans och sedan släppt som en rekommendation av W3C. De aspekter av signering av XML dokument som täcks av denna standard är följande 13 : Canonical XML: Detta är ett sätt av att avgöra om två XML-dokument är identiska på ett logiskt sätt, dvs. att deras innebörd är detsamma även fast de kan ha vissa skillnader. Dessa skillnader kan t.ex. vara ordningsföljden av attribut, blanksteg och liknande. Ett canonical format innebär att ett dokument bearbetas så att data som har mer än en möjlig representation konverteras till ett standard canonical-format. Exempel på XML-dokument som har samma logiska betydelse men som kommer tolkas olika om inte en konvertering standard canonical-format görs: <root> <root> <media min= 180 year= 2006 /> <media year= 2006 min= 180 /> </root> </root> Ett XML-dokument i ett canonical-byte format, är egentligen en egen standard men blev vidareutvecklat för att kunna skapa XML-signaturer. Syntaxen: XML-syntaxen som representerar en signatur. Referenser: Pekare till objekt som ska signeras 12 XML.COM, 2003 13 Introduction to XML Encryption and XML Signature, Lautenbach, B, Information Security Technical Report, 2004, s3 17

Omvandlingar: Steg som följs och utförs på refererade objekt och som resulterar i en signering. KeyInfo: Hjälpmedel för applikationen att hitta de nycklar som användes för att signera dokumentet. Regler för bearbetning: De steg som ska följas när ett dokument signeras eller valideras. En digital signatur fungerar på så sätt att avsändaren räknar fram ett hashvärde av data som ska skickas, detta signeras sedan med avsändarens privata nyckel som inkluderas i signaturer. Nycklarna som nämns kallas för Public Key Cryptography 14 och är en metod som används för att säkert utbyta information över osäkra nätverk som exempelvis Internet. Varje medverkande i ett informationsutbyte har ett par nycklar, en privat och en publik nyckel, den publika nyckeln delas ut till dem som vill kommunicera med dem medan den privata nyckeln hålls hemlig. Dessa bägge nycklar har ett matematiskt samband men kryptot är designat så att det är näst intill omöjligt att få fram den privata nyckeln genom den publika. Det enda sättet att dekryptera informationen är genom den matchande privata nyckeln som mottagaren av informationen måste ha tillgång till 15. När sedan mottagaren får informationen autentiseras signaturen och hashvärdet dekrypteras med avsändarens bifogade nyckel. Efter detta skapar mottagaren ett eget hashvärde av data och jämför detta med avsändarens hashvärde, stämmer dessa överrens är integriteten av informationen fastställd. Vid det fallet där hashvärdena dock ej stämmer överrens har informationen förändrats under kommunikationen alternativ stämmer ej signaturen överrens vilket innebär att informationens integritet ej är pålitligt 16. Vid användning av digitala signaturer kan hela eller delar av ett dokument signeras vilket betyder minskad belastning av processorkraft och tidsåtgång eftersom endast data som kräver det behöver signeras. I vissa fall kan det dessutom vara nödvändigt att endast signera delar av ett dokument, ett exempel på detta är ett signerat formulär som skickas till en användare för att fyllas i. Om hela detta dokument hade signerats skulle en ändring av användaren resultera i att signaturen inte validerade mot originalsignaturen när sedan formuläret skickas tillbaka av användaren. 5.1.1 Uppbyggnaden av en XML Signatur En XML Signatur kan bestå av många element eftersom en del är obligatoriska och andra frivilliga. 14 XML.COM, 2001 15 XML.COM, 2001 16 Maintaining the Integrity of XML Signatures by using the Manifest element, Hussain, O.K.; Soh, B., Industrial Electronics Society, 2004. 18

Nedan visas ett exempel på en signatur, i denna signatur går att utläsa att XML dokumentet som är signerat är http://www.w3.example.com/foo.xml eftersom det är vad som är angivet i Reference-elementet. Figur 3 - Exempel på XML signatur (Källa: http://www.w3.org) Vid användandet av digitala signaturer på XML-filer finns det dock några bieffekter som hänsyn ska tas till. Komplexa omvandlingar kan vara mycket processorkrävande och bör därmed undvika att användas där stora volymer data ska behandlas. En annan anledning till att stora dokument bör undvika att signeras som helhet är att kanonisation kan ta lång tid eftersom hela dokumentet först måste läsas in till minnet innan det kan konverteras. Kanonisation innebär kortfattat att ändringar som inte påverkar ett dokuments innehåll tas bort, däremot klarar kanonisering ej av att ta bort ändringar i form av indenteringar som vissa program automatiskt gör för att snygga upp koden. Dessa former av ändringar gör vid validering av dokumentet stämmer inte hashvärdet med ursprunget och signaturens bedöms som ej pålitlig. Användandet av dessa digitala signaturer har speciellt stor nytta i system som använder sig av Web Services eftersom data kan skickas över stora avstånd och via många servrar. Genom dessa signaturer går det alltså att säkerhetsställa att informationen är densamma vid mottagandet som vid sändningen även vid tillfällen där informationen passerar genom tredjepartsservrar på Internet något som är själva grunden i Web Services. 19

6 Konfidentialitet Att erbjuda säkerhet i form av tillit innebär att informationen inte kan kommas åt av obehöriga. I detta kapitel kommer några metoder för kryptering att förklaras. 6.1 XML Kryptering För att uppnå kriteriet med att förhindra obehöriga från åtkomst till informationen finns en möjlighet att kryptera ett XML-dokument, konceptet med kryptering av XML dokument härstammar från XMLDS. XML Encryption är en föreslagen standard från W3C som används för att kryptera XML-dokument. Förutom att kryptera hela dokumentet klarar denna standard att kryptera ett element och alla dess underelement, alla underelement av ett specifikt element data samt elementattribut. Det finns även möjlighet att kryptera olika delar med olika nycklar vilket innebär att delar av dokumentet kan läsas av olika mottagare. Ett exempel på detta i användning är en order som gjorts innehåller information om vilka varor som beställts samt summan och bankuppgifter för dem. Det är då möjligt att göra att två olika krypteringar, en för banken och en för företaget som säljer varorna. Banken kan då endast se summan samt kontoinformationen medan leverantören endast kan se orderinformation. Vid de element eller underelement som har valts att krypteras ersätts elementet med ett <EncryptedData> element som innehåller data fast i krypterad form. Vid kryptering av XML dokument tillkommer ytterligare element, ovan nämnd samt; <EncryptedKey> innehåller en krypterad nyckel samt information som krävs för att dekryptera den. Dessa element har i sin tur olika komponenter 17 : <EncryptionMethod> - beskriver vilken algoritm som använts vid krypteringen. <KeyInfo> - Information om nyckeln som använts för att kryptera data i dokumentet, detta element är återanvänt från XMLDS och därifrån går också alla övriga <KeyInfo> element att också använda. Ytterligare två element från XMLDS är definierade för XML Encryption - <EncryptedKey> och <AgreementMethod>, dessa element beskrivs nedan. <EncryptedKey> - Detta element innehåller dekrypteringsnyckeln som ska användas vid dekryptering, dock i krypterat format genom att den är krypterad med mottagarens publika nyckel. Genom att göra detta är det endast mottagaren av meddelandet som kan dekryptera nyckeln genom att använda sin privata nyckel. 17 Introduction to XML Encryption and XML Signature, Lautenbach, B, Information Security Technical Report, 2004, s9 20

<AgreementMethod> - elementet kan användas för att identifiera de nycklar och procedurer som användes för att anskaffa en publik krypteringsnyckel. <CipherData> - obligatoriskt element som antingen innehåller (<CipherValue>) den krypterade datan eller innehåller den en referens (<CipherReference>) som pekar på var den krypterade datan finns, detta gör det möjligt att skicka den krypterade datan i ett externt dokument. <EncryptionProperties> - innehåller tilläggsinformation om den krypterade datan. Innehållet i detta element är applikationsberoende. Krypteringen av ett XML-dokument fungerar på liknande sätt som vid digital signering av XML-dokument, lämpligen körs kanoniseringsalgoritm (se avsnittet om XML Signaturer för förklaring) över data som ska krypteras för att ta bort tecken som ej påverkar dokumentets innehåll. Informationen krypteras sedan och sätts in i en <CipherValue> struktur som å sin sida placeras i ett <EnryptedData> element. Nedan visas ett exempel på hur en ett XML-dokument ser ut före och efter en kryptering. Figur 4 - Okrypterat XML-dokument (Källa: Introduction to XML Encryption and XML Signature, Lautenbach, B, Information Security Technical Report, 2004) 21

Figur 5 - Kryperat XML-dokument (Källa: Introduction to XML Encryption and XML Signature, Lautenbach, B, Information Security Technical Report, 2004) Att använda XML Encryption istället för SSL är dock inget alternativ - kräver en applikation att hela kommunikationen måste vara säkrad så ska SSL användas 18. Användandet av XML Encryption är istället ett bättre väl där det krävs en kombination av säker och osäker kommunikation där delar av datan är krypterad. XML Encryption har också en stor fördel vid att information fortfarande är krypterad även efter mottagandet, till skillnad mot SSL som endast är krypterat under transport. Genom att använda kryptering av XML dokument går det därmed att kraftigt försvåra för att utomstående kommer åt informationen som transporteras till och från Web Servicen. Ett exempel där användning av XML kryptering är lämplig kan vara i t ex en bankmiljö där kunderna ansluter till bankens Web Service, informationen som skickas är oftast känslig och genom att kryptera denna ökar kundernas och bankens säkerhet. 6.2 Secure Sockets Layer Ett annat sätt att skydda dataintegriteten är att använda Secure Sockets Layer (SSL) som fungerar lite annorlunda är XMLDS. SSL är inriktad på att se till datakommunikation sker säkert över Internet, dvs. data som skickas är krypterad 18 IBM, 2002 22

under själva transporten. Utan kryptering av data kan information som skickas över Internet riskera att läsas av en tredje part som avlyssnar kommunikationen. Secure Sockets Layers är designat för att skapa en säker kanal mellan klienter och servrar, detta är ett av världens mest använda säkerhetsprotokoll och anses av många ska användas på alla servrar för att skydda information som skickas över Internet 19. SSL kan bl.a. användas för att säkra webbsidor, intranät och Web Services. Det är möjligt att se om en webbtjänst använder sig av SSL genom att leta efter hänglåssymbolen som då visas i webbläsaren, detta hänglås indikerar att dataöverföringen kryteras med hjälp av SSL. Eftersom i princip alla moderna webbläsare har SSL inbyggt behöver inte användarna bekymra sig om denna bit, allt som krävs är att användaren godkänner ett certifikat från servern. Ett certifikat ges ut av olika certifieringsorgan och detta är ett intyg på att servern som innehar ett sådant är de som dem utger sig för att vara 20. I nedanstående figur visas hur ett certifikat kan ses i webbläsaren: 19 Securing online business with SSL, Waite, S., Network Security, 2006, s1 20 XML.COM, 2001 23

Figur 6 - Exempel på certifikat I figuren ovan går det att utläsa information om det aktuella certifikatet. Informationen som kan utläsas är: Vad för slags certifikat som utfärdats, i detta fall rör det sig om ett SSLservercertifikat. Vem/vilka certifikatet är utfärdat till tilltalsnamn (webbadress) samt organisationen som äger domänen. Vilken organisation som utfärdat certifikatet, i detta fall VeriSign Trust Network. Giltighet när certifikatet införskaffades (2006-03-03) och när det upphör att gälla (2007-03-04). För att en webbsida ska kunna få ett SSL-certifikat krävs att en ansökan göras till ett företag som utfärdar dessa certifikat. Ett certifikat utfärdat av VeriSign har genomgått följande autentiseringsprocess för att säkerhetskälla att organisationen är legitim och har registrerats hos berörda myndigheter 21 : 21 Verisign, 2006 24

Att organisationen fortfarande är verksam Att organisationen äger/har rätt att använda den domän som har angetts i fältet för nätverksnamn i begäran om certifikatssignering (CSR) Att organisationskontakten arbetar för den organisation som anges i det utmärkande namnet Att företagskontakten är medveten om certifikatsbegäran Att den angivna tekniska kontakten är behörig att ta emot ett digitalt ID En nackdel som nämns med användandet av Secure Sockets Layer är att precis all kommunikation krypteras vilket i och för sig är en bra sak, men eftersom all data ska krypteras respektive dekrypteras vilket orsakar högre systembelastning och ökad tidsåtgång 22. I vissa fall kan det tänkas att endast en del av informationen skulle behöva krypteras, det finns risk för att det uppstår en slags onödig kryptering alltså. Ytterligare en aspekt som nämns med SSL är att vid användning i SOA miljöer som Web Services är så transporteras ofta data genom flera olika anslutningar, detta medför att mellanhanden måste starta en ny SSL-session med den tredje mottagaren. Något som särskilt bör tas hänsyn till är att vid användandet av endast SSL som kryptering är informationen endast säker under transporten, när den sen ska lagras hos servern eller i vissa fall hos klienten kommer den återgå till okrypterad form. Beroende på vilken applikation som utvecklas kan det krävas ytterligare metoder för att skydda informationen. 6.3 Virtuella Privata Nätverk Användandet av Virtuella Privata Nätverk (VPN) är ett annat sätt att säkra en Web Service och dess användare 23. Genom användandet av VPN i distribuerade system så skapas en säker krypterad tunnel mellan användare och server, all data som transporteras via denna tunnel är därmed skyddad mot avlyssningen eller manipulation av data. En intressant möjlighet att använda VPN och Web Services tillsammans presenteras i artikel utgiven 2004 24. Där föreslås att förutom klient och server ska en mellanhand skapas, en Central Management Operation Point i fortsättningen kallad MOP. Denna mellanhand är i sig själv en Web Service men hanterar bara själva handhavandet medan själva affärsprocessen sker mellan klient-server. En klient ansluter sig därmed till MOP: en som sedan verifierar klienten och dennes 22 A Security Model Design in Web Service Environment, Zhang Mi; Cheng Zunping; Ma Ziji; Zang Binyu, Computer and Information Technology, 2005 23 Managing and securing Web services with VPNs, Alchaal, L.; Roca, V.; Habert, M., Web Services, 2004, s1 24 Managing and securing Web services with VPNs, Alchaal, L.; Roca, V.; Habert, M., Web Services, 2004 25

behörighet, efter det skapas en dynamisk VPN-tunnel direkt mellan klient och server, detta sker med varje ny klient som ansluter. MOP Klient VPN Web Service Oskyddat nätverk, ex Internet Figur 7 - Förslag till Web Services i kombination med VPN Fördelen med ovanstående lösning är enligt skaparna är att det centrala hanteringssystemet tar hand om klient autentisiering, hanterar policys och säkerhetskonfigurationer vilket i sin tur gör att utvecklarna av den Web Service som tillhandhåller de tjänster klienten vill anropa kan fokusera på affärsnyttan och överlåta säkerheten. Ett bekymmer som nämns i samband med denna lösning är prestandafrågorna, dels att låta all datakommunikation gå via en krypterad tunnel gör att prestanda blir lidande och det är en komplex uppgift att optimera dessa. En annan aspekt är tiden det tar att upprätta en VPN anslutning, i försöken som gjordes 2004 med denna lösning var genomsnittstiden för upprättandet 24 sekunder, skaparna hävdar dock att denna tid kan reduceras 25. 25 Managing and securing Web services with VPNs, Alchaal, L.; Roca, V.; Habert, M., Web Services, 2004, s7 26

7 Icke-förnekande Det ursprungliga uttrycket på engelska är Non-Repudiation och översatt till svenska blir detta icke-förnekande, denna term innebär att tekniker inom kryptografi används som ska bevisa att den som sänt ett meddelande har sänt det 26. 7.1 Introduktion till problemet med ickeförnekande Genom användandet av digitala signaturer uppnås förutom dataintegritet också ytterligare ett kriterie på vägen mot informationssäkerheten Icke-förnekande kriteriet. Behovet av detta uppstår främst på grund av avsändare med ont uppsåt. Genom att uppnå detta kriterium garanteras att avsändare i ett senare skede inte kan förneka att denne sände meddelandet, vilket sammanfattningsvis innebär att avsändaren är densamme som skaparen av meddelandet. För att kunna förhindra detta krävs att både meddelandet och avsändaren kan autentiseras samtidigt 27. Ett exempel kan tänkas vara när ett företag gör en beställning av ett annat företag, när företaget som mottog beställningen levererar ordern och sedan skickar ut en faktura ska inte företaget som gjorde beställningen ha möjlighet att förneka detta. Att använda digitala signaturer är i inte tillräckligt i detta fall eftersom de inte klarar förhindra en s.k. replay-attack. En sådan attack innebär att det första meddelandet som skickades från avsändaren (och är digitalt signerat) mottas och valideras men också kopieras, antingen från mottagaren eller från en tredje part. Detta meddelande är då fortfarande digitalt signerat och kommer att godkännas ytterligare en gång om det skickas. Exempelvis skulle detta kunna innebära att ett meddelande innehållande en order kopieras och sänds flera gånger vilket innebär flera beställningar. Att endast autentisera avsändaren är inte heller tillräckligt eftersom en avsändare med ont uppsåt skulle kunna hävda att meddelandet då har modifierats under transporten. 7.2 Metoder för att säkerhetskälla ickeförnekande Lösningen till detta problem skulle kunna vara att använda en kombination av kriterierna autentisiering och dataintegritet, vilket gör att sårbarenhet minskar för dessa attacker. Tyvärr är detta inte heller tillräckligt pga. av några olika faktorer. En faktor är att i exempelvis digitala signaturer finns det inte någon räknare som räknar 26 IDG Dataordlista 27 IBM, 2001 27

antalet gånger ett meddelande har skickats, detta innebär att en mottagare av ett meddelande skulle t.ex. kunna hävda att denne fått två beställningar. En lösning på detta problem som föreslås av IBM 28 är att utvecklare av Web Services ska lägga till en ej repeterade sträng vid skapandet av ett meddelande innan det signeras. Genom att göra detta och då exempelvis använda en tidstämpel eller en räknare blir varje meddelande unikt och mottagaren eller sändaren kan inte hävda något annat. Dock finns det ändå minst en säkerhetslucka kvar i dessa kriterier vad händer om mottagaren av ett SOAP-meddelande vidarebefordrar meddelandet till en tredje part? Signaturen stämmer, dataintegriteten är intakt och meddelandet är fortfarande unikt vilken gör den tredje mottagaren kan hävda att en beställning gjorts eller liknande. För att undvika detta scenario är det möjligt för utvecklade att innan signering specificera i SOAP-meddelandet vilken mottagare meddelandet är ämnat för. 28 IBM, 2001 28

8 Behörighet Behörighet ska inte förväxlas med autentisering även om de vid en första anblick påminner om varandra. En autentiseringprocess har till uppgift att verifiera identiteten hos motparten, medan behörighet (Authorization) har till uppgift att kontrollera att klienten är berättigad till informationen som förfrågats. Nedan redovisas de funna teknikerna för detta ändamål. 8.1 Security Assertions Markup Language Security Assertions Markup Language (SAML) är precis som övriga språk som används i Web Services baserat på XML och är en standard för att utbytta autentisiering mellan olika applikationer 29. Detta är särskilt användbart vid lösningar där flera olika system kommunicerar med Web Servicen och dessutom med varandras Web Services. Genom användandet av SAML i en SOA miljö som Web Services där ofta flera olika leverantörer av tjänster kan vara involverade kan leverantörerna utfärda s.k. assertions för deras egna pålitliga affärspartners, en sort försäkran om att denna partnern är pålitligt. Genom att utfärda denna försäkran får partnern tillgång till de tjänster som leverantören själv har ett pålitligt samarbete med. För att förtydliga detta är det enklast med ett exempel: En internetföretag inriktat på resor har samlat flygbolag, hotell, bilutyrningsföretag under samma sajt liknande en portal. Denna portal har flera kundgrupper, både business to business (b2b) och business to customer (b2c). Portalen får en förfrågan från ett resebolag som ordnar paketresor att de vill ha möjlighet att under period ha tillgång till de olika tjänsterna som kan återfinnas i portalen, t.ex. Web Services tillhörande hotell, flygbolag osv. Portalen utfärdar då en tidsbegränsad försäkran och kallas då för SAML authority, resebolaget som efterfrågade försäkran kallas för requester application. Resebolaget har nu fått en försäkran från portalen om att de är en pålitlig partner till portalen, denna försäkran läggs sedan i ett WSS-meddelande som skickas t.ex. till ett hotell. I figuren nedan visas en översikt hur detta fungerar. 29 XML.COM, 2003 29

Portal (SAML Authority) Hotell (Web Service) Flygbolag (Web Service) Tillfällig försäkran (Assertion) Biluthyrning (Web Service) Resebolag (requester application) Turistattraktioner (Web Service) Figur 8 Användning av SAML, resebolaget får genom försäkran från Portalen om pålitlighet tillgång till anslutna Web Services. Vid skapande av en Assertion (Försäkran) finns det möjlighet att specificera flera olika sorters villkor för när försäkran gäller, exempelvis för när försäkran ska börja gälla och när den ska sluta. I meddelandet med försäkran går det också att utläsa vid vilken tidpunkt försäkran utfärdades, vem utfärdaren av försäkringen är samt vilket förhållande utfärdare och föremålet för försäkran har. För att de mottagare som tar emot autentiseringen ska veta att det verkligen var portalen i exemplet som utfärdade försäkringen inkluderas även den digitala XML signaturen till dem som utfärdade försäkran. Möjligheten att kunna skapa dess försäkringar om pålitlighet är speciellt användbart vid tillfällen när en klient behöver få tillgång till en miljö med flera olika Web Services från olika leverantörer. 8.2 Extensible Access Control Markup Language Extensible access control markup language (XACML) ger möjlighet att definiera en säkerhetspolicy och för att ta beslut om behörigheter. XMACML skapades för att ersätta behörighets-kontrollerade mekanismer som var applikationsspecifika. Detta innebar att varje leverantör hade sin egen metod för åtkomstkontrollerande metoder vilket gjorde att olika system fick svårt att kommunicera med varandra utan utvecklarna fick anpassa dem till varandra. Enligt företaget Sun Microsystems medför användandet av XACML flera fördelar 30 : 30 Sun Microsystems, 2006 30

En standard åtkomstpolicy kan ersätta flertalet av de applikationsspecifika Eftersom åtkomstpolicyn inte behöver skrivas om för varje applikation sparas administratörerna tid och pengar Tidsåtgången vid utveckling minskar eftersom utvecklarna slipper skapa nya språk utan kan istället återanvända befintliga Ordentliga verktyg för att skapa åtkomstpolicys kommer utvecklas eftersom det blir en standard Eftersom det finns tillägg till XACML har det möjlighet att tillgodose de flesta behov. En XACML policy kan användas på flera resurser samtidigt vilken hindrar att olika versioner av åtkomstpolicys används XACML policys kan referera till varandra vilket kan vara användbart för stora organisationer XACML erbjuder två komponenter att användas vid utveckling av Web Services. Den första är ett policyspråk som låter utvecklade specificera åtkomstregler för vem som kan göra vad och när. Den andra komponenten är språk som presenterar en förfrågan om åtkomst och sedan beskriver svaret för sådana förfrågningar. Genom att använda XACML kan alltså kriterier för olika aktiviteter som t.ex. läsning, kopiering, radering kontrolleras. Exempel på kriterier som kan krävas genom användning av XACML är 31 : Protokollspecifika regler t.ex. att överföringen måste ske via SSL. Användarspecifika attribut användaren måste vara sjuksköterska eller högre. Autentiseringsspecifika kontroller användaren måste ha blivit autentiserad genom användning av en digital enhet. För att utföra kontroller av behörigheter skickas varje förfrågan till en enhet som skyddar själva Web Services, denna enhet kallas för Policy Enforcement Point (PEP). Denna enhet skapar i sin med hjälp av XACML-språket en ny förfrågan som är baserad på attribut som ämne, handling, önskad resurs samt övrig information som kan finnas tillgänglig. PEP skickar denna nya förfrågan till en annan enhet Policy Decision Point (PDP). Denna enhet undersöker begäran och hämtar policyreglerna (också skrivna i XACML) som ska användas och avgör sedan om åtkomsten är godkänd. 31 Computerworld, 2003 31

1 Policy Enforcment Point (PEP) 2 Policy Decision Point (PDP) Klient 3 Web Service Figur 9 Översikt över XACML arkitekturen 1. Förfrågan till PEP om åtkomst till Web Servicen 2. Förfrågan behandlas i PDP med avseende på önskad resurs, behörighetsattribut, handling m.m. Svaret returernas till PEP. 3. Förfrågan godkändes och klienten får tillgång till Web Servicen Som synes i figuren ovan agerar Policy Enforcement Point och Policy Decision Point en slags vakt som kontrollerar vilken resurs klienten önskar, om den är behörig samt vilken handling som önskas ske med resursen, t.ex. hämtning eller uppdatering av information. 8.3 Behörighetskontroll via UDDI UDDI är en standard som skapar en plattform som låter företag och applikationer att snabbt, enkelt och dynamiskt att hitta och använda Web Services på Internet genom att skapa ett register 32. Registret som skapas över Web Services kan antingen presenteras över ett publikt nätverk som Internet eller i ett internt nätverk som ett Intranät. Detta register underlättar sedan betydligt när en ny användare vill ansluta till företaget som erbjuder tjänsten, registret över de olika Web Services som erbjuds listas helt enkelt upp för den nya användaren. Precis som SOAP och WSDL så är UDDI uppbyggt med hjälp av standarden XML och används ofta tillsammans med HTTP-protokollet. Användandet av detta register har flera fördelar, dels är det möjligt för företag att nå ut och visa deras Web Service, men också för att blivandet klienter kan bedöma tjänstens säkerhet samt vilka protokoll som används. 32 UDDI Access Control, Dai, J.; Steele, R., 2005, s1 32

Eftersom information om säkerhet och protokoll kan ses i detta register undviker företag gärna att publicera registret publik och ger därför endast särkskilt godkända samarbetspartners möjlighet att se detta 33. Problemet som kan dyka upp här är att olika samarbetspartners kan behöva olika sorters information, detta gör att det behövs någon slags behörighetskontroll av vilka som har rätt att utläsa vad från registret. I avsnittet om behörighet belyses detta vidare. Eftersom en publik UDDI erbjuder information om anrop samt lagring av data är detta en potentiell säkerhetsrisk, detta gör att många företag väljer att publicera sin UDDI internt och skyddat av brandväggar där endast utvalda samarbetspartners får åtkomst till dem via autentisering. Ett bekymmer som föreligger är att olika samarbetspartners har olika behov och behöver inte ha tillgång till viss information om Web Servicen. I en rapport från 2005 (UDDI Access Control, Dai, J.; Steele, R., 2005) föreslås en lösning där UDDI förses med en behörighetspolicy baserat på XACML. Även om XACML erbjuder policykontroller så sker dessa när klienten redan har blivit autentiserad, genom att använda behörighetsregler via UDDI sker detta innan klienten blivit autentiserad av Web Servicen. Behörighetskontrollen via UDDI gör att en anslutande klient som kontrollerar registret ser endast det Services som den är behörig till, övriga är osynliga. Detta kan tänkas vara till användning vid ett företag som både har kunder och leverantörer, de har förmodligen inte samma behov kunden kanske behöver tillgång till ordersystemet medan leverantörer behöver tillgång till lagersystemet. I rapporten som nämns ovan föreslås en rollbaserad kontrollmodell som implementeras XACML. I en rollbaserad kontrollmodell finns fem grundelement: användare, roller, objekt, operationer och behörigheter 34. Objekten som blir skyddade i denna modell är de olika posterna i ett register som visar Web Services. Genom tilldelandet av roller är det möjligt för administratören att snabbt och enkelt lägga till nya användare/partners. Exempelvis skapas två roller, kund och en leverantör. Om sedan företaget får en ny leverantör av en vara/tjänst läggs leverantören till i systemet och tilldelas rollen som leverantör i systemet och ärver därmed dessa prilivegier. Denna åtkomstmodell fungerar på detta sätt när en klient ansluter till registret och begär en lista på tillgängliga Web Service. 1. Klienten autentiseras genom inloggning till registret 2. Klientens ID matchas med rollen 3. Systemet kontrollerar alla Web Services som användaren har tillgång till 33 UDDI Access Control, Dai, J.; Steele, R., 2005, s1 34 UDDI access control, Dai, J.; Steele, R., 2005, s3 33

4. Två listor skapas under klientens session åtkomstbara och ej-åtkomsbara services 5. En lista presenteras för klienten med tillgängliga Web Services och relevant information 6. De övriga Web Services som finns men som klienten ej har behörighet till visas ej i listan Figur 10 Policy (Källa: UDDI access control, Dai, J.; Steele, R., 2005, s3) 34

Figur 11 Definering av roll i policy (Källa: UDDI access control, Dai, J.; Steele, R., 2005, s4) 35