Sikkerhedsanalyse af WSRP

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

Download "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="http://docs.oasis-open.org/wss/2004/01/oasis wsswssecurity-secext-1.0.xsd" xmlns="http://docs.oasisopen.org/wss/2004/01/oasis wss-wssecurity-secext-1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 24

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

Timeout-politik for den fællesoffentlige føderation

Timeout-politik for den fællesoffentlige føderation Side 1 af 8 7. november 2012 Timeout-politik for den fællesoffentlige føderation Dette dokument beskriver en politik for timeout af brugersessioner i den fællesoffentlige føderation, der er obligatorisk

Læs mere

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Sundhedsdatanettets Anatomi UNI-C Router Organisation A Router Router Organisation B Firewall Firewall Linjesikkerhed

Læs mere

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in (samt mulighed for FMK tilgang via SOSI STS) 15.marts 2017 /chg Baggrund Private aktører på sundhedsområdet som apoteker,

Læs mere

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet Digital Sundhed Brugerstyringsattributter - Introduktion - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Læsevejledning... 2 3. Aktører... 2 4. Autentifikation...

Læs mere

Teknisk Dokumentation

Teknisk Dokumentation Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...

Læs mere

Præcisering af transportbaseret sikkerhed i Den Gode Webservice

Præcisering af transportbaseret sikkerhed i Den Gode Webservice Præcisering af transportbaseret sikkerhed i Den Gode Webservice 1. Historik...2 2. Indledning...3 3. SSL/TLS baseret netværk...3 4. Sundhedsdatanettet (VPN)...5 5. Opsummering...6 6. Referencer...6 Side

Læs mere

Guide til NemLog-in Security Token Service

Guide til NemLog-in Security Token Service Guide til NemLog-in Security Token Service Side 1 af 10 18. juni 2014 TG Denne guide indeholder en kort beskrivelse af, hvordan en myndighed eller itleverandør kan benytte NemLog-in s Security Token Service

Læs mere

Sikker udstilling af data

Sikker udstilling af data Sikker udstilling af data Digitaliseringsstyrelsen 8. oktober 2012 Thomas Gundel Agenda Baggrund hvorfor udstille data? OWSA Model T Identitetsbaserede Web Services NemLog-in s fuldmagtsløsning OAuth 2.0

Læs mere

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks SOSIGW - Driftsvejledning for SOSIGW 1.0 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Kontrol af korrekt driftstilstand... 2 Ændring af statisk konfiguration... 2 Logfil... 2 Backup... 3

Læs mere

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 SOSI (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 Indhold Hvad og hvem er SOSI Visionen og Missionen Begreber, arkitektur og teknik Hvad er SOSI Projekt initieret og drevet af Ribe- og

Læs mere

Valg af webservice standard

Valg af webservice standard Valg af webservice standard Agenda Valg til en serviceorienteret infrastruktur Identitetsbaserede Services, Kåre Kjelstrøm Teknologiske trends og udfordringer Debat, spørgsmål og kritik Skal du lave en

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Certifikatpolitik for NemLog-in

Certifikatpolitik for NemLog-in Side 1 af 9 7. november 2012 Certifikatpolitik for NemLog-in Version 1.2 Dette dokument beskriver certifikatpolitikken for NemLog-in løsningen. Politikken definerer hvilke typer certifikater, der må anvendes

Læs mere

Certifikatpolitik. For den fællesoffentlige log-in-løsning. Side 1 af 9 2. december Version 1.1

Certifikatpolitik. For den fællesoffentlige log-in-løsning. Side 1 af 9 2. december Version 1.1 Side 1 af 9 2. december 2009 Certifikatpolitik For den fællesoffentlige log-in-løsning Version 1.1 Dette dokument beskriver certifikatpolitikken for den fællesoffentlige log-inløsning. Politikken definerer

Læs mere

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0.

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0. Side 1 af 12 19. september 2008 Autencitetssikring Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning Version 1.0. Denne vejledning introducerer problemstillingen omkring

Læs mere

Identitetsbaserede webservices og personlige data

Identitetsbaserede webservices og personlige data > Identitetsbaserede webservices og personlige data Version 0.8 IT- & Telestyrelsen juni 2009 Indhold > Indledning 3 Målgruppe 3 Afgrænsning 4 Definitioner og begreber 5 Scenarier 7 Scenarie med browser

Læs mere

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen -

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - spn@itst.dk Velkommen! Dette er en WORKSHOP Ikke et fintunet kursus!!

Læs mere

Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity Providere.

Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity Providere. Side 1 af 17 19. september 2008 Logningspolitik For den fællesoffentlige log-in-løsning Version 1.0. Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity

Læs mere

Den Gode Sårjournal Service MedCom, version W 1

Den Gode Sårjournal Service MedCom, version W 1 Den Gode Sårjournal Service MedCom, version 1.0.0 W 1 Den Gode Sårjournal Service Rettelser... 3 Formål... 4 Funktionalitet... 5 GetSignOnLink... 5 GetNumberOfUnreadNotes... 5 Bilag A: Specificering af

Læs mere

Analyse af udfordringer ved iframe integrationsformen

Analyse af udfordringer ved iframe integrationsformen Analyse af udfordringer ved iframe integrationsformen Version 0.8 9. april 2008 Portalintegrationsprojektet Se mere på www.modernisering.dk/integrationsmodel 1 INDHOLDSFORTEGNELSE INDLEDNING...4 1.1 BAGGRUND...

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. AUGUST 2013 Fil: DIADEM - Kom godt igang - Ver 1.7.0.docx Indhold 1.

Læs mere

Kald af PingService via SOAPUI

Kald af PingService via SOAPUI Kald af PingService via SOAPUI Author: Integration Expert Team (IET) Owner: Integration Expert Team (IET) Page 1 of 24 1. Dokumenthistorik Kald af PingService via SOAPUI Revisioner Dato for denne version:

Læs mere

DataHub Forbrugeradgangsløsning Spørgsmål og svar

DataHub Forbrugeradgangsløsning Spørgsmål og svar 9. Januar 2013 MEH/MHC DataHub Forbrugeradgangsløsning Spørgsmål og svar Dok 75938-12_v2, Sag 10/3365 1/7 1. Generelt 1.1 I hvilket omfang yder Energinet.dk support til elleverandørerne? Forretningskonceptet

Læs mere

Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1

Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1 Den Gode NationalePrøveNummer Service MedCom, version 1.0 W 1 MedCom, Den Gode NPN Service ver. 1.0 2 Den Gode NationalePrøveNummer Service MedCom version 1.0 Formål... 5 Introduktion... 5 Ansvar... 6

Læs mere

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Miljøportalsekretariatet Ref.: jejnb Den 22. november 2007 Baggrund I forbindelse med strukturreformen

Læs mere

23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring

23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring 23. maj 2013Klik her for at angive tekst. HHK/KMJ Vejledning til brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående

Læs mere

It-sikkerhedstekst ST9

It-sikkerhedstekst ST9 It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO)

Læs mere

ecpr erstatnings CPR Design og arkitektur

ecpr erstatnings CPR Design og arkitektur 1 ecpr erstatnings CPR Design og arkitektur Indhold ecpr erstatnings CPR... 1 Indhold... 2 Formål... 3 Overblik... 4 Snitflader... 4 Komponenter... 5 Webservice... 5 Statuskomponent... 5 Forretningslag...

Læs mere

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA 26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer,

Læs mere

Den Gode LÆ Service MedCom, version 1.0 W 1

Den Gode LÆ Service MedCom, version 1.0 W 1 Den Gode LÆ Service MedCom, version 1.0 W 1 MedCom, Den Gode LÆ Service ver. 1.0 2 Den Gode LÆ Service MedCom version 1.0 Formål... 5 Serviceudbyders Ansvar... 6 Tilgængelighed... 6 Funktionalitet... 7

Læs mere

Sikker mail Kryptering af s Brugervejledning

Sikker mail Kryptering af  s Brugervejledning Sikker mail Kryptering af e-mails Brugervejledning side 1/9 Indholdsfortegnelse 1 Introduktion... 3 2 Anvendelse (Quick start)... 3 2.1 Sikker e-mail... 3 3 Brugergrænsefladen (detaljeret)... 3 3.1 Send

Læs mere

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne > Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne IT- & Telestyrelsen, Kontor It-infrastruktur og Implementering februar 2010 Indhold > 1 Introduktion 4 1.1 Føderationsfordele

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017 Webservice kald System-til-system integration Ny Easy ATP 1. februar 2017 Side 1 of 9 Dokumenthistorik Revisionshistorik Dato for denne revision: 01.02.2017 Dato for næste revision ukendt Revisions Revisions

Læs mere

Security Token Service. Snitflade OIO WS Trust

Security Token Service. Snitflade OIO WS Trust Security Token Service Snitflade OIO WS Trust Side 1 af 7 Indholdsfortegnelse 1. Versionsnummer... 3 2. Snitfladebeskrivelse... 3 3. Servicebeskrivelse... 3 3.1 Identity provider... 3 3.2 Supported binding...

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

Privatlivsfremmende teknologier (PETs)

Privatlivsfremmende teknologier (PETs) Privatlivsfremmende teknologier (PETs) Appendiks 7 Håndbog i: Privatlivsimplikationsanalyse IT og Telestyrelsen INDHOLDSFORTEGNELSE Privatlivsfremmende teknologier... 3 Midler til imødegåelse af privatlivskrænkende

Læs mere

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark Digital post, NemSMS & Fjernprint samt strategien for udvikling af mobile løsninger for Digital post og Min side

Læs mere

DESIGNDOKUMENT (Teknisk dokumentation)

DESIGNDOKUMENT (Teknisk dokumentation) 29. feb.2016 version 1.2 Lægemiddelstyrelsens E2B Bivirkningsservice DESIGNDOKUMENT (Teknisk dokumentation) Dokument historik Version Dato Ændring 1.0 19-06-2014 Final version ifm. idriftsættelse 1.1 29-06-2015

Læs mere

Notat om Single sign-on for kliniske brugere af telemedicinsk sårvurdering i det nationale projekt for udbredelse af telemedicinsk sårvurdering

Notat om Single sign-on for kliniske brugere af telemedicinsk sårvurdering i det nationale projekt for udbredelse af telemedicinsk sårvurdering Notat om Single sign-on for kliniske brugere af telemedicinsk sårvurdering i det nationale projekt for udbredelse af telemedicinsk sårvurdering Baggrund I det nationale projekt for udbredelse af telemedicinsk

Læs mere

Produktbeskrivelse for. Min-log service på NSP

Produktbeskrivelse for. Min-log service på NSP Produktbeskrivelse for service på NSP Sundheds professionel Borger Fagsystem / Serviceudbyder Sundhed.dk 1 2 3 (Registreringsservice) (Konsolideringsservice) (Udtræksservice) Indeks Database (oprydning)

Læs mere

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed.

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed. Sikkerhedsmodeller for OIOREST Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø Telefon: 3545 0000 Fax: 3545 0010 Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/)

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

SOSI STS Testscenarier

SOSI STS Testscenarier SOSI STS Testscenarier Version 1.0.1 Status: Offentliggjort Indholdsfortegnelse 1 Introduktion... 2 1.1 Baggrund...2 1.2...2 1.3 Baggrundsmateriale... 2 1.4 Adgang...2 2 Test af STS Webservice... 4 2.1

Læs mere

Version 0.61 - Udkast

Version 0.61 - Udkast Side 1 af 22 14. januar 2007 Integrationstest ved føderationstilslutning Version 0.61 - Udkast Dette dokument henvender sig til offentlige myndigheder samt andre, der skal tilsluttes den fællesoffentlige

Læs mere

Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og Google Apps skoleløsning Version 1.0, 30.

Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og Google Apps skoleløsning Version 1.0, 30. Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og skoleløsning Version 1.0, 30. september 2010 Dette dokument giver et kort overblik hvordan brugeroplysninger i Odenses

Læs mere

Digitaliseringsstyrelsen

Digitaliseringsstyrelsen Nemlog-in Beskrivelse af Leverandørens Version: 2.c ID: 32309 2013-06-17 Indhold 1 INTRODUKTION... 3 2 TEST AF SERVICES... 4 2.1 NEMLOG-IN SSO/SLO... 4 3 TILSLUTNING AF SERVICE METADATA... 8 3.1 NEMLOG-IN

Læs mere

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering.

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering. Hvad er KRYPTERING? Kryptering er en matematisk teknik. Hvis et dokument er blevet krypteret, vil dokumentet fremstå som en uforståelig blanding af bogstaver og tegn og uvedkommende kan således ikke læses

Læs mere

Vilkår vedrørende brug af Støttesystemet Adgangsstyring

Vilkår vedrørende brug af Støttesystemet Adgangsstyring Vilkår vedrørende brug af Støttesystemet Adgangsstyring 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige

Læs mere

Ibrugtagning af Fødselsindberetningsservicen på NSP

Ibrugtagning af Fødselsindberetningsservicen på NSP Ibrugtagning af Fødselsindberetningsservicen på NSP Udarbejdet af: NSI Version: 1.0 Dato: 09.07.2013 Indholdsfortegnelse 1 Vejledning til ibrugtagning af Fødselsindberetningsservicen... 3 1.1 Læsevejledning

Læs mere

Sikkerhed i Stamdatamodulet KOMBIT

Sikkerhed i Stamdatamodulet KOMBIT Sikkerhed i Stamdatamodulet KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Oversigt... 4 3.1 Relevante OCES-detaljer... 4 4 Overholdelse af persondatalov mv.... 5 5 Importer...

Læs mere

Opsætning af Outlook til Hosted Exchange 2007

Opsætning af Outlook til Hosted Exchange 2007 Opsætning af Outlook til Hosted Exchange 2007 Sådan opsættes Outlook 2007 til Hosted Exchange 2007. Opdateret 29. december 2010 Indhold 1 Indledning... 2 2 Outlook 2007 klienten... 2 3 Automatisk opsætning

Læs mere

Administration af brugere vha. sammenhængende log-in

Administration af brugere vha. sammenhængende log-in Hvad er sammenhængende log-in? Danmarks Miljøportal Ref.: jejnb 21. august 2012 Formål Formålet med beskrivelsen er at skabe et overblik over sammenhængende log-in, som en nem og enkel måde at administrere

Læs mere

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for SUP-specifikation, version 2.0 Bilag 9 Sikkerhed og samtykke Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af indholdet kan gengives med tydelig kildeangivelse Indholdsfortegnelse 1 Introduktion...

Læs mere

IT Arkitekt Søren Peter Nielsen

IT Arkitekt Søren Peter Nielsen 2007 IT Arkitekt Søren Peter Nielsen ! " #$! % & & '() * Links og Clipping - Bruger überportal Anonym bruger Myndighedsportal A Myndighedsportal B Links og Clipping - Bruger überportal Login? Login? Med

Læs mere

Reducér risikoen for falske mails

Reducér risikoen for falske mails Reducér risikoen for falske mails Center for Cybersikkerhed 1 November 2017 Indledning Center for Cybersikkerhed oplever i stigende grad, at danske myndigheder og virksomheder udsættes for cyberangreb.

Læs mere

Bilag 2 Kundens IT-miljø

Bilag 2 Kundens IT-miljø Bilag 2 Kundens IT-miljø Indholdsfortegnelse 1. GENERELT... 2. KU S SYSTEMLANDSKAB OG INTEGRATIONEN TIL DETTE... 3. DATATILGANG... 4. SSO... 5. ADMINISTRATION AF BRUGERE OG BRUGERRETTIGHEDER... Side 2/5

Læs mere

SOSIGW. - Administrationskonsol for SOSIGW 1.0.6. Indeks

SOSIGW. - Administrationskonsol for SOSIGW 1.0.6. Indeks SOSIGW - Administrationskonsol for SOSIGW 1.0.6 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Administrationskonsollen... 2 Generel brug af konsollen... 3 Fremsøgning af ID-kort... 3 Søgning

Læs mere

Bilag WebService LoginModule (BSKAuth)

Bilag WebService LoginModule (BSKAuth) Regionshuset It digital forvaltning BSK programmet Olof Palmes Allé 17 Kontakt@regionmidtjylland.dk www.regionmidtjylland.dk Bilag WebService LoginModule (BSKAuth) Navn Web Service: LoginModule Metode/operation:

Læs mere

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation...

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation... Digital Sundhed Brugerstyringsattributter - Politikker - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Identifikation...... 2 2.1. Politik... 2 3. Sundhedsfaglig

Læs mere

Brugerskabte data en national service (BSD) - produktbeskrivelse

Brugerskabte data en national service (BSD) - produktbeskrivelse - 1 Brugerskabte data en national service (BSD) - produktbeskrivelse Brugerskabte data en national service (BSD) - produktbeskrivelse...1 Indledning...1 Formål...1 Beskrivelse...1 Basale krav til det bibliotek/website

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Contents 1 Introduktion 1 2 Arkitekturoverblik 3 2.1 Eksterne snitflader..................................................

Læs mere

UDSNIT 8. februar 2008

UDSNIT 8. februar 2008 UDSNIT 8. februar 2008 Dette udsnit indeholder indeholder en introduktion til hvad begrebet brugerstyring dækker over Kolofon: OIO Referencemodel for tværgående brugerstyring Dette baggrundsdokument kan

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013Klik her for at angive tekst. NOTAT Bilag 11: Anvenderkrav til adgangsstyring - Støttesystemerne Context handler, Security Token Service og Administrationsmodul (Bilag til dagsordenspunkt

Læs mere

SOSI Gateway Komponenten (SOSI GW)

SOSI Gateway Komponenten (SOSI GW) SOSI Gateway Komponenten (SOSI GW) - en security domain gateway Version 1.2 1/8 Indledning Region Syddanmark er udvalgt som pilotregion for projektet Det Fælles Medicingrundlag, og i den forbindelse arbejdes

Læs mere

Præsentation af BSK regionens identity and access management platform

Præsentation af BSK regionens identity and access management platform Regionshuset It digital forvaltning BSK programmet Olof Palmens alle 17 Kontakt@regionmidtjylland.dk www.regionmidtjylland.dk Præsentation af BSK regionens identity and access management platform BrugerStamdataKataloget

Læs mere

DataHub Forbrugeradgangsløsning NemID Quick Guide

DataHub Forbrugeradgangsløsning NemID Quick Guide 20. august 2012 JHH/MEH DataHub Forbrugeradgangsløsning NemID Quick Guide Dok 75936-12_v1, Sag 10/3365 1/6 Indhold 1. NemId/Digital Signatur... 3 2. Tjenesteudbyderaftaler... 3 2.1 Selve aftalen... 3 2.2

Læs mere

Hurtig og sikker adgang til sundhedsfaglige data. Esben Dalsgaard, chef it-arkitekt, Digital Sundhed

Hurtig og sikker adgang til sundhedsfaglige data. Esben Dalsgaard, chef it-arkitekt, Digital Sundhed Hurtig og sikker adgang til sundhedsfaglige data Esben Dalsgaard, chef it-arkitekt, Digital Sundhed Præsentationens fokus Megen fokus på hvordan der kan skabes lettere adgang til relevante sundhedsfaglige

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1. OKTOBER 2012 Fil: DIADEM - Kom godt igang - Ver 1.3.docx Indhold 1. INDLEDNING...

Læs mere

WSRP analyse Analyse af integrationsmetoder ved brug af WSRP

WSRP analyse Analyse af integrationsmetoder ved brug af WSRP WSRP analyse Analyse af integrationsmetoder ved brug af WSRP Udarbejdet af IT- og Telestyrelsen i samarbejde med EOS Eastfork Object Space ved Joakim Recht. Publikationen kan hentes på It- & Telestyrelsens

Læs mere

BESTILLING AF NEMID. For at bestille ny NemID vælger du www.nets-danid.dk. Vælg Bestil NemID medarbejdersignatur.

BESTILLING AF NEMID. For at bestille ny NemID vælger du www.nets-danid.dk. Vælg Bestil NemID medarbejdersignatur. BESTILLING AF NEMID For at bestille ny NemID vælger du www.nets-danid.dk Vælg Bestil NemID medarbejdersignatur. CVR nummeret trækker automatisk adressen fra CVR registeret, så den skal IKKE ændres. Bekræft

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

Kravspecification IdP løsning

Kravspecification IdP løsning Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige

Læs mere

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen NemHandel i cloud - sikkerhedsmæssige overvejelser Helle Schade-Sørensen IT og Telestyrelsen Agenda Lidt om NemHandel Rationalet for valg af cloud Overvejelser vedr. sikkerhed Løsning og erfaringer indtil

Læs mere

Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23

Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23 Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23 Formål Formålet med dette notat er at beskrive forskellige løsninger for kommunikationssikkerhed til brugerne af bibliotek.dk, med henblik

Læs mere

Føderal brugerstyring og SSO

Føderal brugerstyring og SSO Føderal brugerstyring og SSO Morten Strunge Nielsen 23. september 2010 Brugere bliver gns. provisioneret i 16 systemer og de-provisioneret i 10 Gns. bruger anvender 16 minutter pr. dag på login 38% af

Læs mere

2. Systemarkitektur... 2

2. Systemarkitektur... 2 Indholdsfortegnelse 2. Systemarkitektur... 2 2.1 Præsentationsserverarkitektur... 3 2.2 Applikationsserverarkitektur... 7 Version 7.0 Side 1 af 7 5. Systemarkitektur Arkitekturen for Nyt BBR bygger på

Læs mere

Vi vil ikke bruge eller dele dine oplysninger, undtagen de tilfælde som er beskrevet i denne fortrolighedspolitik.

Vi vil ikke bruge eller dele dine oplysninger, undtagen de tilfælde som er beskrevet i denne fortrolighedspolitik. Fortrolighedspolitik Effektiv fra: 8. november 2017 Introduktion Pagobox ApS ( "Pleo", "os", "vi" eller "vores") driver Pleo.io webstedet, Pleo webapplikationen, Pleo mobilapplikationen og tilbyder Pleo

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo Digitalisering med en Microsoft platformen Kenneth Wohlers, Agenda Sikker post Nye muligheder Vores løsning - VMG Scenarier Teknisk overblik Hvad er Sikker post Teknologi Certifikater Standarder Formål

Læs mere

Indberetning til eindkomst via SFTP. Folder: J:\Kunder\eIndkomst Projektdokumentation\SFTP\Vejledninger\EC SFTP_eIndkomst 2008-01-22.

Indberetning til eindkomst via SFTP. Folder: J:\Kunder\eIndkomst Projektdokumentation\SFTP\Vejledninger\EC SFTP_eIndkomst 2008-01-22. Indberetning til eindkomst via SFTP Forfatter: IBM Emne: Indberetning til eindkomst via SFTP Side 1 af 9 Dokumenthistorik Revisionshistorik Dato for denne revision: 22.01.2007 Dato for næste revision:

Læs mere

Vejledning om avanceret afhentning. i Digital Post på Virk.dk.

Vejledning om avanceret afhentning. i Digital Post på Virk.dk. Vejledning om avanceret afhentning og sortering i Digital Post på Virk.dk. Denne vejledning beskriver, hvordan virksomheder, foreninger m.v. med et CVR-nummer kan modtage Digital Post, herunder hvordan

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Forskellen på Chained root og Single root certifikater Denne vejledning vil prøve på at beskrive forskellen på et Chained root og et Single root udstedt certifikat. Derudover vil vi også forsøge at beskrive

Læs mere

Sådan fungerer Danmarks Miljøportal. en pixibog om infrastrukturen bag Danmarks Miljøportal

Sådan fungerer Danmarks Miljøportal. en pixibog om infrastrukturen bag Danmarks Miljøportal Sådan fungerer Danmarks Miljøportal en pixibog om infrastrukturen bag Danmarks Miljøportal Kort om Danmarks Miljøportal Danmarks Miljøportal giver adgang til mange forskellige fællesoffentlige data om

Læs mere

It-sikkerhedstekst ST6

It-sikkerhedstekst ST6 It-sikkerhedstekst ST6 Registrering af en fysisk person med henblik på udstedelse af faktorer til et personligt login Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST6 Version

Læs mere

Arbejdsgruppen vedrørende Beskyttelse af Personer i forbindelse med Behandling af Personoplysninger. Henstilling 1/99

Arbejdsgruppen vedrørende Beskyttelse af Personer i forbindelse med Behandling af Personoplysninger. Henstilling 1/99 5093/98/DA/endelig udg. WP 17 Arbejdsgruppen vedrørende Beskyttelse af Personer i forbindelse med Behandling af Personoplysninger Henstilling 1/99 om usynlig og elektronisk behandling af personoplysninger

Læs mere

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær.

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær. EfterUddannelse.dk FraværService - systemdokumentation BRUGERDOKUMENTATION: WEB-SERVICE Af: Logica Indhold 1. Indledning... 1 1.1 Formål... 1 1.2 Webservice version... 1 1.3 Historik... 1 2. Absence Webservice...

Læs mere

Digital Signatur Infrastrukturen til digital signatur

Digital Signatur Infrastrukturen til digital signatur Digital Signatur Infrastrukturen til digital signatur IT- og Telestyrelsen December 2002 Resumé: I fremtiden vil borgere og myndigheder ofte have brug for at kunne kommunikere nemt og sikkert med hinanden

Læs mere

E-BUSINESS SOLUTIONS FROM CSC! "

E-BUSINESS SOLUTIONS FROM CSC! E-BUSINESS SOLUTIONS FROM CSC! " Dette dokument beskriver e-tl kommunikationstest For at sikre en tidlig aftestning af forbindelsen fra eksterne parter til e-tl er der implementeret en række Web Services,

Læs mere

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Indholdsfortegnelse Indledning... 3 Systemkrav... 4 Installation af Citrix-klient... 5 Tilpasning

Læs mere

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3 Notat 21. februar 2017 Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3 Dette notat giver en overordnet konceptuel fremstilling af, hvordan erhvervsområdet forventes håndteret samlet

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

Læs mere

Brugermanual. PoP3 og Outlook Express Webmail www.321mail.dk. Udarbejdet af IT-afdelingen 2005

Brugermanual. PoP3 og Outlook Express Webmail www.321mail.dk. Udarbejdet af IT-afdelingen 2005 Brugermanual PoP3 og Outlook Express Webmail www.321mail.dk Udarbejdet af IT-afdelingen 2005 Indholdsfortegnelse 1. ÆNDRING AF OUTLOOK EXPRESS KONTO... 4 2. OPRETTELSE AF OUTLOOK EXPRESS KONTO... 6 2.1

Læs mere