Adgangsstyring for systemer

Fælleskommunal Adgangsstyring for systemer sikrer, at it-systemer kun får adgang til den information, som de har rettigheder til.
Om Integrationer FAQ

Fælleskommunal Adgangsstyring for systemer styrer it-systemers adgang til data, der er tilgængelig i den fælleskommunale infrastruktur via:

  • Webservices
  • Filer (Fælleskommunal Filudveksling)
  • Hændelser/beskeder (Fælleskommunal Beskedfordeler)

Adgangsstyring for systemer styrer også it-systemers adgang til selv at udstille data, aflevere filer eller afsende hændelser/beskeder via infrastrukturen.

Et it-systems adgang sker efter principperne om autentifikation og autorisation:

  • Autentifikation: It-systemets identitet bestemmes ud fra det tilknyttede virksomheds-/organisationscertifikat eller system-/funktionscertifikat.
  • Autorisation: It-systemets rettigheder til en service styres via serviceaftaler, der er godkendt af de myndigheder, it-systemet ”arbejder” på vegne af.

Forskellige sikkerhedsmodeller

Data i infrastrukturen tilgås og udveksles gennem integrationer. I en integration kan der være forskellige kombinationer af webservices, beskeder og filer i spil, hvilket betyder, at der kan være mere end én sikkerhedsmodel, som du skal forholde dig til for at dit it-system kan bruge en given integration.

I FAQ-sektionen nedenfor, kan du læse mere om de sikkerhedsmodeller, der bruges i infrastrukturen til hhv. webservices, beskeder og filer.

 

Vilkår for Adgangsstyring for systemer

It-systemer, der skal have adgang til eller udstille data i infrastrukturen, skal overholde vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale infrastruktur.

Du kan læse mere om adgangsstyring i infrastrukturen i beskrivelse af sikkerhedsmodellen. 

Integrationer - Adgangsstyring for systemer

SF1512
Adgangsstyring
Sikkerhed - Udstil service med Token-sikkerhed (Security Token Service)
Integrationen giver kommunale fagsystemer mulighed for selv at udstille en service med token-sikkerhed, der er trusted af Security Token Service.
Læs mere
SF1514
Adgangsstyring
Sikkerhed - Hent Token fra Security Token Service
Integrationen giver kommunale fagsystemer mulighed for at få udstedt et security token af komponenten Security Token Service. Integrationen skal anvendes, når fagsystemet ønsker systemmæssig adgang (via et servicekald eller lignende) til et andet it-system, der udbyder en service. Integrationen skal eksempelvis anvendes, når fagsystemet skal anvende integrationer, som består af services, der er udstillet i den fælleskommunale infrastruktur. Det omfatter typisk web- og filservices på Serviceplatformen samt beskedservices på Beskedfordeleren.
Læs mere
SF1516
Adgangsstyring
Sikkerhed - Hent Access Token
Integrationen giver kommunale fagsystemer mulighed for at få vekslet et SAML Token, udstedt af Security Token Service, til et Access Token. Access Token skal bruges i fagsystemets kald til de RESTful webservices på Serviceplatformen, der accepterer Access Tokens.
Læs mere

FAQ - Adgangsstyring for systemer

I infrastrukturen bruges tre typer af sikkerhedsmodeller til webservices:

  • Fælleskommunal sikkerhedsmodel
  • Simpel fælleskommunal sikkerhedsmodel
  • Simpel sikkerhedsmodel

Fælles for de tre modeller er, at it-systemers adgang til data styres og er afhængig af godkendte serviceaftaler. En serviceaftale er en aftale mellem en leverandør og en myndighed om, at et konkret it-system må få adgang til konkrete data. En serviceaftale er samtidig myndighedens instruks til KOMBIT om, at der må udleveres data til it-systemet. Serviceaftaler indgås i Fælleskommunalt Administrationsmodul.

Nogle webservices er udstillet både med Fælleskommunal sikkerhedsmodel og Simpel fælleskommunal sikkerhedsmodel. KOMBIT anbefaler i de tilfælde, at du bruger Fælleskommunal sikkerhedsmodel. 

Fælleskommunal sikkerhedsmodel (Security Token)

Fælleskommunal sikkerhedsmodel er token-baseret adgangsstyring, dvs. at et it-system skal hente et token fra Security Token Service for at få adgang til data via webservicen. Modellen bruges til de fleste webservices i infrastrukturen.

Sikkerhedsmodellen bruger SAML token-sikkerhed med enten Liberty Basic SOAP Binding eller IDWS Binding (OIO IDWS SOAP Profile).

Adgang til data styres ud fra servicesystemroller, dataafgrænsninger og myndighedskontekst. En servicesystemrolle bestemmer hvilke handlinger et it-system må udføre, mens en dataafgrænsning bestemmer hvilke data, it-systemet må få adgang til. Fx kan et system, der skal hente sager om dagpenge, have servicesystemrollen ”Hent sag” og dataafgrænsning kan være angivet til ”KLE 32.30”, der er KLE-nummer for dagpenge ved sygdom og barsel.

Simpel fælleskommunal sikkerhedsmodel (Authority Context)

Simpel fælleskommunal sikkerhedsmodel er certifikat-baseret adgangsstyring. Det betyder, at adgang til data styres af it-systemets certifikat inkl. CVR-nummer på den myndighed, it-systemet ”arbejder” på vegne af.

Sikkerhedsmodellen bruges kun til nogle af de webservices, der er udstillet på Serviceplatformen. 

Et it-system får adgang til al data for den myndighed, som it-systemet har godkendte serviceaftaler med om brugen af webservicen.

Simpel sikkerhedsmodel (Invocation Context)

Med Simpel sikkerhedsmodel får et it-system adgang til al data, hvis der er en godkendt serviceaftale om brug af webservicen. 

Adgang til data styres ud fra it-systemets certifikat og serviceaftaler.

Læs mere

Du kan læse mere om sikkerhedsmodellerne i Programmers Guide - Sikkerhed i den fælleskommunale infrastruktur. 

Security Token kombinerer certifikatsikkerhed med et token:

  • Certifikatsikkerheden udmøntes ved, at systemet etablerer en 2-vejs SSL-forbindelse til serviceudbyderen. 
  • Et gyldigt token (SAML-token) indlejres i webservicekaldet, og indeholder roller, dataafgrænsninger og myndighedskontekst, som modtager validerer. Det gyldige token udstedes til det kaldende system fra infrastrukturkomponenten Security Token Service.

Et it-system kalder en webservice udstillet med Security Token således:

  1. Systemet kalder Security Token Service for at hente et token til den webservice, som it-systemet ønsker at kalde.
    • Et token er service-specifikt. Hvis der skal kaldes flere webservices, skal der hentes flere tokens.
    • Tokens har en gyldighedsperiode og kan genbruges inden for denne gyldighedsperiode. Dermed skal man ikke trække et nyt token til en service, før ens nuværende token er tæt på at udløbe. Gyldigheden er p.t. 8 timer, og udløbstidspunktet står i det udstedte token.
  2. It-systemet etablerer en sikker 2-vejs SSL-forbindelse til serviceudbyder.
  3. It.systemet generer et request, og kalder webservicen med det udstedte token.
  4. Webservicen validerer requestet og sender et svar tilbage til it-systemet.

For at få udstedt et gyldig token og kalde en webservice i infrastrukturen, skal du gennemføre fire skridt:

  1. Leverandøren opretter systemet som "Anvendersystem" i Fælleskommunalt Administrationsmodul
  2. Leverandøren anmoder en myndighed om adgang til services via en serviceaftale i Fælleskommunalt Administrationsmodul
  3. Myndigheden godkender serviceaftalen i Fælleskommunalt Administrationsmodul
  4. Leverandøren installerer nødvendige server-certifikater fra hhv. serviceudbyder og Security Token Service i sit it-system

JSON Web Token (JWT)

Security Token Service kan også udstede JSON Web Token (JWT). Det betyder, at serviceudbydere, der understøtter JWT på deres webservices (fx REST), også kan bruge Security Token Service.

Endepunkter til Security Token Service:

  • Eksternt testmiljø Security Token Service: 
    https://n2adgangsstyring.eksterntest-stoettesystemerne.dk/runtime/services/kombittrust/14/certificatemixed
     
  • Produktionsmiljø Security Token Service: 
    https://n2adgangsstyring.stoettesystemerne.dk/runtime/services/kombittrust/14/certificatemixed

Endepunkter til JSON Web Tokens:

  • Eksternt testmiljø JWT (Security Token Service): 
    https://n2adgangsstyring.eksterntest-stoettesystemerne.dk/runtime/api/rest/oauth/v1/issue
     
  • Produktionsmiljø JWT (Security Token Service): 
    https://n2adgangsstyring.stoettesystemerne.dk/runtime/api/rest/oauth/v1/issue

Hurtigt i gang med Security Token (Fælleskommunal sikkerhedsmodel)

Der findes eksempel-klienter, hvor du uden at skulle registrere et it-system og anmode om serviceaftaler, kan få udstedt et token og kalde en webservice i Eksternt testmiljø.

Eksempelklienterne fungerer ud-af-boksen, da de indeholder de nødvendige certifikater og arbejder med it-systemer og serviceaftaler, som allerede er registreret i Fælleskommunalt Administrationsmodul.

Der er en eksempel-klient i Java og en i .Net, som kan hentes på Github:

Vær opmærksom på de forudsætninger, der står skrevet i readme-filerne  klienterne, så de nødvendige biblioteker og frameworks installeres i de rigtige versioner inden afvikling af klienten. Vær også opmærksom på evt. at rette til i run.bat/run.sh fil, hvis installation af frameworks, ligger på andre stier end angivet i disse filer.

Fælleskommunal Filudveksling er beskyttet med SFTP. 

Når et it-system skal aflevere/hente filer og kvitteringer, logger it-systemet på Serviceplatformens SFTP-server ved brug af it-systemets SSH-nøgle. Serviceplatformen skal derfor kende den offentlige del af SSH-nøglen.

Adgang til filer styres desuden af ruter oprettet ud fra godkendte serviceaftaler.

Et it-system kan modtage hændelser/beskeder fra Fælleskommunal Beskedfordeler på to måder:

  1. Beskedfordeleren afleverer beskeder til en REST-service, som it-systemet udstiller 
  2. It-systemet henter beskeder fra Beskedfordeleren via AMQP

REST-aflevering er sikret med en 2-vejs SSL-forbindelse. It-systemet kan kun modtage beskedtyper, der er godkendte serviceaftaler på, og som it-systemet har opsat abonnement på i Beskedfordelerens brugergrænseflade.

AMQP-afhentning autoriseres ud fra serviceaftaler for it-systemet og de abonnementsudtryk, der er sat op for it-systemet i Beskedfordelerens brugergrænseflade. I sit AMQP-kald til Beskedfordeleren, skal it-systemet indlejre et token, som it-systemet har fået udstedt fra Security Token Service.

På denne side kan du læse mere brugen af certifikater i infrastrukturen, og hente de offentlige nøgler for funktions- og SSL-certifikater for infrastrukturløsningerne: https://digitaliseringskataloget.dk/teknik/certifikater