Udgivet af: IT- & Telestyrelsen. IT- & Telestyrelsen Holsteinsgade København Ø. Telefon: Fax:

Størrelse: px
Starte visningen fra side:

Download "Udgivet af: IT- & Telestyrelsen. IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø. Telefon: 3545 0000 Fax: 3545 0010"

Transkript

1

2 Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade København Ø Telefon: Fax:

3 Sikkerhedsvejledning til OAuth sikkerhedsmodeller for OIOREST IT- & Telestyrelsen april 2011

4 Indhold > 1. Indledning 5 Baggrund 5 Formål 5 Målgruppe 6 Afgrænsninger 6 2. Principperne i OAuth 8 3. Scenarie med web server som klient 11 Sekvens ved dataudveksling 12 Dekobling af autorisations- og ressource server Implementeringsvalg 15 Autentifikation af klient 15 Sikring af transportkanalen 16 Autentifikation af servere 16 Autentifikation af bruger 17 Granularitet af adgang til ressourcer (scope) 18 Indhentning af brugerens accept 19 Ægthed af svar 21 Beskyttelse og validering af adgangsbilletter 22 Format af web service kald 22 Format af adgangsbilletter Lovgivning om persondata 25 Roller 25 Omfang af data, der udleveres 26 Samtykke fra brugeren 26 Transmission af persondata over åbne net Fællesoffentlig brugerstyring 28 Samspil med NemID og NemLog-in 28 Relation til identitetsbaserede web services Implementeringer 31 Facebook 32 Dailymotion Referencer 34

5 1. Indledning > Baggrund En række faktorer medfører et stigende behov for udstilling samt deling af data mellem tjenester på internettet - både indenfor den private og offentlige sektor. Som eksempler kan nævnes fremkomsten af sociale tjenester, mashups, Web 2.0, den voksende digitalisering af samfundet generelt - og den offentlige sektor specifikt. Data er et væsentligt råstof i digitale løsninger, og der er et meget stort potentiale i at udstille og genbruge dem på tværs af løsninger. Ved at udveksle data mellem tjenester er der mulighed for at øge datas værdi, sammenstille data på nye måder, skabe nye og innovative services og tjenester til gavn for brugerne, effektivisere arbejdsgange og muliggøre helt nye forretningsområder. Samtidig er der også en række potentielle farer og risici forbundet med at udstille og dele data i særdeles når der er tale om personlige data. Her opstår let udfordringer for brugernes sikkerhed og privatliv, hvis det ikke sker på en gennemtænkt og betryggende måde. Derfor opstiller lovgivningen en række krav, der bl.a. har til formål at værne og beskytte personlige data. Udover de juridiske barrierer for deling af data findes også en række teknologiske og forretningsmæssige barrierer, der hindrer realiseringen af det store potentiale. Formål OAuth er en protokol specificeret af Internet Engineering Task Force, som gør det muligt for én tjeneste at give andre tjenester adgang til brugerressourcer (eksempelvis brugeres data) under kontrol af brugeren. Ved at give brugeren kontrollen kan den enkelte selv afgøre, hvornår adgang til ressourcer tillades, fordi det giver værdi, eller hvornår adgangen skal forhindres. Dette er et meget fundamentalt mønster, som kan anvendes i talrige sammenhænge, hvor der indgår personlige ressourcer. Vejledningen har til formål at vise, hvordan man kan anvende OAuth på en sikker og forsvarlig måde, der lever op til god praksis samt lovgivning om persondata. Med andre ord er hensigten at være med til at nedbryde de tekniske, sikkerhedsmæssige og juridiske barrierer for deling af data. Vejledningen er en videreførelse af den tidligere vejledning Sikkerhedsmodeller for OIOREST (se [SIKMODEL]), og kan ses som en naturlig udbygning af dette arbejde. Den primære fordel ved OAuth i forhold til de tidligere beskrevne modeller er som nævnt, at brugeren med OAuth får direkte kontrol over hvilke af hans ressourcer, der delegeres adgang til. Udover at beskrive sikkerhed og implementeringsvalg i OAuth, kommer vejledningen også ind på persondataloven samt relationen til øvrige offentlige initiativer indenfor sikkerhed og brugerstyring. 5

6 Målgruppe Dokumentet henvender sig til udviklere, it arkitekter og projektledere, der har brug for tekniske råd og vejledning til de mange implementeringsvalg, der er forbundet med anvendelse af OAuth med særligt fokus på de sikkerhedsmæssige aspekter. I og med at der er mange åbne valg, er der også mulighed for at træffe mindre gode valg, der har uheldige konsekvenser, og derfor er vejledning relevant. Da forskellige applikationer har forskellige behov, opstilles der ikke normative retningslinjer. I stedet illustreres muligheder og konsekvenser ved de forskellige implementeringsvalg, således at læseren bliver i stand til at vælge de løsninger, der optimale for hans egen situation. Der fokuseres på anvendelse af OAuth indenfor den offentlige sektor eksempelvis i forbindelse med digitale selvbetjeningsløsninger til borgere eller virksomheder. Mange af diskussionerne har dog almen relevans og kan derfor også anvendes i andre sammenhænge. Afgrænsninger OAuth er beregnet til deling af brugernes egne data; ved deling af andre (ikkepersonlige eller ikke-sikkerhedsbelagte) ressourcer som eksempelvis kort eller adresseoplysninger, er OAuth ikke relevant. Der henvises til [SIKMODEL] for sikkerhedsmodeller, som er velegnede for sikkerhedsbelagte men ikkepersonlige data. Vejledningen behandler udelukkende tekniske- og sikkerhedsmæssige aspekter ved implementering af OAuth i en tjeneste. Forhold vedrørende drift og forvaltning af tjenester er således bevidst fravalgt, selvom de i høj grad kan være relevante i forhold til sikkerhed samt opfyldelse af lovgivning. Endvidere berøres forretningsmæssige aspekter mellem parterne ikke, eksempelvis i form aftaler, der regulerer anvendelsen af data, betaling samt servicemål (oppetider, svartider, kapacitet etc.). Det tilrådes, at der udarbejdes aftaler mellem parterne, der regulerer sådanne forhold men det er blot ikke formålet med denne vejledning at komme ind på disse emner. OAuth rummer en række forskellige scenarier med forskellige typer klienter. I denne vejledning fokuseres på klienter, der er web servere, da dette er hyppigst forekommende i den offentlige sektor. Mange af overvejelserne er dog også relevante for de andre scenarier som eksempelvis når klienten er en JavaScriptklient, der afvikles i en browser (User Agent), eller når klienten aktivt indhenter akkreditiver fra andre udstedere (Autonomous client) til brug for OAuth interaktion. 6

7 OAuth 2.0 versus OAuth 1.0 Vejledningen fokuserer på OAuth version 2.0, selvom denne i skrivende stund stadig er i draft status hos IETF. Dette valg er truffet på baggrund af, at specifikationen har været stabil i længere tid, og at en række store spillere indenfor området allerede har implementeret den, hvilket ligeledes formodes at være et tegn på en vis modenhed. De fleste overvejelser i vejledningen er desuden af overordnet karakter, som formentlig ikke påvirkes, hvis specifikationen ændres på detailniveau. Dog kunne ændring af protokollens sikkerhedsmæssige design få betydning, men dette vurderes mindre sandsynligt. Såfremt OAuth 2.0 ændres på væsentlige punkter i den videre standardiseringsproces, vil der blive udgivet en opdatering til denne vejledning, som adresserer ændringerne. 7

8 2. Principperne i OAuth > Dette kapitel introducerer kort principperne, der ligger til grund for designet af OAuth protokollen, således at læseren kan få et indblik i motivationen for protokollen. OAuth er udsprunget af konkrete erfaringer og udfordringer med at dele brugerdata mellem web sites på internettet eller mere generelt ønsket om delegeret adgang til brugernes ressourcer 1. Særligt er erfaringer fra sociale tjenester som Twitter og Facebook samt andre internetpionerer som Google blevet inddraget. I arkitekturen opereres med flg. aktører (de engelske termer fra OAuth specifikationen er anført med kursiv): Bruger (Resource Owner / User) Brugeren er en person, som anvender applikationer hos forskellige tjenesteudbydere og ejer personlige ressourcer hos disse (eksempelvis brugerdata). Klient (Client) Klienten er den software (f.eks. web applikation eller portal), som brugeren interagerer med, og som har behov for at tilgå brugerens ressourcer hos en anden part (ressource serveren). Autorisationsserver (Authorization Server) Autorisationsserveren interagerer med brugeren og indhenter brugerens accept af, at hans ressourcer må tilgås af klienten. Ressourceserver (Resource Server) Ressource serveren er den part, der udstiller brugerens ressourcer (eksempelvis brugerdata) overfor andre tjenester, og som kun giver adgang, hvis autorisationsserveren har sagt god for det (via brugerens accept). Ofte vil autorisationsserver og ressourceserver høre til samme tjenesteudbyder således at den part, der varetager brugerens ressourcer, selv indhenter brugerens accept til, at de må tilgås af eksterne parter. I mere avancerede scenarier kan de to roller blive spillet af forskellige parter gennem etablering af et tillidsforhold, hvilket der gives eksempler på senere i vejledningen. 1 I det følgende anvendes termen ressource om de data eller objekter, som der ønskes etableret en delegeret adgang til. Dette kan eksempelvis være at læse eller opdatere brugerens data hos en fremmed tjeneste. 8

9 Før OAuth blev introduceret, var det udbredt praksis på mange web sites, at applikationer, der skulle tilgå ressourcer fra et andet site, bad brugeren om at indtaste sit brugernavn og kodeord til tjenesten, hvorefter applikationen kunne logge på som brugeren og derefter tilgå de ønskede ressourcer. Denne praksis er stærkt problematisk, idet brugeren fuldstændig mister kontrollen: Der gives fuld adgang til alle ressourcer brugeren kan ikke delegere adgang til specifikke ressourcer eller i et begrænset tidsrum. Tjenesten kan impersonere brugeren, idet den nu er besiddelse af brugerens kodeord. Dette kan både ske som en del af tjenestens virkemåde eller hvis brugerens kodeord opsnappes af hackere eller interne medarbejdere. Jo flere tjenester brugeren deler sit kodeord med, jo større er risikoen for misbrug og identitetstyveri. Brugeren kan ikke tilbagekalde sin accept på anden måde end at skifte kodeord og da vil det påvirke samtlige applikationer, der anvender kodeordet. Andre (og stærkere) autentifikationsmekanismer end brugerid + kodeord er ikke mulige herunder eksempelvis digital signatur. 9

10 Som svar på disse udfordringer blev OAuth protokollen designet ud fra følgende principper: Brugeren (ressourceejeren) adskilles logisk fra klienten / applikationen, som vil tilgå ressourcen. Brugeren skal ikke udlevere sine credentials (eksempelvis password) til klienten for at hans ressourcer kan deles. Brugeren ejer sine ressourcer. Brugeren har kontrol over fremmede tjenesters adgang til hans ressourcer via eksplicit autorisering. Autorisationer er specifikke og tidsbegrænsede. Overførslen af data kan ske på en privacy-venlig måde, således at kun de nødvendige, formålsrelevante data videregives til klienten, og så klienten ikke får kendskab til brugerens id, password eller andre unødvendige oplysninger hos ressourceserveren. Den server, som autoriserer, at ressourcer tilgås, er logisk dekoblet fra den server, hvor ressourcerne er placeret. I praksis drives de dog ofte af samme organisation. 10

11 3. Scenarie med web server som klient > I dette kapitel beskrives det mest almindeligt forekommende scenarie med delegeret adgang via OAuth, nemlig hvor brugeren anvender en internet browser og tilgår et web site, der ønsker at tilgå brugerens ressourcer (f.eks. hente brugerdata) hos et andet web site. Det første web site agerer dermed i rollen som klient og det andet web site som ressource server. Et eksempel på dette scenarie kunne være, at en bruger er i færd med at ansøge om et lån i en netbank, hvor netbanken ønsker at hente brugerens seneste årsopgørelse hos SKAT med henblik på at kreditvurdere brugeren. Et andet eksempel kunne være en bruger, der gerne vil ansøge om friplads i en daginstitution, hvor applikationen til brug for sagsbehandlingen ønsker at hente oplysninger om vedkommendes børn hos CPR registret. Figur 1: Roller og interaktioner i web scenarie 11

12 Sekvens ved dataudveksling Nedenstående figur viser i detaljer sekvensen mellem parterne, når klienten første gang forsøger at tilgå en ressource: Figur 2: Sekvens når klient er web server Sekvensen består af flg. trin: a) Klienten sender brugerens browser til autorisationsserveren for at indhente brugerens accept til, at data kan hentes. I kaldet medsendes en klient ID, en beskrivelse af hvilken adgang der ønskes til hvilke ressourcer (scope), samt en URL hvor browseren skal sendes tilbage til, når interaktionen med autorisationsserven er ovre. b) Autorisationsserveren autentificerer brugeren og indhenter dennes accept af, at klienten senere må hente de data, der er blevet forespurgt om. c) Hvis brugeren accepterer at hans ressourcer tilgås, sendes browseren tilbage til klienten sammen med en autorisationskode (access code) ellers sendes en fejlkode. d) Klienten sender en forespørgsel om en adgangsbillet (access token) og autentificerer sig i kaldet samt og inkluderer autorisationskoden fra sidste trin. e) Autorisationsserveren validerer kaldet og udsteder en adgangsbillet til at tilgå ressourcer, hvis alt er ok. f) Klienten kalder nu ressource serveren med henblik på at tilgå de ønskede brugerressourcer. I kaldet medsendes adgangsbilletten fra sidste trin. 12

13 g) Ressource serveren validerer adgangsbilletten og udfører kaldet, hvis alt er ok. Når klienten har fået udstedt en adgangsbillet, kan efterfølgende tilgange til ressourcer ske mere simpelt ved at udføre trin f) og g) ovenfor, indtil adgangsbilletten udløber, eller der ønskes adgang til nye ressourcer. Dekobling af autorisations- og ressource server Som det fremgår af beskrivelsen ovenfor, er autorisations- og ressourceserverne logisk helt dekoblede, og de kan derfor leveres af forskellige serviceudbydere. Det vigtigste krav er, at udbyderen af ressourceserveren stoler på udbyderen af autorisationsserveren i forhold til at autentificere brugeren korrekt, indhente brugerens accept og udstede adgangsbilletter, som modsvarer brugerens accept af delegeret adgang til hans ressourcer. Derudover er det nødvendigt, at autorisationsserveren kender de scope parametre, som ressourceserveren anvender, og kan præsentere dem for brugeren samt at billetformatet er aftalt mellem ressourceserver og autorisationsserver. I simple scenarier vil udbydere af ressourcer ofte selv etablere en autorisationsserver, og dermed er tillidsforhold, ansvar og repræsentation af ressourcer nemt klaret. I mere avancerede scenarier kan autorisationsserveren leveres af en ekstern part eksempelvis efter flg. modeller 2 : Flere udbydere af ressourcer går sammen om at etablere en fælles autorisationsserver dels for at spare udgifter til etablering og dels for at gøre det nemmere for brugeren at styre mange autorisationer ét fælles sted. En fællesoffentlig tjeneste etablerer en autorisationsserver, som borgere kan anvende mod mange digitale selvbetjeningsløsninger. Brug af eksterne tjenester til autorisationer åbner dermed OAuth for integration med eksterne trust frameworks. Her er en oplagt mulighed at repræsentere autorisationer ved brug af SAML Assertions udstedt og signeret af en troværdig tredjepart eksempelvis en fællesoffentlig autorisationsserver som nævnt ovenfor. 2 Ovennævnte skal blot opfattes som tænkte eksempler, der illustrerer mulighederne. Der findes endnu ikke (kendte) danske eksempler på delte autorisationsservere efter disse modeller. 13

14 Når autorisationsserver og ressourceserver leveres af forskellige parter, anbefales det at udarbejde en skriftlig aftale mellem de to organisationer, der udbyder tjenesterne. Aftalen kan eksempelvis regulere format og indhold af adgangsbilletter, ansvar, sikkerhed, drift, logning og overholdelse af lovgivning (særligt persondataloven) og samarbejde. Aftalen danner grundlag for, at ressourceserveren har tillid til billetter udstedt af autorisationsserveren på brugerens vegne. 14

15 4. Implementeringsvalg > I OAuth er en række valg op til de parter, der implementerer protokollen i deres applikationer og tjenester. Dette skyldes ønsket om at understøtte flere forskellige brugsmønstre, samt at forskellige applikationer har forskellige behov - herunder krav til sikkerhed. Dermed kan en OAuth implementering opfattes som en specifik integration mellem klient, autorisationsserver og ressourceserver, hvor parterne skal være enige om en række vælg og parametre, og hvor andre OAuth integrationer med andre parter kan være forskellige. Generelt bør de sikkerhedsmæssige valg afspejle de foreliggende risici, og det kan derfor kraftigt anbefales, at man gennemfører en risikoanalyse inden implementering. Er data ikke følsomme, behøver man ikke etablere et højt sikkerhedsniveau, men er der tale om følsomme data, bør sikkerheden omvendt være høj, hvilket skal afspejles i implementering og drift. I det følgende behandles en række af de åbne valg i en OAuth implementering, og der gives en række anbefalinger vedr. disse. Der fokuseres snævert på implementering af protokollen i applikationer og en lang række øvrige forhold som drift, procedurer etc. behandles ikke. Det antages, at data er følsomme, og at der derfor skal etableres et højt sikkerhedsniveau, da dette er en hyppigt forekommende situation i den offentlige sektor, og da konsekvenserne af forkerte valg er store. Udover de rent sikkerhedsmæssige forhold, bør man altid tage højde for lovgivningen herunder persondataloven. Dette aspekt behandles i et særskilt kapitel senere i dokumentet. Autentifikation af klient I kaldene mellem klient og autorisationsserver foreskriver OAuth protokollen, at klienten autentificeres. På dette område er OAuth helt åben og tillader alle slags autentifikationsmekanismer dog højst én ad gangen. OAuth specificerer selv én mulig mekanisme baseret på bruger id og password, men denne kan ikke anbefales med mindre data er helt ufølsomme. Det anbefales i stedet at autentificere klienten med et OCES Funktions- eller Virksomhedscertifikat via TLS (se [TLS] samt [RFC2818]) transportkanalen i overensstemmelse med principperne beskrevet i Sikkerhedsmodeller for OIOREST [SIKMODEL]. Serveren bør i den forbindelse sættes op til kun at godkende certifikater fra organisationer, som der forudgående er indgået en integrationsaftale med. 15

16 OAuth kræver desuden ikke, at kaldene mellem klient og ressource server autentificeres i stedet benyttes adgangsbilletten 3 (eng. access token) til at autentificere kaldet. Med henblik på at styrke sikkerheden, herunder risikoen for misbrug af stjålne billetter, anbefales det dog at benytte samme autentifikation som for kald til autorisationsserver altså SSL/TLS klientautentifikation baseret på et OCES Funktions- eller Virksomhedscertifikat. Sikring af transportkanalen OAuth protokollen 4 rummer i sig selv ingen mekanismer til sikring af fortrolighed samt integritet af kommunikationen mellem parterne. Det anbefales derfor udelukkende at anvende protokollen via sikre transportforbindelser med stærk kryptering som for eksempel SSL, TLS eller tilsvarende (eksempelvis VPN). I forbindelse med opsætning af TLS på serverne, er der en række forhold man bør være opmærksom på, herunder at konfigurationer med svag kryptering skal frakobles, så de ikke kan blive valgt run-time, når klient og server forhandler algoritmerne for sessionen. Der henvises til [SIKMODEL] for detaljer om sikker opsætning af TLS. Autentifikation af servere Klienten bør sættes op således, at der er sikkerhed for, at der kun kan kommunikeres med kendte autorisations- og ressourceservere. Typisk sker dette ved, at klienten via sin konfiguration har angivet en række URLparametre på disse servere, der indledes med https:// prefikset. I den situation skal klienten ved etablering af TLS forbindelsen til serveren blot validere, at servercertifikatet for modparten indeholder det forventede domæne i Subject feltet 5, samt at certifikatet er gyldigt (ikke udløbet, ikke spærret, er udstedt af en anerkendt certifikatudsteder etc.). Denne validering er normalt del af basal TLS håndtering, men det kan være en god idé at kontrollere, at klienten ikke accepterer at etablere ukrypterede forbindelser (med http prefiks). 3 Billetten er et såkaldt bearer token dvs. adgang gives til alle, som kan præsentere tokenet et princip som er kendt fra eksempelvis sessionscookies og visse slags SAML Assertions. Dette fordrer, at tokenet beskyttes godt mod uautoriseret adgang herunder ikke sendes over ukrypterede transportforbindelser. 4 Dette gælder version 2.0. I version 1.0 findes en signaturmekanisme, som kan sikre integritet af data samt autentifikation af klienten. 5 Et TLS certifikat rummer i CN feltet i Subject elementet det domæne, som certifikatet er bundet til. 16

17 Autentifikation af bruger OAuth kræver, at autorisationsserveren autentificerer brugeren, inden brugerens accept indhentes. Formålet er naturligvis at sikre, at det er brugeren selv, der giver accept til, at hans data deles. Protokollen foreskriver ikke, hvorledes denne autentifikation foregår, og derfor kan mange forskellige mekanismer understøttes. Normalt vil man vælge den autentifikationsmekanisme, som brugerdata allerede er beskyttet af men det er ikke strengt nødvendigt, eftersom autorisationsserveren er dekoblet fra ressourceserveren. For digitale selvbetjeningsløsninger vil det være naturligt at overveje flg. mekanismer: Autentifikation baseret på NemID / digital signatur. Autentifikation baseret på NemLog-in (som bygger på ovenstående). Begge loginmekanismer giver en høj grad af vished for brugerens identitet (det såkaldte Assurancelevel), og er på forhånd vurderet som tilstrækkelige til at tilgå personfølsomme data. Begge mekanismer kan endvidere tilvejebringe et CPR nummer, som brugerdata ofte er koblede til i den offentlige sektor 6. NemLog-in har den fordel, at såfremt brugeren allerede er logget ind på en offentlig løsning, da vil det aktuelle log-in foregå med såkaldt Single Sign-On (SSO). Dette betyder, at brugeren automatisk bliver logget ind på autorisationsserveren og dermed ikke (igen) skal angive sit kodeord til Digital Signatur / NemID. 6 Det frarådes generelt at koble brugerdata med et CPR nummer, hvis det kan undgås. 17

18 Figur 3: Brugerautentifikation via NemLog-in Granularitet af adgang til ressourcer (scope) I kaldene fra klient til autorisationsserver kan man fremsende en beskrivelse af de brugerressourcer, som klienten ønsker at tilgå. Dette repræsenteres som et antal simple tekststrenge, der medsendes i den såkaldte scope parameter. Brugen af denne mekanisme er valgfri i OAuth, idet ressourcerne også kan være underforstået af sammenhængen (eller være angivet i brugerdialogen se næste afsnit). Det anbefales dog generelt, at ressourcerne beskrives eksplicit, hvor det giver mening, således at brugeren ikke ved en fejl tildeler for bred adgang eller skal gætte sig til, hvad klienten har behov for. OAuth specificerer ikke, hvordan ressourcer samt anmodning om adgang til disse kan udtrykkes som tekststrenge det er helt op til den, der udstiller ressourcerne. På den måde kan OAuth benyttes til at give adgang til mange forskellige slags ressourcer, og det er så op til implementationen at finde en passende repræsentation. Generelt kan det anbefales at indføre en så specifik og finkornet repræsentation af ressourcer og adgange som muligt, idet man her grundlæggende sætter begrænsningerne for, hvor godt brugeren kan styre adgangen til sine ressourcer herunder at applikationer ikke får adgang til mere end højst nødvendigt. Dette skal naturligvis balanceres mod hensynet til, at det skal være muligt at bygge værdifulde klientapplikationer - også nye applikationer i fremtiden, der 18

19 ønsker at anvende data på innovative måder, der ikke oprindeligt var forudset. I eksemplet med adgang til skattemappen fra en netbankapplikation kan man eksempelvis definere adgange svarende til: Hele brugerens skattemappe. Seneste årsopgørelse i skattemappen. Værdien af feltet personlig indkomst fra seneste årsopgørelse. Her kunne man så definere konkrete scope strenge, der afspejlede disse adgange. Indenfor REST paradigmet opereres med en særlig konvention, hvor ressourcer udpeges via URL er. Et eksempel fra [PRAKSIS] viser at URL en giver flg. svar: <kommune ref="http://oiorest.dk/danmark/kommuner/101"> <nr>101</nr> <navn>københavn</navn> <region ref="http://oiorest.dk/danmark/regioner/1085"/> <veje ref="http://oiorest.dk/danmark/kommuner/101/veje"/> <adresser ref="http://oiorest.dk/danmark/kommuner/101/adresser"/> <lokaliteter ref="http://oiorest.dk/danmark/kommuner/101/lokaliteter"/> <skoledistrikter ref="http://oiorest.dk/danmark/kommuner/101/skoledistrikter"/> <skoler ref="http://oiorest.dk/danmark/kommuner/101/skoler"/> <valgdistrikter ref="http://oiorest.dk/danmark/kommuner/101/valgdistrikter"/> <graense ref="http://oiorest.dk/danmark/kommuner/101/grænse"/> </kommune> Generelt anbefales det at følge denne konvention for udpegning af ressourcer, hvor det giver mening for den konkrete applikation. Bemærk endvidere, at OAuth ikke indeholder nogen specifikation af, hvorledes ressourcer repræsenteres (eksempelvis returnerede brugerdata). Ligeledes peges her på anbefalingerne i OIOREST for http baserede ressourcer - eksempelvis bør man overveje, om der findes en passende MIME type for ressourcen (eksempelvis XML eller et billede). Indhentning af brugerens accept Som beskrevet ovenfor har autorisationsserveren til opgave at indhente brugerens accept af, at klienten får adgang til den ønskede brugerressource, og herefter at udstede en adgangsbillet, som klienten efterfølgende kan anvende mod ressourceserveren. OAuth foreskriver ikke, hvordan brugerens tilladelse indhentes herunder hvorledes brugerdialogen udformes kun at brugeren forudgående bliver autentificeret (som tidligere beskrevet). I dette afsnit gives en række anbefalinger, som både er nyttige og nødvendige, hvis man skal opfylde persondatalovens krav til samtykker. Der henvises til kapitlet om lovgivning senere i vejledningen for detaljer. 19

20 Det vigtigste formål med brugerdialogen er, at det er krystalklart for brugeren, hvilken adgang han giver til sine ressourcer. Derfor bør følgende informationer være tydelige i skærmbilledet: At brugeren er i færd med at delegere adgang, samt at han i skærmbilledet skal give sin accept. Her er det god praksis at brugeren aktivt skal vælge adgangen til eller med andre ord at deling ikke er default-indstillingen. Det bør være tydeligt, hvem der ønsker adgang, til hvilke ressourcer samt hvor længe. Det bør være tydeligt for brugeren, hvordan han kan tilbagekalde delegeringen, hvis han fortryder. OAuth beskriver ikke hvordan en tilbagekaldelse af accept skal fungere, så det må man implementere i hvert enkelt tilfælde. Det anbefales, at der stilles en brugergrænseflade til rådighed for brugeren, hvor tilbagekaldelsen kan igangsættes. Når ressourceserver og autorisationsserver er dekoblede, må man nøje overveje, hvor og hvordan tilbagekaldelse af accept kan ske herunder hvorledes brugeroplevelsen kan blive mest hensigtsmæssig. Her kan det være relevant at etablere en systemgrænseflade mellem ressourceserver og autorisationsserver til notifikation af disse hændelser. Hvis man har valgt, at klienten angiver scope parametre i kaldene mod autorisationsserveren (se ovenfor), bør brugerdialogen tage højde for disse og præsentere for brugeren på et let forståeligt sprog, hvilken adgang klienten aktuelt beder om. Der skal med andre ord etableres en kobling mellem den maskinelle repræsentation af en adgang (tekstparametre til scope) og den menneskelige forklaring af disses betydning. Scope parametrenes format og indhold designes af ressourceserveren (med udgangspunkt i de udbudte ressourcer) og anvendes af klient og autorisationsserver. Hvis det er muligt, bør man udforme dialogen, så brugeren kan indskrænke den adgang, som klienten beder om. Et eksempel i forbindelse med adgang til en hierarkisk mappestruktur med filer kunne være, at brugeren selv kan vælge hvilke mapper eller undermapper, som der gives adgang til. Her kunne en klient være tilbøjelig til at bede om adgang til alle mapper, mens brugeren så i stedet kan udpege de specifikke mapper, han ønsker at give adgang til. Herudover bør brugeren have mulighed for at justere det tidsinterval, hvori klienten får adgang herefter skal brugeren spørges på ny. Format på brugeraccept OAuth overlader helt til implementeringen at designe den måde, hvorpå brugeren afgiver sinn accept. Hvis indhentning af accept overholder visse formalia, kan det udgøre et samtykke i persondatalovens forstand, hvilket i en række situationer er en betingelse for udveksling af data. For detaljer henvises til kapitlet om persondataloven senere i vejledningen. Derudover bør man 20

21 overveje de forretningsmæssige krav til, at brugerens accept efterfølgende kan dokumenteres. Overordnet er der to oplagte muligheder for brugerinteraktionen: Brugeren klikker Accepter i en tjekboks eller trykker på en knap. Brugeren underskriver en samtykkeerklæring med sin digitale signatur (velkendt fra betalinger i netbanker). Den første metode er meget udbredt og simpel at implementere - men giver begrænset mulighed for efterfølgende at dokumentere, at brugeren rent faktisk gav sin accept. Ved i stedet at lade brugen benytte sin digitale signatur til at signere samtykket opnår autorisationsserven en stærk dokumentation for, at brugeren var indforstået men det koster til gengæld en del kompleksitet at implementere (herunder integration af Java Applets til signering i web siden samt brug af API er til efterfølgende validering af signaturen). Under alle omstændigheder bør applikationen foretage en detaljeret logning af brugerens valg, der efterfølgende kan tjene til dokumentation for hændelsesforløbet. Hvilken metode man anvender, må bero på en konkret risikovurdering samt en vurdering af lovgivningen. Man bør eksempelvis være opmærksom på, at Persondataloven indeholder en række krav til samtykker, hvilket behandles i et særskilt kapitel senere i vejledningen. Det kan også anbefales at foretage en usability-test af skærmbilledet med rigtige brugere med henblik på at sikre, at interaktionen er forståelig og brugervenlig også for brugere med mindre stærke it-kundskaber, hvis sådanne skal anvende løsningen. Ægthed af svar OAuth protokollen adresserer ikke ægthed og integritet af svaret fra ressource serveren udover hvad der opnås ved anvendelse af sikre transportprotokoller. I situationer, hvor dette måtte være vigtigt, kan man overveje at lade ressourceserveren signere data på applikationsniveau med en digital signatur 7 (eksempelvis hørende til et OCES Funktions- eller Virksomhedscertifikat). Her vil man mod en ekstra kompleksitet opnå en øget sikkerhed samt god mulighed for efterfølgende at dokumentere, hvilke data man fik udleveret. Dette kan være relevant, hvis klienten skal træffe vigtige afgørelser på baggrund af data fra tredjeparter som i det tidligere nævnte eksempel med en 7 Her bør man overveje XML dsig standarden. Se for detaljer. 21

22 netbankapplikation, der giver kredit på baggrund af brugerens skatteoplysninger. Beskyttelse og validering af adgangsbilletter De adgangsbilletter, som autorisationsserveren udsteder til klienten, kan have to typer: de såkaldte bearer tokens eller mac tokens 8. Førstnævnte betyder, at de giver adgang til ressourcer blot ved at blive præsenteret (uanset hvem der præsenterer dem og uden yderligere credentials). Derfor er det vigtigt, at klienten ved brug af bearer tokens sørger for at beskytte adgangsbilletterne (eller rettere hele requestet) mod uautoriseret adgang både fra eksterne samt interne. Eksempelvis bør de ikke sendes over ukrypterede transportkanaler eller til uautentificerede parter og heller ikke logges i ukrypteret form til disk. Det er ligeledes en god idé, at begrænse gyldighedsperioden mest muligt for at sikre mod misbrug. Derudover bør billetterne være beskyttet mod, at klienten kan fabrikere eller modificere dem til at opnå flere rettigheder end tiltænkt - eksempelvis ved at autorisationsserveren signerer dem. Alternativet til bearer tokens (se [OAUTH] afsnit 7.1) er bruge en såkaldt MAC algoritme til signering af requestet herunder tokenet. Dette går ud på at klienten signerer http requestet med en hemmelighed (et password som input til en MAC algoritme), der er bundet til tokenet. Dermed kan en billet kun kan anvendes af den klient, som besidder den hemmeligheden. Ressourceserveren har til opgave at validere modtagne adgangsbilletter herunder at sikre, at de ikke er udløbet, at de er udstedt af en godkendt autorisationsserver, samt at billettens autorisation omfatter det kald, som klienten foretager. Som før nævnt er styring af autorisationer (herunder indhold og format på adgangsbilletter) op til den konkrete implementering og ikke foreskrevet af OAuth. Format af web service kald OAuth foreskriver ikke hvilken mekanisme, der anvendes i kommunikationen mellem klient og ressourceserver, når brugerens ressourcer tilgås. Det eneste krav er, at HTTP protokollen anvendes og at et antal parametre kan overføres (herunder adgangsbilletten udstedt af autorisationsserveren). Adgangsbilletten kan medsendes enten via en http header (Authorization), som en del af URI en (oauth_token parameter) eller i HTTP body som en form-parameter (oauth_token). 8 Denne type er tilføjet i draft 12 af OAuth 2.0 formentlig på grund af en del kritik af, at der kun var de mere usikre bearer tokens tilbage efter at man fjernede signering af request parametre fra OAuth

23 Hvordan applikationsdata indlejres i kald og i svar er der således ingen krav til og dermed er det op til den konkrete implementering at vælge den mekanisme, der er mest hensigtsmæssig til den foreliggende situation. Det mest oplagte og udbredte valg i kombination med OAuth er REST, men SOAP kan dog også være en mulighed. For anbefalinger på førstnævnte område henvises til [PRAKSIS]. Format af adgangsbilletter Som beskrevet ovenfor fremsender klienten en adgangsbillet til ressourceserveren, når brugerens ressourcer tilgås. Billetten repræsenterer de adgange til ressourcer og gyldighedsperioder, som brugeren har givet sin accept til. OAuth specifikationen beskriver ikke formatet eller strukturen på de adgangsbilletter (tokens), som udveksles mellem autorisationsserver og ressourceserver, og det er dermed op til den konkrete implementering af fastlægge. Det eneste krav er, at billetten kan repræsenteres som en tekststreng og specifikationen viser, hvordan denne kan indlejres i URL fragmenter, som JSON strukturer, HTTP header felter eller HTTP form variable. Bemærk at klienten ikke har behov for at forstå indholdet af adgangsbilletter; den skal blot opfatte dem som black-box strenge, der modtages fra autorisationsserveren og sendes videre til ressourceserveren. Ved design af billetters indhold anbefales det at overveje flg. muligheder: a) Tokenet indeholder blot en unik reference, hvor ressourceserveren efterfølgende laver et opslag til autorisationsserveren med denne som nøgle for at hente de reelle oplysninger om autorisationen. Her er det vigtigt, at tokenet indeholder tilstrækkelig meget entropi (f.eks. et meget stort tilfældigt tal), således at andre ikke har nogen reel mulighed for at gætte gyldige værdier og dermed kidnappe gyldige autorisationer. Med denne teknik kan man undgå at implementere digital signering af tokenet (se næste punkt), hvilket kan være en lettelse. b) Tokenet indeholder reelle indholdsdata om autorisationen eksempelvis som sæt af (navn, værdi) par kendt fra repræsentation af HTML form variable. Når tokenet beskriver autorisationen er det vigtigt at sikre, at klienten ikke kan manipulere med indholdet for eksempelvis at opnå en større adgang. En oplagt metode til at undgå dette er, at en af navnværdi parrene indeholder en digital signatur fra autorisationsserveren over de øvrige par, idet ressourceserveren så kan validere signaturen og konstatere, hvis parametrene er blevet ændret. For inspiration til denne 23

24 metode henvises til OAuth 1.0 protokollen 9. Her skal det bemærkes, at en række implementeringer har fundet denne mekanisme besværlig at håndtere i praksis, idet blot den mindste fortolkningsforskel i dannelsen af signaturen (eksempelvis samling og kanonisering af strenge) vil give en valideringsfejl. 9 Bemærk at OAuth 1.0 beskriver, hvordan en klient kan signere HTTP request parametre ved at konkatenere dem til en samlet streng og herefter beregne en hash værdi. Tokenet skal derimod signeres af autorisationsserveren for at beskytte det mod manipulation af bl.a. klienten. 24

25 5. Lovgivning om persondata > OAuth tilvejebringer en teknisk mekanisme, hvormed data kan udveksles mellem to tjenester. Ofte vil der være tale om personlige data, og her er det vigtigt at være opmærksom på lovgivningen på området nærmere betegnet persondataloven [PDL], sikkerhedsbekendtgørelsen [SBK] samt vejledningen til sidstnævnte [VJL]. Udover de generelle regler kan der findes specielle regler indenfor visse områder som eksempelvis på sundhedsområdet. Endelig kan der henvises til Datatilsynets anbefalinger til beskyttelse af privatlivets fred i sociale netværkstjenester [SOC] et område hvor brug af OAuth historisk har været udbredt. Dette kapitel beskriver en række berøringsflader mellem OAuth og reglerne vedr. persondata. Der fokuseres snævert på de sikkerhedsmæssige aspekter, hvor (hensigtsmæssig) anvendelse af OAuth kan hjælpe med at opfylde lovgivningens krav i situationen omkring videregivelse af data til en tredjepart. Det er vigtigt at pointere, at anvendelse af OAuth i henhold til denne vejledning ikke i sig selv er tilstrækkeligt til at opfylde kravene i lovgivningen eksempelvis beskriver vejledningen ikke aspekter vedr. drift og organisatoriske kontroller. Man bør altid foretage en helhedsorienteret vurdering af, hvordan persondata behandles, samt kontakte Datatilsynet, hvis der er tvivl om, hvordan reglerne skal fortolkes. For en bredere afdækning af de juridiske forhold i forbindelse med videregivelse henvises til [SIKMODEL] samt [IDWS]. Det antages nedenfor, at de brugerdata som findes hos ressourceserveren, er indsamlet og i øvrigt behandles i overensstemmelse med lovgivningen, og overvejelserne går derfor udelukkende på videregivelsessituationen. Roller Indledningsvis er det vigtigt at afklare, hvilke roller de enkelte parter i et OAuth scenarie har i forhold til lovningen. I de beskrevne scenarier flyder brugerens data mellem en ressourceserver og en klient. Her vil ejeren af ressourceserveren som regel være dataansvarlig, og den organisation, som udbyder klienten, enten være dataansvarlig eller databehandler. Som oftest vil modtageren / klienten anvende brugerdata til et nyt selvstændigt formål og dermed som hovedregel være dataansvarlig. Autorisationsserveren kan enten opereres af den dataansvarlige (samme organisation som opererer ressourceserveren) eller af en tredjepart men det skal bemærkes, at der normalt ikke flyder personlige data til denne. I de fleste tilfælde vil OAuth scenarier altså kunne opfattes som en videregivelse af data mellem to selvstændige, dataansvarlige organisationer. I henhold til Persondataloven skal de(n) dataansvarlige foretage en anmeldelse til Datatilsynet, hvori behandlingen af data deklareres. 25

26 Omfang af data, der udleveres I persondatalovens 5 fremgår, at man ikke må indsamle oplysninger, som omfatter mere end det formål, hvortil data senere skal bruges. På den baggrund er det relevant at udstille ressourcerne på en måde, så modtageren kan forespørge specifikt på de nødvendige data - uden at få for meget med. Her kan OAuth s scope parametre benyttes til at indsnævre omfanget af data (og dertil hørende samtykker). Det er dermed op til ressourceejeren at udstille data på en tilstrækkelig finkornet måde - samt til klienten kun at forespørge på specifikke data, som der er brug for. Samtykke fra brugeren OAuth opererer som tidligere beskrevet med en model, hvor brugeren skal give sin accept af, at hans ressourcer tilgås af klienten. Hvis denne accept indhentes på en passende måde, kan det udgøre et samtykke i persondatalovens forstand, hvilket i mange situationer vil legitimere behandling samt udveksling af data. Definitionen af et samtykke i persondataloven er enhver frivillig, specifik og informeret viljestilkendegivelse, hvorved den registrerede indvilger i, at oplysninger, der vedrører den pågældende selv, gøres til genstand for behandling. De fleste steder i loven, hvor der opereres med samtykke, anføres endvidere, at dette skal være udtrykkeligt. Ved at følge anbefalingerne i denne vejledning vedr. udformning og indhentning af samtykker, vurderes det, at der er en overvejende sandsynlighed for, at de formelle krav til samtykker i persondataloven opfyldes. Det anbefales dog under alle omstændigheder at foretage en konkret vurdering i det enkelte tilfælde samt at kontakte Datatilsynet, hvis der hersker tvivl om fortolkning af reglerne. Et specialtilfælde, som nøje bør overvejes, er når ressourceserver og autorisationsserver drives af forskellige organisationer. I den situation er det således en anden part, der indhenter samtykket, end den dataansvarlige, som har brug for det i henhold til lovgivningen. Her bør der etableres aftaler, procedurer samt tekniske foranstaltninger, som sikrer den dataansvarlige, at samtykket kan dokumenteres. En mulighed er eksempelvis, at brugeren signerer en samtykkeerklæring med sin digitale signatur og at signaturen overføres til ressourceejeren, som herefter selv kan tjekke gyldigheden samt logge signaturen som bevis på samtykket. Transmission af persondata over åbne net Sikkerhedsbekendtgørelsen [SBK] og vejledningen til denne [VJL] opstiller retningslinjer for sikring af persondata, som sendes over åbne net (som f.eks. 26

27 internettet). Kravene går bl.a. på sikring af fortrolighed, integritet og autenticitet i kommunikationen. Disse krav kan opfyldes ved at anvende OAuth i kombination med TLS og digitale certifikater, som beskrevet tidligere i denne vejledning. Fortrolighed og integritet af kommunikationen kan generelt sikres ved at benytte sikre transportkanaler baseret på TLS. Her er det vigtigt at være opmærksom på, at TLS-implementationer kan sættes op til at benytte en række forskellige krypterings- og hashalgoritmer samt forskellige nøglelængder. Ved transmission af følsomme data kræves iflg. reglerne stærk kryptering baseret på en anerkendt algoritme, hvilket kan være AES eller Tripple-DES algoritmerne med en nøglelængde på mindst 128 bit. Det er her vigtigt at huske, at systemerne konfigureres, så svage algoritmer ikke kan vælges run time, når klient og server forhandler parametrene for TLS forbindelsen (såkaldte Cipher suites). Autenticiteten af parterne kan sikres ved at anvende digitale certifikater for klient og server i forbindelse med etablering af TLS forbindelser. Her skal man være opmærksom på, at TLS har to forskellige modeller: én hvor kun serveren bliver autentificeret og én hvor både server og klient autentificeres med et certifikat. Her bør man vælge sidstnævnte. Endelig bør certifikaterne være af en god kvalitet eksempelvis OCES Virksomheds- eller Funktionscertifikater. 27

28 6. Fællesoffentlig brugerstyring > I dette kapitel sættes OAuth i sammenhæng med øvrige offentlige initiativer indenfor brugerstyring og sikkerhed. Samspil med NemID og NemLog-in Som tidligere nævnt er autentifikation af brugeren ikke en del af OAuth, så her må man finde en passende mekanisme, der passer til sammenhængen. For offentlige digitaliseringsløsninger vil det være oplagt at tilbyde autentifikation via NemID enten direkte eller via NemLog-in, hvor sidstnævnte kan give brugeren single sign-on med andre offentlige tjenester. Hvis brugeren eksempelvis allerede er logget på en offentlig tjeneste, vil log-in til den nye applikation (som benytter OAuth) via NemLog-in kunne ske uden aktiv brugerinvolvering dermed spares brugeren for unødige log-ins. Der er altså intet overlap mellem OAuth og NemID / NemLog-in, og de kan derfor supplere hinanden fint. Dog bør man være opmærksom på, at implementeringsopgaven og kompleksiteten vokser, når en applikation skal integreres med disse tjenester. Relation til identitetsbaserede web services IT- og Telestyrelsen har lanceret et andet koncept kaldet OIO Identitetsbaserede web services 10 (herefter forkortet OIOIDWS se bl.a. [IDWS]), som kan løse flere af de samme opgaver som OAuth herunder sikre web service kald på vegne af en bruger. I tabellen nedenfor sammenlignes de to koncepter. Helt overordnet kan man sige, at OIOIDWS retter sig mod SOAP baserede web services, hvor adgang opnås via et SAML token, mens OAuth er mere åbent og hverken specificerer web service protokol eller billetformat. Dog sker stort set alle kendte anvendelser af OAuth med REST som web service protokol - og OAuth er nøje knyttet til HTTP og lader sig ikke umiddelbart anvende over andre transportkanaler (f.eks. JMS), som det er tilfældet med SOAP. OIOIDWS specificerer en rig sikkerhedsmodel med en vis kompleksitet, mens OAuth lader mange valg være op til implementeringen og derfor kan understøtte simple scenarier såvel som mere avancerede scenarier (hvor implementeringen så skal realisere mere fra scratch ). Område / egenskab OIO IDWS OAuth Specifikationer og standarder OIO profiler af SAML, WS- Security og WS-Trust fra OASIS. IETF Draft. 10 Se bl.a. 28

29 Web service mekanisme SOAP Uspecificeret men ofte anvendes REST. Transportsikkerhed Kompleksitet af implementering Klientteknologi Granularitet af sikkerhedsmodel Mulighed for genbrug af implementering Profileret til TLS alene men kan let udvides til eksempelvis applikationskryptering. Høj Klient er enten en server eller en rig pc-applikation (tyk klient). Finkornet mulighed for rige identitets- og rettighedsattributter samt avancerede trust-forhold. Stor grundet høj standardisering. OAuth 2.0 er stærkt bundet til TLS. Middel tenderende til lav afhængigt af, hvor finkornet en model, der anvendes. Klient kan være tynd som f.eks. en mobiltelefon eller en JavaScript klient men også tyk. Uspecificeret op til implementering, men de fleste anvendelser benytter en simpel, grovkornet model. Lille grundet mange bilaterale valg mellem tjenester. Token / billet format OIOSAML Assertion. Uspecificeret op til implementering. Repræsentation af rettigheder Indhentning af brugeraccept Trust / tillid mellem parter Understøttelse i standardprogrammel (applikationsservere) Understøttelse i fællesoffentlige tjenester OIOSAML Basic Privilege Profile. Valgfrit, kan ske med Request-to-Interact. Enten bilateralt eller føderalt. Eksempelvis kan tillid etableres via en føderationsgodkendt Security Token Service. Understøttelse i en række kommercielle SOAP stakke, applikationsservere samt open source reference implementeringer. Understøttet i KFOBS løsningen, som er planlagt til lancering primo Uspecificeret op til implementering. Obligatorisk i OAuth Protokollen. Bilateralt mellem klient og ressourceserver. Flere open source implementeringer men lille udbredelse i kommercielle web service stakke. Endnu ikke planlagt understøttelse i fællesoffentlige tjenester. Da OIOIDWS og OAuth både har en række forskelle og ligheder, må man i hvert enkelt tilfælde gøre op, hvad der er mest hensigtsmæssigt at anvende. Her kan det være relevant at tage hensyn til den teknologi ens partnere anvender, klientteknologi (browser versus mobiltelefon), hvordan ressourcer udstilles (SOAP versus REST), hvor avanceret en sikkerhedsmodel, man har behov for, samt endelig hvor stor kompleksitet projektet kan bære. 29

30 30 >

31 7. Implementeringer > På trods af at OAuth 2.0 stadig kun foreligger som udkast, findes der allerede en række implementeringer 11 de fleste af draft 10 udgaven, da draft 12 stadig er ret ny (i skrivende stund). I dette kapitel beskrives interessante aspekter af nogle af disse implementeringer, som dels viser brug af OAuth i praksis, og dels viser, hvordan man som udvikler relativt hurtigt kan komme igang. Serverimplementeringer (kombinerede autorisationsservere og ressourceservere): Dailymotion (draft 10) - Microsoft Access Control System (draft 10) - ndows-azure-appfabric-labs-september-release-now-available.aspx Facebook's Graph API (draft 10) - (see ociallipstick.com/?p=239) Salesforce (draft 10) - Resthub open source framework for Java (draft 10) - Gowalla (draft 8) - 37Signals (draft 5) - GitHub - Ruby oauth2-server (draft 0) - Klientimplementeringer: Cocoa - iphone and ipad - Ruby Gem - Ruby oauth2-core - PHP (draft 9) - Python - Nedenfor gennemgås interessante aspekter af et par af disse implementeringer som på mange punkter afviger fra anbefalingerne i denne vejledning. 11 Kig evt. på for en opdateret liste. 31

32 Facebook Facebook udstiller ressourcer fra brugernes konti til eksterne klienter, som enten kan være web servere eller JavaScript klienter. På den måde kan andre firmaer dels lave applikationer på Facebook platformen dels udnytte Facebook data i eget regi. I forbindelse med adgangen, vil Facebook autentificere brugeren med deres Facebook log-in og prompte for accept af, at deres basale data bliver tilgået, som illustreret nedenfor: I eksemplet ovenfor benævnes klienten My Great Website. Dialogen giver brugeren et overblik over hvilke oplysninger, der ønskes delt og default indstillingen er at acceptere deling. Hvis klienten ønsker flere oplysninger end de basale data, har Facebook defineret en lang række scope parametre, som identificerer de enkelte attributter i en Facebook konto. Ved at angive disse som parametre i kaldet, kan der forespørges på specifikke attributter. Som eksempler kan nævnes brugerens fødselsdag, uddannelseshistorik, interesser, hjemby, fotos, religiøseller politisk overbevisning, adresse mv. Selve token formatet er ikke dokumenteret, idet både autorisationsserver og ressourceserver ejes af Facebook. Dailymotion Dailymotion er en tjeneste, hvor brugerne kan uploade, dele og finde videoklip. Ligesom Facebook understøtter tjenesten ekstern adgang til brugernes ressourcer via OAuth fra enten web servere eller JavaScript klienter. Når klienter anvender Dailymotion s OAuth 2.0 grænseflade, får de som udgangspunkt adgang til brugerens offentlige data (brugernavn, publicerede videoklip mm). Ved at anvende tre simple scope parametre ( read, write, 32

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

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

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

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

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

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

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

It-sikkerhedstekst ST2

It-sikkerhedstekst ST2 It-sikkerhedstekst ST2 Overvejelser om sikring mod, at personoplysninger kommer til uvedkommendes kendskab i forbindelse med Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST2 Version

Læs mere

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang 29.04.2015 USS/XSTJ Version 1.3 1. Indledning... 2 2. Proces for kundestyret dataadgang... 2 2.1 Fuldmagtsgivning

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

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

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

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

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

LUDUS Web Installations- og konfigurationsvejledning

LUDUS Web Installations- og konfigurationsvejledning LUDUS Web Installations- og konfigurationsvejledning Indhold LUDUS Web Installations- og konfigurationsvejledning... 1 1. Forudsætninger... 2 2. Installation... 3 3. Konfiguration... 9 3.1 LUDUS Databasekonfiguration...

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

It-sikkerhedstekst ST4

It-sikkerhedstekst ST4 It-sikkerhedstekst ST4 Datatransmission af personoplysninger på åbne net Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST4 Version 1 Oktober 2014 Datatransmission af personoplysninger

Læs mere

End-to-end scenarier for fuldmagtsløsningen

End-to-end scenarier for fuldmagtsløsningen End-to-end scenarier for fuldmagtsløsningen Side 1 af 6 15. januar 2013 TG Dette notat beskriver en række end-to-end scenarier for fuldmagtsløsningen. Formålet er at illustrere sammenhænge og forløb på

Læs mere

Artikel om... Digital signatur. OpenOffice.org

Artikel om... Digital signatur. OpenOffice.org Artikel om... Digital signatur OpenOffice.org Rettigheder Dette dokument er beskyttet af Copyright 2005 til bidragsyderne, som er oplistet i afsnittet Forfattere. Du kan distribuere og/eller ændre det

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

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Økonomistyrelsen Marts 2011 Side 1 af 16 Oversigt over dokumentet...3

Læs mere

It-sikkerhedstekst ST5

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

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

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

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Introduktion til NemID og Tjenesteudbyderpakken

Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S 11. april

Læs mere

Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID. (NemID tjenesteudbyderaftale [NAVN på NemID tjenesteudbyder indsættes])

Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID. (NemID tjenesteudbyderaftale [NAVN på NemID tjenesteudbyder indsættes]) Lautrupbjerg 10 DK-2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 www.nets.eu CVR-nr. 30808460 P. 1-11 Standardvilkår for modtagelse af OCES-certifikater fra Nets DanID (NemID tjenesteudbyderaftale

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

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 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

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

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

Procesbeskrivelse - Webprogrammering

Procesbeskrivelse - Webprogrammering Procesbeskrivelse - Webprogrammering Indholdsfortegnelse Forudsætninger... 1 Konceptet... 2 Hjemmesiden... 2 Server-side... 3 Filstrukturen... 3 Databasehåndtering og serverforbindelse... 4 Client-side...

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

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

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. 1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale

Læs mere

Cloud Computing De juridiske aspekter

Cloud Computing De juridiske aspekter Cloud Computing De juridiske aspekter Forskningsnet Konference 2010 Middelfart Advokat Nis Peter Dall Hvad er Cloud? IaaS (Infrastructure as a Service) - Computerkraft, lagerplads mv. stilles til rådighed

Læs mere

Henkel Norden AB ("Henkel") er en del af Henkel Corporation, og i henhold til DPA, er Jörg Heine, den dataansvarlige: schwarzkopf.dk@henkel.

Henkel Norden AB (Henkel) er en del af Henkel Corporation, og i henhold til DPA, er Jörg Heine, den dataansvarlige: schwarzkopf.dk@henkel. HENKEL FORTROLIGHEDSPOLITIK Vi, hos Henkel, tager vores forpligtelser i henhold til dansk lov om databeskyttelse (persondataloven) alvorligt og er forpligtet til at beskytte dit privatliv. Denne fortrolighedserklæring

Læs mere

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater TDCs Signaturserver Side 2 Indhold Indledning...3 Teknisk projekt... 3 Tekniske forudsætninger... 3 Installation af klienten... 4 Udstedelse af signatur... 4 Anvendelse af signaturen... 6 Eksport af signaturen...

Læs mere

Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in. Digitaliseringsstyrelsen 2013

Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in. Digitaliseringsstyrelsen 2013 Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in Digitaliseringsstyrelsen 2013 Side 2 af 31 Indhold Indhold... 2 0. Praktisk info... 5 0.1 Om tiltrædelse af vilkår... 5 0.2 Om gateway-leverandørers

Læs mere

Løsningsbeskrivelse for log-in og signering med NemID. Valg af målgruppe og navigation omkring NemID på jeres tjeneste.

Løsningsbeskrivelse for log-in og signering med NemID. Valg af målgruppe og navigation omkring NemID på jeres tjeneste. Løsningsbeskrivelse for log-in og signering med NemID Valg af målgruppe og navigation omkring NemID på jeres tjeneste. Om dette dokument Indhold I dette dokument kan du finde en overordnet løsningsbeskrivelse

Læs mere

Sag 61828-mho Udkast 06.05.2015. Cookiepolitik. 1. Politik for brug af HC Containers onlinetjenester

Sag 61828-mho Udkast 06.05.2015. Cookiepolitik. 1. Politik for brug af HC Containers onlinetjenester Sag 61828-mho Udkast 06.05.2015 Cookiepolitik 1. Politik for brug af HC Containers onlinetjenester På denne side oplyses om de nærmere vilkår for brugen af www.hccontainer.dk og eventuelle andre hjemmesider,

Læs mere

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK 2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Adgang til kundeportalen

Adgang til kundeportalen Til elleverandørerne Adgang til kundeportalen 3. april 2012 XSTJ/LRO Følgende dokument har til formål at orientere elleverandørerne om implementering og testning af den it-funktionalitet, som skal sikre

Læs mere

Sikkerhedsmodeller for Pervasive Computing

Sikkerhedsmodeller for Pervasive Computing Sikkerhedsmodeller for Pervasive Computing Christian Damsgaard Jensen Safe & Secure IT-Systems Research Group Informatik & Matematisk Modellering Danmarks Tekniske Universitet Email: Christian.Jensen@imm.dtu.dk

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login

Læs mere

Medarbejdersignatur - sådan gør organisationerne i dag. Morten Storm Petersen Signaturgruppen A/S morten@signaturgruppen.dk

Medarbejdersignatur - sådan gør organisationerne i dag. Morten Storm Petersen Signaturgruppen A/S morten@signaturgruppen.dk Medarbejdersignatur - sådan gør organisationerne i dag Morten Storm Petersen Signaturgruppen A/S morten@signaturgruppen.dk Min baggrund Etablerede TDC s certificeringscenter 1998-2006 Modtog Dansk IT s

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

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 26. maj 2014 Side 1-11 Indholdsfortegnelse

Læs mere

WHITEPAPER DokumentBroker

WHITEPAPER DokumentBroker WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,

Læs mere

Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net

Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net 18. november 2011 Vejledning Windows 7 - eklient Opkobling via ADSL eller anden kabelforbindelse til P-net. Tilslutning med Cisco AnyConnect VPN-klient (Windows) til AARHUS TECH P-net Cisco AnyConnect

Læs mere

POLITIK FOR DATABESKYTTELSE

POLITIK FOR DATABESKYTTELSE POLITIK FOR DATABESKYTTELSE Disse retningslinjer for databeskyttelse beskriver, hvordan vi bruger og beskytter oplysninger, som du afgiver i forbindelse med brug af vores hjemmeside. Vi har forpligtet

Læs mere

STS Anvenderdokument i. STS Anvenderdokument

STS Anvenderdokument i. STS Anvenderdokument i STS Anvenderdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.4 2014-07 N iii Indhold 1 Introduktion 1 1.1 Målgruppen...................................................... 1 2 STS 1 2.1 Snitflade........................................................

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

Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7. Forslag til fælles sikkerhedsmodel for Grunddataprogrammet

Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7. Forslag til fælles sikkerhedsmodel for Grunddataprogrammet Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7 Forslag til fælles sikkerhedsmodel for Grunddataprogrammet Status: Version 1.2 Version: 19.06.2014 Indholdsfortegnelse 1. INDLEDNING... 4 1.1 BAGGRUND...

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note PC Klient 2.4.0.17 o Support for at Domain maskiner kan logge på ConnectAnywhere automatisk med Windows credentials Løsningen forudsætter/kræver at man logger på Windows

Læs mere

lov nr. 429 af 31/05/2000 med senere ændringer om behandling af personoplysninger (Persondataloven).

lov nr. 429 af 31/05/2000 med senere ændringer om behandling af personoplysninger (Persondataloven). Bilag 6 Databehandleraftale og databehandlerinstruks 1. Leverandøren overholder de til enhver tid gældende regler og forskrifter for behandling af personoplysninger under Kontrakten, herunder: lov nr.

Læs mere

Indstilling Master i IT-sikkerhed. Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI

Indstilling Master i IT-sikkerhed. Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI Indstilling Master i IT-sikkerhed Jette Lundin it-vest leder på Handelshøjskolen Lektor på IFI Baggrund Med it i alting, Supply Change Management, netværksorganisationer og med systemer sammensat af kommunikerende

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Fælles Bibliotekssystem

Fælles Bibliotekssystem Fælles Bibliotekssystem Møder med leverandører af 3. partssystemer, der integrerer til FBS Afholdt d. 22. og 23. oktober 2014 Spørgsmål til organisation, rammeplan og tilslutningsforløb: 1. Hvem leverer

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

Sådan udstiller du dine data

Sådan udstiller du dine data Sådan udstiller du dine data Teknisk vejledning til at sætte Offentlige Data I Spil Version 1.0, august 2010 > Sådan udstiller du dine data Teknisk vejledning til at sætte Offentlige Data I Spil Udgivet

Læs mere

It-sikkerhedstekst ST7

It-sikkerhedstekst ST7 It-sikkerhedstekst ST7 Overdragelse af faktorer ved udstedelse af et personligt login til en identificeret fysisk Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST7 Version 1 Februar

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet

DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet DI og DI ITEKs vejledning om beskyttelse mod elektronisk industrispionage fra udlandet Sammenfatning Denne vejledning adresserer risikoen for industrispionage fra statssponserede aktører i udlandet mod

Læs mere

Information til nye kunder

Information til nye kunder Indhold I denne mini- guide finder du svarene på de spørgsmål, vi oftest bliver stillet, når pleje.net skal implementeres. Guiden er inddelt i seks afsnit, som indeholder: 1. Oprettelse af brugere og brugergrupper

Læs mere

Brugervejledning. Generering af nøgler til SFTP-løsningen vedrørende. datakommunikation med Nets. Nets A/S - versionsdato 28.

Brugervejledning. Generering af nøgler til SFTP-løsningen vedrørende. datakommunikation med Nets. Nets A/S - versionsdato 28. Nets A/S Lautrupbjerg 10 P.O. 500 DK-2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu CVR-nr. 20016175 Brugervejledning Generering af nøgler til SFTP-løsningen vedrørende datakommunikation

Læs mere

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

Læs mere

Version 1.0 Januar 2011. Xerox Phaser 3635MFP Extensible Interface Platform

Version 1.0 Januar 2011. Xerox Phaser 3635MFP Extensible Interface Platform Version 1.0 Januar 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX og XEROX and Design er varemærker tilhørende Xerox Corporation i USA og/eller andre lande Der foretages regelmæssigt ændringer

Læs mere

Nets - Medarbejder Signatur

Nets - Medarbejder Signatur Nets - Medarbejder Signatur Nets Direkte Kommunikation Nøgle Bestilling Version: 2.1, Oktober 2013 Continia Software a/s Hjulmagervej 55 DK-9000 Aalborg Denmark Tel. +45 82 30 50 00 Support mail: cm@continia.dk

Læs mere

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE 1 Tekniske Krav 1.1 Hardware krav: En skærm gerne med touch Hvis skærmen ikke har touch, skal du bruge et tastatur og en mus Webcam Gerne i HD En ekstern lydenhed

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

It-revision af selvejende institutioner Seminar i Rigsrevisionen den 5. maj 2015

It-revision af selvejende institutioner Seminar i Rigsrevisionen den 5. maj 2015 It-revision af selvejende institutioner Seminar i Rigsrevisionen den 5. maj 2015 Hvem er vi? It-revisor Claus. B. Jensen, CISA, CIA Lang erfaring med it-revision i bl.a. pengeinstitutter og forsvaret Ansat

Læs mere

Login-tiden, Første gang tager det måske 1 ½ - 2 min. Andet gang ½ - 1 ½ min...9

Login-tiden, Første gang tager det måske 1 ½ - 2 min. Andet gang ½ - 1 ½ min...9 Ver. 1.8 RDS Side: 1 af 27 Indhold: Inden du kan benytte RDS-løsningen, skal din PC være opdateret...2 Login på RDS-løsningen...3 Login-tiden, Første gang tager det måske 1 ½ - 2 min. Andet gang ½ - 1

Læs mere

Sikkerhed i trådløst netværk

Sikkerhed i trådløst netværk Sikkerhed i trådløst netværk Når du opsætter et trådløst netværk betyder det at du kan benytte dit netværk uden at være forbundet med kabler, men det betyder også at andre kan gøre det samme, hvis du ikke

Læs mere

ATP WS Provider Profile

ATP WS Provider Profile ATP WS Provider Profile Author: Integration Expert Team (IET) (IET) Subject: ATP WS provider profile Page 1 of 16 1. Dokumenthistorik ATP WS Provider Profile Revisioner Dato for denne version: 13.11.2014

Læs mere

Introduktion til brugeradministratorer i SEB v2

Introduktion til brugeradministratorer i SEB v2 Indledning Dette dokument er en introduktion til brugerstyringssystemet SEB. Dokumentet tager udgangspunkt i en brugeradministrators opgaver. SEB består overordnet af to dele 1) En fælles loginside som

Læs mere

Kontorchef Cecile Christensen, Center for sikkerhed og systemforvaltning. 5. november 2014 1

Kontorchef Cecile Christensen, Center for sikkerhed og systemforvaltning. 5. november 2014 1 Tilgængelighed, fortrolighed og integritet. Høj kvalitet i informationssikkerhed og dokumentation Hvilken betydning har principper og anbefalinger i sikkerhedsstandarden ISO 27001 for kvaliteten af dokumentationen?

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

Bilag 1 Kundens opgavebeskrivelse

Bilag 1 Kundens opgavebeskrivelse Bilag 1 Kundens opgavebeskrivelse Side 2 af 12 Indhold 1. Indledning... 3 1.1. Baggrund og formål... 3 1.2. Vision og mål... 3 1.3. Målgruppe... 3 2. Begreber... 4 2.1. Begrebsliste... 4 3. Opgavebeskrivelse...

Læs mere

Anbefalinger til interaktionsdesign og brugervalg af applet

Anbefalinger til interaktionsdesign og brugervalg af applet Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Anbefalinger til interaktionsdesign og brugervalg af applet Nets DanID

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Symantec - Data Loss Prevention

Symantec - Data Loss Prevention Symantec beskyttelse af data/dokumenter Beskrivelsen af Symantecs bud på tekniske løsninger. I beskrivelsen indgår tre følgende løsninger fra Symantec: - Data Loss Prevention - Disk eller ekstern device

Læs mere

Opsætning af Outlook til Hosted Exchange 2003

Opsætning af Outlook til Hosted Exchange 2003 Opsætning af Outlook til Hosted Exchange 2003 Sådan opsættes Outlook 2007 til Hosted Exchange 2003 Opdateret 15. november 2011 Indhold 1 Indledning... 2 2 Opsætning af Outlook 2003... Error! Bookmark not

Læs mere

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Side 1 af 5 Vejledning 2. august 2013 NITRI Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Indholdsfortegnelse Formål...2 Virksomhedssignatur...2 Funktionssignatur...3

Læs mere

Trimble Access Service (Sync)

Trimble Access Service (Sync) Vejledning i opsætning af Trimble AccessSync Trimble har ved Dimensions November 2012 ændret deres forretningsmodel med hensyn til deres AccessSync funktionalitet. Tidligere har det krævet et særskilt

Læs mere

Databehandleraftale 2013

Databehandleraftale 2013 Databehandleraftale 2013 For kunder, som anvender hostede/saas INNOMATE HR løsninger 1, forpligter INNOMATE a/s sig på følgende Databehandleraftale: 1. I overensstemmelse med Persondataloven, er INNOMATE

Læs mere

Instrukser for brug af it

Instrukser for brug af it it sikkerhed Instrukser for brug af it Må Skal ikke Kan Januar 2010 Version 1.0 Indhold Forord................................................... 3 Resumé.................................................

Læs mere

Projekt: VAX NemHandel 4.0

Projekt: VAX NemHandel 4.0 Ejer: mysupply ApS Projekt: VAX NemHandel 4.0 Emne: Dette dokument beskriver de tekniske specifikationer for VAX NemHandel 4.0 samt krav til miljøet, herunder hardware og software, hvori VAX NemHandel

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Forbruger login med NemID Til forbrugsdata på DataHub

Forbruger login med NemID Til forbrugsdata på DataHub Forbruger login med NemID Til forbrugsdata på DataHub 2. maj 2012 JHH Testdrejebog Udført for: Energinet Tonne Kjærsvej 65 7000 Fredericia Steen Jungdal Udført af: Signaturgruppen A/S IT-huset Åbogade

Læs mere

Når du udstiller dine data

Når du udstiller dine data Når du udstiller dine data Juridisk vejledning i at sætte Offentlige Data I Spil Version 1.0, november 2010 > Når du udstiller dine data Juridisk vejledning i at sætte Offentlige Data I Spil Udgivet af:

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

Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes. Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5.

Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes. Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5. Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5. maj 2015 Den nuværende persondatalov Fra år 2000, løbende smårevisioner

Læs mere