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

Størrelse: px
Starte visningen fra side:

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

Transkript

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

2 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige administration, samt vedligehold, og indgåelse og vedligehold af aftaler om adgang til it-systemer. Dokumentet er opdelt i følgende afsnit: Afsnit 2 Vilkår for Leverandørens anvendelse af rammearkitekturens administrationsmodul Afsnit 3 Vilkår for adgangsstyring for anvendersystemer Afsnit 4 Vilkår for adgangsstyring for serviceudbydere Afsnit 5 Vilkår for adgangsstyring for anvendersystemer med brugeradgang Afsnit 6 Ikke-funktionelle vilkår vedrørende adgangsstyring Underbilag A: Begrebs og informationsmodeller for administrationsmodulet Underbilag B: Begrebs og informationsmodeller for adgangsstyring Vejledningen benytter en lang række begreber, der har en specifik betydning for Adgangsstyring. Mange af begreberne er beskrevet i vejledningen når de benyttes. Læseren henvises i øvrigt til Underbilag A og Underbilag B for en nærmere beskrivelse af begreberne. 1.1 Overblik over adgangsstyring Adgangsstyring handler om at styre, hvilke brugere og systemer, der får adgang til it-systemer, herunder Støttesystemerne. Adgangsstyringen håndterer både hvem der kan logge ind i et it-system, og hvilken adgang, der efterfølgende gives til forskellige data og funktionalitet i it-systemet. Adgangsstyringen understøtter to forskellige scenarier: når et it-system (anvendersystem) tilgår en service i et andet it-system (serviceudbyder) når en bruger tilgår et it-system (brugervendt system) Disse to scenarier uddybes yderligere i det efterfølgende. I adgangsstyringsmodellen kaldes et it-system, der: udstiller en service for en serviceudbyder anvender en service for et anvendersystem udstiller en brugergrænseflade for et brugervendt system Adgangsstyring for serviceudbydere En lang række it-systemer, der udstiller services, kræver at en myndighed godkender at et andet it-system kan anvende servicen. Myndighedens godkendelse kan eksempelvis være påkrævet fordi servicen udleverer data, som myndigheden er dataansvarlig for, eller fordi myndigheden skal betale for anvendelse af servicen. Adgangsstyring understøtter det tilfælde, hvor et it-system udstiller en service, der kan anvendes af forskellige myndigheder, men hvor adgang til servicen, kan styres for hver enkelt myndighed. En service kan både benyttes til at udlevere data fra en serviceudbyder, til at indlevere data til serviceudbyderen eller til at få serviceudbyderen til at udføre en handling for anvendersystemet. Side 2 af 21

3 Anvendersystem udstiller fælleskommunal service til Serviceudbyder Støttesystemerne, Klassifikation, Organisation, Sags- og Dokumentindeks og Ydelsesindeks er eksempler på serviceudbydere. Fælleskommunale fagsystemer så som Kommunernes Ydelsessystem og Kommunernes Sygedagpenge vil ligeledes optræde som serviceudbyder. Andre systemer skal registreres som serviceudbydere, hvis de ønsker at udstille data. Anvendersystemer vil eksempelvis være fagsystemer, der skal anvende et af Støttesystemerne. Anvendersystemer kan også være et støttesystem, der ønsker at anvende i service, der udstilles af et andet støttesystem. Et givet it-system kan således både indtræde i rollen som anvendersystem og i rollen som serviceudbyder Serviceaftaler Når et anvendersystem skal have adgang til en service, kræves der en godkendelse fra den Myndighed, som anvendersystemet skal tilgå servicen på vegne af. Denne godkendelse indhentes i form af en serviceaftale. Indgåelse af serviceaftaler er systemunderstøttet via rammearkitekturens administrationsmodul. En serviceaftale indgås i praksis ved at Leverandøren af et anvendersystem anmoder om indgåelse af serviceaftalen og Myndigheden godkender eller afviser denne anmodning. Anvendersystem Serviceudbyder Leverandør af Identificerer Giver adgang til Dataansvarlig for Anmoder om Serviceaftale Godkender Leverandør Myndighed En serviceaftale tjener som en databehandleraftale, der giver Leverandøren af anvendersystemet en instruks om at måtte behandle Myndighedens data og overføre dem mellem anvendersystemet og serviceudbyderen. Serviceaftalen indeholder endvidere de adgangsrettigheder (i form af systemroller), som giver anvendersystemet adgang til serviceudbyderen. Derved kan serviceaftalen automatisk håndhæves, når anvendersystemet tilgår service, der udstilles af serviceudbyderen Systemroller og dataafgrænsninger Serviceudbyderen håndhæver adgangskontrol på baggrund af et antal systemroller. En systemrolle beskriver en gruppering af hvilken funktionalitet og data hos serviceudbyderen, som systemrollen giver adgang til. Mange it-systemer har en indbygget rettighedsmodel, der gør det muligt at detailstyre rettighedstildelinger i it-systemet. Eksempelvis kan det være muligt at tildele rettigheder for specifikke objekter og specifikke handlinger i it-systemet. En systemrolle vil være en gruppering af disse detailrettigheder. Mange Side 3 af 21

4 eksisterende it-systemer opererer allerede med begreber, der giver en sådan gruppering af detailrettigheder i systemroller. Systemroller tildeles anvendersystemer i forbindelse med indgåelsen af en serviceaftale. Anvendersystemet får derved lov til at tilgå den funktionalitet, og de data, hos serviceudbyderen, som myndigheden har godkendt i serviceaftalen giver adgang til. Når anvendersystemet tilgår en service, der udstilles af en serviceudbyder, håndhæver denne, ud fra de tildelte systemroller, at anvendersystemet kun får adgang til en begrænset mængde funktionalitet og data. Servicesystemrolle tildeles kan indholde håndhæves af Dataafgrænsning Anvendersystem tilgår Serviceudbyder Adgangsstyringsmodellen for brugere, der beskrives i de efterfølgende, er også er baseret på systemroller. Der bruges derfor betegnelsen servicesystemrolle for en systemrolle, der håndhæves af en serviceudbyder for at skelne dem fra systemroller, der bliver brugt i forbindelse med adgangsstyring for brugere (de såkaldte brugersystemroller). En systemrolle kan indeholde en række dataafgrænsninger, som begrænser systemrollens datamæssige virkefelt. Eksempelvis ville en systemrolle Hent sag kunne indeholde en dataafgrænsning på sagstype defineret som et KLE nummer. Anvendersystem kan så tildeles servicesystemrollen Hent sag og man kan sætte dataafgrænsningsværdien sagstype = *. Således autoriseres anvendersystemet til at hente alle sager, der har en sagstype med KLE hovedgruppe 27 og KLE gruppe Flow for anvendelse af en service Når et anvendersystem tilgår en service udstillet af en serviceudbyder, foregår adgangsstyring ved at anvendersystemet først anmoder Security Token Service om et adgangstoken med de servicesystemroller, som anvendersystemet er tildelt Security Token Servicen er et støttesystem i rammearkitekturen, der har til formål at udstede adgangstokens. Adgangstokens er baseret på SAML standarden og anmodninger til Security Token Servicen forgår ved brug af OIO WS-Trust protokollen. Når anvendersystemet tilgår serviceudbyderen medsendes dette token, og serviceudbyderen tillader så adgang ud fra disse servicesystemroller. For at forhindre uautoriseret adgang er alle tokens signeret med kryptografiske signaturer. Side 4 af 21

5 Anvendersystem Anmoder om token Security Token Service Autoriserer Serviceudbyderroller til Serviceudbyder Tilsluttes og opsættes via Administrationsmodulet Anvendersystemer og serviceudbyder tilsluttes til rammearkitekturen via rammearkitekturens administrationsmodul. Administrationsmodulet benyttes ligeledes til at indgå serviceaftaler. Security Token Servicen opdateres løbende fra rammearkitekturens administrationsmodul med informationer om anvendersystemer, serviceudbyder og serviceaftaler efterhånden som disse registreres. Security Token Servicen kan således automatisk udstede adgangstokens for de tilsluttede systemer på baggrund af de indgåede serviceaftaler. Det overvejes at udvikle en lokal Security Token Service, der er et system, som kan opsættes lokalt hos en myndighed. Den lokale Security Token Service får delegeret retten til at udstede adgangstokens for kommunens lokale anvendersystemer. Hvis man anvender en lokal Security Token Service behøver anvendersystemer ikke at være registreret i rammearkitekturens administrationsmodul og indgå serviceaftaler for at få adgang til en serviceudbyder. Vilkårene for lokale anvendersystem vil derfor være lidt anderledes end de vilkår der er beskrevet nedenfor. Eksempelvis skal et lokalt anvendersystem ikke registreres i rammearkitekturens administrationsmodul og det skal kontakte den lokale Security Token Service for at få udstedt lokale adgangstokens, der sidenhen skal veksles hos rammearkitekturens Security Token Service. Hvis det besluttes at udvikle en lokal Security Token Service vil der blive publiceret anvendervilkår for lokale anvendersystemer Adgangsstyring for brugere Fagsystemer skal oftest anvendes af brugere fra forskellige myndigheder. Rammearkitekturen understøtter derfor adgangsstyring for brugere, der giver brugere fra forskellige myndigheder mulighed for tilgå de fællekommunale systemer. Rammearkitekturens adgangsstyring for brugere er baseret på en fødereret model. Brugere oprettes, tildeles adgang til rammearkitekturens system og autentificere lokalt hos de enkelte myndigheder. Rammearkitekturen implementerer så den infrastruktur, der muligøre at myndighedens bruger i praksis kan få adgang de forskellige systemer, der er tilsluttet rammearkitekturen. De systemer, som understøttes af rammearkitekturens adgangsstyring for brugere kalder for brugervendte systemer: Side 5 af 21

6 tilgår Brugervendt system Bruger De fælleskommunale fagsystemer er eksempler på brugervendte systemer. De fællekommunale støttesystemer, vil også have en brugergrænseflade til administrativt brug og vil derfor også være eksempler brugervendte systemer. Man kan på sigt også forestille sig at nogle kommuner vil indkøbe systemer til eget brug, der vil benytte rammearkitekturens model for adgangsstyring. Disse systemer vil så også være brugervendte systemer i rammearkitekturens adgangsstyringsmodel Roller og dataafgrænsninger Adgangskontrollen for brugervendte systemer håndhæves, ligesom for serviceudbydere, ud fra systemroller med tilhørende dataafgrænsninger. Disse systemroller kaldes brugersystemroller, for at skelne dem fra de systemroller, der benyttes af serviceudbydere. Et brugervendt system håndhæver brugeradgang ud fra et antal brugersystemroller med tilhørende dataafgrænsninger. Disse udarbejdes i forbindelse med designet af det brugervendte system. For at understøtte en fødereret model for adgangsstyring, der kan anvendes af forskellige myndigheder, tillader rammearkitekturens adgangsstyring, at hver enkelt myndighed kan redigere deres egne jobfunktionsroller. En jobfunktionsrolle er en samling af brugersystemroller, hvor de tilhørende dataafgrænsninger endvidere er tildelt en dataafgrænsningsværdi. Jobfunktionsroller giver således myndighederne mulighed for at samle brugersystemroller i nogle overordnede roller og vil derved gøre den daglige administration med at tildele roller til brugere lettere for myndigheden. Jobfunktionsroller bør udarbejdes af myndigheden, så de svarer til de jobfunktioner, den enkelte myndighed har. En jobfunktionsrolle kunne eksempelvis svare til en jobfunktion som Borgerservicemedarbejder, Udbetaler for kontanthjælp eller som Sagsbehandler for børn og unge. Idet jobfunktionsroller kan defineres forskelligt for hver enkelt myndighed, giver det myndighederne mulighed for at organisere deres arbejde forskelligt, selv om de anvender de samme brugervendte systemer. Jobfunktionsroller kan indholde Brugersystemrolle tildeles kan indholde Dataafgrænsning håndhæves af tilgår Brugervendt system Bruger Side 6 af 21

7 Jobfunktionsroller administreres af Myndigheden i rammearkitekturens administrationsmodul. Selve tildelingen af jobfunktionsroller til brugere, foregår derimod lokalt hos myndigheden ved brug af dens egen brugeradministrationsløsning Flow for bruger log-in Når en bruger skal logge ind på et brugervendt system, der understøttes af rammearkitekturens adgangsstyring, foregår det overordnet set som beskrevet nedenfor. Autentificeres af Identity Provider Autoriserer Jobfunktionsroller til Context Handler Autoriserer Brugersystemroller til Brugervendt system Bruger Tilsluttes og opsættes via Administrationsmodulet Når en bruger tilgår et brugervendt system, og ikke er logget ind, sender det brugervendte system brugeren videre til myndighedens egen Identity Provider. En Identity Provider er et system, der kan autentificere brugeren, og som ved hvilke jobfunktionsroller brugeren er tildelt. En Identity Provider i den fælleskommunale rammearkitektur vil som oftest være et system, der er integreret med myndighedens eksisterende brugeradministrationsløsning. Man kan herunder også integrere til myndighedens eksisterende single sign-on løsning, således at brugeren ikke oplever at blive spurgt om eksempelvis brugernavn og password i forbindelse med autentifikation for det brugervendte system, såfremt brugeren allerede er logget ind på andre af myndighedens systemer. Når brugeren er autentificeret, udsteder Identity Provideren en SAML token, der indeholder brugerens identitet, hvilken myndighed brugeren kommer fra, samt hvilke jobfunktionsroller brugeren er tildelt. SAML tokenet fra Identity Provideren sendes videre til Context Handleren, der er et system i den fælleskommunale rammearkitektur. Context Handleren omveksler SAML tokenet til et andet SAML token, der indeholder brugersystemroller for det specifikke brugervendte system, som brugeren ønsker at logge ind på. Dette SAML token med brugersystemrolle videresendes til det brugervendte system, der opretter en session for brugeren. I denne session håndhæver det brugervendte system, at brugeren kun får adgang til den funktionalitet og data, som brugeren er autoriseret til, i henhold til det medsendte SAML token. Hele det ovenstående log-in flow er rent teknisk baseret på den eksisterende OIOSAML standard. Dog vil der blive udarbejdet en ny attributprofil for SAML tokens, så disse kan indeholde jobfunktionsroller og systemroller. Dette er ikke understøttet i den eksisterende OIOSAML standard. Context Handleren opdateres løbende fra rammearkitekturens administrationsmodul, med informationer om Identity Providere, brugervendte systemer og definitioner af jobfunktionsroller efterhånden som disse registres. Context Handleren kan således automatisk omveksle adgangstokens for de tilsluttede myndigheders brugere, på baggrund af de jobfunktionsroller, som myndigheden har defineret. Side 7 af 21

8 Side 8 af 21

9 2. Vilkår for Leverandørens anvendelse af rammearkitekturens administrationsmodul Alle systemer, der skal anvende den fælleskommunale rammearkitektur skal systemet oprettes og administreres i rammearkitekturens administrationsmodul i henhold til vilkår i dette afsnit. For at Systemet kan anvende rammearkitekturen, skal Leverandøren oprettes som tilslutningspart i rammearkitekturs administrationsmodul, og Leverandøren skal oprette en tilslutningsaftale for Systemet i administrationsmodulet. 2.1 Vilkår for oprettelse som tilslutningspart Vilkår #1 Oprettelse af tilslutningspart Kategori: (v) Type: Ikke funktionelt Leverandøren skal oprette sig som tilslutningspart i rammearkitekturens administrationsmodul, for kunne tilslutte systemer til rammearkitekturen og redigere aftaler og roller for disse. Vilkår #2 Leverandøren skal udpege Administratorer Kategori: (v) Type: Ikke funktionelt Leverandøren skal udpege en, eller flere, administratorer i Leverandørens organisation. Disse administratorer skal varetage forskellige administrative roller på vegne af Leverandøren, herunder en rolle til at kunne indgå juridisk bindende aftaler for Systemet, og en anden rolle til foretage teknisk administration af Systemet. Disse administratorer skal kunne logge på rammearkitekturens administrationsmodul ved anvendelse af et OCES medarbejder certifikat. Leverandøren af Systemet skal løbende ajourføre de udpegede administratorer, med eventuelle ændringer af ansvarlige personer i Leverandørens organisation. 2.2 Vilkår for oprettelse af tilslutningsaftaler Vilkår #3 Etablering af aftale om tilslutning Kategori: (v) Type: Ikke funktionelt Leverandøren er ansvarlig for at anmode om tilslutning af Systemet til rammearkitekturen via rammearkitekturens administrationsmodul. Leverandøren af Systemet skal anvende rammearkitekturens administrationsmoduls brugergrænseflade til dette formål. Leverandøren af Systemet er forpligtiget til at tiltræde, og overholde, vilkårene i den til enhver tid gældende aftale for tilslutning af systemer til den fælleskommunale rammearkitektur. Side 9 af 21

10 Vilkår #4 Oprettelse af tilslutning Kategori: (v) Type: Ikke funktionelt Leverandøren er ansvarlig for at Systemet tilsluttes via rammearkitekturens administrationsmodul, med den, eller de, systemtyper (brugervendt system, anvendersystem og/eller serviceudbyder), der er relevante for Systemet. Leverandøren af Systemer skal oprette alle relevante konfigurationsoplysninger for Systemet, eksempelvis navn, beskrivelse, SAML metadata, OCES certifikat til identifikation af Systemet, og systemroller. Konfigurationsoplysninger varierer afhængigt af systemtype. Vilkår #5 Vedligehold af tilslutning Kategori: (v) Type: Ikke funktionelt Leverandøren er ansvarlig for at konfigurationsoplysninger for Systemet er korrekte og løbende opdateres, herunder at certifikater opdateres inden udløb. Side 10 af 21

11 3. Vilkår for adgangsstyring for anvendersystemer Såfremt Systemet er et anvendersystem skal Systemet opfylde de vilkår, der er beskrevet i dette afsnit for at kunne få adgang til en serviceudbyder. Et anvendersystem er i denne sammenhæng et system, der anvender en af de services, der udstilles af en serviceudbyder, som benytter rammearkitekturens model for adgangsstyring. Adgang til serviceudbydere kræver, at der er oprettet en serviceaftale. En serviceaftale beskriver hvilken adgang et givet anvendersystem får til data, og funktionalitet, hos en given serviceudbyder. Serviceaftaler indgås altid i kontekst af en given Myndighed, og giver således anvendersystem adgang på til data og funktionalitet på vegne af en specifik Myndighed. Indgåelse af en serviceaftale foregår via rammearkitekturens administrationsmodul, hvor det er Leverandøren af et anvendersystem, der skal oprette en anmodning om indgåelse af en serviceaftale. Denne anmodning fremsendes til Myndigheden og, såfremt denne godkender aftalen, vil anvendersystemet automatisk blive tildelt de adgangsgivende systemroller, der er nødvendige for at tilgå serviceudbyderen. Når anvendersystemet i praksis skal tilgå en serviceudbyder, kræver det at anvendersystemet har et gyldigt Security Token, der medsendes til kald af serviceudbyderen. Security Token et udstedes til anvendersystemet af rammearkitekturens Security Token Service. 3.1 Vilkår for oprettelse og vedligehold af aftaler Vilkår #6 Etablering af serviceaftaler Kategori: (v) Type: Ikke funktionelt Leverandøren af Systemet er ansvarlig for at anmode om nye serviceaftaler, der er nødvendige for Systemets brug af en fælleskommunal serviceudbyder. Leverandøren af Systemet skal anvende rammearkitekturens administrationsmoduls brugergrænseflade, til at anmode om serviceaftaler. Vilkår #7 Vedligehold af serviceaftaler Kategori: (v) Type: Ikke funktionelt Leverandøren af Systemet er ansvarlig for at vedligeholde indgåede aftaler, ved at foretage nødvendige ændringsanmodninger til eksisterende serviceaftaler til Systemets brug af rammearkitekturen. Leverandøren af Systemet skal anvende rammearkitekturens administrationsmoduls brugergrænseflade til dette formål. Side 11 af 21

12 3.2 Vilkår for integration med Security Token Service Vilkår #8 Brug af Security Token Service Systemet skal benytte Security Token Servicen i rammearkitekturen, til at få udstedt SAML Security Tokens forud for kald af adgangsbegrænsede services, der udstilles af fælleskommunale serviceudbydere. Security Token Service kaldes med en <RequestSecurityToken >-besked, i henhold til OIO WS-Trust profilen af OASIS WS-Trust standarden. Kald til Security Token Servicen signeres med et OCES certifikat, der er tilknyttet Systemet, og som forinden er registreret af Leverandøren af Systemet via rammearkitekturens administrationsmodul. 3.3 Vilkår for anvendelse af serviceudbydere Vilkår #9 Anvendelse af adgangsbegrænsede serviceudbydere Systemet skal medsende gyldige security tokens hentet fra Security Token Service, ved kald til adgangsbegrænsede services udstillet af en serviceudbyder. Bemærkning: Et SAML token må caches og anvendes så længe det er gyldigt således, at efterfølgende service-kald til samme serviceudbyder ikke behøver involvere forudgående kald til Security Token Servicen, for at etablere et nyt Security Token. Vilkår #10 Etablering af sikker forbindelse Når Systemet kalder serviceudbyderen, skal Systemet etablere en sikker forbindelse med serviceudbyderen, der sikrer gensidig autentifikation af systemerne, samt integritet og hemmeligholdelse af servicekaldet, og dets data. Etablering af den sikre forbindelse skal ske i henhold til de vilkår, serviceudbyderen udstikker for etablering af en sikker forbindelse. Bemærkning: Grænsefladerne for de enkelte serviceudbydere er endnu ikke fastlagt, og derfor er der heller ikke endnu fastlagt specifikke protokoller for hvordan man etablerer en sikker forbindelse. Etablering af den sikre forbindelse forventes at blive baseret på WS-* protokolstakken, hvor autentifikation af Systemet baseres på adgangstokens, udstedt af den fælleskommunale Security Token Service, for følgende fælleskommunale støttesystemer: Klassifikation Organisation Side 12 af 21

13 Sags- og Dokumentindeks Ydelsesindeks Det er endnu ikke afgjort hvordan etablering af den sikre forbindelse foregår for følgende fælleskommunale støttesystem: Beskedfordeler Side 13 af 21

14 4. Vilkår for adgangsstyring for serviceudbydere Vilkår i dette afsnit er relevante for alle systemer, der skal optræde som serviceudbyder af en fælleskommunal service i henhold til rammearkitekturens adgangsstyringsmodel. En serviceudbyder er et it-system, der udstiller en service, hvor adgangsbegrænsning sker i henhold til en serviceaftale, som er registeret i rammearkitekturens administrationsmodul. Der påhviler ikke direkte Leverandøren af serviceudbyderen nogen forpligtigelser i forbindelse med indgåelse af serviceaftaler, idet disse aftaler indgås mellem leverandøren af et anvendersystem og de Myndigheder, som anvendersystemet har behov for at tilgå serviceudbyderen på vegne af. Til gengæld skal serviceudbyderen håndhæve adgangskontrol, når anvendersystemet tilgår serviceudbyderen. Håndhævelsen af adgangskontrol sker ud fra en række systemroller med tilhørende dataafgrænsninger. Disse defineres af Leverandøren af serviceudbyderen i forbindelse med udvikling af systemet, og det er således mulighed for at definere disse systemroller, og dataafgrænsninger, så de passer til den adgangsstyringsmodel, der allerede måtte findes i systemet. Systemroller, med tilhørende dataafgrænsninger, for serviceudbyderen oprettes, og vedligeholdes af Leverandøren af serviceudbyderen via rammearkitekturens administrationsmodul, så de kan tildeles til anvendersystemer, når der indgås en serviceaftale. Serviceudbyderen skal håndhæve adgangskontrol på baggrund af Security Tokens, der udstedes af rammearkitekturens Security Token Service. Disse Security Tokens medsendes i servicekald til serviceudbyderen, og indeholder attributter, der beskriver hvilke systemroller et anvendersystem er tildelt. 4.1 Vilkår for oprettelse og vedligehold af systemroller Vilkår#11 Understøttelse af Systemroller Systemet skal understøtte adgangskontrol ud fra en række systemroller med tilhørende dataafgrænsninger. Leverandøren af Systemet er ansvarlig for at definere en række systemroller, og tilhørende dataafgrænsninger, til Systemet. Systemroller og dataafgrænsninger skal være kompatible med rammearkitekturens begrebs- og informationsmodel for adgangsstyring som beskrevet i Underbilag B Systemroller og dataafgrænsninger skal defineres, så de er tilstrækkeligt finkornede til at imødegå de forretningsmæssige behov der er for at kunne skelne mellem forskellige former for adgang til Systemet. Systemroller og dataafgrænsninger skal repræsenteres eksternt som en unik URI med et systemspecifikt præfiks. Side 14 af 21

15 Vilkår #12 Registrering af systemroller og dataafgrænsninger Leverandøren af Systemet er ansvarlig for at registrere systemroller, med tilhørende dataafgrænsninger, i rammearkitekturens administrationsmodul og løbene vedligeholde disse. Bemærkning: Registrering af systemroller, og tilhørende dataafgrænsninger, foregår i rammearkitekturens administrationsmodul i forbindelse med at systemet tilsluttes. 4.2 Vilkår for håndhævelse af adgangskontrol Vilkår #13 Håndhævelse af adgangskontrol Systemet skal håndhæve adgangskontrol ved alle kald til Systemets services. Adgangskontrollen skal håndhæves ud fra de attributter, der findes i det servicesystemtoken, der medsendes til servicekaldet. Et servicesystemtoken er et SAML Security Token, der blandt andet indeholder attributter, der beskriver anvendersystemets tildelte systemroller, og tilhørende dataafgrænsninger. Systemroller er altid tildelt i en given anvenderkontekst (CVR nummer). Systemet skal sikre at anvendersystemet kun får adgang til funktionalitet, og data, i Systemet, der svarer til de systemroller med tilhørende dataafgrænsninger, som tokenet indeholder. Som en del af adgangskontrollen skal Systemet validere, at SAML tokenet er gyldigt, herunder at det er udstedt af rammearkitekturens Security Token Service. Er Tokenet ikke gyldigt skal adgang til Systemet nægtes. Vilkår #14 Adskillelse mellem Myndigheder Adgangskontrollen skal sikre, at der er adgangsbegrænsning mellem Myndighedernes data, ved at respektere de anvenderkontekster (CVR numre), der fremgår af det modtagne servicesystemtoken. Side 15 af 21

16 Vilkår #15 Etablering af sikker forbindelse Systemets services skal udstille funktionalitet og data via en sikker forbindelse, der sikrer gensidig autentifikation af systemerne, samt integritet og hemmeligholdelse af servicekaldet og dets data. Leverandøren af Systemet skal udstikke præcise retningslinjer for hvordan en sikker forbindelse etableres. Disse retningslinjer skal svare til de retningslinjer, der benyttes af de fælleskommunale støttesystemer. Ved udstilling af services med personhenførbare data, skal krav i persondataloven og sikkerhedsbekendtgørelsen overholdes, herunder krav til stærk kryptering, logning og kontrol med afviste adgangsforsøg. Bemærkning: For følgende fælleskommunale støttesystemer forventes etablering af den sikre forbindelse at blive baseret på WS-* protokolstakken, hvor autentifikation af Systemet baseres på adgangstokenet udstedt af den fælleskommunale Security Token Service: Klassifikation Organisation Sagsindeks Dokumentindeks Ydelsesindeks Det er endnu ikke afgjort hvordan etablering af den sikre forbindelse foregår for følgende fælleskommunale støttesystem: Beskedfordeler Side 16 af 21

17 5. Vilkår for adgangsstyring for et brugervendt system Vilkår i dette afsnit kan være relevante at medtage i et udbud, såfremt Systemet, der udbydes, skal foretage adgangsstyring for brugere. Vilkårene i dette afsnit skal stilles til Systemet, såfremt Systemet skal foretage adgangsstyring for brugere i henhold til rammearkitekturens føderationsmodel for adgangsstyring. Det er dog ikke obligatorisk, at adgangsstyring for brugervendte systemer forgår i henhold til rammearkitekturens adgangsstyringsmodel, for at et givet system kan optræde som et anvendersystem i rammearkitekturen. I forbindelse med et it-udbud bør kommunen nøje overveje fordele og ulemper ved at anvende rammearkitekturens model for adgangsstyrring for brugere. Håndhævelsen af brugerrettigheder sker ud fra en række brugersystemroller, og tilhørende dataafgrænsninger. Disse defineres af Leverandøren af det brugervendte system i forbindelse med udvikling af systemet og der er således mulighed for at definere disse brugersystemroller og dataafgrænsninger, så de passer til den adgangsstyringsmodel, der allerede måtte findes i systemet. Brugersystemroller med tilhørende dataafgrænsninger for et brugervendt system oprettes, og vedligeholdes, af Leverandøren af Systemet via rammearkitekturens administrationsmodul. Her kan Myndigheder anvende disse brugerbrugersystemroller i forbindelse med administration af adgangsstyring for Myndighedens brugere. Brugeradgang håndteres efter en føderationsmodel. For et brugervendt system betyder det, at det ikke behøver at kende de enkelte brugere. Systemet skal i forbindelse med bruger-login henvise brugeren til rammearkitekturens Context Handler, der sørger for, at bruger-login håndteres af brugerens egen organisation. Systemet skal efterfølgende håndhæve adgang på baggrund af adgangstokens, der udstedes af rammearkitekturens Context Handler. 5.1 Vilkår for oprettelse og vedligehold af brugersystemroller Vilkår #16 Brugersystemroller Systemet skal understøtte adgangskontrol ud fra en række brugersystemroller med tilhørende dataafgrænsninger. Leverandøren af Systemet er ansvarlig for, at definere en række brugersystemroller, og tilhørende dataafgrænsninger, til Systemet. Brugersystemroller og dataafgrænsninger skal være kompatible med rammearkitekturens begrebs- og informationsmodel for adgangsstyring, som beskrevet i Underbilag B Brugersystemroller og dataafgrænsninger skal defineres så de er tilstrækkeligt finkornede til at imødegå de forretningsmæssige behov der er, for at kunne skelne mellem forskellige former for adgang til Systemet. Brugersystemroller og dataafgrænsninger skal repræsenteres eksternt som en unik URI med et systemspecifikt præfiks. Side 17 af 21

18 Vilkår #17 Registrering af brugersystemroller og dataafgrænsninger Leverandøren af Systemet er ansvarlig for at registrere, og løbende vedligeholde, brugersystemroller med tilhørende dataafgrænsninger i rammearkitekturens administrationsmodul. Herunder skal Leverandøren vedligeholde anvenderkontekster på brugerbrugersystemroller, så en given brugerbrugersystemrolle kun er tilgængelig for relevante Myndigheder, jf. begrebsmodellen i Underbilag A 5.2 Vilkår for bruger-login, brugersessionsstyring og bruger-logout Vilkår #18 Brugerlog-in via Context Handler Log-in af brugere til Systemets web-baserede grænseflader skal håndteres via Context Handleren (SAML Identity Provider) i rammearkitekturen ved brug af OIOSAML protokollen. Systemet skal overholde OIOSAML profilen (version 2.0.9), dog med en anden attributprofil. Bemærkning: KOMBIT planlægger at definere en ny SAML profil baseret på OIOSAML, men med et andet sæt af attributter. Det vil så blive et vilkår at denne nye SAML profil understøttes. En ny SAML profil vil i givet fald blive udarbejdet i forbindelse med etablering af Context Handleren. Attributprofilerne vil blive udarbejdet ud fra informationsmodellen for adgangsstyring i Underbilag B. Vilkår #19 Vilkår for OIOSAML Implementering Systemet skal, i sin SAML implementering, håndtere SAML AuthnRequest og SingleLogout protokollerne. Systemet skal både kunne være initierende og ikke-initierende i forhold til SAML SingleLogout. Side 18 af 21

19 Vilkår #20 Sessionsoprettelse Efter log-in af brugeren, udtrækkes informationer fra SAML token (modtaget fra Context Handler) indeholdende bl.a. de brugersystemroller, der er tildelt den aktuelle bruger for Systemet. På baggrund af indholdet af det modtagne SAML token, oprettes en lokal session med brugeren, og der kan evt. just-in-time oprettes en lokal brugerkonto, hvis Systemet har behov herfor. Der sker således ingen oprettelser af brugere (provisionering) forud for login. Vilkår #21 Sessionsstyring Systemet skal selv håndtere sessionsstyring med brugerens browser, og herunder implementere timeout af brugersessioner ved inaktivitet i en vis periode. Det skal være muligt at konfigurere alle timeout perioder. Vilkår #22 Logout Systemet skal på brugergrænseflader implementere en visuel komponent til Logout (via en knap eller et link), som giver brugeren mulighed for at logge af Systemet, samt øvrige systemer, der har en session med Context Handleren. Endvidere skal Systemet udstille en SOAP baseret logout mekanisme (SAML endpoint), som kan kaldes fra Context Handleren for tvungen logout af en bruger. Side 19 af 21

20 5.3 Vilkår for håndhævelse af adgangskontrol Vilkår #23 Håndhævelse af adgangskontrol Systemet skal håndhæve adgangskontrol over for brugere til data og ressourcer, som Systemet udstiller via brugergrænsefladen. Adgangskontrollen skal håndhæves ud fra de attributter der findes i den SAML token, der anvendes ved oprettelse af brugerens session. Attributterne indeholder blandt andet oplysninger om brugerens kontekst (CVR nummer) og tildelte brugersystemroller med tilhørende dataafgrænsninger. Systemet skal sikre at brugeren kun får adgang til funktionalitet og data i Systemet, der svarer til brugersystemroller med tilhørende dataafgrænsninger, som tokenet indeholder. Som en del af adgangskontrollen skal Systemet validere at SAML tokenet er gyldigt, herunder at det er udstedt af Context Handleren. Er Tokenet ikke gyldigt, skal adgang til Systemet nægtes. Vilkår #24 Adskillelse mellem Myndigheder Adgangskontrollen skal sikre, at der er adgangsbegrænsning mellem Myndighedernes data, ved at respektere den anvenderkontekst (CVR nummer), der fremgår af det modtagne SAML token. Vilkår #25 Delegering Systemet skal understøtte rammearkitekturens model for delegering af roller fra én organisation til en anden. Dette betyder at modtagne SAML tokens kan indikere, at brugeren har modtaget en brugersystemrolle på vegne af en anden organisation, end brugeren kommer fra. Mere specifikt vil brugersystemrollen have en scope attribut, som indikerer et andet CVR nummer. I dette tilfælde skal Systemet give brugeren den adgang, som defineres i brugersystemrollen, på vegne af den delegerende organisation. 6. Ikke-funktionelle vilkår Vilkårene i dette afsnit er relevante for alle systemer, der skal benytte adgangsstyring i rammearkitekturen uanset om de er anvendersystemer, serviceudbydere eller brugervendte systemer. Side 20 af 21

21 6.1 Sikring af systemer, der foretager adgangsstyring Rammearkitekturens adgangsstyringsmodel er baseret på anvendelse af OIO SAML, OIO WS-Trust og OCES certifikater. Alle anvendersystemer, serviceudbydere og brugervendte systemer, der optræder som SAML end-point, skal overholde følgende Vilkår for sikring. Vilkår #26 Validering af tokens og certifikater Kategori: (v) Type: Ikke-funktionelt Signaturer, certifikater og security tokens skal sikkerhedsvalideres af Systemet før brug. Der må kun accepteres SAML tokens, som er digitalt underskrevet med Context Handlerens eller Security Token Servicens certifikat. Alle certifikater skal spærretjekkes mod DanID inden de anvendes. Vilkår #27 AssuranceLevel Kategori: (v) Type: Ikke-funktionelt Leverandøren af Systemet skal definere hvilket niveau af autenticitetssikring (level of assurance) der er behov for, for at tilgå Systemet. Leverandøren af Systemet skal anvende den fællesoffentlige referenceramme for definition af autenticitetssikring i [OIO-A- LEVEL]. Ved modtagelse af et security token skal Systemet validere, at tokenet er udstedt på mindst samme niveau, som kræves for at opnå adgang. Eksempelvis må et token med Assurancelevel=2 ikke anvendes til at tilgå et system, der kræver niveau 3. Hvis Systemet giver adgang til fortrolige eller følsomme personoplysninger, bør det krævede niveau sættes til mindst 3. Vilkår #28 Beskyttelse af private nøgler Kategori: (v) Type: Ikke-Funktionelt Leverandøren af Systemet er ansvarlig for at beskytte private nøgler mod uautoriseret adgang herunder de private nøgler til de OCES funktionscertifikater, som anvendes mod Context Handler og Security Token Service. Vilkår #29 Beskyttelse af trust-stores Kategori: (v) Type: Ikke-Funktionelt Systemet skal beskytte de lokale trust stores (f.eks. lokale kopier af metadata og certifikater fra Context Handler og Security Token Service) mod uautoriseret adgang. Det er Leverandøren af Systemets ansvar, at trust stores beskyttes tilstrækkeligt. Side 21 af 21

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan Anvendersystemer afsender og/eller modtager objekter til/fra

Læs mere

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det

Læs mere

Klik her for at angive tekst.

Klik her for at angive tekst. 30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav

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

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

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

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

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

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

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

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,

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

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

Vilkår vedrørende anvendelsen af Støttesystemet Organisation

Vilkår vedrørende anvendelsen af Støttesystemet Organisation Vilkår vedrørende anvendelsen af Støttesystemet Organisation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Organisation,

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

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

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

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

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

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

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

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

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

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

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

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

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

Security Token Service. Snitflade OIO WS Trust

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

Læs mere

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

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

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

Sags- og Dokumentindeks og Ydelsesindeks

Sags- og Dokumentindeks og Ydelsesindeks Støttesystemet Sags- og Dokumentindeks og Ydelsesindeks 1 Sags- og Dokumentindeks og Ydelsesindeks To af de otte Støttesystemer 2 Kombit Støttesystemerne Sags- og Dokumentindeks og Ydelsesindeks Hvad er

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

Acadre-integration til SAPA

Acadre-integration til SAPA Løsningsbeskrivelse Leverandør: Formpipe Software A/S Borupvang 5D DK-2750 Ballerup CVR nr. 29177015 Indholdsfortegnelse 1.0 Acadre-integration til SAPA... 1 1.1 Overordnet beskrivelse... 1 1.2 Detaljeret

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

Databehandleraftale vedrørende brug af. WinPLC og relaterede services. Version 1.0 d. 1. november Parterne. Kundenr.:

Databehandleraftale vedrørende brug af. WinPLC og relaterede services. Version 1.0 d. 1. november Parterne. Kundenr.: Databehandleraftale vedrørende brug af WinPLC og relaterede services Version 1.0 d. 1. november 2015 Parterne Kundenr.: Klinikkens navn og adresse (evt. stempel) (herefter den Dataansvarlige) og (herefter

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

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

SAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL

SAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL SAPA KRAVSPECIFIKATION v. 0.8 Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL Sags- og partsoverblikket Vise adresser der har adressebeskyttelse Adressen

Læs mere

Vilkår for dialogintegration SAPA

Vilkår for dialogintegration SAPA Vilkår for dialogintegration SAPA Klaus Rasmussen 26. oktober 2016 Indhold 1. Indledning og vejledning... 3 1.1 Definitioner... 4 2. Krav til it-systemer for at kunne udføre dialogintegration... 5 2.1

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

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

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

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

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

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

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

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

Læs mere

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

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

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

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

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

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

Teknisk leverandørspor - Serviceplatformen

Teknisk leverandørspor - Serviceplatformen Teknisk leverandørspor - Serviceplatformen Dagsorden 1. Velkomst og opfølgning 2. Brainstorm 3. Demo Administrationsmodul 4. Brugerstyring, certifikater og adgang til services 5. Integrationsmønstre 6.

Læs mere

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014 Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,

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

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

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

Krav og vejledning til kommunernes fremtidige it-udbud

Krav og vejledning til kommunernes fremtidige it-udbud Klik her for at angive tekst. Krav og vejledning til kommunernes fremtidige it-udbud I forbindelse med det forestående monopolbrud udarbejder KOMBIT i samarbejde med kommunerne en trin-for-trin drejebog,

Læs mere

AFTALE OM BEHANDLING AF PERSONOPLYSNINGER. Mellem. [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren )

AFTALE OM BEHANDLING AF PERSONOPLYSNINGER. Mellem. [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren ) AFTALE OM BEHANDLING AF PERSONOPLYSNINGER Mellem [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren ) og Midttrafik Søren Nymarks Vej 3 8270 Højbjerg CVR-nr.: 29943176 (herefter Midttrafik

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

STS-KOMMUNENETVÆRK. 5. og 7. april 2016 Kenneth Møller Johansen

STS-KOMMUNENETVÆRK. 5. og 7. april 2016 Kenneth Møller Johansen STS-KOMMUNENETVÆRK 5. og 7. april 2016 Kenneth Møller Johansen Første kommune er live på Adgangsstyring Og alle står i kø for at få lov til at teste og anvende Støttesystemerne Første bølge i monopolbruddet

Læs mere

Integration SF1570 - SKAT R75 Integrationsbeskrivelse - version 2.0.0

Integration SF1570 - SKAT R75 Integrationsbeskrivelse - version 2.0.0 Integration Integrationsbeskrivelse - version 2.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2014-10-06 DGJ 0.1 Første version 2015-06-29 JJN 0.2 Referencerettelser

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

Bilag 2.1.B Integrationer og snitflader Samarbejdsplatformen

Bilag 2.1.B Integrationer og snitflader Samarbejdsplatformen Bilag 2.1.B Integrationer og snitflader Samarbejdsplatformen INSTRUKTION TIL TILBUDSGIVER Nærværende bilag 2.1.B (Integrationer og snitflader) udgør et supplement til bilag 2 (Kravspecifikation). Bilaget

Læs mere

Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 2.0

Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 2.0 Underbilag 2M Begrebs- og informationsmodel for Ydelsesindeks Version 20 Begrebsmodellen for Ydelsesindeks Begrebsmodellen med de centrale forretningsobjekter er illustreret i Figur Begrebsmodel og definition

Læs mere

It-sikkerhedstekst ST6

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

Læs mere

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

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

Læs mere

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

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

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

Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet):

Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside:  ISBN (internet): > Identitetsbaserede web services og personlige data Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens

Læs mere

BILAG 5 DATABEHANDLERAFTALE

BILAG 5 DATABEHANDLERAFTALE BILAG 5 DATABEHANDLERAFTALE INDHOLDSFORTEGNELSE 1. Formål og omfang... 5 2. Databehandlers opgave... 5 3. Instruks... 5 4. Brug af ekstern Databehandler eller underleverandør... 5 5. Behandling i udlandet...

Læs mere

Databehandleraftale. om [Indsæt navn på aftale]

Databehandleraftale. om [Indsæt navn på aftale] Databehandleraftale om [Indsæt navn på aftale] Jf. bestemmelserne i lov nr. 429 af 31. maj 2000 om behandling af personoplysninger med senere ændringer (Persondataloven) mellem Vesthimmerlands Kommune

Læs mere

SKI 02.19. Version 1.0

SKI 02.19. Version 1.0 SKI 02.19 Version 1.0 23. maj 2015 1 Indhold Indledning... 3 Snitfladernes etablering og tilgængelighed... 3 Integrations- og anvendervilkår... 3 Beskrivelse af KOMBITs snitfladeoversigt... 4 Faneblad:

Læs mere

1 Begrebsmodel for Ydelsesindeks

1 Begrebsmodel for Ydelsesindeks 1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående

Læs mere

Informationsmateriale til leverandørerne om. Den fælleskommunale Serviceplatform Version 1.1, december 2013

Informationsmateriale til leverandørerne om. Den fælleskommunale Serviceplatform Version 1.1, december 2013 Informationsmateriale til leverandørerne om Den fælleskommunale Serviceplatform Version 1.1, december 2013 Den fælleskommunale Serviceplatform Fra 1.januar 2014 åbner den fælleskommunale Serviceplatform

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

Opnåelse af tilladelse til at udbyde spil i Danmark

Opnåelse af tilladelse til at udbyde spil i Danmark Opnåelse af tilladelse til at udbyde spil i Danmark Vejledning til teknisk tilslutningsforløb 1.7.2015 Version 1.2 Historik for dokumentet: Version Dato Opsummerende beskrivelse af ændringer 1.0 2011.06.30

Læs mere

Dokumentation af sikkerhed i forbindelse med databehandling

Dokumentation af sikkerhed i forbindelse med databehandling - Dokumentation af sikkerhed i forbindelse med databehandling Al databehandling, der er underlagt persondataloven, skal overholde de tekniske krav, der er opstillet i Datatilsynets bekendtgørelse 528 (sikkerhedsbekendtgørelsen).

Læs mere