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

25 env:mustunderstand="1"> <wsse:usernametoken wsu:id="poaddq5bhfyfodrshyvq6g22" xmlns:wsu=" <wsse:username> </wsse:username> </wsse:usernametoken> </wsse:security> Denne profil benytter sig således ikke af nogen SAML mekanismer overhovedet. Således kan der heller ikke medsendes andre oplysninger end brugernavn og evt. password. Username Token suppleres normalt af en XML-signatur, så det ikke er muligt at ændre i brugernavnet uden at det kan ses. Ligesom med SAML er denne metode uafhængig af, hvad der ellers sendes i SOAP-requestet, og metoden er dermed også anvendelig med både WSRP 1.0 og 2.0. Metoden har, ligesom de øvrige profiler, den ulempe, at der kræves fuld tillid mellem portal og portlet, da det er portalen selv, der udfylder Username Token og signerer beskeden. Mekanisme til autentifikation mellem portal og portlet Det er oplagt at benytte WSS selv til at implementere autentifikationen mellem afsender og modtager, da beskederne er signerede af portalen, og det er dermed muligt at se, hvor de kommer fra. Om de enkelte modtagere rent faktisk understøtter denne form for filtrering kan være mere tvivlsomt, og i så fald kan normal SSL anvendes, ligesom i de øvrige profiler. Fortrolighed mellem portal og portlet WSS kan både signere og kryptere, og hvis krypteringen slås til, er der fortrolighed mellem portal og portlet. Alternativt kan anvendes en normal SSL-forbindelse. Udveksling af brugeridentifikation Brugerens id sendes som en del af WSS-headeren ved at bruge Username Token. Der kan kun sendes et enkelt brugernavn, ikke andre attributter. Det er selvfølgelig muligt at kode en hel assertion som en enkelt streng, som kan sendes med i feltet, men det komplicerer modtagelsen af værdien, da modtageren skal afkode værdien for at genskabe den oprindelige assertion. Krav til portal og portlet Der stilles ikke nogen specifikke krav til, hvilken version af WSRP, der anvendes, da WSS fungerer ved at tilføje data til SOAP-headeren udenom WSRP, og dermed kan både version 1.0 og 2.0 bruges. Selve portalen skal være i stand til at overføre det autentificerede brugernavn til Username Token-feltet, og på modtagersiden skal WSS understøttes. Hvis der skal foretages adgangskontrol på baggrund af, hvem der har signeret et request, skal modtageren også understøtte denne form for filtrering. Fordele og ulemper I forhold til SAML er der kun en grund til at vælge WSS i stedet for SAML, nemlig at der ikke introduceres endnu en standard, med de konsekvenser for overskuelighed og fejlmuligheder, som det medfører. Metoden er simpel i sig selv, men WSS er en relativt kompliceret standard at implementere, og produktunderstøttelsen kan derfor variere. I modsætning til WSRP-profilen, transporteres brugernavnet dog på en standardiseret måde, og WSS-metoden må derfor betegnes som bedre end WSRP-profilen, på de portaler, der understøtter WSS. 25

26 Kort gennemgang af portalunderstøttelse Den følgende tabel viser en oversigt over hvilke WSRP portaler, der understøtter SAML og WS- Security, samt hvilken version af WSRP de understøtter. Gennemgangen fokuserer på netop disse punkter, da det er dem, de forskellige profiler bygger på, og oversigten giver dermed et overblik over, hvilke portaler, der understøtter hvilke profiler. Portalprodukter, der slet ikke understøtter WSRP er ikke medtaget. 26

27 Portal WSRP SAML WS- Security BEA 1.0, 2.0 WebLogic [B_intro], Portal [B_javadoc] Oracle Portal 1,0, 2.0 [O_new], [O_JDev] IBM Ja [WS_hb] WebSphere NetUnity (.Net) Liferay Portal (OS) Apache WSRP4J 1 (OS) StringBeans Portal (OS) SAP NetWeaver SharePoint Server 2007 exo platform (OS) uportal (OS) JBoss Portal (OS) Ja [NetUnity] Ja [LifeRay_WSRP] 1.0 [WSR4J], [WSR4J_2] 1.0, 2.0 [SB_w2], [SB_wsrp] 1.0 [SAP_wsrp] 1.0, kun consumer [SP_WSRP][SP_v1] Ja 2 [Exo_wsrp] Ja [up_faq] 1.0 [JBoss_wsrp] Ja [B_SAML] 1.1 [O_faq] 1.1 [WS_hb] Nej Ja [BEA_sec] Ja [O_faq] 1.0 [WS_hb] Ja [NET_Feat] Nej Nej Nej Nej Nej Nej Nej Nej Nej Ja [SAP_open] Nej [SP_search] Ja [SAP_open] Nej SAML over WS- Security Ja [B_as] Ja [O_WS] Ja, i Committee Draft [WS_hb] Nej Formentligt Nej Nej Nej Nej Nej Nej Nej Kun til SSO 3 [JBoss_SSO] Ja [JBoss_ws] Nej JetSpeed 2 (OS) Jahia 5 (Community Nej 4 Nej Nej Nej Nej (muligt via WSRP4J) Nej [J_search] Nej [J_search2] Nej Ed. Er OS) 27

28 Denne oversigt er ment som et hurtigt overblik over hvilke portaler, der understøtter hvilke teknologier relateret til sikkerhedsprofilerne. Oversigten er lavet ved en søgning på nettet efter producenternes produktark og dokumentation samt øvrige artikler om portalerne. Oversigten er ikke ment som en afdækkende analyse af hver portal, hvorfor et Nej i tabellen uden kilde-angivelse betyder, at det ikke umiddelbart var muligt at finde en side, der beskrev den nødvendige understøttelse. Flere portaler understøtter WSRP og/eller SAML uden at skrive, hvilke version de understøtter disse portaler har et Ja i den tilhørende kolonne. Det må antages, at disse portaler blot understøtter hhv. WSRP 1.0 og/eller SAML 1.0, da der ikke står andet. Generelt kan det siges, at der ikke er support for WSRP 2.0, SAML og WS-Security på mange af WSRP-portalerne. Support for SAML og WS-Security findes ligeledes kun i de store kommercielle portal-produkter og ikke i Open Source portalerne (angivet med OS i parentes). Hvis SAML og WS- Security support ønskes på en eller flere af disse portaler, så vil det først skulle udvikles. Under søgningen for SAML support blev der ikke konstateret support for SAML 2.0 i nogen af portalerne. SAML-profilen fra side 18 kræver heller ikke nogen features fra SAML 2.0 specifikationen, hvorfor dette ikke ses som et aktuelt problem, med mindre DK-SAML 2.0 profilen skal understøttes [DK-SAML]. Generelt virker det ikke som om, der er meget fokus på brugen af WSRP 2.0, SAML og WS-Security på portalerne, og markedet virker således umodent og ikke klart til at implementere sikkerhed på højt niveau mellem remote portlets. Profilsammenligning De fire profiler opfylder alle samme behov, nemlig behovet for at udveksle brugeridentifikation mellem portal og portlet. Måden de gør det på er dog forskellig, og hver har sine fordele og ulemper. Der er også nogle ligheder: Alle tre kræver fuld tillid mellem portal og portlet, da der ikke er en 3. part involveret, som kan bruges til at verificere, at brugeren rent faktisk er korrekt autentificeret. Alle tre skal også suppleres af en form for kryptering, enten over SSL eller WS-Security. Hvor WSRP profilen bruger en proprietær teknik til at overføre bruger-id, bygger SAML Token profilen på en standardiseret metode, der også er gyldig udenfor WSRP, nemlig NameIdentifier i et Subject. Ligeledes bruger WS-Security-profilen et standardiseret felt, Username Token. I forhold til standardisering og kommunikation mellem forskellige systemer, er SAML eller WS-Security derfor at foretrække, men prisen for at bruge dem er en væsentlig forøgelse af kompleksiteten i et system. I forhold til WSRP-profilen, er virkeligheden imidlertid, at eftersom autentifikationsoplysninger ikke er en del af WSRP, så er der stor variation i, hvordan det er implementeret. Nogle portaler bruger usercontextkey til at transportere bruger-id, mens andre bruger feltet til noget andet. Vi er ikke stødt på nogen portaler, der umiddelbart understøttede WSRP-extensions, og NavigationalParameters er en WSRP 2.0-feature. WSRP profilen virker dermed som en meget usikker løsning, der vil kræve en del arbejde i de forskellige portaler. Forskellen mellem SAML og en ren WS-Security-løsning er, at SAML er en generisk mekanisme til at udveksle brugeroplysninger, hvor WS-Security ikke er designet til det Username Token er en konvention, der er vedtaget efterfølgende, og som kun understøtter 28

29 udveksling af brugernavnet (og evt. password). SAML er derfor mere fremtidssikret, da den understøtter vilkårlige attributter. Den største ulempe ved SAML er, at det komplicerer systemet en del. SAML bruges oftest i forbindelse med WS-Security, som i sig selv er temmelig kompliceret. Implementationsdetaljerne skal selvfølgelig gemmes væk af portalerne, men det kan betyde, at det kun er de store portaler, der understøtter det. I næste afsnit er der en kort gennemgang af, hvad de forskellige portalprodukter understøtter. Endelig er der en teknisk simple løsning, HTTP-profilen, hvor information overføres ved hjælp af HTTP headers. I modsætning til SAML og WS-Security overføres informationerne på en ikke-standardiseret form, og det vil betyde at den indbyggede produktunderstøttelse er meget lav. Til gengæld er løsningen formentligt simpel at implementere, da den ikke kræver yderligere teknologier for at fungere. Hvad mangler for at profilerne kan tages i brug? De opstillede profiler burde virke i teorien, men hvorvidt de er mulige at implementere i en portal, er et mere åbent spørgsmål. Forfatterne af denne rapport har benyttet den viden, det har været muligt at indsamle om portalerne indenfor rammerne af de tilgængelige ressourcer, men denne rapport bygger alligevel på en række antagelser om, hvordan og i hvilken grad de eksisterende portalprodukter understøtter de forskellige teknikker, som SAML, WS-Security signering og kryptering, WSRP- extensions, mv. Et åbent spørgsmål er fx om det er muligt at lave en SAML assertion, der indeholder de ønskede oplysninger? Nogle portaler understøtter mulighederne via en brugervenlig, men ikke særligt fleksibelt grafisk brugergrænseflade, mens andre formentligt understøtter dem via forskellige mindre brugervenlige back- end hooks. Andre portaler giver formentligt slet ikke mulighed for at teknikkerne kan anvendes, medmindre de kodes direkte ind i portalen som det formentligt vil være muligt at gøre for alle Open Source portalerne. Et andet spørgsmål er, for de teknikker, der er understøttet, om de kan benyttes sammen i den aktuelle portal. Når en SAML assertion er lavet, kan den så specificeres til at blive sendt signeret og krypteret vha. WS-Security? Og er det overhovedet muligt at specificere hvad den skal bestå af? Hvis man står og skal implementere de af de angivne profiler, vil det formentligt være rart at vide til hvilken grad de forskellige portaler understøtter de forskellige teknikker og hvordan de enkelte profiler kan implementeres. Dette kan undersøges i praksis i en Proof of Concept (PoC) undersøgelse. En sådan undersøgelse ligger dog udenfor denne rapports rammer. Alternativer ved manglende teknologi-understøttelse Skulle en af profilerne blive valgt, uden at der bliver lavet en tilstrækkelig tilbundsgående PoC undersøgelse, og skulle det vise sig, at den ikke er mulig at implementere i de eksisterende produkter, så kan der være brug for en strategi for, hvordan bruger-id kan udveksles uden den nødvendige portalunderstøttelse. Her ser vi to umiddelbare muligheder: Den første er helt at undlade en profil, og lade portaler og portletterudveksle bruger-id på individuelle måder, der aftales mellem parterne, som det fx ses på sundhed.dk. Dette vil give nogle meget tungere portaler og portletter og tilhørende ekstraarbejde. 29

30 Alternativt kan en anden allerede kendt teknik anvendes for at få fx SAML-understøttelse: nemlig en proxy-løsning. Denne teknik ses allerede anvendt ved portlet-producere, der kan anvende en proxy, der pakker normale portlets ind som WSRP-portlets som vist på figur 3. Et eksempel på dette er WSRP4J, som kan pakke en JSR-168-portlet ind og gøre den tilgængelig via WSRP. På samme måde kunne der implementeres en generisk WSRP/SAML-proxy, der validerer og udpakker et SAML-request og sender det videre som et normalt WSRP-request, mens den placerer brugeridentifikationen et velkendt sted, så portletten kan aflæse det. Denne del er vist på figur 3 som Ingoing SAML proxy. Figur 3: WSRP/SAML proxy setup Samme koncept kunne bruges i forbindelse med afsendelse af requests fra portaler, der ikke understøtter SAML. Her er der tale om Outgoing SAML proxy på figur 3, hvor portalen konfigureres til at sende WSRP-requests til proxyen i stedet for direkte til produceren. Proxyen kan så konvertere det oprindelige request til et SAML-baseret request. Princippet er altså, at bruger-id sendes fra portalen på en portalspecifik måde, og proxyen transformerer derefter denne måde til et standard-request med SAML. Det bliver derfor nødvendigt at lave forskellige implementationer til forskellige portaler, da portalerne kan placere brugernavnet forskellige steder. En sådan løsning, hvor SAML implementeres ved hjælp af proxyer, har den klare fordel, at portaler og portlets ikke behøver at understøtte SAML direkte. Det bør ses som en overgangsmekanisme, men det gør det muligt at kræve, at kommunikationen mellem portal og portlet baseres på SAML, og de implementationer, der så ikke understøtter det, kan anvende disse proxyservere. Dermed er der også en yderligere fremtidssikring i tilfælde af, at det senere bliver nødvendigt udnytte SAML til at sende andre attributter end bruger-id, da proxyserverne igen kan stå for at konvertere mellem SAML og et ældre format. Det skal dog bemærkes at den skitserede løsning kan begrænses af, at de enkelte portaler ganske enkelt ikke giver mulighed for at tilgå den lokale sikkerhedskontekst programmatisk, eller at adgangen er så begrænset, at det ikke er muligt at genskabe en komplet assertion. 30

31 Konklusion > Vi har i denne analyse gennemgået forskellige profiler, der kan anvendes til at etablere en sikkerhedskontekst i forbindelse med WSRP. Profilerne har alle det til fælles, at de kræver fuld tillid mellem portal og portlet, og denne tillid bør etableres med omhu. SAML-profilen udnytter ikke det fulde potentiale i SAML, da der endnu ikke er etableret nogen standardiseret og understøttet profil for, hvordan identiteter propageres i en arkitektur, der ligner den der er tilfældet med WSRP. Profilerne bruger forskellige mekanismer til at transportere brugeridentifikationen mellem portal og portlet, og den mest fleksible er klart SAML-profilen, der til gengæld også er den mest komplicerede at implementere. Det afspejles i oversigten over portalprodukterne, hvor det er ret få, der understøtter WSRP og SAML. Især er det en mangel i open source-produkterne, hvilket betyder, at der stilles store krav til både portalerne og producerne, som vil blive nødt til at installere store og dyre løsninger for at understøtte SAML-profilen. En løsning på dette kunne være en SAML-proxy, der pakker et WSRP/SAML-request ud og sender det videre som et normalt WSRP-request, mens brugeroplysningerne placeres så de stadig er tilgængelige for portletten. Alternativet er helt at undlade en fælles sikkerhedsprofil, og lade portalerne og portletterne lave individuelle aftaler for udveksling af bruger-id. Hele sikkerhedsanalysen har også vist, at selvom WSRP er en relativt simpel standard, så øger sikkerhedsaspektet kompleksiteten meget. Simple portlets, der er uafhængige af en konkret bruger er simple at implementere og anvende, men lige så snart at der skal udveksles brugeroplysninger, bliver det kompliceret. Så længe portal og portlet udvikles i samme miljø er det ikke det helt store problem, da det er afprøvet af leverandøren på forhånd, men i et scenarie hvor der er et væld af forskellige portal- og portletimplementationer, som det er muligt ved remote portlets, er det en helt anden sag. Søgning på internettet viser desuden, at det ikke er muligt at finde konkrete erfaringer fra andre, der har forsøgt at køre et system baseret på WSRP i et sikkert og pålideligt miljø. Dette kan give anledning til, at tænke over, om det overhovedet er smart, at lave en profil til at sikre kommunikation mellem portal og portlet. Rækken af begrænsninger listet i denne rapport er betydelige, og det er et åbent spørgsmål, om portalerne er modne til at køre WSRP under et højt sikkerhedskrav, og om der, på et internationalt plan, overhovedet vil blive satset på at få udviklet portalerne i denne retning. Problemerne opstår som følge af satsningen på remote portlets frem for en mindre teknisk krævende portalløsning, der baserer sig på at linke ud til de enkelte serviceudbydere eller generelt når en service skal agere på vegne af en konkret bruger. Under alle omstændigheder bør et konkret Proof of Concept gennemføres før der laves en satsning på en konkret profil. Et sådant PoC vil kunne identificere de væsentligste forskellige i de forskellige portalprodukter, samt vise om profilen overhovedet kan bringes til at virke i et miljø med mange forskellige platforme. Desuden vil et PoC kunne frembringe værdifulde standardkomponenter og -opsætninger til platformene, så alle implementører ikke skal konfigurere alt fra bunden. Uden et PoC er der en stor risiko for, at opgaven med at implementere WSRP bliver for uoverskuelig for de forskellige portaler og leverandører, og at det senere viser sig, at den valgte profil alligevel ikke kan fungere på tværs. Andre behov i forbindelse med sikkerhed Vi har i denne analyse behandlet et antal forskellige emner i forhold til sikkerhed indenfor WSRP. Der er taget udgangspunkt i, at den danske single signon profil baseres på en SAML 2.0-løsning, og vi har fokuseret på at etablere en SAML-kommunikation mellem portal og 31

32 portlet som det første skridt på vejen. Det betyder ikke, at alle problemer er løst. Vi ser bl.a. behov for at se på følgende opgaver: Etablering af en national SAML-baseret IdP med tilhørende letvægtsmoduler, så det er simpelt at integrere vilkårlige services op imod den nationale IdP. Udvikling af bedre understøttelse for SAML på open source-platformene. Uden den nødvendige understøttelse bliver service-leverandører tvunget til at investere i store og tunge systemer. Implementation af proxy-løsninger, så SAML-understøttelse ikke nødvendigvis skal være indbygget i de forskellige services. Udformning og standardisering af SAML-profil til at propagere sikkerhedskontekst til webservices. Dette er formentligt relateret til arbejdet med Secure Token Service. Behandling af privacy-aspekterne ved at kunne sammenføre bruger-information på tværs af flere serviceudbydere. 32

33 Litteraturliste > B_as: BEA Systems, Security Policy Assertion Reference, 2007, B_intro: BEA Systems, Introduction to WSRP, 2007, B_javadoc: BEA Systems, Bea WebLogic Portal Server 10.0 JavaDoc, 2006, B_SAML: BEA, Establishing WSRP Security with SAML, 2007, BEA_sec: BEA Systems, Security Policy Assertion Reference, 2007, CARML: Jeff Erickson, Identity Governance Framework, 2007, CARML-spec: Phil Hunt, Client Attribute Requirements Markup Language (CARML) Specification, 2006 Cons: Hirsch, Philpott, Maler, Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0, 2005 Considerations: Hirsch, Philpott, Maler, Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0, 2005 DK-SAML: IT- og Telestyrelsen, SAML Profile for SSO in Danish Public Sector V2.0 - Draft July 2007, 2007 Exo_prob: Anonym, Exo WSRP stinks, 2005, / discussionitem_view Exo_wsrp: exp platform, Testing the EXO-PC WSRP producer, 2007, Hunt: Phil Hunt, SignOn.com and CARML, 2007, ID-SPEC: Liberty Alliance, Liberty Alliance ID-WSF 2.0 Specifications, 2007, ications IDWSF: Jeff Hodges, NeuStar, Inc. et al., Liberty ID-WSF Authentication, SingleSign-On, and Identity Mapping Services Specification, 2006 J_search: Jahia Ltd, Search result for "SAML", 2007, J_search2: Jahia Ltd, Search results for "ws-security", 2007, JBoss_SSO: jboss.org, JBoss Federated SSO, 2007, JBoss_ws: [email protected], JBoss.com - Wiki - WSSecurityFeatures, 2006, JBoss_wsrp: Julien Viet, Chris Laprun, Chapter 9. Web Services for Remote Portlets (WSRP), 2006, Jetspeed_home: Apache Software Foundation, Jetspeed 2 Enterprise Portal, 2007, 33

34 LA: Liberty Alliance, Home, 2007, LifeRay_WSRP: LifeRay, WSRP in Liferay, 2006, NET_Feat: NetUnity Software, NetUnity WSRP.Net Framework, 2004, NetUnity: NetUnity Software, NetUnity Software - WSRP Portal and WSRP Portlet Framework for.net, 2004, O_faq: Sandhya Rajput, Oracle Fusion Middelware - FAQ, 2006, O_JDev: Oracle, Oracle Webcenter 10g R3 Data Sheet, 2007, O_new: Oracle, OracleAS Portal New Features, 2004, O_WS: Oracle, WS-Security Authentication, 2007 OCES: IT- og Telestyrelsen, OCES - Digital Signatur, 2007, OIM-WSRP: Digital Forvaltning, OIM Bilag 3 WSRP v0.6 - Retningslinier for WSRP, 2007 SAML: Lockhart, Campbell, OASIS Security Services (SAML) TC, 2007, SAML-Exec: Madsen, Maler, SAML V2.0 Executive Overview, 2005 SAML-Profiles: Hughes, Cantor, Hodges, Hirsch, Mishra, Philpott, Maler, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, 2005, open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML-Tech: Ragouzis, Hughes, Philpott, Maler, Security Assertion Markup Language (SAML) V2.0 Technical Overview, 2006 SAP_open: SAP, SAP NetWeaver Standards Support: Open Standards, 2007, SAP_open: SAP, SAP NetWeaver Standards Support: Open Standards SAP_wsrp: help.sap.com, WSRP Application Sharing Mode, 2007, ntent.ht m SB_w2: Nabh Information Systems, StringBeans Version 3.2 API Documentation, 2006, SB_wsrp: Nabh Information System, StringBeans WSRP Implementation: An Overview, 2006, SHIB: Internet2, Shibboleth Project, 2007, SOSI: SOSI, ServiceOrienteret SystemIntegration, 2007, SOSI-TEK: Kåre Kjelstrøm, Jan Riis, ServiceOrienteret SystemIntegration - Teknisk Løsningsbeskrivelse, 2006 SP_search: microsoft.com, Søgte i SharePoint Server 2007 efter: "saml", 2007, 34

35 SP_v1: microsoft.com, Microsoft.SharePoint.Portal.WebControls.WSRPWebService Namespace, 2007, SP_WSRP: Microsoft, Microsoft Office SharePoint Server 2007 product overview, 2007, SSL: NetScape, SSL 3.0 Specification, 1996, up_faq: Bill Brooks, FAQ, 2007, WS_hb: Ueli Wahli, Owen Burroughs, Owen Cline, Alec Go, Larry Tung, Web Services Handbook for WebSphere Application Server 6.1, 2006 WS_hb: Ueli Wahli, Owen Burroughs, Owen Cline, Alec Go, Larry Tung, Web Services Handbook for WebSphere Application Server 6.1, 2006, WS-Security: OASIS, OASIS Web Services Security (WSS) TC, 2006, WSR4J: Apache Software Foundation, Welcome to WSRP4J, 2006, WSR4J_2: Diego, Nabble - wsrp4j 2.0?, 2007, WSRP: Thompson, OASIS Web Services for Remote Portlets (WSRP) TC, 2007, WSRP10: OASIS, Web Services for Remote Portlets Specification, 2003 WSS: OASIS, Web Services Security: 3 SOAP Message Security 1.14, 2004 WSS-UT: OASIS, Web Services Security UsernameToken Profile 1.0,

36 Center for Serviceorienteret Infrastruktur Center for Serviceorienteret Infrastruktur (CSI) blev oprettet 1. december 2006 for en periode på tre år. Centeret har til opgave at lede og facilitere opgaven med at producere en åben, national infrastruktur. Centeret har samlet en række af IT- og Telestyrelsens medarbejdere, der hidtil har arbejdet med forskellige aspekter af samme felt, herunder arbejdet med serviceorienteret arkitektur (SOA), brugerstyring og infrastruktur til e-handel.

37

38 <