Menu
Om den fælleskommunale infrastruktur Infrastrukturens løsninger Tilslutning Teknikken bag infrastrukturen Vilkår og aftaler Kontakt og support

Adgangsstyring for systemer

Adgangsstyring sikrer, at systemer kun kan tilgå information, de har rettigheder til i den fælleskommunale infrastruktur.

Hvad er Adgangsstyring for systemer?

Adgangsstyring for systemer foregår ud fra Autentifikation og Autorisation.

  • Autentifikation består i at bestemme systemets Identitet ud fra det tilknyttede virksomheds/organisationscertifikat eller system/funktionscertifikat.
  • Autorisation – hvilke rettigheder har systemet til en given service. Dette styres via serviceaftaler, der er godkendt af de myndigheder, systemet arbejder på vegne af.

Alt efter hvilke data, der udbydes af en service, kan der anvendes forskellige sikkerhedsmodeller. Dette gøres for at understøtte, at et system kun får adgang til præcis de data, som systemet har et formål med at behandle.

Simpel services 

For denne type services har et system adgang til alt data, hvis der forligger en godkendt serviceaftale. Adgangen styres ud fra systemets certifikat.

Simpel fælleskommunal service

For denne type services har et system adgang til alt data for den/de myndigheder, der har godkendt serviceaftaler. Adgangen til denne type service styres af systemets certifikat inklusive CVR-nummeret på den myndighed, systemet arbejder på vegne af.

Fælleskommunale services 

På disse services styres adgangen med servicesystemroller og dataafgrænsninger. Roller beskriver hvilke handlinger systemet må udføre, mens dataafgrænsninger beskriver hvilke data, de må få adgang til. Fx kan et system, der skal hente sager, der omhandler dagpenge have:

  • Rolle: Hent sag
  • Dataafgrænsning: KLE 32.30 (KLE-nummer for Dagpenge ved sygdom og barsel).

Adgangsstyring for systemer

Fælleskommunal Adgangsstyring for systemer styrer systemers adgang til de data, der er tilgængelige via komponenterne i den fælleskommunale infrastruktur.

Komponenter i den fælleskommunale infrastruktur, der gør data tilgængelige, er:

  • Webservices
  • Filtransport via Serviceplatformen
  • Forretningshændelser via Fælleskommunal Beskedfordeler

Adgangsstyring for Systemer styrer også systemers adgang til at udstille data i den fælleskommunale infrastruktur. Det kan gøres på tre måder:

  • Udstilling af webservices
  • Udstilling af filer via Serviceplatformens Filtransport
  • Udstilling af Forretningshændelser via Fælleskommunal Beskedfordeler

Data udveksles gennem integrationer og en integration kan kombinere en eller flere af komponenterne ovenfor. Adgangsstyring til de enkelte komponenter er forskellig og beskrevet individuelt nedenfor. Hvis en integration kombinerer flere komponenter, skal man således forholde sig til de forskellige komponenters individuelle adgangsstyring.

 

Webservices, Filudveksling og Beskedfordeler

Der er tre typer af sikkerhedsmodeller til webservices, med deres tilsvarende implementering som udstilles i den fælleskommunale infrastruktur:

  • Fælleskommunal sikkerhedsmodel, der anvendes på de fleste services
  • Simpel fælleskommunal sikkerhedsmodel
    •  Authority Context udstilles kun på Serviceplatformen
       
  • Simpel sikkerhedsmodel
    • Invocation Context udstilles af Serviceplatformen
    • Certifikat baseret sikkerhed på Fælleskommunal Administration webservice

Fælleskommunal sikkerhedsmodel er den anbefalede sikkerhedsmodel, og den sikkerhedsmodel man, ved tilslutning til en webservice, skal anvende. Flere webservices udstilles både som Fælleskommunale services og som Simple Fælleskommunale services. Der skal anvendes de Fælleskommunal services, da KOMBIT udfaser anvendelsen af Simple Fælleskommunale services.

Authority Context og Invocation Context vil ikke blive yderligere beskrevet her, men kan findes i Programmers guide til Sikkerhed i den Fælleskommunale Infrastruktur. Kontakt helpdesk@serviceplatformen.dk ved behov for information om disse sikkerhedsmodeller.

SAML token-sikkerhed

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 den fælleskommunale infrastrukturkomponent Security Token Service.

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

  1. Systemet kalder Security Token Servicen for at hente et token til den webservice, som 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. Systemet etablerer en sikker 2-vejs SSL-forbindelse til Serviceudbyder.
  3. Systemet generer et request, og kalder webservicen med det udstedte token.
  4. Webservicen validerer requestet og sender et svar tilbage til systemet.

For at få udstedt et gyldig token og kalde en webservice i den fælleskommunale infrastruktur, skal man gennemføre fire skridt; de tre første gennemføres i Fælleskommunalt Administrationsmodul, og det sidste foretages på den server, der skal foretage systemets kald:

  1. Leverandøren opretter systemet som Anvendersystem
  2. Leverandøren anmoder en Myndighed om adgang til services via en serviceaftale
  3. Myndigheden godkender serviceaftalen
  4. Leverandøren installerer nødvendige server-certifikater fra hhv. Serviceudbyder og Security Token Service

Ny version af Security Token Service

I 2023 går en ny version af Security Token Service i drift.

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

Integrationerne for Security Token Service er:
 

Vejledning til Fælleskommunalt Administrationsmodul til fx oprettelse af system som 'Anvender' samt anmodning om serviceaftale, findes her: Brugervejledning til Administrationsmodulerne for leverandører.

Certifikater for den fælleskommunale infrastruktur findes her.

Endepunkter til Security Token Service

Endepunkter til Security Token Service 2:

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

Endepunkter til JSON Web Tokens:

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

Hurtigt i gang med Adgangsstyring for Serviceplatformens webservices

Der findes eksempel-klienter, hvor man uden at skulle registrere systemer og anmode om serviceaftaler, kan få udstedt et token og kalde en webservice på Serviceplatformen. Disse eksempelklienter fungerer ud-af-boksen, da de indeholder de nødvendige certifikater og arbejder med systemer og serviceaftaler, som allerede er etableret i Fælleskommunalt Administrationsmodul. Afviklingen af klienterne foregår mod Serviceplatformens Eksterne testmiljø. 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-filen for hver af klienterne, så de nødvendige biblioteker og frameworks installeres i de rigtige versioner forud for afvikling af den konkrete klient. Vær i øvrigt opmærksom på evt. at tilrette i den run.bat/run.sh fil, hvis installation af frameworks, ligger på andre stier end angivet i disse filer.

Filudveksling på Serviceplatformen er beskyttet med SFTP. Et system logger på SFTP-serveren ved brug af systemets SSH-nøgle.

Udveksling af filer fra systemet foregår således:

  1. Systemet logger på SFTP-serveren ved brug af systemets SSH-nøgle.
  2. Systemet lægger en datafil i OUT-folderen på SFTP-serveren, dernæst lægger systemet en triggerfil hørende til datafilen i OUT-folderen på SFTP-serveren.
  3. Systemet afhenter teknisk kvittering i IN-folderen på SFTP-serveren.

Der er to skridt, der skal gennemføres for at få adgang til Serviceplatformens SFTP-server, disse gennemføres begge i Fælleskommunalt Administrationsmodul:

  1. Opret systemet som Anvender
  2. Konfigurer SFTP

Hvis systemet allerede er oprettet som Anvender, fx hvis man allerede kalder webservices på Serviceplatformen, kan man springe det første skridt over. Konfiguration af SFTP kræver, at man vælger et SFTP-brugernavn (som ikke kan ændres). Dernæst skal man uploade den offentlige del af sin SSH-nøgle. Vejledning til hvordan man genererer SSH-nøgle og SFTP Servicen i øvrigt, findes her: Vejledning til Serviceplatformens SFTP Service.pdf

Vejledning til Fælleskommunalt Administrationsmodul til fx oprettelse af system som Anvender, findes her: Brugervejledning til Administrationsmodulerne for leverandører.pdf

Certifikater for den fælleskommunale infrastruktur findes her: Certifikater

Et system kan få forretningshændelser fra Fælleskommunal Beskedfordeler på to måder:

  1. Beskedfordeler afleverer beskeder til en af systemet udstillet REST-service (integration SF1461)
  2. Systemet afhenter beskeder fra Beskedfordeler via AMQP (integration SF1461)

De to metoder har lidt forskel i sikkerhedsmodel, og er beskrevet i det følgende:

REST-aflevering til systemet sikres med en 2-vejs SSL-forbindelse, kombineret med serviceaftale for beskedtype samt abonnementsudtryk i Beskedfordeleren. Serviceaftalen autoriserer, at systemet alene kan sætte abonnement for beskeder, der er godkendt serviceaftale for.

AMQP-afhentning autoriseres ligeledes med serviceaftale og abonnementsudtryk i Beskedfordeleren. I sit AMQP-kald til Beskedfordeleren har systemet indlejret et token, som systemet har fået udstedt fra Security Token Service, tilsvarende hvis det var en webservice på Serviceplatform, der skulle kaldes.

Certifikater for den fælleskommunale infrastruktur findes her: Certifikater

 

Vilkår:

Det er nødvendigt, at vilkår for anvendelse af sikkerhedsmodellen i den fælleskommunale rammearkitektur anvendes. 

Læs vilkår for anvendelse af sikkerhedsmodellen og beskrivelsen af sikkerhedsmodellen.