Sikkerhedsanalyse af WSRP

Transkript

1 Sikkerhedsanalyse af WSRP Analyse af sikkerhedsaspekter ved udveksling af brugerinformation mellem portaler og WSRP-portlets

2 Sikkerhedsanalyse af WSRP Analyse af sikkerhedsaspekter ved udveksling af brugerinformation mellem portaler og WSRP Udarbejdet af IT- og Telestyrelsen i samarbejde med TRIFORK ved Joakim Recht.og Ole Pedersen Publikationen kan hentes på It- & Telestyrelsens hjemmeside: Forside foto: Thomas Yde Udgivet af: IT- & Telestyrelsen Holsteinsgade København Ø Telefon: Fax:

3 Sikkerhedsanalyse af WSRP Analyse af sikkerhedsaspekter ved udveksling af brugerinformation mellem portaler og WSRP-portlets IT- & Telestyrelsen august 2007

4 Indhold > Introduktion 6 Hvad er sikkerhed? 7 Rapportens forudsætninger 8 Rapportens opbygning 8 Introduktion til SAML 9 Anvendelsesscenarier 10 Udvikling og trends indenfor SAML 12 WSRP uden fuld tillid mellem portal og portletproducer 12 Liberty Alliance ID-WSF 13 SOSI 13 Profiler 15 Hovedmål 15 Single Signon 15 Single Logout 15 Autentifikation mellem portal og portlet. 15 Autentifikation af brugeren 16 Fortrolighed 16 Privacy 17 Audit-log 17 Profil-oversigt og -opbygning 18 SAML Token Profil 19 Mekanisme til autentifikation mellem portal og portlet 20 Fortrolighed mellem portal og portlet 20 Udveksling af brugeridentifikation 20 Krav til portal og portlet 20 Fordele og ulemper 20 WSRP profil 21 UserContextKey 21 Extension 21 NavigationalParameter 22 Sammenligning 22 Mekanisme til autentifikation mellem portal og portlet 22 Fortrolighed mellem portal og portlet 22 Udveksling af brugeridentifikation 23 Krav til portal og portlet 23 Fordele og ulemper 23 HTTP-profil 23 Mekanisme til autentifikation mellem portal og portlet 23 Fortrolighed mellem portal og portlet 24 Udveksling af brugeridentifikation 24 Krav til portal og portlet 24 Fordele og ulemper 24 Username Token profil 24 Mekanisme til autentifikation mellem portal og portlet 25 Fortrolighed mellem portal og portlet 25 Udveksling af brugeridentifikation 25

5 Krav til portal og portlet 25 Fordele og ulemper 25 Kort gennemgang af portalunderstøttelse 26 Profilsammenligning 28 Hvad mangler for at profilerne kan tages i brug? 29 Alternativer ved manglende teknologi-understøttelse 29 Konklusion 31 Andre behov i forbindelse med sikkerhed 31 Litteraturliste 33

6 Introduktion > WSRP-standarden [WSRP] gør det muligt at hente indhold til en portal fra portlets, der ligger på vilkårlige servere. Det sker ved at bruge webservices, der lever op til snitfladerne specificeret i WSRP. Standarden bekymrer sig næsten udelukkende om at hente data til præsentation og delegerer i stedet sikkerhedsproblematikker til de relevante standarder og protokoller, fx SSL/TLS [SSL], WS-Security [WS-Security] og SAML [SAML]. I de mest simple opsætninger med WSRP-portlets er sikkerhed ikke noget større problem. Det drejer sig fx om den klassiske vejrudsigt, der ikke er afhængig af en konkret bruger. Når en portlet skal vise brugerspecifik data, er det imidlertid en anden situation. Det kunne fx være en portlet, der viser en brugers skattekort fra SKAT. I det tilfælde skal portletten kende brugerens identitet, fx repræsenteret ved CPR-nummer eller lignende, og i en sådan situation hjælper WSRP i sig selv ikke, da standarden indeholder ikke umiddelbart indbyggede muligheder for at propagere en brugers identitet fra en portal til en portlet, og det er derfor nødvendigt at udvide opsætningen med andre protokoller eller standarder for at understøtte denne slags scenarier. Denne rapport gennemgår en række forskellige profiler, der alle forsøger at løse problemet med at udveksle brugeridentifikation sikkert mellem portal og portlet. Når vi i denne rapport bruger begrebet brugeridentifikation eller bruger-id, så menes der en nøgle, der identificerer brugeren i den rolle, som brugeren optræder i. En privat-person vil således kunne blive repræsenteret ved vedkommendes PID eller CPR-nr., mens en virksomhedsmedarbejder også vil blive identificeret ved den virksomhed, som vedkommende repræsenterer. Den danske SAML profil til brug indenfor det offentlige i Danmark [DK-SAML], specificerer hvilke personspecifikke oplysninger, der kan og skal udveksles mellem webservices. Generelt kan det siges, at for at identificere en bruger (en borger, et firma, eller en medarbejder) dikterer denne profil, at flere attributter skal udveksles, og at attributterne kan variere alt efter om der er tale om en privatperson eller en medarbejder i et firma. Den overordnede strategi for at identificere en bruger er, at brugere autentificeres ved hjælp af en SAML 2.0-baseret Identity Provider (IdP). Identity Provideren sørger for, at brugere logges ind via fx digital signatur, og gør det også muligt at implementere single signon (SSO) på tværs af domæner [SAML-Profiles]. 6

7 Figur 1: WSRP-opsætning Figur 1 viser hvordan de basale kommunikationsafhængigheder er i en opsætning, der anvender en SAML 2.0 IdP. For det præcise flow i strukturen henvises til afsnittet om SAML på side 6. Det vigtige her er, at en bruger i kraft af sin browser kommunikerer med en portal (pil nr. 1) og en IdP (pil nr. 2). IdP'eren sørger for, at browseren er autentificeret, og portalen kan få en garanti for, at brugeren er blevet korrekt autentificeret. Portalen kan så vise indhold fra forskellige portlets. Indholdet hentes via WSRP (pil 3) fra WSRP portlet containers, der hver især kan indeholde et antal forskellige portlets. Eftersom der ikke er direkte kontakt mellem portlet og browser, har en portlet ikke umiddelbart samme garanti for brugerens identitet som portalen selv har. Problemet er, at der ikke automatisk opbygges en sikkerhedskontekst, der dækker hele systemet, og brugerens identitet propageres derfor ikke rundt. Hvis portal og portlet er udviklet af de samme og hostes i samme miljø, er det formentligt ikke noget større problem. I sådanne tilfælde må det antages, at der er fuld tillid mellem portalen og den enkelte portlet, så hvis portalen angiver, at den har fat i en autentificeret bruger, så kan en portlet stole på, at det faktisk også er tilfældet. Hvis en portlet imidlertid udstilles for en bredere skare, i det ekstreme tilfælde stilles til rådighed på internettet som en frit tilgængelig WSRP-portlet, kræver det mere at etablere den nødvendige tillid. Basalt set er der to måder at gøre det på: Enten ved at sikre, at kun godkendte portaler får adgang, eller ved at kræve et eller andet form for bevis for, at portalen rent faktisk har fat i en autentificeret bruger. Den første metode kan håndteres ved fx firewalling, krypterede forbindelser og lignende. Den anden metode kræver typisk en tredjepart, som portletten stoler på, og som udsteder et uafviseligt bevis for, at brugeren er korrekt autentificeret til at bruge portletten via portalen. Hvad er sikkerhed? Sikkerhed er allerede blevet nævnt flere gange, men i virkeligheden er det ikke et entydigt begreb, og derfor er det relevant at opdele begrebet i nogle mere konkrete elementer: Autentifikation: Sikring af at brugerens identitet er kendt og bekræftet. Autorisation: Når en bruger er identificeret, hvad har brugeren så adgang til? o Adgang til en bestemt service: Hvem må tilgå en service, fx en WSRP-portlet? Transportsikkerhed: Her er spørgsmålet hvordan selve transporten af data foregår. Sker det fx over en krypteret linje, og er det muligt for andre at ændre i det sendte data? Privacy: Sikring af privatlivets fred hvem må få adgang til personfølsomme oplysninger, fx CPR-nummer, og må systemer samkøre data uden brugerens godkendelse? Uafviselighed: Sikring af, at afsenderen af en besked ikke efterfølgende kan afvise at have afsendt beskeden. Denne analyse beskæftiger sig ikke direkte med at løse udfordringerne ved autorisation-aspektet og går ikke i dybden med privacy-aspektet, da det ligger udenfor analysens rammer. 7

8 Rapportens forudsætninger Rapporten er lavet ved en afsøgning på internettet. For at sikre at de opstillede profiler med rimelighed vil kunne implementeres på gængse portal-produkter, er der også lavet flere afprøvninger på Oracle Portal, der har dannet udgangspunktet for de opstillede profiler. Der er dog ikke lavet et decideret Proof of Concept af de enkelte profiler, da målet har været en mere teoretisk gennemgang, og den reelle produktunderstøttelse er derfor ukendt. Rapportens opbygning Analysen fortsætter med en kort gennemgang af SAML for at skabe en fælles forståelse af, hvad SAML er. Så kommer en kort oversigt over hvor udviklingen indenfor anvendelsen af SAML er på vej hen. Derefter kommer en gennemgang og sammenligning af forskellige profil-alternativer, og endelig en opsamling og overordnet gennemgang af de forskellige portalprodukters understøttelse for de teknologier, profilerne er baseret på. 8

9 Introduktion til SAML > SAML står for Security Assertion Markup Language. I dette afsnit vil vi kort beskrive hvad SAML er, og hvordan det bruges i forbindelse med autentifikation af brugere på webservices [SAML- Tech][SAML-Exec]. Kort fortalt er SAML en mekanisme til at udveksle information om brugeroplysninger, herunder identifikation, autentifikation og vilkårlige attributter. SAML er en XML-standard, og gør det muligt at kommunikere denne form for oplysninger på tværs af domæner og platforme. Standarden er bygget til at blive integreret og evt. konkretiseret i andre standarder, fx er Shibboleth og Liberty Alliances standarder baseret på SAML. I sig selv er SAML ikke andet end et XML-format for, hvordan brugeroplysninger struktureres. Det XML-dokument, der indeholder brugeroplysningerne kaldes en SAML assertion. En SAML assertion er typisk udstedt af en identitets-udbyder efter forespørgsel fra en service-udbyder, som illustreret på figur 2. Ud over brugerens identitet indeholder en SAML assertion typisk også oplysninger om, hvordan brugeren er blevet autentificeret (fx via password eller digital signatur) og et interval for, hvornår oplysningerne er gyldige. IdPen vil også typisk signere en assertion, og således stille garanti for indholdet i denne. I den aktuelle situation er indholdet af SAML assertions fastlagt i [DK-SAML]. Figur 2: Autentifikation via IdP I relation til WSRP-opsætningen fra figur 1, så er brugeren stadig repræsenteret i opsætningen igennem en browser. Service Provideren er her den portal, som brugeren vil logge ind på (fx borger.dk), mens IdPen også er den samme altså fx en landsdækkende service, som kan autentificere brugere og udstede SAML assertions. Portletterne er ikke involverede i autentifikationsprocessen. De skal i stedet for kommunikere med portalerne og få deres brugeroplysninger derigennem og det er netop denne proces, som denne rapport fokuserer på i de efterfølgende afsnit. I flowet fra figur 2 bliver en bruger autentificeret på en portal (en Service Provider) ved først at forsøge at tilgå portalen (pil 1). Da brugeren (browseren) ikke er logget ind på portalen i forvejen, bliver han videresendt til en IdP (pil 2), der fortager en autentificering af brugeren fx ved password- eller digital signatur-tjek. Når brugeren har bekræftet sin identitet overfor IdPen, udsteder IdPen en SAML assertion til brugeren, som brugeren så kan videresende til portalen (pil 3) som bevis for sin identitet. Selve autentifikationensprocessen er ikke en del af SAML-specifikationen, men ofte forekommende mekanismer er login med brugernavn/password eller certifikatbaseret login. 9

10 Med denne SAML assertion fortæller IdPen således hvem brugeren er. Den kan det også specificere, hvordan brugeren er blevet autentificeret, og hvor længe autentifikationen gælder. Denne SAML assertion kan være signeret af IdPen, og hvis portalen har tillid til IdPens oplysninger, kan den således på den baggrund logge brugeren ind. I dette flow er det portalen, der starter autentifikationsprocessen ved at omdirrigere den ikkeautentificerede bruger til IdPen. Det er også muligt at få IdPen til at starte denne proces. Dette alternative flow kan bruges, hvis brugeren logger ind på IdPen og derfra tilgår portalen. Dette flow vil vi dog ikke behandle nærmere i denne rapport. Ved at bruge en SAML assertion som informationsbærer af bruger-autentifikationsoplysningerne, sikres det, at disse oplysninger bliver udvekslet på en standardiseret og ensartet måde, således at der opnås uafhængighed mellem portaler, når brugeroplysninger skal udveksles. Bemærk dog, at SAML assertionen ikke i sig selv gør dette scenarie sikkert, da SAML kun fungerer som informationsbæreren. IdPen holder styr på, at brugeren er logget ind (via en lokal cookie), samt hvem der har fået udstedt assertions. Når brugeren forsøger at tilgå en ny serviceudbyder, hvor brugern ikke allerede er logget ind, så kan denne serviceudbyder kontakte IdPen (via brugerens browser). IdPen kan ud fra den lokale cookie genkende brugeren og automatisk udstede en ny SAML assertion til den nye serviceudbyder, uden at brugeren behøver at indtaste autentificeringsoplysninger igen. Således skal brugeren kun indtaste autentificerings-oplysninger én gang for at få adgang til flere services, og brugeren vil således opleve et Single Signon system. Når brugeren (automatisk) er blevet autentificeret overfor den nye serviceudbyder, kan denne serviceudbyder logge brugeren ind og etablere en lokal session. Herefter behøver serviceudbyderen ikke at kontakte IdPen mere for at interagere med brugeren. Anvendelsesscenarier Med SAML følger en række profiler, der beskriver forskellige anvendelsesscenarier. Det drejer sig bl. a. om den netop beskrevne Web Browser Single Signon (SSO) profil, der er et af de primære anvendelsesscenarier for SAML. Profilen er en standardiseret beskrivelse af, hvordan en bruger, ved at logge ind på én serviceudbyder, efterfølgende automatisk kan blive logget ind på flere andre serviceudbydere. Dette letter brugerens arbejdsgang, da brugeren således slipper for at skulle logge ind, hver gang han tilgår en ny service. Grundideen bag SSO scenariet er, at når en serviceudbyder kontakter IdPen, og brugeren allerede har autentificeret sig ved denne IdP, så kan IdPen autentificere brugeren overfor serviceudbyderen uden at skulle interagere med brugeren, fx ved at kræve at brugeren indtaster brugernavn og password. En anden profil er Single Logout [SAML-Profiles], indført med SAML 2.0, der er modparten til Single Signon her bliver brugeren på én gang logget ud fra alle servicerne, der benytter den aktuelle IdP. 10

11 Single Logout giver en brugeroplevelse af, at der logges ud fra alle systemer på én gang. IdPen holder her styr på, hvor brugeren er blevet logget ind, og når der kommer en anmodning om logout, sender IdPen requests til alle services om, at brugeren skal logges ud. De enkelte services får hermed mulighed for at terminere de lokale sessions. Federated Identity er en tredje profil, der er specificeret for SAML. Den kan bruges, hvis der er behov for, at flere uafhængige services eller programmer skal skabe en tilstand, hvor de kan samarbejde og er enige om brugerens identitet. En bruger vil typisk have en personlig konto ved flere serviceudbydere, og Federated Identity tilbyder så en måde, hvorpå disse serviceudbydere kan skabe en fælles bruger-identifikationsnøgle og sammenkoble denne til brugerens personlige konti ved de enkelte udbydere. På denne måde skabes der et grundlag for, at serviceudbyderne automatisk kan dele information om brugeren og dermed begrænse behovet for interaktion med brugeren. Denne profil vil kunne bruges til at dele brugerinformation mellem flere forskellige portaler og lette sammenkædning af data. Der eksisterer også en række andre profiler [SAML-Profiles], der er en del af SAML-standarden. Fælles for alle profilerne er, at de konkretiserer nogle ofte forekommende anvendelsesscenarier, så de kan implementeres ens på tværs af domæner. Specifikationen af en profil er bygget op efter en bestemt skabelon, så de alle har den samme struktur. Vi vil nu se på, hvilken udvikling, der er indenfor SAML. 11

12 Udvikling og trends indenfor SAML > SAML kommer, som beskrevet ovenfor, med et antal forskellige profiler. Der mangler dog en profil for propagering af sikkerhedsoplysninger til en bagvedliggende service alle de eksisterende profiler omhandler scenarier, hvor en bruger kommunikerer med en række serviceudbydere. I disse tilfælde har brugeren mulighed for at sende SAML assertions rundt til serviceudbyderne, og serviceudbyderne kan via IdPens signatur i disse assertions få sikkerhed for brugerens identitet. I mange tilfælde er det dog ikke nok. Det oftest forekommende tilfælde er, at en serviceudbyder, det kunne fx være en portal, har behov for at kommunikere med andre udbydere på vegne af brugeren. I det aktuelle tilfælde skal en portal hente præsentation fra et antal WSRP-portlets, og disse portlets vil også gerne kunne have sikkerhed for brugerens identitet. Hvis portletproduceren ikke har fuld tillid til portalen, så vil den ikke kunne stole på portalens beskeder, med mindre der i beskederne er stillet garanti for indholdet af en 3. part, som portletproduceren har tillid til. Problemet er, at portalen i princippet kan være en forfalsket portal, der forsøger at logge følsom data ud af produceren, ved at postulere at den agerer på vegne af en bruger. Der er ikke noget i SAML, der hindrer, at det kunne lade sig gøre at give den sikkerhed til portletten i form af en SAML assertion fra en 3. part, men den præcise mekanisme er endnu ikke standardiseret i en profil, hvilket betyder at understøttelsen for propagering af brugeridentitet må forventes at være meget svag. Et eksempel på hvordan denne understøttelse kan opnås, er beskrevet i det følgende afsnit. Derefter følger en kort beskrivelse af 2 initiativer, der søger at standardisere eller implementere tilsvarende løsninger. WSRP uden fuld tillid mellem portal og portletproducer Figur 2: IdP-signerede beskeder bruges hele vejen Den sikreste løsning er den, hvor en WSRP-portlet kan få en konkret garanti for, at portalen agerer på vegne af en bruger, der er korrekt autentificeret hos en velkendt og pålidelig IdP, til at bruge netop denne WSRP-portlet gennem den aktuelle portal, som det er vist på figur 2. Hvis det 12

13 er tilfældet, kan portletten operere uden at kræve fuld tillid til portalen, da portalen ikke vil være i stand til at udstede en sådan garanti det er kun IdP'en, der kan det. Det er naturligvis stadig muligt for portalen at opsnappe data, der vedrører autentificerede brugere, og derfor er et vist tillidsforhold formentligt stadig nødvendigt, men det vigtige er, at autentifikationsmekanismen mellem portal og portlet ikke længere beror på maskinautentifikation (fx ved brug af firewall, certifikater eller anden statisk konfiguration), men i stedet bygger på, at hver enkelt brugers identitet er velkendt og garanteret. I dette scenarie er det ikke en SAML assertion kun udstedt til portalen, der sendes rundt. En sådan assertion vil være for generel og vil for let kunne misbruges. I stedet udsteder IdPen udstede mere specifikke assertions, der autentificerer brugeren til at bruge en bestemt portal og en bestemt række portletter. Liberty Alliance ID-WSF Liberty Alliance [LA] startede som et initiativ, der skulle løse de problemer, SAML efterfølgende har løst, nemlig: kommunikation af brugeroplysninger, autentifikation, single signon oplysninger mv. Liberty Alliance lagde grundlaget for SAML, og bruger nu SAML 2.0 som den underliggende specifikation for deres udvidelser. En af specifikationerne fra Liberty Alliance er ID-WSF (Identity Web Service Framework) [ID-SPEC], der nu er i version 2.0. Som andre specifikationer fra Liberty Alliance, bygger den på SAML 2.0, og den definerer en profil for, hvordan webservices kan interagere med hinanden. En del af dette er en profil for, hvordan identitetsbaserede webservices kan kommunikere, altså på en sikker måde udveksle SAML-beskeder, i stil med måden beskrevet i sidste afsnit. Dette er beskrevet i [IDWSF] som ID-WSF SAML Token Service Profile, der beskriver, hvordan en IdP kan udstede SAML assertions, der kan bruges når en serviceudbyder skal kommunikere med en anden, som det fx er tilfældet i en WSRP- baseret portal. ID-WSF er en færdig specifikation, der kan implementeres, men det store problem i forhold til WSRP er, at det er portalerne og portletcontainerne, der skal understøtte den, hvorfor ID-WSF ikke er et oplagt valg til at implementere WSRP sikkerhed. SOSI Et dansk initiativ, der søger at løse samme problematik indenfor sundhedssektoren, er SOSI (ServiceOrienteret SystemIntegration) [SOSI]. Projektet har til formål at udføre konkrete forsøg med at implementere sikre webservices. Det sker ved at udnytte eksisterende standarder, herunder OCES [OCES] og SAML, til at implementere single signon, brugerautentifikation og -autorisation, uafviselighed mv. Projektet har primært fokus på sundhedssektoren, men mange af principperne kan uden problemer overføres til andre sektorer. Det tekniske design er beskrevet i [SOSI-TEK], og beskriver hvordan den tekniske løsning ser ud. Det interessante i WSRP-portal-sammenhæng er, at løsningen fokuserer på at sikre system-system-kommunikation, altså fx den kommunikation der sker mellem portal og WSRP-producer. Der er altså andre, der arbejder på problemstillingen med at webservices kan have behov for at kende brugerens identitet. Men da dette arbejde ikke er færdigt og mundet ud i en standardiseret profil, så kan vi ikke pt. arbejde videre med SOSI projektet. 13

14 De ovenstående profil-tiltag er blot eksempler på, hvordan denne opsætning kan implementeres, og der er endnu ingen konsensus omkring, hvilken profil der vil blive understøttet i de forskellige portalprodukter i fremtiden. 14

15 Profiler > I dette kapitel vil vi se på en række profiler, der kan sikre sikker overførsel af bruger-id mellem portaler og portletter. Vi starter med at beskrive hovedmålene ved disse profiler, hvorefter vi beskriver de enkelte profiler. Hovedmål De hovedmål som profilerne skal opfylde er beskrevet i dette afsnit, sammen med de retningslinier, der er fælles for alle profilerne for at opnå disse mål. Single Signon De opstillede profiler skal muliggøre Single Signon, som det er beskrevet i den danske SAML 2.0 profil for Single Signon indenfor det offentlige [DK-SAML]. Single Signon virker overordnet som beskrevet i afsnit 2, og fokuserer på login af brugeren på portalen. Når først brugeren er logget ind på portalen, må portletterne ikke kræve yderligere login [OIM-WSRP], hvorfor portletterne skal få informationen om brugeren via portalen. Bruger-id skal således sendes automatisk til portletten. Den anvendte teknik til at overføre bruger-id vil være profil-specifik, og vil blive beskrevet nærmere under hver enkelt profil. I forhold til WSRP, er forbindelsen mellem portal og portlet som udgangpunkt tilstandsløs, men lige som med normal HTTP kan der etableres tilstand i form af en session. Denne session er forskellig fra den normale session mellem portal og browser på den måde, at den først oprettes i det øjeblik, portletten anvendes af brugeren første gang. Da en portlet ikke kan kommunikere direkte med browseren, vil det ikke give mening at koble autentifikationen af en bruger sammen med WSRP- sessionen. Den måde autentifikation normalt foregår på er, at en given side på en server er beskyttet, og når brugeren besøger den første gang, bliver brugeren omdirrigeret til en login-side enten lokalt eller hos en IdP. Når brugeren er korrekt logget ind, sættes en attribut i brugeren session, og der gives adgang til de beskyttede sider. I forhold til WSRP er dette flow ikke muligt, da en portlet ikke har mulighed for at omdirrigere brugeren på samme måde. Den eneste holdbare løsning er at sende autentifikationsoplysningerne i alle requests, og dermed holde kommunikationen tilstandsløs. Single Logout Den danske SAML profil [DK-SAML] muliggør Single Logout fra portaler, som beskrevet i afsnit 2.1. Denne funktionalitet skal også fungere når en portal gør brug af WSRP-portletter. Som beskrevet ovenfor, så er kommunikationen mellem portal og portlet tilstandløs, og der er derfor ingen autentifikationssession, der kan eller skal termineres. Single logout har derfor ingen betydning i forhold til WSRP, da det udelukkende er et spørgsmål om, at portalens sessions termineres. Autentifikation mellem portal og portlet. Et afgørende punkt indenfor sikkerheden i en WSRP-opsætning er, at der er oprettet tillid mellem portalen og portletten. Uden at kunne stole på at, andre services ikke misbruger den tilsendte information, så bør personfølsom information slet ikke udveksles. Denne tillid kan initieres ved, at der udarbejdes en juridisk kontrakt mellem portal og portlet, der bekræfter dette gensidige tillidsforhold og at de vil overholde detaljerne i den valgte profil. 15

16 Når først der er oprettet et gensidigt tillidsforhold mellem portal og portlet, så kan portalen og portletten udveksle følsom information, såfremt de kan autentificere hinanden. Dette kan fx ske ved hjælp af SSL/TLS certifikat-tjek og brug af firewall. Autentifikation af brugeren Vi har allerede diskuteret hvordan brugeren kan blive autentificeret på portalen vha. en IdP og SAML Single Signon profilen. Et andet centralt spørgsmål er, hvordan der opnås autentificering af brugeren på portletten. Da brugeren ikke kommunikerer direkte med portletten, så må denne autentifikation ske gennem portalen, og autentifikationen af brugeren bygger således på tillid mellem portalen og portletten. Da mulighederne for at misbruge en opsnappet SAML-assertion er til stede og kan være en alvorlig trussel imod systemets sikkerhed, bør al transport af SAML assertions ske over sikre linjer. Dette er dog ikke i sig selv nok til at hindre, at en SAML assertion kan blive opsnappet. Den kan fx stadig blive opsnappet gennem huller i den lokale sikkerhed fx ved brugeren eller på portalen. Derfor bør mulighederne for at misbruge en opsnappet SAML assertion ligeledes forsøgt hindret, fx ved at give en SAML assertion kortest mulig tidsgyldighed typiske kun nogle få minutter [DK-SAML] samt begrænse mængden af følsom information i en SAML assertion. Modtageren af en SAML assertion bør sikre at tidsgyldigheden er overholdt, og afvise SAML assertions, der er udløbet. Ligeledes bør modtageren sikre, at en bestemt SAML assertion kun bliver accepteret én gang, og derefter ikke bliver genbrugt således bør den heller ikke videresende den til andre serviceudbydere [Cons]. Derfor bør en SAML assertion udstedt af en IdP for én bestemt bruger til én bestemt portal ikke videresendes til øvrige serviceudbydere. Denne assertion bør kun bruges, til at brugeren kan dokumentere sin identitet overfor portalen. Da den SAML assertion, som portalen har fået af IdPen, ikke bør bruges til andre formål, bør denne assertion ikke bruges direkte af portalen imod portletten, og derfor kan IdPen heller ikke stille garanti for brugerens identitet overfor portletten i form af en digital signatur. Optimalt fik portalen IdPen til at udstede en ny assertion, der autentificerer brugeren til at bruge den aktuelle portlet gennem den aktuelle portal, men dette er ikke en mulighed i øjeblikket se afsnit 3.1. Selv hvis IdPens assertion alligevel sendes direkte videre, vil der hurtigt opstå muligheder for fejl. Et oplagt eksempel er hvis en bruger logger på portalen via SAML, men venter med at tilgå en bestemt portlet til IdPens assertion er udløbet. Eftersom udløbstiden er relativt kort, er det ikke et urealistisk scenarie, og det vil resultere i, at portletten afviser IdPens assertion, og brugeren kan dermed ikke anvende portletten. Bruger-id'et må således sendes på andre måder. I de enkelte profiler diskuterer vi forskellige muligheder for at udveksle dette bruger-id. Fortrolighed For at opnå fortrolighed mellem portal og portlet, og hindre, at sendte assertions opfanges, og evt. ændres uden at modtageren kan opdage eller forhindre det, skal data sendt mellem portal og portlet sikres. For at sikre fortrolighed i kommunikationen mellem portal og portlet, skal al følsom kommunikation mellem parterne krypteres. Dette kan opnås ved at benytte SSL 3.0 eller TLS 1.0, eller alternativt WS-Security. [WSRP10] 16

17 Privacy Denne rapport omhandler de teknologiske udfordringer, der er ved at få en portal (fx borger.dk) til at agere på vegne af en vilkårlig bruger (fx en dansk statsborger). Når dette er teknisk muligt opstår det politiske spørgsmål om, hvorvidt det er ønskværdigt at have et sådan setup. Når en portal kan agere på vegne af en bruger, og der skal skabes et miljø, hvor flere serviceudbydere kan samarbejde og udveksle og sammenkøre data, så vil der kunne opstå flere problematiske scenarier, hvor der sker udveksling og sammenkørsel af private oplysninger, uden at borgeren har kendskab til denne udveksling eller har givet tilladelse til at denne udveksling sker. Der er således, ud over de tekniske udfordringer, også en række politiske udfordringer, der skal tages højde for i sådan et setup. Dette er sikkerhedsspørgsmål som fx federations og privacy skal alle portlets fx have brugerens fulde identitet, eller kan de nøjes med et alias, så brugerens informationer ikke kan kobles sammen på samme måde? Og i hvor stor udstrækning skal brugeren have kendskab til den sammenkobling af data, der finder sted? Pga. risikoen for huller i sikkerhedsopsætningen, vil der altid være en risiko for, at brugeroplysninger kan blive opsnappet, hvorfor kun relevant brugerinformation bør videresendes fra portalen. Ligeledes bør brugeren orienteres når følsomme informationer overføres og udveksles, og give samtykke til at dette sker, og den udvekslede information bør afspejle dette. Der er dog pt. ingen understøttelse af denne slags brugervalg i de aktuelle Identity Provider'ere, omend der arbejdes på det fx i form af CARML (Client Attribute Requirement Markup Language) projektet [CARML][Hunt][CARML-spec]. Et andet bud på, hvordan privacy kan opnås er Shibboleth, der arbejder med at udveksle brugerattributter mellem services [SHIB]. I [Considerations] foreslås at IdPen håndtere dette problem ved at bruge forskellige bruger-id'er imod de forskellige portaler/servicesudbydere, således at portalerne/servicesudbyderne ikke kan sammenkøre deres data. Denne løsning kan dog ikke hindre, at én portal kan sammenkøre bruger-oplysninger fra flere forskellige portletter, og det hjælper heller ikke på transparens i forhold til, at brugeren kan se, hvilke oplysninger der sendes hvorhen. Audit-log Retningslinierne for brug af WSRP i den Fællesoffentlige Integrationsmodel [OIM-WSRP] foreskriver, at der udføres logning af hændelser for at kunne spore misbrug. Hændelser omfatter i denne sammenhæng forespørgsler og svar sendt mellem portalen og de anvendte portletter. Retningslinjerne foreskriver at følgende logges: (1) Tidspunkt for hændelsen, (2) Identifikation af den person der udfører hændelsen, og evt. dennes arbejdsstation, (3) Formålet med hændelsen, (4) Reference til den information, hændelsen omfattede. Referencen til den omfattede information skal muliggøre, at man kan finde frem til hvilken bruger- information, som hændelsen omfattede. Der er flere forskellige parametre, der sendes fra portletten til portalen, og uændrede tilbage igen, der muliggør, at portletten kan opretholde et tilstandsbegreb overfor brugeren. Ud over de forespørgsel- og svar-specifikke oplysninger, der sendes, så bør disse tilstandsoplysninger også logges, så de specifikke oplysninger kan sættes i kontekst. Der er her tale om (1) Navigational state: En parameter, der angiver portlettens tilstand. (2) Transient state: Herunder (2a) Interaction State, der svarer til inputparametre til portlettens operationer. (2b) Session state, der er IDet til portlettens interne session for brugeren og (3) Persistent state, der angiver registreringen mellem portalen og portletten. Herunder (3a) Consumer Registration (registrationhandle) og (3b) Portlet (portlethandle). 17

18 Da loggen kan indeholde følsom information, skal den beskyttes imod uautoritseret adgang. Portalen og portletten har hver især ansvar for logning af hændelserne. For blot at kunne spore misbrug af systemet fra brugerens side (misbrug gennem brugernes browsere), er det tilstrækkeligt at logge alle indgående beskeder til portalen og portletterne, hvilket også vil være den letteste form for logning at implementere. Ønskes det også at kunne spore misbrug fra en 3. part, fx fra en part, der indskyder falske beskeder eller ændrer beskeder i kommunikationen mellem portalen og portletterne, så vil det også være nødvendigt at logge udgående beskeder fra portalen og portletterne, da det således er muligt at sammenholde loggen af indgående og udgående beskeder og hermed spore 3. partens beskeder. Hvis al kommunikation mellem portalen og portletterne i forvejen sker på sikre linjer, burde denne form for 3. parts misbrug dog ikke kunne finde sted, og logning af indgående beskeder er således tilstrækkeligt. Når der er retningslinjer der forskriver logning, så vil det medføre et ansvar der pålægges portalen, hvilket vil gøre den tungere at implementere og vedligeholde. Profil-oversigt og -opbygning Der er forskellige muligheder for at implementere sikkerhed når der anvendes WSRP. Disse muligheder konkretiseres i det efterfølgende i 4 profiler: SAML Token Profil: Bruger-id sendes som et SAML token. WSRP Profil: Baseres på at bruger-id sendes i et selv-standardiseret felt i selve WSRP-requestet. Dette er den teknisk simpleste løsning, og stiller ikke store krav til portalen. HTTP-profil: Brugeri-id sendes i almindelige HTTP-headers. Username Token Profil: Bruger-id sendes i et WS-Security Username Token. Hver profil er karakteriseret ved nogle egenskaber: En mekanisme til autentifikation mellem portal og portlet. Fortrolighed mellem portal og portlet. Udveksling af brugeridentifikation. Krav til portal og portlet, herunder krav til WSRP-version. Generelle fordele og ulemper. I nogle af profilerne sendes bruger-id'et kun som én attribut, i modsætning til [DK-SAML], der beskriver en række af attributter til at identificere borgere, virksomheder, og medarbejdere. I disse profiler vil det således være nødvendigt at indføre en enkelt identifier, der kan bruges som identifikation. Dette kunne evt. være en sammenskrivning af de i [DK-SAML] krævede attributter til én enkelt streng-repræsentation. Ingen af profilerne implementerer den løsning, der er skitseret i afsnit 3.1, hvor der ikke er krævet fuld tillid mellem portal og portlet. Det skyldes primært, at der i profilerne er taget udgangspunkt i, hvad der er praktisk muligt i de eksisterende portalimplementationer, og dette sætter nogle relativt store begrænsninger. En af de væsentlige ting, der i øjeblikket er adskilt fra portal-portlet-sikkerheden er, hvordan brugeren er blevet autentificeret i første omgang. Som portalimplementationerne er bygget op lige nu, er der ingen direkte sammenhæng mellem brugerautentifikationen og det WSRP-request, 18

19 der sendes til en portlet. Det betyder, at selvom der bruges SAML 2.0 på portalen til at logge brugeren ind, og der bruges SAML 2.0 til at kommunikere med en portlet, så er det to helt forskellige assertions, der sendes rundt, og den garanti for brugerens identitet, som portalen får fra IdP'en, kan derfor ikke leveres videre til portletten. Nedenfor er en gennemgang af de tre profiler, og derefter kommer en sammenligning og opsamling over de tre. SAML Token Profil I afsnit argumenterede vi for, at den originale SAML assertion fra IdPen ikke bør videresendes direkte til øvrige services. Indholdet i SAML assertionen kan dog godt blive sendt videre i en SAML assertion, som portalen laver, og evt. signerer. Således bliver indholdet i den nye SAML assertion i stedet garanteret af portalen, og brugeren af indholdet af den nye SAML assertion må derfor også blot bero på modtagerens tillid til den udstedende portal. Lad os således gentage os selv fra introduktion af kapitel 2: SAML er kun en repræsentationsform til bruger-identitets-oplysninger. En (signeret) SAML assertion i sig selv stiller ingen garantier. Fx er det ikke til at vide om en bruger er blevet logget ud igen, siden en SAML assertion blev oprettet. Om man vil stole på indholdet af en SAML assertion må hvile på, om man har tillid til afsenderen og den der har udstedt og signeret den pågældende SAML assertion. Profil bruger en ny SAML assertion til at transportere bruger-id. Det sker uafhængigt af WSRP ved at inkludere en assertion i selve webservice-kaldet. Denne assertion indeholder i det aktuelle tilfælde bruger-id i et Subject som NameIdentifier. NameIdentifier er en del af SAML-specifikationen. NameIdentifier har en Format-attribut, der bestemmer indholdet af feltet. Feltet skal være en simpel tekst, og kan dermed kun indeholde en enkelt værdi. Ud over denne værdi kan der i assertionen være en AttributeStatement, der indeholder yderligere attributter. Denne assertion udveksles under forudsætning af, at modtageren (WSRP-produceren) stoler på portalen, da det er portalen, der selv laver den aktuelle SAML assertion. Der er ingen IdP, der stiller garanti for brugerens identitet. Dette angives ved at oplysningerne sendes i en SAML assertion, der indeholder en ConfirmationMethod, der er sat til sender-vouches. Det betyder basalt set, at du kan stole på denne besked, hvis du stoler på udstederen (Issuer) og på den (Sender) der har signeret beskeden. Et eksempel på en sådan assertion kan ses her: <saml:assertion MajorVersion="2" MinorVersion="0" xmlns="urn:oasis:names:tc:saml:2.0:assertion" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" AssertionID="WV3P0XqCp5qSA62wwffquQ22" IssueInstant=" T13:54:33Z" Issuer="myPrivateIssuer"> <saml:conditions NotBefore=" T13:54:33Z" NotOnOrAfter=" T13:56:33Z"/> <saml:authenticationstatement AuthenticationInstant=" T13:54:33Z" AuthenticationMethod="urn:oasis:names:tc:SAML:2.0 :am:password"> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameidformat:unspecified"> </saml:nameid> <saml:subjectconfirmation> <saml:confirmationmethod> 19

20 urn:oasis:names:tc:saml:2.0:cm:sendervouches </saml:confirmationmethod> </saml:subjectconfirmation> </saml:subject> </saml:authenticationstatement> </saml:assertion> I dette tilfælde er brugerens id sat til , og afsenderen meddeler desuden, at brugeren er autentificeret ved hjælp af brugernavn og password. For at mindske mulighederne for misbrug af en SAML assertion, bør tidsgyldigheden begrænses til nogle få minutter [Cons]. Her er den sat til at gælde fra 13:54:33 til 13:56:33. En SAML assertion kræver altså, at der er et tillidsforhold mellem afsenderen og modtageren, da beskeden ikke indeholder andre oplysninger om brugeren end brugerens id. I et mere sikkert scenarie ville der være en besked fra IdP'en inkluderet, så modtageren kunne være sikker på, at brugeren rent faktisk var blevet autentificeret det korrekte sted. Som tidligere nævnt understøttes dette ikke af nogen af de eksisterende portalimplementationer, og derfor baseres SAML-profilen på sender-vouches- metoden. Mekanisme til autentifikation mellem portal og portlet I tilfælde af at der anvendes WS-Security, kan autentifikationen mellem portal og portlet opnås ved at checke, at beskederne er signeret med en godkendt signatur. Det er formentligt ikke alle, der understøtter filtrering på enkelte signaturer, så det vil være relevant at implementere maskinautentifikationen ved hjælp af enten SSL-signaturer og/eller firewalling. Fortrolighed mellem portal og portlet Sikring af data mellem portal og portlet kan sikres enten ved at signere og kryptere indholdet af de enkelte beskeder ved hjælp af WS-Security/XML-signaturer og WS-Security kryptering eller ved at anvende SSL. Da SSL også kan anvendes som autentifikationsmekanisme, er det oplagt at basere fortrolighed på SSL også. Udveksling af brugeridentifikation Brugeridentifikationen sendes i en SAML assertion i et NameID-felt og evt. med attributter i AttributeStatement. ConfirmationMethod sættes til sender-vouches, og beskeden signeres. Hele SAML- beskeden sendes mellem portal og portlet i SOAP-headeren, indlejret i WS-Security. Krav til portal og portlet Det er naturligvis et krav til portal og portlet, at de er i stand til at opbygge og modtage SAML assertions. Som angivet er formatet SAML 2.0-specifikt, men de tilsvarende elementer findes også i SAML 1.1, og det vil dermed være nok at kræve SAML 1.1. Der er ingen specifikke krav til, hvilken version af WSRP der anvendes. Både WSRP 1.0 og 2.0 nævner SAML som understøttende standarder, der kan anvendes i kombination med WSRP for at overføre brugeroplysninger. Fordele og ulemper Det er en klar fordel, at brugeridentifikationen overføres som en uafhængig del af WSRP-requestet, og at det sker på en standardiseret måde via SAML, da overførslen således ikke 20

21 er begrænset til kun at indeholde brugernavn (og evt. password), men kan udvides til vilkårlige brugerspecifikke oplysninger. Dette vil fx være nødvendigt, hvis alt informationen fra [DK-SAML] skal udveksles. Det største problem ved denne (og de øvrige) profiler er, at modtageren af et request skal have fuld tillid til, at afsenderen har autentificeret brugeren korrekt. I afsnit 3.1 omtalte vi forskellige profiler og forslag til, hvordan det kan løses, men ingen af disse er implementeret endnu i nogle af portalprodukterne. WSRP profil Denne profil er baseret på, at bruger-id udveksles via et standardiseret felt i det normale WSRP-request. Dette er den mest basale måde at udveksle brugeroplysninger på, hvorfor det også den mest begrænsede. Det primære spørgsmål i denne profil er, hvor bruger-id skal placeres. Der er tre muligheder: Som usercontextkey En extension, fx i RuntimeContext Som navigationalparameter UserContextKey WSRP-standarden definerer, at der i WSRP-requests kan medsendes en UserContext [WSRP10] En del af denne er en usercontextkey, som ifølge standarden er en nøgle til UserContext-objektet. Nogle portalimplementationer benytter dette felt til at transportere brugernavnet på den bruger, der er logget ind på portalen. Oracle Portal er en af de portaler, der anvender denne metode. Problemet er, at standarden også specificerer, at usercontextkey ikke må ændre sig for en given portlet-registrering (når en WSRP-portlet skal vises i en portal registreres den i portalen). Derfor kræver denne metode, at der registreres en portlet pr. bruger noget som WSRP er forberedt på, men portalerne formentligt ikke understøtter. Noget andet uhensigtsmæssigt i denne sammenhæng er, at WSRP-portlets ofte implementeres som almindelige JSR-168-portlets, der så udstilles gennem WSRP (fx via WSRP4J [WSRP4J], som det er tilfældet med virk.dk). Det betyder, at der ikke er adgang til de ekstra-informationer, der er i WSRP, og som ikke er i JSR-168. Et eksempel på dette er, at i WSRP kan portalen specificere hvordan brugeren er blevet autentificeret. Det sker ved at sætte userauthentication i RuntimeContext til fx wsrp:none eller wsrp:password. Der er ikke noget tilsvarende i JSR-168, og derfor går denne information ofte tabt, og det kan dermed være svært at se, om brugeren rent faktisk er autentificeret eller ej. For at gøre det endnu værre, indsætter nogle portaler et standardbrugernavn i usercontextkey når der ikke er nogen bruger Oracle Portal sætter fx PUBLIC ind, uden at der umiddelbart er mulighed for at ændre på værdien, og dermed er det svært generelt at skelne mellem den anonyme bruger og en autentificeret bruger. Extension Et alternativ til at bruge usercontextkey er at definere en extension i fx RuntimeContext. WSRP tillader, at der defineres udvidelser i de forskellige typer. I praksis sker det ved at definere den nye type i et XML-skema og så referere til den type. Det største problem ved sådan en løsning er igen portalunderstøttelse. For det første skal alle WSRP-requests modificeres, så de får vedhæftet den ekstra information, og for det andet skal modtageren hente informationen ud igen. At hente det ud er formentligt ikke lige så svært som at få det lagt i. Problemet med at lægge ekstra data i er, at de fleste portalimplementationer styres via en grafisk 21

22 brugergrænseflade, og det er meget begrænset hvad der er af muligheder for at skrive den nødvendige kode, der skal til for manuelt at tilføje feltet på request- niveau. NavigationalParameter I WSRP 1.0 kunne en portal medsende navigationalstate i requests. Dette repræsenterer en portlets tilstand, og svarer lidt til normal url-parametre i et GET-request. I WSRP 1.0 har portalen ingen forståelse af, hvad der ligger i navigationalstate, da det er genereret af portletten, og det sendes bare tilbage til portletten som det blev modtaget. WSRP 2.0 introducerer en NavigationalContext, der både kan indeholde en privat tilstand i stil med navigationalstate fra WSRP 1.0 og en række offentlige parametre, som portalen kan bruge, fx til at lave en kobling til andre portlets. I stedet for at lave en kobling til en anden portlet, kan portalen koble en parameter til den interne sikkerhedskontekst og på den måde placere bruger-id i en navigationsparameter. Sammenligning De tre muligheder har hver deres fordele og ulemper. usercontextkey benyttes allerede af nogle portaler til at transportere bruger-id, men det må forventes, at andre portaler bruger feltet til noget andet, da dette ville være helt i henhold til specifikationen. Hvis usercontextkey således allerede bruges af portalen (eller portletten), så vil denne fremgangsmåde ikke umiddelbart kunne implementeres. NavigationalParameter har den fordel, at flere portalimplementationer rent faktisk giver mulighed for at koble en parameter til en attribut i et objekt (fx Oracle Portal), og dermed er det muligt at trække det nuværende bruger-id ud fra portalen og sende det til en portlet. Således vil denne fremgangsmåde formentligt kunne virke i praksis på flere portaler. Ulempen er, at løsningen kræver WSRP 2.0. Den sidste mulighed, at bruge en extension, er formentligt den korrekte løsning under forudsætning af, at udvekslingen af bruger-id skal ske i selve WSRP-requestet. Problemet her er, at så vidt vides giver ingen af de nuværende portalimplementationer mulighed for at tilføje den slags til et WSRP-request, hvorfor denne løsning kan være vanskelig at implementere med de eksisterende portal produkter. Således ser ingen af ovenstående WSRP-profiler ud til at være oplagte valg, hvis den skal være umiddelbart implementerbar, og understøtte WSRP v1.0. Men hvis der skal satses på én af teknologierne må extensions være den mest fleksible, da den vil understøtte, at der fremsendes flere parametre, og under er en del af WSRP 1.0 specifikationen. Mekanisme til autentifikation mellem portal og portlet Denne profil er en simpel udvidelse af WSRP-standarden. Sikkerheden for, at kun godkendte portaler kommunikerer med produceren implementeres på transportniveau. Dette kan implementeres på to måder: Ved hjælp af firewalling og ved hjælp af certifikater. Fortrolighed mellem portal og portlet Som med autentifikation mellem portal og portlet, skal fortrolighed implementeres på transportlaget. I denne profil implementeres det ved at anvende en SSL-forbindelse mellem de to parter. 22

23 Udveksling af brugeridentifikation Da extensions er den mest egende af de tre onder, må denne profil bruge extenstions til at udveksle bruger-id i WSRP requestet. Krav til portal og portlet På trods af, at princippet bag denne profil er meget simpelt og angivet i WSRP 1.0 specifikationen, kan profilen alligevel give anledning til problemer, hvis den skal implementeres. Som tidligere nævnt, så er det et krav, at det er muligt at ændre i et WSRP-request inden det sendes afsted. Hvis det ikke er muligt, kan brugeridentifikationen ikke flyttes fra portalen til det ønskede sted i WSRP-requestet. Profilen stiller ingen krav til WSRP-versionen, så både WSRP 1.0 og 2.0 vil kunne fungere. Fordele og ulemper Generelt er det en ulempe at indlejre brugeridentifikationen i et WSRP-request, da standarden meget klart siger, at det er meningen at brugeridentifikation skal sendes ved hjælp af andre standarder, fx WS- Security eller SAML [WSRP10 afs. 11.2]. Nogle portaler har muliggjort, at brugeridentifikation sendes med indlejret i requestet, men der er ingen garanti for, at det sker på en ensartet måde. Hvis det skal gøres ensartet, er en extension det oplagte valg, men det kræver så at portalerne gør det muligt at ændre i requests. Til gengæld er løsningen ret simpel. Kryptering og adgangskontrol sker på transportniveau, og der er ingen krav til hvilken version af WSRP der anvendes. HTTP-profil De øvrige profiler fokuserer alle på at levere brugeroplysningerne i et XML-format over SOAP. Et lavpraktisk alternativ er at sende oplysningerne i HTTP-requestet i stedet. Det kan ske ved at definere specifikke headers for de forskellige attributter, og sende disse headers med hver gang der laves et WSRP-request. Et eksempel på et request med ekstra headers er vist nedenfor: POST /WSRP_v1_Markup_Service HTTP/1.1 Host: localhost User-Agent: OpenOffice X-DKSAML-Certificate-Serial-Number: X-DKSAML-PID: SOAPAction: urn:oasis:names:tc:wsrp:v1:getmarkup <env:envelope...>... </env> Eftersom HTTP-headers frit kan defineres, er det ikke noget problem at sende flere attributter dog er headers ikke velegnede til strukturerede data, som fx XML er det. Simple attributter som brugernavn og lignende attributter er dog ikke noget problem. Mekanisme til autentifikation mellem portal og portlet 23

24 Profilen gør ikke noget for at sikre, at kun godkendte portaler må snakke med en portlet, og dermed skal denne autentifikation sikres på anden måde. Den oplagte mulighed er at bruge SSL og/eller firewalling. Fortrolighed mellem portal og portlet Igen baserer denne profil sig på ren HTTP, og fortrolighed skal derfor sikres på et andet niveau. Den eneste reelle mulighed her er at køre SSL, eller at forbindelsen kører over en krypteret linje, fx VPN. Udveksling af brugeridentifikation Udvekslingen af brugeridentifikationen sker ved at indsætte HTTP headers, der indeholder de relevante oplysninger. Disse headers er specifikke for WSRP-området, og det er dermed ikke en generel mekanisme. Krav til portal og portlet I forhold til anvendelse af forskellige standarder, er dette den simpleste løsning, da den ikke kræver mere end det, der er i en almindelig webserver. Der er dog stadig brug for, at portalen indsætter de korrekte headers i WSRP-requests, hvilket vil være udfordringen i denne profil. Til gengæld er belastningen på portlets ikke så stor, da portlets ofte i forvejen har adgang til det rå HTTP-request, hvor de kan læse de relevante headers fra. Fordele og ulemper Den største fordel ved denne profil er, at den i forhold til anvende teknologier er meget simpel. Hvorvidt det er muligt at tilføje headers til et request fra en portal er uvist, men hvis der anvendes en proxy- løsning, som beskrevet senere, vil det kunne lade sig gøre. Ulemperne er så, at løsningen er meget lavpraktisk, og at der ikke anvendes standardiserede headers. Desuden vil det blive problematisk hvis der skal udveksles strukturerede data, da HTTP headers ikke er velegnede til det formål. Username Token profil Denne sidste profil bygger på ren Web Service Security (WS-Security eller blot WSS) [WSS]. SAML- profilen indeholdte mulighed for at sende beskeder signeret og/eller krypteret med WS-Security, men WS-Security har også en indbygget mulighed for at sende brugeridentifikation. Forskellen fra SAML er, at metoden er langt mindre fleksibel, da der kun kan sendes én attribut i WSS's bruger-id-felt. Men sålænge dette er tilstrækkeligt, kan denne profil også bruges. WSS sendes ligesom SAML assertions som en del af SOAP-headeren. Mekanismen til at transportere bruger-id er Username Token [WSS-UT], og et eksempel ser ud som følger: <wsse:security xmlns:wsse=" xmlns=" xmlns:env=" 24