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

Størrelse: px
Starte visningen fra side:

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

Transkript

1 > Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne IT- & Telestyrelsen, Kontor It-infrastruktur og Implementering februar 2010

2 Indhold > 1 Introduktion Føderationsfordele 4 2 Arkitekturkomponenter 6 3 Grundlæggende scenarie 8 4 Overvejelser Oprette tillidsforhold Metadata udveksling Repræsentation af adgangsrettigheder Identity Provider discovery-funktion 11 5 Identity Provider integration Autentifikation af bruger Opbevarelse af information om adgangsrettigheder Overvejelser ved oprettelse af netværk 15 6 Service Provider integration Adgangskontrol Integration med lokale adgangskontrolsystemer Overvejelser ved oprettelse af netværk 18 Appendix A: References 19

3 Dokument Historie Version Dato Initialer Ændringer TG Dokument oprettet

4 1 Introduktion > Denne guide beskriver hvordan to organisationer kan indgå i en føderation vha. den danske OIOSAML-profil af OASIS SAML-standarden 1. Fokus vil være på den offentlige sektor, men teknikkerne kan også bruges i andre sektorer. Den grundlæggende ide bag konceptet sammenhængende login er at ansatte i organisation (A) kan tilgå (web-)applikationer stillet til rådighed af organisation (B) i et andet sikkerhedsdomæne sømløst og sikkert uden at skulle logge på eller anskaffe en ny brugerkonto hos (B). OIOSAML løser dette problem ved at levere arkitekturkomponenter og protokoller. Denne guide beskriver hvordan offentlige organisationer kan oprette føderationer i praksis samt integrere med en eksisterende infrastruktur såsom LDAP register. Figur 1: Føderationskonceptet Bemærk at OIOSAML også bruges i andre føderationsscenarier hvor en central tredjepart er ansvarlig for at autentificere brugere (f.eks NemLog-in løsninger). Scenariet bruges ofte for borgerrettede applikationer, hvor brugeren ikke tilhører en reel organisation, som kan stå inde for vedkommendes identitet. Disse scenarier er ikke en del af denne guide, som udelukkende fokuserer på identity providers i lokale organisationer. 1.1 Føderationsfordele Der er mange fordele ved at bruge de føderationsmekanismer, der vil blive beskrevet i denne guide: 1 Security Assertions Markup Language se [SAMLCore] for detaljer. 4

5 > Brugeradministrationen reduceres. En organisation, der stiller en applikation (B) til rådighed, behøver ikke administrere en anden organisation(a) s brugere/ansatte samt deres rettigheder til at bruge applikationen. I stedet bliver brugere administreret i deres egen organisation, hvilket betyder en reduktion i den administrative byrde. Bedre sikkerhed. Når brugerne er administreret i deres egen organisation bliver sandsynligheden for, at deres rettigheder er korrekte væsentligt forøget, hvilket forbedrer sikkerheden. Hvis f.eks. en ansat i organisation(a) skifter stilling eller forlader organisationen, er det sandsynligt at den lokale administrator bliver kontaktet og sørger for at opdatere adgangsrettighederne. Nogle organisationer har endda udrullet identitetstyringssystemer, som sørger for at adgangsrettigheder automatisk bliver opdateret, når en ansats stamdata ændres (f.eks i en HR database). Hvis ansatte har brugerkonti hos andre organisationer, er sandsynligheden for at deres adgangsrettigheder bliver opdateret meget mindre. Mindre udgifter til integration. Integration med OIOSAML er baseret på åbne, internationale standarder, hvilket sænker udgiften til integration. Hvis offentlige organisationer fødererer med flere forskellige partnere, kan de samme integrationskomponenter genbruges. Kommercielle standardprodukter og gratis open source referenceimplementationer af OIOSAML er tilgængelige [REFIMPL]. Brugeroplevelsen bliver forbedret. Brugere undgår at blive tildelt nye brugerkonti for hver applikation, de skal bruge (f.eks. nyt bruger ID og password, som de skal huske og ændre med jævne mellemrum). Derudover opnår de single sign-on, så de ikke behøver at logge ind gentagne gange på en arbejdsdag, hvilket betyder at brugerens oplevelse og produktivitet forbedres. Portaler kan samle applikationer sømløst. Ved at opnå single-sign on til (web)applikationer er det muligt at bygge portaler, der samler og integrerer adskillige applikationer fra forskellige organisationer. Hvis applikationerne er integreret i portalen via en web-browser (f.eks. iframing eller link), er det ikke nødvendigt at modificere applikationer der bruger SSO, men er udviklet til selvstændigt brug, for at applikationerne kan bruges i en portal. Den danske borgerportal (borger.dk) og virksomhedsportal (virk.dk) er eksempler på portaler, der bruger integration via web-browser. 5

6 2 Arkitekturkomponenter > Før de forskellige scenarier kan blive beskrevet, skal de individuelle roller og komponenter i arkitekturen præsenteres. SAML Identity Provider Denne komponent bliver udrullet i organisationer, hvor medarbejderne har brug for adgang til applikationer hos andre organisationer. Identity Provider-komponenten kan autentificere lokale bruger og derefter udstede en såkaldt SAML assertion (se herunder), som identificerer brugeren og hans rettigheder overfor applikationer i et andet sikkerhedsdomæne. Dvs. at Identity Provider attesterer de lokale brugeres identiteter overfor andre organisationers applikationer. Når Identity Provider har brug for at autentificere en lokal bruger, kan brugeren logge ind direkte med sine brugeroplysninger, eller organisationen kan gøre brug af en SSOmekanisme såsom Kerberos. Autentifikation overfor Identity Provider er dog udenfor rammerne af OIOSAML. Det kan være nødvendigt for Identity Provider at hente en brugers adgangsrettigheder, når den skal lave en SAML assertion f.eks. fra et LDAP register, hvor den lokale organisation administrerer lokale brugere. Dette er også udenfor rammerne af OIOSAML. Flere detaljer om integration af SAML Identity Provider-komponenter vil kunne ses senere i denne guide. SAML Service Provider Denne komponent bliver udrullet i organisationer, der tilbyder webapplikationer til andre organisationer. Komponenten arbejder sammen med Identity Provider i brugerens egen organisation for at autentificere brugeren og få adgangsrettigheder, som kan bruges til at afgøre, om brugeren har adgang til applikationen. Dvs. at Service Provider stadig definerer og kontrollerer adgangen til applikationer, mens Identity Provider kun tildeler rettigheder til brugere. SAML Service Provider og SAML Identity Provider stoler på hinanden og kommunikerer i overensstemmelse med protokoller defineret i OIOSAML. Før de kan kommunikere, skal de 2 komponenter udveksle metadata som beskriver kommunikations-endpoints(url er), certifikater til digital signaturer og kryptering, understøttede attributter etc. SAML Assertion En SAML assertion er et XML-dokument, som dannes af Identity Provider ved modtagelse af en forespørgsel om autentificering af en bruger fra en Service Provider. Den indeholder information om brugerens identitet, hvornår brugeren blev autentificeret, styrken af autentifikationen og attributter om brugeren, der kan indeholde information om adgangsrettigheder forventet af Service Provider (f.eks. roller). OIOSAML definerer indholdet af assertions i den offentlige sektor samt et antal standardiserede identitetsattributter. Da information om adgangsrettigheder varierer fra implementation til implementation, er attributterne ikke defineret i OIOSAML og må defineres lokalt enten efter aftale mellem en lokal Identity Provider og Service Provider eller for en sektor (f.eks. sundhedssektoren). OIOSAML opstiller regler for hvordan lokale attributter skal defineres, bl.a. navngivningskonventioner. 6

7 > Applikation Applikationen er en webapplikation eller portal der kræver brugerautentifikation før beskyttede ressourcer kan tilgås. I scenarierne herunder er autentifikationsprocessen delegeret til separate SAML Service Provider-komponenter (som til gengæld delegerer til en Identity Provider-komponent i brugerens organisation). Service Provider-funktionaliteten kan også implementeres direkte i applikationen. 7

8 3 Grundlæggende scenarie > Herunder er et grundlæggende scenarie beskrevet, som illustrerer hvordan en bruger i en organisation kan bruge en lokal SAML 2.0-baseret Identity Provider til at få adgang til applikationer i et andet sikkerhedsdomæne. Scenariet vil være et vejledende eksempel igennem hele dette dokument, og de efterfølgende afsnit vil præcist beskrive forskellige aspekter af dette scenarie især integration med SAML-komponenter. I figur 2 er den lokale autentifikationsløsning i brugerens organisation et Active Directory (Kerberos), men andre løsninger kan også bruges. Figur 2: Flow i det grundlæggende scenarie Trinene er som følger: 1. Brugeren logger ind til sit lokale netværk i starten af en arbejdsdag. 2. På et tidspunkt laver brugeren via sin browser en forespørgsel til en webapplikation, der stilles til rådighed af organisation B. 3. Applikationen kræver autentifikation og autorisation af brugeren, så applikationen videresender brugeren til dens lokale SAML-baserede autentifikationsserver. 4. Autentifikationserveren finder brugerens Identity Provider (Discoverymekanismen bliver beskrevet senere) og sender en SAML autentifikationsforespørgsel til den. 5. SAML Identity Provider autentificerer brugeren via den lokale domain controller og henter information om brugerens adgangsrettigheder frem fra det lokale register, som er relevant for organisation B. Derudover laver den en session med brugeren og sætter sin identifikator i brugerens common domain cookie. 6. SAML Identity Provider laver en SAML 2.0 assertion der indeholder brugerens autentifikations- og autorisationsinformation og returnerer den. 8

9 > 7. SAML-serveren hos organisation (B) validerer den tilsendte SAML assertion, udtrækker information om adgangsrettigheder, omformaterer om nødvendigt informationen til et internt format, og returnerer det. 8. Applikationen laver en session med brugeren og ekspederer forespørgslen baseret på brugerens identitet og den supplerede adgangsrettighedsinformation. Forudsætningerne og antagelserne i det ovenstående scenarie er: At organisation (B) stoler på organisation A s autentifikation af deres egne brugere og administration af adgangsrettigheder til applikationer. De 2 organisationer har udvekslet SAML metadata, herunder hvilke adgangsrettigheder (grupper, roller, privilegier), organisation (B) behøver. Organisation (B) har skilt sin SAML-implementation ud fra applikationen (trin 3). I nogle tilfælde kan SAML-implementationen være direkte indlejret i applikationen. Administratorer i organisation A har tildelt de påkrævede adgangsrettigheder til lokale brugere. Service Provider (org. B) kan afgøre hvilken Identity Provider, den skal sende autentifikationsforespørgslen til (se discovery-funktionalitet nedenunder). SAML Identity Provider i organisation (A) skal kun bruge den lokale domain controller til bruger autentifikation ved første anvendelse. Derefter har den sin egen session med brugeren og kan udstede et token automatisk. 9

10 4 Overvejelser > Dette kapitel beskriver en række overvejelser, der er relevante, når man skal oprette en føderation mellem organisationer i den offentlige sektor. OIOSAML vedrører kun arkitektur, protokoller og policies, men der er mange andre ting at overveje, eksempelvis juridiske og organisatoriske spørgsmål, hvordan adgangsrettigheder bliver repræsenteret, og integration med den eksisterende infrastruktur. 4.1 Oprette tillidsforhold En grundlæggende forudsætning i en føderation er, at der er et tillidsforhold mellem Identity Provider og Service Provider. F.eks. skal en Service Provider have tillid til at Identity Provider autentificerer brugere korrekt, at Identity Provider kan stå inde for brugernes identitet, tildele de rigtige adgangsrettigheder, samt drive et sikkert system og følge aftalte procedurer og politikker. Som udgangspunkt skal enhver Identity Provider, der ønsker at deltage i den fællesoffentlige føderation, indgå en aftale med sekretariatet for det fællesoffentlige brugerstyringssamarbejde i Økonomistyrelsen. Føderationen har defineret en række krav, der skal mødes af alle Identity Providere i føderationen, herunder tekniske krav, sikkerhedskrav og krav til logning, tid etc. Når en Identity Provider har opfyldt disse føderationskrav, bliver dens metadata føjet til en såkaldt white list på den fællesoffentlige føderations netsted. Her kan en Service Provider undersøge om en Identity Provider findes på føderationens white list og dermed have tillid til, at føderationskravene er opfyldt Lokale aftaler En Service Provider-organisation vil typisk kræve en godkendelse af et sæt vilkår og betingelser for brug af deres applikationer, som går ud over føderationskravene (som er applikations- og datauafhængig). Omvendt kan en Identity Provider-organisation også have krav til Service Provider f.eks. angående kvalitet af service, fordi den givne applikation kan være kritisk for Identity Provider-organisationens forretningsprocesser. Hvis det er tilfældet, er det nødvendigt at lave en lokal aftale mellem Identity og Service Provider. Aftalen kan regulere mange områder bl.a. roller og ansvar, procedurer, kvalitet af service, sikkerhedskrav såsom til adgangskontrol til applikationen, krav til håndtering af følsomme data udstillet af applikationen, og krav til Identity Provider-organisationen om korrekt håndtering af brugeradgang til applikationen i henhold til Service Providers procedurer. 4.2 Metadata udveksling Efter tillidsforhold og juridiske aftaler er blevet oprettet mellem organisationerne, er det nødvendigt at udveksle metadata mellem Identity og Service Provider (dvs.importere partnerens metadatafil i sit eget system). En organisations metadatafil indeholder teknisk information om SAML installationen såsom end-points (URL er) for SAML services, certifikater brugt til signering og kryptering og understøttede attributter. Formatet for metadata er standardiseret og yderligere specificeret i OIOSAML. 10

11 > Ved at importere partnerens metadatafil er et teknisk tillidsforhold implicit etableret. Dvs. at SAML servere nu vil acceptere og bruge SAML forespørgsler signeret af partnerens digitale signatur. 4.3 Repræsentation af adgangsrettigheder Mange applikationer kræver ikke kun brugerautentifikation, men også information om brugerens adgangsrettigheder, hvilket kan være gruppemedlemskab, roller eller privilegier til at differentiere adgang. Hos lokale Identity Provider-organisationer bør information om adgangsrettigheder administreres af en lokal administrator i brugerens egen organisation. For at dette scenarie skal virke, skal Service Provider på forhånd kommunikere til Identity Provider hvilke informationer om adgangsrettigheder, der er påkrævet, såvel som semantik og procedurer. F.eks kan en applikation påkræve en attribut rolle som kan have værdierne bestyrer, indkøber, admin eller almindelig_ansat. Dette kommunikeres til Identity Provider, som skal sørge for at den lokale administrator internt tildeler disse roller til brugere, som har brug for adgang til applikationen, og at de tildelte roller ved afvikling bliver inkluderet i de udstedte SAML assertions til denne applikation. Service Provider skal definere den påkrævne adgangsrettighed som et sæt SAML attributnavne med associerede værdier, som kan blive inkluderet i en SAML assertion. For at undgå overlappende attributnavne kræver OIOSAML, at attributnavne defineret af en organisation (f.eks. Service Provider) er en URL med organisationens domænenavn som præfiks. Eksempel: <saml:attribute Name= urn:dk:dmp:attributes:roles NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <saml:attributevalue>miljoe_natur_naturdata_fdc,miljoe_natur_naturdata_laes </saml:attributevalue> </saml:attribute> Service Provider-organisationen kan have flere applikationer, som hver har et forskelligt sæt adgangsrettighedsattributter. For ikke at blotlægge denne kompleksitet til alle organisationer, som bruger applikationen, kan man bruge role mapping. Det betyder, at Service Provider udadtil kun kræver, at Identity Provider bruger nogle få konsoliderede roller, som internt oversættes til applikationsroller, for på denne måde at skærme af for kompleksiteten. Service Provider-krav til adgangsrettighedsattributter kan blive kommunikeret som metadata eller via en out-of-band mekanisme til Identity Provider. En SAML metadatafil kan f.eks. indeholde et <AttributeConsumingService> element, som er en liste med attributnavne krævet af en applikation. 4.4 Identity Provider discovery-funktion Et centralt spørgsmål er hvordan en Service Provider finder en brugers Identity Provider, når brugeren prøver at tilgå en applikation. For afgøre dette, skal en Service Provider gøre følgende: 11

12 > 1. Først skal den prøve at læse common domain cookie (domænet er fobs.dk for den fællesoffentlige føderation) for at undersøge, om den kan identificere brugerens nuværende Identity Provider. Det er obligatorisk for OIOSAMLkompatible Identity Providere at oprette en common domain cookie, når brugeren er autentificeret, således at hvis en bruger har en session med en Identity Provider, vil en common domain cookie være oprettet. 2. Hvis common domain cookie ikke kan identificere en brugers Identity Provider, skal Service Provider bede brugeren om at vælge en Identity Provider fra en liste af Identity Providere, som den har fødereret med (brugeren vælger sin egen organisation). Common domain cookie i OIOSAML er transient, hvilket betyder, at den vil blive fjernet når, browseren genstartes. 12

13 5 Identity Provider integration > Dette kapitel beskriver den integration, som normalt er påkrævet af en Identity Provider-organisation. Det antages, at Identity Provider har anskaffet en SAMLkomponent f.eks. enten et kommercielt produkt eller en open source implementation 2. En række overvejelser om integration af eksisterende infrastruktur er beskrevet herunder. Detaljerne i integrationen vil variere en del afhængig af både SAML-produkt og eksisterende infrastruktur for brugerstyring. 5.1 Autentifikation af bruger Identity Provider er ansvarlig for at autentificere lokale brugere, inden den udsteder SAML assertions til applikationen. Det kan gøres på forskellige måder: Autentifikation med brugeroplysninger opbevaret i organisationens LDAP register. Autentifikation vha. single sign-on løsning udrullet i organisationen (f.eks. Kerberos). Autentifikation med digitalt certifikat udstedt af en ekstern Certificate Authority (CA) - f.eks. det danske OCES medarbejdercertifikat. Den valgte autentificeringsmekanisme skal være integreret med et SAML-produkt (f.eks. login siden). De fleste SAML-produkter tillader brugen af tilpassede loginmekanismer og mange understøtter også Kerberos og LDAP registre uden tilpasning (så integrationen er en konfigurationsudfordring, ikke et programmeringsspørgsmål). En vigtig detalje er, at styrken af autenticitetssikringen skal være afspejlet i den udstedte SAML assertion. OIOSAML specificerer en obligatorisk attribut AssuranceLevel, som har en værdi mellem 1 og 4. Jo højere tal, jo højre tillid til den påståede identitet. Normalt korrelerer autentifikation med brugernavn/password til niveau 2 og autentifikation med digital signatur (softwarebaseret) korrelerer til niveau 3, men andre faktorer end autentifikationsmetoden har også indflydelse, såsom proceduren for den initielle autentifikation af brugeren, når akkreditivet skal udstedes. Identity Provider skal analysere hvilken AssuranceLevel, der opnås ved en given autentifikation, og inkludere det i den udstedte assertion. Mere information om AssuranceLevel kan findes i [AUTH-LEV] og [AUTH-LEV2]. Bemærk, at en Servicer Provider kan vælge at give adgang til følsomme applikationer (og data) på baggrund af den AssuranceLevel, der bliver tilskrevet hos Identity Provider. Service Provider skal som følge af kravene i forbindel med føderationstilslutningen lave en risikoanalyse for deres applikationer og data for at fastslå den påkrævede AssuranceLevel. Det betyder, at brugere fra en organisation der implementerer en lav AssuranceLevel muligvis ikke kan tilgå følsomme applikationer. 2 Open source reference implementationer af OIOSAML i Java og.net kan hentes fra 13

14 > 5.2 Opbevaring af informationer om adgangsrettigheder Service Providere kan definere adgangsrettighedsattributter, som Identity Provider organisationen skal tildele brugere og inkludere i de tildelte SAML assertions. Der er flere måder at opbevare denne information på: Adgangsrettigheder kan blive gemt i et brugerkatalog (f.eks. LDAP) som allerede indeholder information om brugere og deres adgangsrettigheder til interne applikationer. En relationel database kan oprettes til formålet. Funktionalitet fra et Identity Provider produkt kan bruges. Valget af, hvilken metode, man skal bruge, vil afhænge af, hvordan organisationen i forvejen administrerer brugere internt. Hvis en organisation eksempelvis har en brugeradministrationsløsning for interne applikationer, kan denne bruges, så der ikke bliver skabt et nyt administrativt område. Derudover skal et Identity Provider-produkt kunne hente informationen, når den skal udstede SAML assertions. De fleste SAMLprodukter kan hente brugerinformation fra mange forskellige slags datakilder, og denne funktionalitet bør overvejes, når et produkt evalueres i forbindelse med en anskaffelse. Herunder er vist et eksempel, hvor information fra en bruger-database bliver inkluderet i en SAML assertion. Når brugeren Bob prøver at tilgå en applikation hos organisation B, laver den lokale Identity Provider hos organisation A en forespørgsel til databasen og finder ud af, at organisation B forventer en attribut ved navn roller, og at værdien tildelt til Bob (af den lokale administrator i organisation A) til denne attribut er manager,administrator. Derfor inkluderer Identity Provider denne som en attribut i den SAML assertion, der bliver sendt til Service Provider. Figur 3: Inkludering af information om adgangsrettigheder fra bruger-database i SAML assertion. En gængs løsning er at opbevare information om adgangsrettigheder i et LDAP directory såsom et Active Directory. Det giver to muligheder: 14

15 > a) Informationen kan gemmes vha. grupper fra Active Directory. b) Informationen kan gemmes som brugerdefinerede attributer til brugerobjektet. Når informationen er gemt som et LDAP gruppemedlemskab (a), vil værdien ofte være gruppens Distinguished Name (DN). Dette kan være problematisk, fordi Service Provider udvælger værdierne til adgangsrettighedsattributter og på den måde direkte gruppe objekter ind i Identity Provider s LDAP. Hvis denne fremgangsmåde er under overvejelse, bør en mapning af DN foretages for ikke at forurene Identity Providers LDAP. Det kan i stedet være en fordel at opbevare information om adgangsrettigheder som brugerdefinerede attributter til brugerobjektet i LDAP (b) eller i en separat relationel database. Generelt bør Service Provider definere attributnavne og -værdier til adgangsrettigheder, som kan gemmes både i LDAP og i relationelle databaser. Til sidst er det muligt at Identity Provider vil opbevare attributter, så de er identificeret med den Service Provider, der skal bruge dem. En assertion til en specifik Service Provider bør kun indeholde de attributter, der er påkrævet af denne. 5.3 Overvejelser om netværk Den server, der hoster Identity Provideren, behøver ikke normalt at være forbundet med internettet fordi kommunikation med Service Provider sker via brugerens browser (med http redirect og post binding). En undtagelse er, hvis en SAML single logout protokol er brugt med en SOAP binding (som er valgfrit i OIOSAML). Det betyder, at Identity Provider komponenten ofte kan installeres i en intern netværkszone (f.eks. en zone dedikeret til servere, som også hoster brugerkataloget, så kataloget kan bruges til brugeridentifikation). Hvis der er brug for en single logout via SOAP binding, skal Identity Provideren placeres i en netværkszone, der tillader både ind- og udgående forbindelser til/fra internettet. Dette kan enten være en demilitariseret zone 3 (DMZ) eller en speciel zone afhængigt af den brugte netværkstopologi. Når man installerer en Identity Provider komponent, er det meget vigtigt at beskytte den private nøgle, der bruges til at signe assertions med, da dette er systemets kronjuvel. Hvis det lykkes en hacker at stjæle den private nøgle, kan han lave sine egne SAML assertions og tilgå Service Provider applikationer på vegne af enhver bruger i Identity Provider organisationen. Derfor, hvis den private nøgle er gemt i en fil, bør den adgangsbeskyttes vha. de muligheder, styresystemet stiller til rådighed, samt krypteres med et password af høj kvalitet. 3 En DMZ tillader normalt ikke udgående forbindelser til internettet ifølge best practice, så alle undtagelser i firewall bør afgrænses til en bestemt server for en bestemt port. Mange organisationer har sandsynligvis allerede netværkszoner, der tillader udgående forbindelser. 15

16 6 Service Provider integration > Dette kapitel beskriver den integration, som normalt er påkrævet af en Service Provider-organisation. Det antages, at Service Provider har anskaffet en SAMLkomponent f.eks. enten et kommercielt produkt eller en open source implementation 4. En række overvejelser om integration af eksisterende infrastruktur er beskrevet herunder. Detaljerne i integrationen vil variere en del afhængigt af både SAML-produkt og eksisterende infrastruktur for brugerstyring. 6.1 Adgangskontrol Inden en Service Provider udstiller applikationer til eksterne brugere, bør den analysere sine krav til sikkerheden af brugerautentifikationen og udfærdige en politik for adgangskontrol. Som tidligere nævnt er AssuranceLevel et udtryk for, hvor sikker man kan være på, at en brugers påståede identitet er korrekt. Den afhænger af både organisationens procedurer og kontrol så vel som tekniske mekanismer. En Service Provider skal som det første klassificere sine applikationer (se AUTH-LEV2) for at afgøre, hvilke sikkerhedskrav, der skal opfyldes for at få adgang. Det vil f.eks. afhænge af hvilke data, applikationen udstiller. Identity Provider kan informere om AssuranceLevel for den nuværende bruger via SAML assertions. Service Provider skal konfigurere sit system til at undersøge denne attribut og kun give adgang til applikationer, hvis sikkerhedskravet er opfyldt. Ydermere skal Service Provider analysere sine applikationer for at afklare, hvilke privilegier, der er påkrævet. Eksempelvis kan en applikation kræve, at brugeren har en bestemt rolle, er medlem af en bestemt gruppe etc. Hvis Service Provider udstiller applikationer med forskellige krav, kan det være en fordel at definere et sæt abstrakte, konsoliderede roller (synlige for Identity Provider) og mappe dem til interne applikationsroller (usynlige for Identity Provider). Adgangskontrollen skal kommunikeres til Identity Provider organisationen, så privilegier kan blive konfigureret i systemet og tildelt til brugere. Information om de påkrævne SAML attributter (syntaks) kan være en del af metadatafilen eller blive kommunikeret på anden måde. Dog er en beskrivelse ofte nødvendig for at forklare hvordan adgangsrettigheder skal tildeles af brugeradministratorer. 6.2 Integration med lokale adgangskontrolsystemer Brugerens identitet og adgangsprivilegier modtages via en SAML assertion fra Identity Provider ved runtime. Service Provider skal bruge den information til at afgøre, om brugeren skal have adgang til den efterspurgte applikation eller ej. Det medfører at en form for integration mellem SAML-komponenten og adgangskontrolkomponenten 5 er nødvendig (medmindre de ikke er en del af det 4 Open source referenceimplementationer af OIOSAML i Java og.net kan hentes fra 5 Dette komponent kaldes et Policy Enforcement Point (PEP). 16

17 > samme system). Integrationen vil afhænge af, hvordan Service Provider håndterer adgangskontrol i sin it-arkitektur. Adgangskontrol kan f.eks. håndteres på følgende måder: a) Det kan være en del af et SAML-produkt (f.eks. en access control suite der understøtter SAML). b) Der kan være en separat server, der varetager adganskontrollen for alle organisationens applikationer (f.eks. en reverse proxy, der kun tillader forespørgsler at passere, hvis de er i overenstemmelse med specifikke krav). c) Den kan varetages af applikationsserveren (container), der hoster applikationen (f.eks. J2EE deklarativ sikkerhed). d) Den kan varetages af selve applikationen (ikke anbefalet, men meget almindeligt). En typisk metode er at få SAML-komponenten til at validere SAML assertions først og derefter videresende vigtig information som key/value-par til processering hos en separat server, der varetager adgangskontrol: Figur 4: Et eksempel på en adgangskontrolkomponent Et andet typisk integrationsmønster (punkt c) er at skrive plug-ins til middleware i den bagvedliggende applikationsserver, som implementerer autentifikation og adgangskontrol såkaldte Pluggable Authentication Modules (PAMs). Ideen er at adskille autentifikations- og autorisationslogik, så det senere hen kan blive erstattet, uden at det er nødvendigt at røre ved applikationerne. Disse plug-ins er som regel realiseret ved at implementere nogle få klasser med fast definerede snitflader, der tillader servermiddleware at forespørge efter informationer om f.eks. brugeridentitet, gruppemedlemsskab og roller. På den måde er kun det plugin, der behøver at kende brugeren, og middleware varetager resten, bl.a. sessionshåndtering og adgangskontrol vha. af prædefinerede adgangspolitikker. Dette er illustreret i figuren herunder, hvor en specialfremstillet SAML-plug-in (den røde boks) gør det muligt at føderere med adskillige applikationer. Læg mærke til at en forudsætning for denne integration er, at applikationer er blevet designet til at uddelegere brugerstyring til applikationsserveren (f.eks. vha. deklarativ sikkerhed). Hvis applikationerne har indkodet egen adgangskontrollogik, skal dette nødvendigvis kodes om. 17

18 > Figur 5:Specialfremstillet plug-in til applikationsserver Eksempler på plug-in-arkitekturer er RoleProvider og MembershipProvider i ASP.Net og JAAS-moduler i Java. Kodeeksempler med.net plug-ins til Umbraco CMS vha. OIOSAML.NET referenceimplementationen kan findes på Softwarebørsen Overvejelser ved netværk Den server, der hoster Service Provider-komponenten, behøver ikke normalt at være forbundet med internettet fordi kommunikation med Identity Provideren sker via brugerens browser (med http redirect og post binding). En undtagelse er, hvis en SAML single logout protokol er brugt med en SOAP binding (som er valgfrit i OIOSAML). Det betyder, at Service Provider-komponenten ofte kan installeres i en intern netværkszone. Hvis der er brug for en single logout protokol via SOAP binding, skal Service Provideren placeres i en netværkszone, der tillader både ind- og udgående forbindelser til/fra internettet. Dette kan enten være en demilitariseret zone eller en speciel zone afhængigt af den brugte netværkstopologi. Når man installerer en Service Provider-komponent, er det meget vigtigt at beskytte den private nøgle, der bruges til at signere autentifikationsforespørgsler og dekryptere svar. Hvis det lykkes en hacker at stjæle den private nøgle kan han dekryptere assertions og tilegne sig viden om indholdet af følsomme attributter. Hvis den private nøgle er gemt i en fil, bør den derfor beskyttes vha. de muligheder, styresystemet stiller til rådighed og krypteres med et password af høj kvalitet

19 Appendix A: Referencer > [OIOSAML] [SAMLCore] [SAMLGlos] [AUTH-LEV] [AUTH-LEV2] [REFIMPL] OIO Web SSO Profile V2.0.6, IT- og Telestyrelsen. Assertion and Protocols for the OASIS Security Assertion Markup Language 2.0, OASIS Standard os.pdf Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard. Vejledning vedrørende niveauer af autenticitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-inløsning, Økonomistyrelsen, Version Referenceimplementationer af OIOSAML i Java og.net: 19

20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lokal implementering af Identity Provider

Lokal implementering af Identity Provider Lokal implementering af Identity Provider En vejledning til kommunernes og ATP's opgaver Version 1.1, december 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tel 24 96 26 38 www.kombit.dk Email kmj@kombit.dk

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

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

Guide til Føderationstilslutning ( kogebog )

Guide til Føderationstilslutning ( kogebog ) Side 1 af 36 27. juli 2009 Guide til Føderationstilslutning ( kogebog ) Version 1.1 Denne guide henvender sig til offentlige myndigheder, der skal tilslutte digitale selvbetjeningsløsninger til NemLog-in.

Læs mere

Notat Konceptmodel for SSO 24-05-2016 ØSY/JESBO/TG

Notat Konceptmodel for SSO 24-05-2016 ØSY/JESBO/TG Notat Konceptmodel for SSO 24-05-2016 ØSY/JESBO/TG FORMÅL Dette notat beskriver et forslag til koncept for Single Sign On-løsning til Moderniseringsstyrelsens kunderettede systemer. Formålet er at beskrive

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

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

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

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

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

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

Guide til føderationstilslutning ( kogebog )

Guide til føderationstilslutning ( kogebog ) Side 1 af 28 1. februar 2008 Guide til føderationstilslutning ( kogebog ) UDKAST- version 0.70 Denne guide henvender sig til offentlige myndigheder samt andre, der skal tilsluttes den fællesoffentlige

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

Version 1.4. Integrationstest ved tilslutning til NemLog-in. Side 1 af 29 19. april 2013

Version 1.4. Integrationstest ved tilslutning til NemLog-in. Side 1 af 29 19. april 2013 Side 1 af 29 19. april 2013 Integrationstest ved tilslutning til NemLog-in Version 1.4 Dette dokument henvender sig til udbydere af it-systemer (eksempelvis offentlige myndigheder), der skal tilsluttes

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

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

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

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

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

Udvidet brug af personligt NemID i erhvervssammenhæng

Udvidet brug af personligt NemID i erhvervssammenhæng Udvidet brug af personligt NemID i erhvervssammenhæng Side 1 af 10 16. juni 2016 TG Baggrund Digitaliseringsstyrelsen planlægger i samarbejde med Erhvervsstyrelsen at gennemføre nogle ændringer i NemLog-in

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

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

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

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

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

Lokal implementering af Identity Provider

Lokal implementering af Identity Provider Lokal implementering af Identity Provider En vejledning til kommunernes og ATP s opgaver Version 1.0 februar 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

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

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

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

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

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

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

Single sign-on cases. SolutionsDay 2011. Morten Strunge Nielsen msn@globeteam.com. Globeteam Virumgårdsvej 17A 2830 Virum

Single sign-on cases. SolutionsDay 2011. Morten Strunge Nielsen msn@globeteam.com. Globeteam Virumgårdsvej 17A 2830 Virum Single sign-on cases SolutionsDay 2011 Morten Strunge Nielsen msn@globeteam.com Globeteam Virumgårdsvej 17A 2830 Virum SSO og føderation i en nøddeskal Cloud Active Directory? Applikationer Indre net?

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

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

Adgangsstyring er en forudsætning for at benytte en i den fælleskommunale infrastruktur, da brugere og systemer ellers ikke vil få adgang.

Adgangsstyring er en forudsætning for at benytte en i den fælleskommunale infrastruktur, da brugere og systemer ellers ikke vil få adgang. Introduktion til Adgangsstyring 1 Om dokumentet Dette papir formidler et overblik over adgangsstyringen i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af arkitekturen, hvilke

Læs mere

OIOSAML.NET og Umbraco. ved Thomas Ravnholt ravnholt @ silverbullet.dk

OIOSAML.NET og Umbraco. ved Thomas Ravnholt ravnholt @ silverbullet.dk OIOSAML.NET og Umbraco ved Thomas Ravnholt ravnholt @ silverbullet.dk Silverbullet, stiftet 2003 Silverbullet A/S IT- rådgivning, projektledelse og implementering Officiel SKI-leverandør Kontorer i Århus

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

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

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

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

LAKESIDE. Sårjournalen. Ændring af sikkerhedsarkitekturen. Version marts 2015

LAKESIDE. Sårjournalen. Ændring af sikkerhedsarkitekturen. Version marts 2015 LAKESIDE Ændring af sikkerhedsarkitekturen Version. 0. marts 0 LAKESIDE A/S Marselisborg Havnevej,. sal DK-8000 Århus C Denmark tlf. + 07 www.lakeside.dk info@lakeside.dk Indledning Formålet med sidste

Læs mere

Anime Kita Selvbetjening Documentation

Anime Kita Selvbetjening Documentation Anime Kita Selvbetjening Documentation Release 1.0.0 Casper S. Jensen February 16, 2015 Contents 1 System Definition 3 2 Arkitektur 5 2.1 Oversigt................................................. 5 2.2

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

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

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

Kommunernes it-arkitekturråd

Kommunernes it-arkitekturråd FØDERATIVE SIKKERHEDSMODELLER TIL SÅRJOURNALEN (OG ANDRE NATIONALE IT-LØSNINGER PÅ SUNDHEDSOMRÅDET) Kommunernes it-arkitekturråd 18. december 2014 HVEM HAR DELTAGET I ARBEJDET? Arbejdsgruppe: Lars Nico

Læs mere

Sikkerhedsanalyse af WSRP

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

Læs mere

Yderligere information om IRM Her kan du finde en online demo af programmet, brugervejledninger, whitepapers, teknisk information mv.

Yderligere information om IRM Her kan du finde en online demo af programmet, brugervejledninger, whitepapers, teknisk information mv. Oracle Information Rights Management (IRM) Oracle - Information Rights Management (IRM) er en nyere form for informationssikkerhedsteknologi, der kan sikre og spore fortrolige digitale data overalt hvor

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

Dataintegration og Single Sign-On Dataintegration internt og eksternt via service enabled arkitektur på Dansk Landbrugs Internetplatform (DLI)

Dataintegration og Single Sign-On Dataintegration internt og eksternt via service enabled arkitektur på Dansk Landbrugs Internetplatform (DLI) Dataintegration internt og eksternt via service enabled arkitektur på Dansk Landbrugs Internetplatform (DLI) Udarbejdet december 2009 Indhold 1 Indledning... 2 2 Nytteværdig... 3 2.1 Eksempler på applikationer

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

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

Bilag 12. Drift af SUP-systemer. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen

Bilag 12. Drift af SUP-systemer. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen Kan med fordel udskrives på en farveprinter, idet figurerne er i farver. SUP-specifikation, version 2.0 Bilag 12 Drift af SUP-systemer Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af

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

Brugeradministrationssystemet

Brugeradministrationssystemet NOTAT Den 13. december 2006 Version 1.0 Brugeradministrationssystemet Af Jens Ole Back, Chefkonsulent, Kontoret for teknik og miljø, KL Det fællesoffentlige Partnerskab om Danmarks Miljøportal (Partnerskabet)

Læs mere

Brugerstyring i digital post

Brugerstyring i digital post Brugerstyring i digital post Denne vejledning beskriver roller og rettigheder i den digitale post-løsning. Version: 3.0 Udarbejdet: november 2011 Udarbejdet af: Digitaliseringsstyrelsen Vejledningen og

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

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

Specifikationsdokument for LDAP API

Specifikationsdokument for LDAP API 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 Specifikationsdokument for LDAP API DanID A/S 5. juni 2014 Side 1-15

Læs mere

Version 1.2. Integrationstest ved tilslutning til NemLog-in. Side 1 af november 2012

Version 1.2. Integrationstest ved tilslutning til NemLog-in. Side 1 af november 2012 Side 1 af 25 15. november 2012 Integrationstest ved tilslutning til NemLog-in Version 1.2 Dette dokument henvender sig til udbydere af it-systemer (eksempelvis offentlige myndigheder), der skal tilsluttes

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

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

(Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring

(Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring (Af forside skal det fremgå, om standarden er i høring, har været i høring eller er godkendt) Begrebsmodel til brugerstyring Version 1.1 Godkendt 21. januar 2010 1 2 > Begrebsmodel til brugerstyring Denne

Læs mere

Føderal identitet. Morten Strunge Nielsen msn@globeteam.com. Globeteam Virumgårdsvej 17A 2830 Virum

Føderal identitet. Morten Strunge Nielsen msn@globeteam.com. Globeteam Virumgårdsvej 17A 2830 Virum Føderal identitet Morten Strunge Nielsen msn@globeteam.com Globeteam Virumgårdsvej 17A 2830 Virum Agenda Muligheder med føderation Strategiske fordele Taktiske fordele Lidt om teknologien Løsningsmodeller

Læs mere

Understøttelse af LSS til NemID i organisationen

Understøttelse af LSS til NemID i organisationen Understøttelse af LSS til NemID i organisationen Table of contents 1 Dette dokuments formål og målgruppe... 3 2 Introduktion til LSS til NemID... 4 2.1 Forudsætninger hos organisationen... 5 2.1.1 SSL

Læs mere

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010. It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud Region Midtjylland 2010. 1 1 Indledning 1.1 Versionshistorie Version Dato Ansvarlig Status Beskrivelse 1.0 2010-05-04 HENSTI Lukket Definition

Læs mere

Identity Access Management

Identity Access Management Identity Access Management Traditionel tilgang til Identity & Access Governance-projekter, udfordringer og muligheder Alex Sinvani ais@dubex.dk Dubex A/S Formålet Opbygge en god konceptuel baggrund for

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12 Installation og Drift Aplanner for Windows Systemer Version 8.15.12 Aplanner for Windows løsninger Anbefalet driftsopsætning Cloud løsning med database hos PlanAHead Alle brugere, der administrer vagtplaner

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

STS Driftsvejledning. STS Driftsvejledning

STS Driftsvejledning. STS Driftsvejledning STS Driftsvejledning i STS Driftsvejledning STS Driftsvejledning ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.1 2012-11 HT STS Driftsvejledning iii Indhold 1 Introduktion 1 2 Konfigurations opdateringer

Læs mere

Anbefaling til unik Id-nøgle

Anbefaling til unik Id-nøgle Anbefaling til unik Id-nøgle 1 / 15 Kolofon: OIO Referencemodel for tværgående brugerstyring Denne anbefaling kan frit anvendes af alle. Citeres fra anbefalingen i andre publikationer til offentligheden

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

Læs mere

Brugerguide til Stamdatamodulets administrator-gui KOMBIT

Brugerguide til Stamdatamodulets administrator-gui KOMBIT Brugerguide til Stamdatamodulets administrator-gui KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Installation... 4 4 Tilgå Konsollen... 4 5 Opret en ny Serviceaftager... 4 6

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

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

NemLog-in. Kenneth Kruuse, projektleder og serviceansvarlig

NemLog-in. Kenneth Kruuse, projektleder og serviceansvarlig NemLog-in Kenneth Kruuse, projektleder og serviceansvarlig Hvad er NemLog-in? SSO - med mere Formålet med NemLog-in Fællesoffentlig infrastruktur bygger ét sted og stiller komponenter gratis til rådighed

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

Sundhedsdatastyrelsens Elektroniske Indberetningssystem (SEI)

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

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

Sektornet VPN Installationsvejledning Windows Vista/7

Sektornet VPN Installationsvejledning Windows Vista/7 Sektornet VPN Installationsvejledning Windows Vista/7 Version 5.0 Af Jesper Skou Jensen og Mads Udengaard Sørensen 1 Start installationen 1 1 Indledning Denne vejledning gennemgår opsætning af Sektornet

Læs mere

Digitaliseringsstyrelsen

Digitaliseringsstyrelsen KFOBS Release Information Version: 7.0 ID: 32309/43491 2014-04-07 Indhold 1 INTRODUKTION... 4 1.1 PRODUKTIONSMILJØ... 4 1.2 TESTMILJØ... 4 2 NEMLOG-IN... 5 2.1 ÆNDRINGER OG FEJLRETTELSER... 5 2.1.1 Release

Læs mere

DAU REMOTE ACCESS LØSNINGSMULIGHEDER OG TEKNOLOGIER MED REMOTE ACCESS JOHN AMMENTORP

DAU REMOTE ACCESS LØSNINGSMULIGHEDER OG TEKNOLOGIER MED REMOTE ACCESS JOHN AMMENTORP DAU REMOTE ACCESS LØSNINGSMULIGHEDER OG TEKNOLOGIER MED REMOTE ACCESS JOHN AMMENTORP AGENDA 01 Kort præsentation 02 Behov i forbindelse med de 4 dimensioner 03 Koncept for sikker forbindelser 04 Netværkssikkerhed

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

Brugerstyring i Digital Post

Brugerstyring i Digital Post Brugerstyring i Digital Post Denne vejledning beskriver roller og rettigheder i Digital Post Administrationsportalen. Den berører også kort sammenhængen med de roller og rettigheder, der er knyttet til

Læs mere