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

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

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

Transkript

1 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 komponenter, der er spil, deres respektive funktioner, og hvordan de interagerer med hinanden i forskellige scenarier. Målgruppen er primært teknisk-orienterede personer, der har behov for at danne sig et overblik over adgangsstyring på arkitekturniveau. 2 Formål med Adgangsstyring Adgangsstyring er en forudsætning for at benytte en i den fælleskommunale infrastruktur, da brugere og systemer ellers ikke vil få adgang. Adgangsstyringen understøtter tre hovedområder: 1. Adgangsstyring for (person)brugere som gennemgås i afsnit Adgangsstyring for systemer som gennemgås i afsnit Administrationsmodulet som gennemgås i afsnit 7. Understøttelsen af disse tre hovedområder realiseres som hvert sit støttesystem i den fælleskommunale infrastruktur. Første hovedområde adresserer således adgang til web-baserede brugergrænseflader, mens andet hovedområde håndterer adgang til webservices (system-til-system kommunikation). Administrationen for begge forgående hovedområder i adgangsstyringen sker gennem Administrationsmodulet i den fælleskommunale infrastruktur, der udgør et selvstændigt støttesystem. Et af de bærende principper i Administrationsmodulet er, at adgang til myndighedernes data sker på baggrund af serviceaftaler (databehandleraftaler) mellem myndighederne og anvenderne af data. Administrationsmodulet vil på baggrund af opsætning og indgåede aftaler provisionere information om adgange til de to adgangsstyringssystemer, som så vil anvende disse i styringen. Selve administrationen af myndighedens medarbejdere sker lokalt hos myndighederne ved genbrug af eksisterende brugeradministrationsløsninger. Adgangsstyringen håndterer autentifikation og autorisation til systemer tilsluttet den fælleskommunale infrastruktur. Der findes en lang række sikkerhedsrelaterede emner, som ikke behandles i dette papir, eksempelvis fysisk sikkerhed, drift, back-up, politikker etc. Fokus i dette papir er således udelukkende på styring af adgange for brugere og it-systemer. 3 Baggrunden for sikkerhedsmodellen Modellen for adgangsstyring er designet ud fra en række forretningsbehov, lovkrav, arkitekturmæssige overvejelser, teknologiske tendenser, fællesoffentlige standarder samt tekniske muligheder og begrænsninger. I det følgende gennemgås de bagvedliggende overvejelser som et fundament til at forstå, hvorfor modellen ser ud som den gør. Sikkerhedsmodellen er baseret på flg. antagelser og principper: 1. Modellen skal understøtte en effektiv brugeradministration, så myndigheder kan vedligeholde deres medarbejderes adgange lokalt - herunder ved oprettelse og nedlæggelse af brugere samt tildeling af

2 rettigheder. Dette skal kunne ske via de forskellige brugeradministrationssystemer, som myndighederne i forvejen anvender (fx Active Directory, IdM-løsninger etc.) 2. Modellen skal understøtte, at myndighederne organiserer sig forskelligt, således at indholdet af eksempelvis jobfunktioner kan variere. Ligeledes skal myndighederne kunne have forskellige sikkerhedspolitikker, som skal kunne understøttes. 3. En medarbejder agerer på ethvert tidspunkt i kontekst af én organisation (myndighed) defineret ved et ansættelsesforhold, hvori medarbejderen kan udføre et antal jobfunktioner. Hvis personen har flere ansættelsesforhold, vil vedkommende skulle skifte aktivt mellem de forskellige kontekster. 4. De fælleskommunale systemer vil blive afviklet i et driftsmiljø, der er separat fra dels fagsystemerne (f.eks. SAPA) og dels myndighedernes egen infrastruktur. Der er med andre ord tale om en distribueret arkitektur, hvor interaktion foregår på tværs af mindst tre adskilte sikkerhedsdomæner. 5. Al kommunikation mellem sikkerhedsdomæner foregår via internettet (med internetprotokoller) under anvendelse af passende beskyttelse. Der etableres således ikke dedikerede netværk til at understøtte tværgående kommunikation. 6. Brugergrænseflader er web-baserede og tilgås af slutbrugerne via internettet. Traditionelle tykke klienter kan driftsafvikles lokalt hos myndigheder, men vil da tilgå den fælleskommunale infrastruktur via en web service grænseflade (se nedenfor). 7. Webservice grænseflader er SOAP- eller REST-baserede og udstilles ligeledes via internettet (herunder via den fælleskommunale serviceplatform). 8. Sikkerhedsmodellen skal funderes på fællesoffentlige standarder og være understøttet af gængse sikkerhedsprodukter og -værktøjer. Dette muliggør integration med de fællesoffentlige brugerstyringsløsninger udviklet af Digitaliseringsstyrelsen som eksempelvis NemLog-in og NemID. 9. Medarbejdere i myndighederne skal opnå single sign-on til brugervendte systemer, således at de ikke behøver at logge på hele tiden. Dette forudsætter, at de er logget på den kommunale infrastruktur. 10. Håndhævelse af adgange (Policy Enforcement) sker decentralt i det enkelte system. 11. Modellen skal understøtte legacy applikationer, som ikke nødvendigvis fra starten er designet til at kunne indgå i en fødereret model baseret på security tokens. Teknikker til dette beskrives senere i dokumentet. 12. Modellen skal understøtte, at myndigheder udfører jobfunktioner for hinanden via delegering. 4 Den token-baserede model På baggrund af ovenstående principper, behov og antagelser er der valgt en token-baseret model for adgangsstyring. Denne indebærer, at brugere og systemer efter autentifikation får udstedt et såkaldt security token (af en betroet komponent i infrastrukturen), som herefter præsenteres overfor det system eller den service, der ønskes adgang til. Et security token indeholder information om brugerens eller systemets identitet samt tildelte adgangsrettigheder, og det er digital signeret af den betroede udsteder, så det ikke kan forfalskes eller manipuleres. Den token-baserede model er grundlaget for en løst-koblet, fødereret arkitektur, hvor de enkelte applikationer og services kun håndhæver adgang lokalt (på baggrund af information i tokenet), men ikke selv håndterer administration af brugere, anvendersystemer og rettigheder. Modellen indebærer således en forenkling både for brugerorganisationerne (myndigheder) og udbyderne af applikationer og services. Sammenhængen i infrastrukturen sikres ved anvendelse af fællesoffentlige standarder (bl.a. OIOSAML og OIO WS-Trust) suppleret med KOMBIT-specifikke udvidelser, som definerer hvilke attributter, der skal forefindes i security tokens (en såkaldt attributprofil). Valget af den token-baserede model er i tråd med de fællesoffentlige initiativer indenfor brugerstyring og er baseret på de samme fællesoffentlige standarder herunder OIOSAML standarden. Som eksempel på andre offentlige initiativer, der benytter en token-baseret model, kan nævnes NemLog-in (fællesoffentlig brugerstyring), Grunddataprogrammet, Borger.dk, Virk.dk, Danmarks miljøportal, Sundhedsområdet mv. 2 af 24

3 Dette giver mulighed for en række synergier eksempelvis i form af tværgående arbejdsgange mellem domæner, genbrug af fællesoffentlige komponenter (fx digitale fuldmagter), single sign-on på tværs af domæner mv. 5 Adgang til brugervendte systemer Ved styring af brugeradgange opereres med flg. komponenter: Medarbejderne registreres i lokale brugerkataloger hos de myndigheder, hvor de er ansat. Her tildeles de et antal jobfunktionsroller ud fra de arbejdsopgaver, de skal varetage. Myndigheder (og andre brugerorganisationer) skal etablere en såkaldt Identity Provider (dvs. udbyder af identitet). Identity Provideren autentificerer organisationens egne medarbejdere (f.eks. på baggrund af lokalt netværkslogin) og udsteder herefter et security token (en SAML billet), som indeholder information om brugeren som fx identitet og tildelte jobfunktionsroller. Identity Provideren udstiller således informationerne fra organisationens brugerkatalog overfor omverdenen via en standardiseret snitflade. Brugervendte systemer i den fælleskommunale infrastruktur indtager rollen af Service Provider (dvs. konsument af identitet). Disse logger brugeren på systemet på baggrund af et security token udstedt af en betroet tredjepart. Mellem myndighedens Identity Provider og det brugervendte systemer indskydes en Context Handler, der er et støttesystem i den fælleskommunale infrastruktur. Denne har til formål at agere som fælles integrationspunkt ( trust broker ), som alle Service Providers og Identity Providers integreres til. Desuden holder Context Handleren styr på, hvilken organisation brugeren aktuelt opererer på vegne af (kontekst), og veksler jobfunktionsroller til de systemspecifikke roller, der giver adgang til de bagvedliggende systemer. Principperne er illustreret nedenfor: 3 af 24

4 Brugerkatalog Identity Provider Context Handler Token a Token b Bruger Myndighed Brugervendt system Denne model giver en hensigtsmæssig ansvarsfordeling, idet brugerne kan administreres lokalt men få adgang centralt (med single sign-on), og samtidig giver den en ønskværdig arkitekturmæssig de-kobling mellem brugervendte systemer og den fælleskommunale infrastruktur. Således kan den enkelte myndighed frit vælge den teknologi og de værktøjer, man ønsker at administrere brugerne med, så længe snitfladen mod omverdenen overholdes. Den fællesoffentlige standard på føderationsområdet er OIOSAML 1, der er en profil af den internationale SAML 2.0 standard fra OASIS. Denne standard er ligeledes hjørnestenen i den fællesoffentlige brugerstyringsløsning NemLog-in og derfor velafprøvet. Digitaliseringsstyrelsen har fået udviklet open source referenceimplementeringer af OIOSAML, som kan lette anvendelsen af standarden. Derudover anvender en række myndigheder i dag SAML via integration til WAYF-løsningen eller Danmarks Miljøportal. Der er foretaget en subprofilering af OIOSAML profilen i form af en såkaldt KOMBIT attributprofil, der definerer indholdet af security tokens i den fælleskommunale infrastruktur som beskrevet i Appendiks A. 5.1 Rollemodel Adgangen til brugervendte systemer styres ud fra en rollebaseret model med to niveauer: Jobfunktionsroller er forretningsmæssige roller, som defineres individuelt af hver myndighed og tildeledes til brugere via det lokale brugerkatalog. Disse udgør det øverste abstraktionsniveau. Systemroller er tekniske roller, som giver adgang til at udføre bestemte handlinger i de underliggende it-systemer. Systemrollerne er specifikke for det enkelte it-system (defineres af 1 4 af 24

5 dette), og derved kan de roller, som mange it-systemer er født med, genanvendes. It-systemerne tvinges med andre ord ikke ind i en fælles rollemodel. I forbindelse med definition af jobfunktionsroller opsætter en administrator i myndigheden en mapning til de underliggende systemroller. Dette sker via Administrationsmodulet i den fælleskommunale infrastruktur, som beskrives senere. Ved tilknytningen mellem en systemrolle til en jobfunktionsrolle er det muligt at tilknytte en eller flere dataafgrænsninger, som angiver hvilke forretningsobjekter eller attributter af disse, systemrollen kan anvendes på. Dette forudsætter dog, at det underliggende it-system understøtter den specifikke dataafgrænsning. De enkelte it-systemer kan håndtere forskellige typer dataafgrænsninger i deres rettighedsmodel. Eksempler på dataafgræsninger kan være KLE numre, følsomhed (ud fra en klassifikation), organisatorisk tilhørsforhold mv. Med henblik på at skabe en generel og fleksibel arkitektur, skal it-systemer udstille / deklarere deres dataafgrænsninger for infrastrukturen. Dette sker ved at it-systemet udstiller en service, som bl.a. oplyser om de understøttede datafgrænsningstyper per systemrolle. Herved kan vilkårlige dataafgrænsninger understøttes, blot deres værdier kan udtrykkes som simple tekststrenge. Begreberne i rollemodellen er skitseret nedenfor: Bruger tildeles indeholder gælder for Jobfunktionsrolle Systemrolle indsnævrer Brugervendt system definerer Dataafgrænsningsværdi Dataafgrænsningstype Nedenstående figur illustrerer en konkret instantiering af modellen, hvor en medarbejder er tildelt to forskellige jobfunktionsroller, som igen er koblet op på 3 underliggende systemroller med tilhørende dataafgrænsninger på disse relationer: 5 af 24

6 Afgrænsning: KLE 10.* Bruger (myndighed) Jobfunktionsrolle 1: Sagsbehandler team A Jobfunktionsrolle 2: Personaleleder i socialforvaltningen Systemrolle 1: Se sags status Systemrolle 2: Se sags afgørelse Systemrolle 3: Se lønoplysninger Afgrænsning: Ansatte i afdeling 25 6 af 24

7 5.1.1 Dynamiske dataafgrænsninger Normalt fastsættes værdien af dataafgrænsninger, når en jobfunktionsrolle kobles til de underliggende brugersystemroller i Administrationsmodulet. Som et tænkt eksempel kunne jobfunktionsrollen Personaleleder blive koblet til systemrollen Se lønoplysninger med dataafgrænsningen Afdeling=23, således at vedkommende kun kan se lønoplysninger på medarbejdere i egen afdeling. Ulempen ved at dataafgrænsningsværdien 23 er fast defineret er imidlertid, at jobfunktionsrollen Personaleleder ikke kan bruges generelt for personaleledere (for andre afdelinger), og dermed kan man ende med et behov for at definere mange udgaver af rollen, der kun adskiller sig ved værdien af dataafgrænsningen. Til imødegåelse af ovenstående situation rummer den fælleskommunale infrastruktur mulighed for såkaldte dynamiske dataafgrænsninger på brugerroller. Med en dynamisk dataafgrænsning gives der mulighed for at værdien af dataafgrænsninger ikke fastsættes på tidspunktet, hvor rollen defineres i Administrationsmodulet, men i stedet parameterstyres ved at myndighedens IdP medsender attributter i det udstedte token. Værdien kan ContextHandler så indsætte dynamisk som værdien af dataafgrænsningen i det token, som medsendes til det brugervendte system. I forlængelse af ovenstående eksempel kunne Myndighedens IdP altså medsende værdien af brugerens afdeling (=23), og denne værdi ville så kunne bruges som værdien af dataafgrænsningen. På denne måde kan jobfunktionsrollen Personaleleder være generisk. Konceptet er illustreret på nedenstående figur: 5.2 Automatiseret tildeling af jobfunktionsroller Som nævnt administreres brugerne (herunder de tildelte jobfunktionsroller) i myndighedernes lokale brugerkataloger. Hvordan dette gøres, er helt op til den enkelte myndighed. Det kan således både gøres manuelt (fx ved at en administrator indmelder brugerne i grupper i et Active Directory, der mappes til udgående roller) eller der kan anvendes Identity Management løsninger, som automatisk eller 7 af 24

8 semiautomatisk tildeler brugerne adgange på baggrund af workflows, data fra eksempelvis et HR-system med organisationsdata, eller som implementerer attestering af adgange samt såkaldt Access Governance, hvor de faktiske adgange sammenholdes med politikker og regler med henblik på at identificere afvigelser. Alle disse ting kan opfattes som et valgfrit automatiseringslag ovenpå brugerkataloget. I næsten alle organisationer er der en sammenhæng mellem de jobfunktioner, medarbejderne udfører, og den placering, de har i organisationen. Det er derfor relevant at afdække sammenhængen mellem disse begreber samt ikke mindst interaktionen mellem sikkerhedskomponenter og den fælles Organisationskomponent i den fælleskommunale infrastruktur. Figuren nedenfor illustrerer koblingen af roller til den organisatoriske placering: Korsbæk Kommune Rolle: ansat Rolle A Social Børn og unge Økonomi Rolle C Enhed 1 Enhed 2 Rolle B Bruger 1 Bruger 2 Bruger 3 Hovedtanken i sikkerhedsmodellen er, at viden om brugerens organisatoriske tilhørsforhold kombineret med lokale regler og workflows kan danne grundlag for (evt. automatisk) tildeling af jobfunktionsroller, som adgangskontrollen herefter kan operere på. Dette betyder, at den tokenbaserede adgangskontrol kan holdes simpel, idet den kun opererer på roller og ikke skal kende organisatorisk tilknytning samt avancerede tildelingsregler, samtidig med at man kan administrere brugerne efter avancerede regler med høj grad af automatisering. Arkitekturen opnår dermed en fordelagtig deling af ansvaret mellem en administrationskomponent (typisk et Access Governance, IAM eller IdM værktøj), der anvender organisatorisk viden og avancerede tildelingsregler 2, og en adgangskontrolkomponent, som blot agerer på de effektive roller, der er resultatet af tildelingen. En sådan opdeling er velkendt fra Identity Management software-suiter, hvor den giver mulighed for en høj grad af automatisering af 2 Eksempelvis omkring separation of duties. 8 af 24

9 brugeradministrationen kombineret med et tværgående overblik over brugernes rettigheder, selvom dette ikke er understøttet i de enkelte applikationers egen rettighedsmodel. Adgangsstyringsmodellen, der er implementeret i denne fælleskommunale infrastruktur, kan således rumme statisk funktionsadskillelse - altså at en bruger ikke er tildelt specifikke roller samtidig som f.eks. rollerne anvis betaling og godkend betaling. Adgangsstyringsmodellen understøtter ikke dynamisk funktionsadskillelse, altså at en bruger er tildelt begge roller, men ikke kan bruge dem på samme dataobjekt. En sådan dynamisk funktionsadskillelse vil skulle løftes af det enkelte fagsystem, der kender til de lokale dataobjekter, samt brugernes relation til disse. Dette ville komplicere kravene til den del af adgangsstyring, der skal implementeres af alle fagsystemerne, og er derfor fravalgt. Figuren nedenfor illustrerer, hvorledes arkitekturen kunne se ud: Access Governance Organisationsinfo (f.eks. HR) Organisation Regler & Workflows Provisionering af rolletildelinger Brugerkatalog Identity Provider Context Handler Rolleinfo SAML token med roller Myndighed Fælles infrastruktur Myndigheden har i eksemplet et brugerkatalog, hvor medarbejderne og deres jobfunktionsroller er registreret. Dette brugerkatalog er baggrunden for udstedelse af SAML tokens ved log-in til brugervendte systemer via Identity Provideren. Ovenpå har myndigheden etableret en Access Governance / IAM / IdM løsning, der provisionerer brugernes roller til brugerkataloget på baggrund af viden om brugernes organisatoriske tilhørsforhold, adgangsregler og workflows (eksempelvis godkendelser fra afdelingsledere etc.). Endvidere kunne man forestille sig at en brugeradministrator kan tildele jobfunktionsroller direkte til en bruger via brugerkataloget, idet man erfaringsmæssigt ikke (kost-effektivt) kan automatisere alle rolletildelinger. Det skal understreges, at det er valgfrit for myndigheder at etablere den automatiserede overbygning i form af et IdM eller Access Governance værktøj (herunder valg af værktøj). For mindre organisationer kan det således være acceptabelt at vedligeholde brugere og roller manuelt. 9 af 24

10 Det har været overvejet hvorvidt der skulle etableres en central Identity Management komponent i den fælleskommunale infrastruktur. Dette er fravalgt idet: Komponenten vil formentlig kræve avancerede integrationer tilbage til myndighedernes sikkerhedsdomæner, hvilket kan være dyrt samt kunne give sikkerhedsmæssige udfordringer. En KOMBIT-løsning vil kunne dække en brøkdel af de systemer, som myndigheder kunne have behov for at integrere mod, og dermed ville værdien være begrænset. Eksempelvis kan man forestille sig, at myndigheden ønsker at integrere et Access Governance / IAM / IdM værktøj med deres HR system, så ansættelser, afskedigelser og jobændringer automatisk slår igennem, at der skal laves integrationer med bestillingssystemer, så nye medarbejdere får bestilt adgangskort, mobiltelefon, PC mv., tildeles en konto og får adgang til myndighedens interne fagsystemer. Ved at den enkelte myndighed kan indkøbe og konfigurere deres egne værktøjer til Access Governance / IAM / IdM opnås en stor fleksibilitet, som en central løsning ikke vil kunne honorere. 5.3 Model for delegering af jobfunktionsroller Der er et behov for, at myndigheder kan udføre jobfunktioner for hinanden, hvilket er løst ved at give mulighed for delegering af jobfunktionsroller fra en myndighed til en anden. Dette sker delvist under anvendelse af Administrationsmodulet i den fælleskommunale infrastruktur. Delegeringen foregår på flg. måde: 1. Myndighed A opretter via Administrationsmodulet en jobfunktionsrolle (i egen kontekst) og tildeler den et antal systemroller til de underliggende it-systemer. 2. Myndighed A angiver i Administrationsmodulet, at jobfunktionsrollen A delegeres til myndighed B. 3. Jobfunktionsrolle A bliver nu synlig for myndighed B, og en brugeradministrator (eller et IdMsystem) for myndighed B kan derfor tildele jobfunktionsrolle A til medarbejdere i myndighed B. 4. Når medarbejdere i myndighed B, som har fået tildelt jobfunktionsrolle A, logger ind via den lokale Identity Provider, inkluderes jobfunktionsrolle A i det udstedte SAML token (på lige fod med de jobfunktionsroller, medarbejderen er tildelt for sin egen myndighed). 5. Context Handleren accepterer dette (qua viden om delegeringen provisioneret fra Administrationsmodulet), og mapper jobfunktionsrolle A til de underliggende systemroller. 6. Det brugervendte system modtager systemrollerne hørende til jobfunktionsrolle A på samme måde som ville have været tilfældet, hvis en medarbejder fra myndighed A havde logget på. I det udstedte token fremgår dog, at brugerens kontekst stadig er myndighed B. Dermed opnår man samlet, at myndighed A styrer hvilke jobfunktioner og dermed underliggende rettigheder som delegeres, mens myndighed B stadig selv håndterer administration af egne medarbejdere. Delegeringskonceptet er illustreret på nedenstående figur: 10 af 24

11 Fælleskommunal Infrastruktur Opret delegeret rolle Lokal STS Myndighed A Web Service Provider Tildel delegeret rolle Myndighed B Jobfunktionsrolleadministrator Administrationsmodulet Brugeradministrator Brugerkatalog 5.4 Detaljeret forløb ved log-in til brugervendt applikation Nedenstående figur illustrerer for løbet ved log-in til en brugervendt applikation, hvor de forskellige komponenter og roller kommer i anvendelse: 11 af 24

12 Brugerkatalog 5. Hent jbf. roller Identity Provider 3. Hent token 6. Roller 7. Token Context Handler 4. Log-in 8. Token 2. Hent token 1. Tilgå applikation via browser Bruger Brugervendt system 1. Brugeren tilgår det brugervendte system med sin browser. 2. Det brugervendte system anmoder Context Handleren om et token til brug for log-in. 3. Context Handleren afgør hvilken Identity Provider, der kan autentificere brugeren, og anmoder denne om et token. Valget af Identity Provider kan ske ved at spørge brugeren eller ved at se på gemte præferencer (f.eks. i cookies), IP-adresse eller andet. 4. Brugeren autentificerer sig overfor den lokale Identity Provider. Hvis denne står på brugerens domæne kan processen være usynlig for brugeren (fx single sign on via Kerberos). 5. Identity Provideren validerer brugerlog-in og henter brugerens jobfunktionsroller fra det lokale brugerkatalog. 6. Jobfunktionsroller returneres på baggrund af opslag. 7. Identity Provideren udsteder et token til Context Handleren med brugerens identitet og jobfunktionsroller. 8. Context Handleren udsteder et nyt token til det brugervendte system, hvor brugerens jobfunktionsroller er omvekslet til systemroller (med tilhørende dataafgrænsninger) relevante for det brugervendte system. 9. Det brugervendte system etablerer en session med brugeren og foretager lokal adgangskontrol på baggrund af indholdet i det modtagne security token. Den beskrevne dialog implementeres som nævnt via SAML protokollen. Interaktionen er detaljeret i nedenstående sekvensdiagram: 12 af 24

13 Bruger Myndigheds Identity Provider Myndigheds Brugerkatalog Context Handler Brugervendt system Initielt log-in 3: Vælg kontekst Kommunal Identity Provider 1: Tilgå brugervendtsystem 2: SAML AuthnRequest 4: SAML AuthnRequest 5: Autentifikation (SSO) 6: Hent jobfkt. roller 7: SAML token med identitet og jobfkt. roller 8: map roller og udsted token 9: SAML token med identitet og systemroller 10: Brugersession 5.5 Revokering af adgange og roller Når en medarbejder bliver spærret i myndighedens lokale brugerkatalog, vil vedkommende ikke længere kunne få udstedt et nyt SAML token (via den lokale Identity Provider), der giver adgang til brugervendte systemer. Dette betyder, at der ikke umiddelbart er behov for yderligere spærring af brugere, end hvad der må forventes at eksistere i forvejen. Tilsvarende gælder for brugere, som får adgang via en digital signatur (NemLog-in) frem for det lokale brugerkatalog: her vil spærring af certifikatet blokere for yderligere adgang. Der skal i støttesystemudbuddets implementeringsfase defineres en konkret timeoutpolitik, som definerer hvor længe SAML tokens kan være gyldige, før de skal fornys. I fællesoffentlig brugerstyring (NemLog-in føderationen) er gyldigheden normalt 30 minutter, mens det i sundhedssektoren er udbredt praksis med en gyldighed på 8 timer. Værdien skal under alle omstændigheder være konfigurérbar til forskellige værdier per autentifikationsmekanisme. Ændringer af rettigheder slår igennem, når brugeren skal forny sit SAML token. Derfor gælder helt de samme overvejelser omkring timeoutpolitik etc. Der findes i den fælleskommunale infrastruktur mekanismer, som kan gennemtvinge et log-out for brugere, men dette kan være stærkt generende for brugerne og bør derfor anvendes med omtanke. 5.6 Brug af AttributServices Med henblik på at understøtte en fleksibel arkitektur, hvor flere komponenter end de lokale Identity Providere kan levere attributinformation om brugere, er der indført såkaldte AttributServices i modellen. Disse er services, som meget svarer til lokale Identity Providere, men som ikke autentificerer brugerne men udelukkende leverer attributinformation om brugerne, som Context Handleren herefter kan inkludere i brugertokens. 13 af 24

14 Når man tilslutter et brugervendt system via Administrationsmodulet, er det muligt at registrere et antal AttributServices, som Context Handleren vil kalde (via SAML AttributeQuery protokollen) for at hente yderligere information om brugeren, når der skal udstedes tokens til applikationen. Context Handleren vil således udstede et token til det brugervendte system, som indeholder foreningsmængden af attributter fra den lokale Identity Provider og de valgte AttributServices. Attributservices kan også anvendes, når den valgte Identity Provider ikke kan levere information om tildelte jobfunktionsroller. Dette gælder eksempelvis ved log-in til Administrationsmodulet, som sker via NemLog-in (med et OCES medarbejdercertifikat). Da NemLog-in kun leverer brugerens identitet, kan Context Handleren kalde en Attributservice, som leverer disse. Dette kræver naturligvis, at det er muligt at mappe mellem brugerens identitet som modtaget af NemLog-in og brugerens identitet i det lokale brugerkatalog. Administrationsmodulet udstiller således en Attributservice, som udstiller de administrationsmodulroller, som kan administreres via Administrationsmodulet. Se Underbilag 2A for detaljer. Brug af en Attributservice til indhentning af jobfunktionsroller er illustreret på nedenstående sekvensdiagram: Bruger Identity Provider (fx NemLog-in) Myndigheds Brugerkatalog Anden Attributservice Context Handler Brugervendt system 1: Tilgå brugergrænseflade 2: SAML AuthnRequest 3: Vælg kontekst 4: SAML AuthnRequest 5: Autentifikation (fx Medarbejdercert.) 6: SAML token med identitet 7: SAML AttributeQuery 8: Jobfunktionsroller og ID 9: SAML AttributeQuery 10: Jobfunktionsroller 11: Map roller og udsted token 12: SAML token med ID og systemroller 13: Brugersession Figur 4: sekvensdiagram for brug af Attributservice 5.7 Synergier med fællesoffentlig brugerstyring Ved anvendelse af en fødereret sikkerhedsmodel baseret på OIOSAML opnås som nævnt en arkitekturmæssig de-kobling af fagsystemerne fra selve brugerautentifikationen. Dette vil gøre det let at skifte autentifikationsmekanismer til eksempelvis medarbejdersignaturer, mobiloptimerede loginmekanismer etc. uden påvirkning af de enkelte fagsystemer. Endvidere udstiller den fællesoffentlige 14 af 24

15 brugerstyringsløsning (NemLog-in) en SAML-baseret Identity Provider komponent, som kobles til Context Handleren, hvilket kan give flg. fordele: Borgere vil kunne logge på Context Handleren via NemLog-in og opnå single sign-on til og med andre borgerrettede løsninger. Dette er eksempelvis relevant, hvis man i fremtiden får brug for at udstille borgervendte services på borger.dk (f.eks. indblik i egne sager). den fælleskommunale infrastruktur håndterer ikke rettighedsstyring for borgere, men vil evt. kunne integrere med fællesoffentlig fuldmagtsløsning, såfremt der måtte være behov for det. Medarbejdere vil kunne logge på Context Handleren via NemLog-in med deres medarbejdersignatur. Dette kan benyttes ved betroede medarbejderes adgang til Administrationsmodulet. 5.8 Sikkerhed for brugerens identitet (AssuranceLevel) Autentifikationen af medarbejdere sker lokalt og indenfor myndighedens eget sikkerhedsdomæne via de Identity Providere, som myndighederne skal etablere. Dermed vil det samlede niveau af sikkerhed for brugerens identitet (AssuranceLevel) være afhængigt af den lokale sikkerhed i organisationen - herunder de etablerede procedurer for indrullering af medarbejdere, politikker for kvalitet af kodeord eller andre credentials, låsning af konti ved afviste adgangsforsøg, begrænsning af log-in til det interne netværk etc. Den enkelte Identity Provider er forpligtet til at vurdere det niveau af AssuranceLevel, som er opnået (på skalaen 1-4) og påstemple værdien i de tokens, der udstedes, således at modtageren kan tage højde for det i adgangsbeslutninger. Mekanismerne til beskyttelse af security tokens (digital signatur) vurderes at kunne understøtte AssuranceLevel 3 3 tilsvarende brug af OCES certifikater, hvilket normalt er det niveau, der kræves for at få adgang til personfølsomme oplysninger via internettet. Dette forudsætter naturligvis, at Identity Provideren initielt opnår AssuranceLevel Håndtering af legacy applikationer I beskrivelsen er det hidtil antaget, at applikationer kan modtage SAML tokens fra Context Handleren indeholdende brugerens identitet og systemroller - og på baggrund af disse foretage en lokal adgangskontrol. Imidlertid kan der forekomme legacy-applikationer, som ikke er designet til at håndtere en fødereret brugerstyring typisk ved at applikationen er født med sit eget brugerkatalog og database med rettigheder. Sådanne applikationer håndteres i sikkerhedsmodellen ved at etablere en forbrænder foran applikationen, der modtager SAML tokenet og just-in-time opretter brugeren og dennes rettigheder i applikationens interne kataloger. Komponenten oversætter altså mellem den fælleskommunale infrastrukturs adgangsstyringsmodel og applikationens proprietære model på samme måde som mange web service gateways (eller ESB er) kan indkapsle legacy systemer i en moderne web service grænseflade udadtil. Det påhviler den enkelte It-systemleverandør at levere en forbrænder komponent, der muliggør at applikationen kan integreres med den token-baserede brugerstyring, som anvendes i den fælleskommunale infrastruktur. Bemærk endvidere, at just-in-time provisioneringen sker lokalt og ikke på tværs af sikkerhedsdomæner, og at applikationens specifikke model indpakkes i applikationens eget domæne. 3 Det såkaldte AssuranceLevel se for detaljer. 15 af 24

16 5.10 Finkornet adgang Den beskrevne model, hvor adgangsstyringen baseres på roller med tilhørende dataafgrænsninger, udgør en grovkornet model, som forventes at kunne dække langt hovedparten af behovet for adgangsstyring i den fælleskommunale infrastruktur. En af de væsentligste fordele ved modellen er, at abstraktionerne (roller og dataafgrænsninger) gør det muligt at administrere adgange eksternt for de brugervendte systemer, således at man kan få et samlet overblik over brugernes adgange og varetage brugeradministrationen ét sted. Enkelte brugervendte systemer kan i særlige tilfælde have behov for at supplere den grovkornede adgangsstyring med mere finkornet adgangsstyring eksempelvis hvis der er behov for at adgangsstyre individuelt på de enkelte forretningsobjekter (sager, dokumenter, organisatoriske enheder etc.). En sådan model skalerer ikke til mange forretningsobjekter og bør derfor kun anvendes i helt særlige situationer. I disse tilfælde er det brugervendte system selv ansvarligt for den supplerende, finkornede adgangsstyring, da denne typisk er tæt knyttet til systemet og forretningsdomænet. Eksempelvis kender Adgangsstyringen ikke til de konkrete forretningsobjekter (fx de specifikke sager og dokumenter), som findes i de brugervendte systemer, og derfor ville det være vanskeligt at udpege disse specifikt i forhold til administration af adgangsregler. Et eksempel på en finkornet adgangsstyring kunne være, at kun navngivne brugere må tilgå en sag (en såkaldt ad-hoc brugergruppe, der kan tilknyttes per sag) desuagtet disse brugeres roller. Dette behov kunne løses ved at oprette en ad hoc brugergruppe i Organisationskomponenten, melde de pågældende brugere ind i gruppen, og påstemple gruppens ID på den pågældende sag i fagsystemet, således at der kan håndhæves adgang (kun brugere der er med i gruppen får adgang). Andre systemer kan have andre behov for finkornet adgangskontrol, som skal håndteres med andre metodikker. 16 af 24

17 6 Adgang til fælleskommunale services Ovenfor er principperne for brugeres adgange til web-baserede applikationer beskrevet. I dette afsnit gennemgås nu principperne for adgang til at kalde fælleskommunale (web) services. Som før anvendes en token-baseret model, hvor det kaldende system (Anvendersystemet) får udstedt et security token med dets identitet og tildelte systemroller. Dette token anvendes herefter ved et efterfølgende web service kald. Den primære forskel til den brugerrettede model er den måde administrationen for adgangsstyring for fælles kommunale service foregår på. For de fælles kommunale services sker administrationen alene i Administrationsmodulet, hvor tildelingen af adgangsgivende systemroller til et anvendersystem foregår i forbindelse med indgåelse af serviceaftaler for en given service. Der er for fællekommunale services ikke kun ét niveau af roller for adgang til services (benævnt servicesystemroller) og altså ikke nogen jobfunktionsroller. Bemærk: udover den tokenbaserede model for adgang til services findes også modeller for simple services i den fælleskommunale infrastruktur, hvor adgang gives alene på baggrund af Anvendersystemets identitet (certifikat) og ikke via tildelte roller. Disse beskrives ikke i her. Hovedprincipperne i den token-baserede model for adgangsstyring for systemer er flg.: Adgang for et anvendersystem til en fælleskommunal service tildeles i Administrationsmodulet i forbindelse med indgåelse af en serviceaftale om brug af servicen. Adgang for et anvendersystem til en fælleskommunal service tildeles som et antal servicesystemroller med tilhørende dataafgrænsninger. Adgang for anvendersystemer til at kalde en web service håndhæves ved præsentation af et SAML token indeholdende et antal servicesystemroller. Tokenet bærer ikke slutbrugeridentitet men Anvendersystemets identitet (dvs. kalderens CVR nummer og et systemid). Der defineres nogle fælles (grovkornede) servicesystemroller, som kan tildeles Anvendersystemer og som services baserer deres adgangskontrol på. Et web service kald sker altid på vegne af én organisation (myndighed) identificeret ved det CVR nummer, der fremgår af kalderens OCES virksomheds- eller funktionscertifikat. For myndigheder er det kun muligt at tilgå organisationens egne data der er med andre ord altid underforstået en dataafgrænsning på CVR nummer niveau. Der etableres et støttesystem i den fælleskommunale infrastruktur kaldet Security Token Service (STS) baseret på WS-Trust standarden (OIO WS-Trust profilen), som Anvendersystemer kan autentificere sig mod og herefter få udstedt et SAML security token. STS en modsvarer altså Identity Provider komponenten (Context Handleren), der servicerer browserapplikationer. Anvendersystemer autentificerer sig mod STS en ved at præsentere et OCES Funktions- eller Virksomhedscertifikat. Certifikatet er forinden registreret af en betroet medarbejder fra myndigheden eller dennes It-systemleverandører i forbindelse med tilslutningen af Anvendersystemet til den fælleskommunale infrastruktur. Modellen for systemadgang via den centrale Security Token Service er skitseret på nedenstående figur: 17 af 24

18 Systemejer Administrationsmodulet 1 3 Security Token Service 2 Rollekatalog Fælleskommunal infrastruktur Anvendersystem 4 Service Myndighed Serviceudbyder Sekvensen på figuren er flg.: 1. Anvendersystemet forespørger om et security token hos Security Token Servicen 4. I kaldet medsendes information om hvilken web service, der ønskes adgang til, og kaldet er signeret med et OCES Funktions- eller Virksomhedscertifikat, der på forhånd er registreret via Administrationsmodulet (via de grå pile). 2. Security Token Servicen validerer kaldet, og fremfinder de servicesystemroller, som Anvendersystemet er tildelt. 3. Der udstedes et SAML token, som returneres til Anvendersystemet. Tokenet er digitalt underskrevet af STS en, rummer information om Anvendersystemets identitet (CVR og systemid), de tildelte roller samt hvilken service (endpoint), hvor tokenet kan anvendes. 4. Anvendersystemet kan nu foretage et (signeret) web service kald mod servicen, hvori SAML tokenet medsendes. Servicen validerer signaturen og at SAML Tokenet er udstedt af den fælleskommunale infrastrukturs STS, hvorefter der gives adgang på baggrund af kalderens identitet og tildelte servicesystemroller, som er udtrukket af SAML tokenet. Tokenet har en gyldighed (f.eks. 1 time), så det kan caches og genbruges i efterfølgende kald, uden at STS en skal kontaktes igen. Ovenstående forløb implementeres via WS-Trust protokollen som illustreret på nedenstående figur: 4 Et WS-Trust RequestSecurityToken 18 af 24

19 Anvendersystem Security Token Service Serviceudbyder 1. Anmod om token (WS-Trust RequestSecurityToken) 2a. Valider kald 2b. Hent systemroller 2c. Udsted token 3. Svar med token (WS-Trust RequestSecurityTokenResponse) 4. Web service kald med token 5. Svar på web service kald Modellen opnår, at den enkelte service ikke skal kende til de kaldende Anvendersystemer og deres certifikater og blot kan stole på SAML tokens udstedt af støttesystemet STS. Dette giver en arkitekturmæssig løs kobling og fleksibilitet fremadrettet: Man kan ændre på autentifikationen uden at påvirke services, herunder autentifikationsmekanismer eller koblingen mellem credentials og systemer. Man kan ændre på aftalehåndtering og koblingen mellem en aftale og autentifikation uden at påvirke services. 6.1 Kald via Serviceplatformen I praksis vil mange services blive udstillet via den fælleskommunale serviceplatform. Her vil anvendersystemet kun kende et endpoint på serviceplatformen, som herefter kalder de bagvedliggende services, indsamler / transformerer svarene og herefter returnerer svar til anvendersystemet. Herved kan serviceplatformen udføre mediering, transformationer og orkestrering af services. I denne situation vil Anvendersystemet skulle tildeles et antal servicesystemroller til den service, der udstilles på serviceplatformen. Serviceplatform får tildelt en speciel adgang til at veksle tokens hos STS en, hvor de indgående servicesystemroller for anvendersystemet veksles til udgående systemroller til de bagvedliggende services, så serviceplatformen kan kalde disse på vegne af anvendersystemet. Dette forudsætter, at STS en er bekendt med sammenhængen mellem front-end og back-end services, og at serviceplatformen konfigureres som et særligt betroet system. Princippet er illustreret på nedenstående figur: 19 af 24

20 Anvendersystem Serviceplatform Security Token Service Serviceudbyder af bagvedliggende service 1: Anmod token 2: Returner token (T1) 3:Servicekald med token (T1) 4: Anmodning om vekslet token (T1) 5: Vekslet token (T2) 6: Web service kald med token (T2) 8: Svar på web service kald 7: Svar på web service kald 6.2 Caching og genanvendelse af tokens Modellen ovenfor beskriver et enkeltstående web service kald mellem Anvendersystem og service baseret på præsentation af et token. I praksis kan der være behov for at understøtte mere avancerede kaldsmønstre: Et Anvendersystem kan have behov for at udføre flere kald på kort tid. Her kan et token med lang levetid genanvendes, så overhead til token udstedelse undgås. Derimod vil der stadig være et overhead forbundet med validering af tokenet for det enkelte kald hos støttesystemet. Anvendersystem og støttesystem kan etablere en session baseret på initiel udveksling af tokens, hvorefter en længerevarende kommunikation anvender sessionen. Her er den fælleskommunale infrastruktur kun involveret i udstedelse af de tokens, som anvendes til etablering af sessionen, mens resten betragtes som en privat protokol mellem Anvendersystem og støttesystem. Systemerne kan altså frit vælge protokol og teknologi til sessionshåndtering (fx WS-Secure Conversation, WS- ReliableMessaging, SSL, SSH etc.). 7 Administrationsmodulet for adgangsstyring Den fælleskommunale infrastruktur indeholder som nævnt et Administrationsmodul, der vil være det centrale knudepunkt for at tilslutte systemer og administrere rettigheder til den fælleskommunale infrastrukturs systemer. Via Administrationsmodulets brugergrænseflade understøttes selvbetjening i forbindelse tilslutning af systemer til infrastrukturen samt administration af deres tilhørende aftaler og konfiguration. Administrationsmodulet benyttes til administration af både adgangsstyring for brugere og adgangsstyring for systemer, der er beskrevet ovenfor. Administrationsmodulet håndterer de underliggende aftaler mellem Myndigheder, It-systemleverandører og KOMBIT, og provisionerer informationer til komponenterne i Adgangsstyring for hhv. brugere og systemer (Context Handler og Security Token Service), således at de kan slå igennem ved udstedelse af security tokens som beskrevet i første del af notatet. Derved vil fagsystemerne håndhæve adgangskontrol ud fra de aftaler, der er indgået i Administrationsmodulet. 20 af 24

21 De følgende afsnit beskriver kort de administrative arbejdsopgaver, der understøttes i Administrationsmodulet. 7.1 Administration af tilslutningsparter Enhver Myndighed og It-systemleverandør, der skal benytte den fællekommunale infrastruktur, skal oprettes som tilslutningspart i Administrationsmodulet. En tilslutningspart vil eksempelvis være de organisationer, der kan indgå som part i de aftaler, der vedrører de it-systemer, der anvender den fælleskommunale infrastruktur. Administrationsmodulet skal understøtte tre typer af tilslutningsparter: Myndighed i denne sammenhæng en organisation, der anvender et it-system og er dataansvarlig for de data, der er tilgængelige gennem den fælleskommunale infrastruktur. En Myndighed vil i praksis være kommunerne eller Udbetaling Danmark. It-systemleverandør den organisation, der leverer et it-system. En It-systemleverandør vil typisk være en virksomhed. Kommuner og andre offentlige Myndigheder vil dog også kunne levere itsystemer til den fællekommunale infrastruktur. Er dette tilfældet, vil Myndigheden optræde i rollen som It-systemleverandør. Forvalter den organisation, der forvalter den fællekommunale den fælleskommunale infrastruktur. Forvalteren er eksempelvis ansvarlig for at oprette tilslutningspart og godkende tilslutninger af itsystemer. Forvalteren vil også i visse tilfælde kunne indgå aftaler på vegne af Myndigheder, hvis forvalteren har fuldmagt hertil. Som udgangspunkt indtræder KOMBIT i rollen som forvalter, men forvaltningsrollen skal kunne lægges ud til andre organisationer. 7.2 Brugeradgang til Administrationsmodulet Som nævnt vil en række medarbejdere hos myndigheder og It-systemleverandører have behov for adgang til Administrationsmodulet. Log-in sker via NemLog-in med et OCES medarbejdercertifikat og brugerne kan tildeles et antal administrationsmodulroller, der er nogle særlige roller, der ikke vedligeholdes i myndighedernes egne brugerkataloger med derimod centralt i Administrationsmodulet. Når en organisation tilsluttes, udpeges relevante administratorer. Arbejdsgangene vil blive lagt ind i dette dokument på et senere tidspunkt. 7.3 Administration af tilsluttede systemer Alle it-systemer, der skal tilsluttes den fællekommunale infrastruktur, skal oprettes i Administrationsmodulet. Tilslutning af et system sker ved at it-systemleverandøren af it-systemet anmoder om en tilslutningsaftale for dette specifikke system. Tilslutningsaftaler visiteres og godkendes af Forvalteren af den Fællekommunale den fælleskommunale infrastruktur, som illustreret på figuren nedenfor. 21 af 24

22 I Administrationsmodulet optræder et it-system med en eller flere systemtyper, der bestemmer hvilken type af funktionalitet it-systemet udstiller. Administrationsmodulet understøtter følgende systemtyper: Identity Provider, Brugervendt system, Anvendersystem og Serviceudbyder. Afhængigt af it-systemets type kan man indgå forskellige typer af aftaler for it-systemet og Administrationsmodulet udstiller forskellige tekniske systemparametre, der er nødvendige for implementering og håndhævelse af disse aftaler. Disse systemparametre vedligeholdes i Administrationsmodulet af it-systemleverandøren af it-systemet. Et givet it-system ville kunne optræde med mere end en systemtype Administration af adgangsstyring for brugervendte systemer Den fælleskommunale infrastruktur har en fødereret model for adgangsstyring af brugere, som beskrevet ovenfor. Her er en Identity Provider er det it-system, der udsteder tokens som attesterer, at en given bruger er autentificeret af en given Myndighed. Administrationsmodulet understøtter indgåelse af føderationsaftaler mellem en Leverandør af en Identity Provider og en Myndighed, der giver Itsystemleverandøren lov til at autentificere og udstede adgangstokens for Myndighedens brugere. Figur 1 Indgåelse af Føderationsaftale Administrationsmodulet er endvidere det fælles modul, der benyttes til at administrere alle oplysninger, der skal deles mellem de forskellige systemer i denne fødererede adgangsstyringsmodel. Administrationsmodulet understøtter følgende opgaver i forbindelse med adgangsstyring til det brugervendte systemer: Tilslutning af Identity Providere og Attributservices. o Herunder registreres certifikater til brug for kryptografiske signaturer på tokens. Tilslutning af brugervendte systemer. o Herunder registreres de Brugersystemroller, som det brugervendte system understøtter håndhævelse af. Administration af Jobfunktionsroller. o Hver Myndighed kan redigere egne Jobfunktionsroller, der passer til Myndighedens jobfunktioner. Herunder opsættes en afbildning mellem Jobfunktionsroller og Brugersystemroller, som beskrevet i afsnit 5.1. Provisionering til Støttesystem Adgangsstyring for brugere. o Føderationsaftaler og Jobfunktionsroller provisioneres til Støttesystem Adgangsstyring for brugere. Støttesystem Adgangsstyring for brugere udsteder så kun tokens i henhold til disse aftaler og opsætninger af Jobfunktionsroller. 22 af 24

23 7.3.2 Administration af adgangsstyring for Serviceudbydere Serviceudbyderne er it-systemer, der kan indeholde Myndigheders data og udstille dem gennem en servicesnitflade, hvor andre systemer kan få adgang til disse data. Via Administrationsmodulet er det muligt for It-systemleverandøren af et Anvendersystem at indgå en serviceaftale med Myndigheden, der giver It-systemleverandøren tilladelse til at benytte servicesnitfladen til at tilgå Myndighedens data i Serviceudbyderen. Figur 2 Indgåelse af Serviceaftale En serviceaftale er en databehandleraftale, der giver It-systemleverandøren af Anvendersystemet en instruks om at måtte behandle Myndighedens data og overfører dem mellem Anvendersystemet og Serviceudbyderen. Serviceaftalen indeholder endvidere de adgangsrettigheder (i form af Servicesystemroller), som giver Anvendersystemet adgang til Serviceudbyderen. Derved kan serviceaftalen automatisk håndhæves, når Anvendersystemet tilgår Serviceudbyderen. Administrationsmodulet er det fælles system, der benyttes til at administrere alle oplysninger, der skal deles mellem de forskellige Tilsluttede systemer i denne fødererede adgangsstyringsmodel. Herunder understøtter Administrationsmodulet følgende opgaver: Tilslutning af Serviceudbydere. o Herunder registreres certifikater til signering af tokens samt de Servicesystemroller, der understøttes Tilslutning af Anvendersystemer o Herunder registreres certifikater til signering ved anmodning om tokens Provisionering af rolletildelinger til Security Token Service. Udtræk af rapporter over indgåede aftaler, metadata for it-systemer, mv. 7.4 Begrebsmodel for Administrationsmodulet Begrebsmodellen for de tilslutningsparter, it-systemer, aftaler, mv. der administreres i Administrationsmodulet er vist herunder. Denne begrebsmodel illustrerer sammenhængen mellem de forskellige begreber. I de følgende afsnit beskrives kort de primære arbejdsopgaver, der kan udføres i Administrationsmodulet. 23 af 24

24 Begrebsmodellen kan læses som følger: En tilslutningspart kan enten være en It-systemleverandør, en Myndighed, eller en Forvalter. En It-systemleverandør kan tilslutte et system ved at indgå en tilslutningsaftale med Forvalteren. Et tilsluttet system kan være: a. En Identity Provider, der udsteder adgangstokens for brugere bestående af Jobfunktionsroller, for de Myndigheder, der har indgået en føderationsaftale herom. b. En attributservice, der udstiller oplysninger om brugeren, herunder hvilke Jobfunktionsroller en bruger er tildelt c. Et Brugervendt system, der håndhæver adgang i henhold til Brugersystemroller. d. En Serviceudbyder, der håndhæver adgang i henhold til Servicesystemroller e. Et Anvendersystem, der anvender en Serviceudbyder i henhold til serviceaftaler, der godkendes af den dataansvarlige Myndighed. En It-systemleverandør kan tilslutte systemer, og kan anmode om aftaler på disse. Aftaler godkendes af Myndighed eller Forvalter 24 af 24

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

SPOR 2 ADGANGSSTYRING. Netværksdage Støttesystemer 11. og 12. marts 2015

SPOR 2 ADGANGSSTYRING. Netværksdage Støttesystemer 11. og 12. marts 2015 SPOR 2 ADGANGSSTYRING Netværksdage Støttesystemer 11. og 12. marts 2015 Hvem er jeg? Rasmus H. Iversen Teknisk Projektleder Teamlead på sikkerhed Har været på STS projektet helt fra starten Mål for dagens

Læs mere

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

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

Læs mere

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

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

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

Læs mere

Bilag 2. Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0

Bilag 2. Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0 Bilag 2 Vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale Rammearkitektur Version 2.0 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer integrerer til og anvender

Læs mere

Guide til NemLog-in Security Token Service

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

Læs mere

Det kommunale systemlandskab

Det kommunale systemlandskab Det kommunale systemlandskab Adgangsstyring for brugere i forhold til KY, KSD og Bruger Log på Kommune Bruger + Job funktions roller Veksler Context Handler Bruger + Brugersystem roller KSD KY Administreres

Læs mere

Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere

Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere 1 Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere Tre af de otte Støttesystemer 2 Kombit Støttesystemerne Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring

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

Udarbejdelse af jobfunktionsroller

Udarbejdelse af jobfunktionsroller Udarbejdelse af jobfunktionsroller En vejledning til kommunernes og ATP s opgaver Version 1.1 marts 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43

Læs mere

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

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

Læs mere

Trin-for-trin guide: Tilslutning af web service til NemLog-in

Trin-for-trin guide: Tilslutning af web service til NemLog-in Trin-for-trin guide: Tilslutning af web service til NemLog-in Side 1 af 18 18. maj 2015 TG Baggrund og formål I foråret 2014 blev der udarbejdet en fælles sikkerhedsmodel for grunddataprogrammet. Modellen

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

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

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

SPOR 2. Opgaveoverblik på Støttesystemerne

SPOR 2. Opgaveoverblik på Støttesystemerne SPOR 2 Opgaveoverblik på Støttesystemerne Det kommunale systemlandskab Det kommunale systemlandskab Adgangsstyring for brugere i forhold til, og SAPA SAPA Bruger Log på Kommune Bruger + Job funktions roller

Læs mere

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform Roadmap for VERA Q3 2015 Rettighed Q2 2015 Klassifikation Q1 2015 Organisation Beskedfordeler Q4 2014 platform Indledning Kommunerne i Vendssyssel ønsker at etablere en moderne infrastruktur til at understøtte

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

Generelt om støttesystemerne

Generelt om støttesystemerne Generelt om støttesystemerne Dette afsnit giver et overblik over de enkelte støttesystemer der indgår i Rammearkitekturen. For yderligere information henvises til de udarbejdede kravspecifikationer. Støttesystemerne

Læs mere

NETVÆRKSDAGE MARTS 2015. Michel Sassene

NETVÆRKSDAGE MARTS 2015. Michel Sassene NETVÆRKSDAGE MARTS 2015 Michel Sassene Emner Baggrund Ibrugtagning af Støttesystemerne Hvorfor dette initiativ? Dialog og opfølgning Status på udviklingsprojektet BAGGRUND Lidt historie I forbindelse med

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

Guide til integration med NemLog-in / Web SSO

Guide til integration med NemLog-in / Web SSO Guide til integration med NemLog-in / Web SSO Side 1 af 13 5. januar 2015 TG Denne guide indeholder en kort beskrivelse af, hvordan en myndighed eller itleverandør kan integrere en it-løsning til NemLog-in

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

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

Introduktion til Klassifikation

Introduktion til Klassifikation Introduktion til Klassifikation 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Klassifikation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af

Læs mere

Støttesystemerne. Det er tid til

Støttesystemerne. Det er tid til 1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare

Læs mere

STS NETVÆRKSDAGE ADGANGSSTYRING. Brian Storm Graversen April 2016

STS NETVÆRKSDAGE ADGANGSSTYRING. Brian Storm Graversen April 2016 STS NETVÆRKSDAGE ADGANGSSTYRING Brian Storm Graversen April 2016 Emner Motivation og baggrund Introduktion til jobfunktionsrollebegrebet Hvad er en jobfunktionsrolle Typer af brugersystemroller Dataafgrænsninger

Læs mere

SNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser

SNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser SNITFLADER TIL INDEKSER Præsentation af de fælleskommunale støttesystemernes snitflader til indekser Introduktion Fokus At give et overblik over: Integration til indekserne Forudsætninger for integration

Læs mere

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

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk

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

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

Introduktion til Støttesystem Organisation

Introduktion til Støttesystem Organisation Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse

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

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

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

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

Læs mere

Vejledning til brug Administrationsmodulet som leverandør med rollerne Leverandøradministrator og Organisationsadministrator

Vejledning til brug Administrationsmodulet som leverandør med rollerne Leverandøradministrator og Organisationsadministrator Vejledning til brug Administrationsmodulet som leverandør med rollerne Leverandøradministrator og Organisationsadministrator Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S Version: 1.0 16.

Læs mere

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

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR

Læs mere

Læsevejledning til review af støttesystemer, marts 2013

Læsevejledning til review af støttesystemer, marts 2013 Læsevejledning til review af støttesystemer, marts 2013 Kommunerne ønsker en fælleskommunal rammearkitektur, der kan understøtte digitaliseringen og åbne for konkurrence på det kommunale it-marked. Rammearkitekturen

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

Fælleskommunal infrastruktur - SAPA-seminar, marts Michel Sassene, KOMBIT

Fælleskommunal infrastruktur - SAPA-seminar, marts Michel Sassene, KOMBIT Fælleskommunal infrastruktur - SAPA-seminar, marts 2014 Michel Sassene, KOMBIT Agenda 1. Hvorfor fælleskommunal infrastruktur? 2. Hvad kan man med infrastrukturen? 3. Brug af infrastrukturen i kommunen

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

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

Overblik over roller og kompetencer i forhold til Støttesystemerne

Overblik over roller og kompetencer i forhold til Støttesystemerne Overblik over roller og kompetencer i forhold til ne En vejledning til kommunernes og ATP s opgaver Version 1.0.1 maj 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

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

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

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

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

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

SPOR 4. Projektlederens rolle, opgaver og estimering. København 11. marts og Horsens 12. marts 2015

SPOR 4. Projektlederens rolle, opgaver og estimering. København 11. marts og Horsens 12. marts 2015 SPOR 4 Projektlederens rolle, opgaver og estimering København 11. marts og Horsens 12. marts 2015 Hvem er jeg? Seniorkonsulent/Implementering af Støttesystemerne 2 måneder i KOMBIT 14 år i en kommune Dagsorden

Læs mere

Introduktion til Støttesystem Ydelsesindeks

Introduktion til Støttesystem Ydelsesindeks Introduktion til Støttesystem 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af hvilke komponenter,

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

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

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

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

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

SPOR 2: STØTTESYSTEMER

SPOR 2: STØTTESYSTEMER SPOR 2: STØTTESYSTEMER Organisering, opgaver og kompetencer V/ Peter Hansen KOMBIT Kommunedage 1.-3. juni 2015 Indhold i sporet I dette spor ser vi nærmere på kommunernes organisering af støttesystemerne,

Læs mere

OFFENTLIG INFRASTRUKTUR I VERDENSKLASSE

OFFENTLIG INFRASTRUKTUR I VERDENSKLASSE SESSION OFFENTLIG INFRASTRUKTUR I VERDENSKLASSE TIL INFORMATIONSMØDER OM NYE STRATEGIER Peter Falkenberg, IT-arkitekt, KL (pfl@kl.dk) (NemID og NemLogin) Anders Lillienfryd, chefkonsulent, KL, (alh@kl.dk)

Læs mere

Integration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1

Integration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1 Integration Integrationsbeskrivelse - version 0.1 rnes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 201n-nn-nn xxx 0.1 Første version Referencer Ref Titel Kommentarer

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

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

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

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

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

KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer og

KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer og KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer 11-03-15 og 12-03-15 Hvem er jeg? Denny Christensen Chefkonsulent og IT Arkitekt i KOMBIT Har været teamlead og skribent på bla. kravspecifikationerne

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

9.2.b. Videreudvikling af NemLog-in

9.2.b. Videreudvikling af NemLog-in Side 1 af 5 9.2.b. Videreudvikling af NemLog-in Målsætning I forlængelse af etableringen af den nye NemLog-in, ses en betydelig efterspørgsel på yderligere funktionalitet og services, der ikke er finansieret

Læs mere

Tilslutning af ny myndighed til NemLog-in

Tilslutning af ny myndighed til NemLog-in Tilslutning af ny myndighed til NemLog-in Side 1 af 5 12. december 2013 TG Denne guide beskriver, hvordan en offentlig myndighed kan tilslutte sig NemLogin, som udbyder af en selvbetjeningsløsning, der

Læs mere

Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform

Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Version 1.0, september 2013 Den fælleskommunale Serviceplatform Ved årsskiftet 2013/14 åbner Den fælleskommunale Serviceplatform

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

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

(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

Opgaveoverblik i forbindelse med ibrugtagning af de fælleskommunale Støttesystemer

Opgaveoverblik i forbindelse med ibrugtagning af de fælleskommunale Støttesystemer Opgaveoverblik i forbindelse med ibrugtagning af de fælleskommunale Støttesystemer En introduktion til kommunernes og ATP s opgaver Version 1.1 februar 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf

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

Ibrugtagning af Fødselsindberetningsservicen på NSP

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

Læs mere

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

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

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

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

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

SDSD: Projektrelevante emner og problemstillinger. Workshop om sikkerhed og privacy 5. december 2007

SDSD: Projektrelevante emner og problemstillinger. Workshop om sikkerhed og privacy 5. december 2007 SDSD: Projektrelevante emner og problemstillinger Workshop om sikkerhed og privacy 5. december 2007 Agenda SDSD s fokus projektmæssigt SDSD s fokus sikkerhed og privacy Lovgivningskrav Indsatsområder Udvalgte

Læs mere

Vejledning til kommuners brug af Serviceplatformen

Vejledning til kommuners brug af Serviceplatformen Vejledning til kommuners brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange på Serviceplatformen...

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

Vejledning til leverandørers brug af Serviceplatformen

Vejledning til leverandørers brug af Serviceplatformen Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...

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

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks 23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

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

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS NOTAT Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS (Bilag til dagsordenspunkt 10, Arkitekturrapport for KITOS) Lars Nico Høgfeldt, Odense Kommune Generel indledning

Læs mere

PRÆSENTATION AF KOGEBOG. Til Serviceplatformen og Støttesystemernes eksterne testmiljø

PRÆSENTATION AF KOGEBOG. Til Serviceplatformen og Støttesystemernes eksterne testmiljø PRÆSENTATION AF KOGEBOG Til Serviceplatformen og Støttesystemernes eksterne testmiljø Dagsorden 1. Velkomst - Formål og begrundelse 2. Oprettelse og anvendelsesproces på SP 3. Oprettelse og anvendelsesproces

Læs mere

STS ARBEJDSGRUPPEMØDE VEJLE

STS ARBEJDSGRUPPEMØDE VEJLE STS ARBEJDSGRUPPEMØDE VEJLE Spørgsmål, kommentarer og svar 14. december Indledning v/ Peter Hansen Strategi for jobfunktionsroller v/ Brian S. Graversen Hvorfor samles implementeringshåndbøgerne for Klassifikation

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

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0

Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Integration SF0770_A - SKAT Indkomst - Opslag personoplysninger Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-

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

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

Vilkår for Dialogintegration

Vilkår for Dialogintegration Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer

Læs mere

Folkekirkens It s arkitekturprincipper

Folkekirkens It s arkitekturprincipper Folkekirkens It s arkitekturprincipper Arkitekturprincipperne består af 11 principper, som skal anvendes ved alle nyanskaffelser og større ændringer af eksisterende it systemer. Arkitekturprincipperne

Læs mere

Integration SF Organisation services Integrationsbeskrivelse - version 2.2.0

Integration SF Organisation services Integrationsbeskrivelse - version 2.2.0 Integration Integrationsbeskrivelse - version 2.2.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-15 TBD 0.1 Første version 2015-04-09 MMT 0.2 Klar

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

Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services

Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services Forretningsmæssige testscases for Seal.net i relation til anvendelse af NSP services Version 1.0 april 2014 Indledning Seal.net er et API som har til formål at lette udviklingen af software som overholder

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