...

Specifikationen af DGWS [DGWS] har en god og uddybende beskrivelse af, hvordan et id-kort er konstrueret og kan anvendes i praksis.

Sikkerhed

<Forudsætninger for anvendelse og krævede adgange, whitelistinger etc., Sikkerhedsniveau. Angiv krav til authentication for at kunne bruge servicen/komponenten.>

...

Identitetsservice

Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er der en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider). På NSP hedder servicen Security Token Service (STS).

Introduktionen af STS betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.

Føderation, ombytning af id-kort og servicekald

Følgende er et eksempel på hvad der sker i de forskellige skridt når en anvender ombytter sit id-kort til et signeret af STS:

1. Anvendersystemet bygger et id-kort indeholdende informationer om brugeren/systemet og signerer det med brugerens/systemets certifikat.

2. Id-kortet sendes til STS, der tjekker at signaturen er korrekt og baseret på et OCES-certifikat udstedt under det samme rodcertifikat som STS's eget.

3. Korrektheden af attributter som personnummer og autorisation verificeres af STS. Ydermere tjekkes det om certifikatet er spærret for anvendelse.

4. STS opbygger et nyt id-kort med de samme informationer og signerer det med STS'ens eget certifikat. Den offentlige nøgle i dette certifikat er kendt af alle komponenter i føderationen.
5. STS sender det nye id-kort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
6. Anvendersystemet indsætter nu det nye id-kort i headeren på alle fremtidige forespørgelser mod NSP-komponenter.
7. NSP-komponenten verificerer at id-kortet er signeret af føderationens certifikat, og stoler herefter på udvalgte dele af id-kortet.

...

Bemærk at et id-kort kan anvendes til flere forespørgelser, så længe det endnu ikke er udløbet.

Offentlige Certifikater til Elektronisk Service

Til generel identifikation, dels som anvender overfor STS og dels for id-kortet overfor services på NSP, kræves digitale certifikater. På NSP skal disse overholde den fælles offentlige standard for certifikater. Standarden hedder OCES, Offentlige Certifikater til Elektronisk Service.

OCES-certifikater

OCES certifikater indeles i fire hovedgrupper, hvoraf de tre anvendes på NSP:

• Medarbejdercertifikat (MOCES)
  Udstedes til en medarbejder af en virksomhed og anvendes til autentifikation af den person, der udfører en handling ifm. sin ansættelse i virksomheden.
• Virksomhedscertifikat (VOCES)
  Udstedes til virksomheder og anvendes til autentifikation af selve virksomheden.
• Funktionscertifikat (FOCES)
  Udstedes til virksomheder og bruges til autentifikation af en applikation, en enhed, en proces eller en service.

Den sidste gruppe af certifikater betegnes som Personcertifikater, og udstedes til identifikation af privatpersoner.

Digitaliseringsstyrelsen og Nets DanID

Alle OCES-certifikater udstedes af Nets DanID der varetager denne opgave for Digitaliseringsstyrelsen. Nets DanID har et rodcertifikat og herunder en række krydscertifikater som bruges til at udstede OCES-certifikaterne. Specielt kan det nævnes at det certifikat, en STS service er konfigureret med, blot er endnu et udstedt certifikat, ganske som alle andre udstedte certifikater. Dog definerer dette certifikat den omtalte føderation. I praksis er det anvender-bibliotekerne Seal.Java og Seal.Net, der kender til dette certifikat og dermed kan verificere id-kort med en signatur, der stammer fra certifikatet.

Id-kort

Id-kortet er det bærende element ifm. signering i STS'en. Som beskrevet i platformsintroduktionen er id-kortet et XML-dokument der indeholder informationer om den person, virksomhed eller applikation, som foretager en forespørgsel mod en NSP-service. Når man ombytter et id-kort i STS'en, placeres id-kortet under SOAP Body elementet. Når man medsender et id-kort ifm. kald af NSP-services placeres det under SOAP Header elementet.

...

Attributter

Et id-kort består af en mængde attributter som anvendersystemet udfylder. En del af disse attributter bliver verificeret af STS, og nogle bliver valideret af komponenterne. Verifikationen i STS gennemgås i næste hovedafsnit.

• Navn: En identifikation af den person/organisation som id-kortet skal repræsentere. Hvis der ikke angives et navn anvender Seal enten brugerens CPR-nummer eller organisationens id.
• Id: Et internt, unikt id, der genereres af Seal.
• Oprettet: Det tidspunkt id-kortet er oprettet og derved gyldigt fra.
• Udløber: Det tidspunkt id-kortet udløber.
• Udsteder: Navnet på den instans, der har udstedt id-kortet. Hver STS-service har sin egen streng. Det er det muligt for anvendere at angive denne, når der genereres et id-kort.
• Autentifikationsniveau: Ved brug af STS er der kun to valide muligheder for autentifikationsniveau; 3 hvis der er tale om et systemid-kort signeret med et VOCES-certifikat eller FOCES-certikat, eller 4, hvis der er tale om et brugerid-kort signeret med et MOCES-certifikat.
• Organisation: Navnet, typen og et id for den organisatoriske enhed som id-kortet repræsenterer. Typen kan være CVR-nummer, en SKS-kode, et yder-nummer eller et p-nummer (Produktionsenhedsnummer).
• IT System: Navnet på det system der initierede forespørgslen. Dette er en fritekst, der kan indsættes af anvendersystemet og vil blive bevaret i det STS signerede id-kort. I nogle tilfælde bruges denne værdi af NSP-komponenter. F.eks. bruges værdien af NAS til at identificere et Pullpoint.

Hvis der er tale om et brugerid-kort er følgende attributter også tilstede

• Bruger: CPR-nummeret, fulde navn og email-adresse på den person som id-kortet repræsenterer.
• Rolle: Den firecifrede uddannelseskode som brugerens autorisation har. Koderne i autorisationsregistret er et subset af uddannelseskoderne fra Danmarks Statistik. Som eksempel kan nævnes at uddannelseskoden 7170 bruges for læger og 5166 bruges for sygeplejersker.
• Autorisationsid: Det autorisationsID som brugerens autorisation har. En anvender har en eller flere autorisationer, hvert med et unikt ID og en uddannelseskode.
• Ansættelse: Den ansættelse i organisationen som brugeren har. Denne værdi er en fritekst og bevares i det STS-signerede id-kort.

Certifikat og signatur

Når et id-kort signeres, enten af anvenderen eller af STS, bliver certifikatets offentlige nøgle lagt ind på id-kortet og kortet signeres med certifikatets private nøgle. Seal-bibliotekerne udfører disse opgaver for een. Hvis man ønsker at vide hvordan det praktisk foregår, så er hele processen beskrevet i "Den Gode Webservice" [DGWS].

Verifikation

Når STS'en modtager en signeringsforespørgsel verificeres id-kortet og anvenderens certificat i flere skridt. Disse skridt er kort beskrevet i de følgende afsnit, og er yderligere uddybet i STS dokumentationen. Verifikationen betyder at komponenter kan stole på korrektheden af de nævnte attributer, hvis id-kortet er signeret af STS'en.

Gyldighed

Et id-kort er kun gyldigt i en bestemt periode. STS'en tjekker derfor at denne periode er oplyst på id-kortet og at det indeholder kaldstidspunktet. Dette gøres for at sikre at man ikke kan udstede et id-kort, der først bliver gyldigt en gang ude i fremtiden.

Et id-kort kan maksimalt være gyldigt i 24 timer, derfor tjekker STS at den ønskede gyldighedsperioden ikke er længere end 24 timer.

Certifikat

Det certifikat, som anvender har brugt til at signere id-kortet i forespørgslen, skal være signeret af Nets DanID's rodcertifikatet (eller af et af krydscertifikaterne). Da der findes flere gyldige sæt af disse (test og produktion), er det vigtigt at anvender har styr på hvilket sæt den kaldende STS er en del af.

Spærrelister

Selv om et certifikat er korrekt udstedt til føderationen, kan det godt blive nægtet adgang. Dette sker ved hjælp af en såkaldt blackliste, der indeholder certifikater, der ikke længere må anvendes. Denne liste vedligeholdes som en del af certifikatinfrastrukturen og anvendes af STS til at afvise certifikater, der f.eks. er blevet kompromiteret eller på anden måde har mistet deres autoritet.

CVR-nummer

STS verificerer at det angivne CVR-nummer matcher det CVR-nummer, der er angivet i certifikatet.

Personnummer

Hvis forespørgslen indeholder et brugerid-kort tjekkes at det angivne personnummer matcher det personnummer, der blev brugt da medarbejdercertifikatet blev udstedt. Verifikationen anvender en ekstern webservice til at finde det personnummer der er knyttet til CVR/RID-nummeret i certifikatet. Hvis der ikke var tilknyttet er CPR-nummer til certifikatet ved udstedelse, så kan dette certifikat ikke bruges til at få et signeret id-kort.

Autorisation

Hvis forespørgslen indeholder et brugerid-kort, så laves der et opslag i autorisationsregisteret for at finde den autorisation, som brugeren anvender. Hvis der er angivet en rolle og/eller et autorisationsID i forespørgelsen, anvendes disse til at udvælge autorisationen. I "STS Anvender dokumentet" er udvælgelsesalgoritmen beskrevet i detaljer. Den følgende liste beskriver de gængse situationer med angivelse af autorisation. Disse situationer er også indeholdt i medfølgende eksempler.

• En bruger med en autorisation: hvis en bruger kun har en autorisation kan denne angives eller helt undlades og dermed lade STS vælge den ene.
• En bruger med flere autorisationer: anvendere skal her angive nok information for STS til at finde en entydig autorisation.
• En bruger uden autorisationer: her skal anvendere undlade at angive en gyldig autorisation.

Den konkrete udformning af forespørgelsen til STS kan ses i eksemplerne.

Definitioner og referencer

...

Identitetsservice

Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er der en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider). På NSP hedder servicen Security Token Service (STS).

Introduktionen af STS betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.

Føderation, ombytning af id-kort og servicekald

Følgende er et eksempel på hvad der sker i de forskellige skridt når en anvender ombytter sit id-kort til et signeret af STS:

1. Anvendersystemet bygger et id-kort indeholdende informationer om brugeren/systemet og signerer det med brugerens/systemets certifikat.

2. Id-kortet sendes til STS, der tjekker at signaturen er korrekt og baseret på et OCES-certifikat udstedt under det samme rodcertifikat som STS's eget.

3. Korrektheden af attributter som personnummer og autorisation verificeres af STS. Ydermere tjekkes det om certifikatet er spærret for anvendelse.

4. STS opbygger et nyt id-kort med de samme informationer og signerer det med STS'ens eget certifikat. Den offentlige nøgle i dette certifikat er kendt af alle komponenter i føderationen.
5. STS sender det nye id-kort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
6. Anvendersystemet indsætter nu det nye id-kort i headeren på alle fremtidige forespørgelser mod NSP-komponenter.
7. NSP-komponenten verificerer at id-kortet er signeret af føderationens certifikat, og stoler herefter på udvalgte dele af id-kortet.

Bemærk at et id-kort kan anvendes til flere forespørgelser, så længe det endnu ikke er udløbet.

Offentlige Certifikater til Elektronisk Service

Til generel identifikation, dels som anvender overfor STS og dels for id-kortet overfor services på NSP, kræves digitale certifikater. På NSP skal disse overholde den fælles offentlige standard for certifikater. Standarden hedder OCES, Offentlige Certifikater til Elektronisk Service.

OCES-certifikater

OCES certifikater indeles i fire hovedgrupper, hvoraf de tre anvendes på NSP:

• Medarbejdercertifikat (MOCES)
  Udstedes til en medarbejder af en virksomhed og anvendes til autentifikation af den person, der udfører en handling ifm. sin ansættelse i virksomheden.
• Virksomhedscertifikat (VOCES)
  Udstedes til virksomheder og anvendes til autentifikation af selve virksomheden.
• Funktionscertifikat (FOCES)
  Udstedes til virksomheder og bruges til autentifikation af en applikation, en enhed, en proces eller en service.

Den sidste gruppe af certifikater betegnes som Personcertifikater, og udstedes til identifikation af privatpersoner.

Digitaliseringsstyrelsen og Nets DanID

Alle OCES-certifikater udstedes af Nets DanID der varetager denne opgave for Digitaliseringsstyrelsen. Nets DanID har et rodcertifikat og herunder en række krydscertifikater som bruges til at udstede OCES-certifikaterne. Specielt kan det nævnes at det certifikat, en STS service er konfigureret med, blot er endnu et udstedt certifikat, ganske som alle andre udstedte certifikater. Dog definerer dette certifikat den omtalte føderation. I praksis er det anvender-bibliotekerne Seal.Java og Seal.Net, der kender til dette certifikat og dermed kan verificere id-kort med en signatur, der stammer fra certifikatet.

Id-kort

Id-kortet er det bærende element ifm. signering i STS'en. Som beskrevet i platformsintroduktionen er id-kortet et XML-dokument der indeholder informationer om den person, virksomhed eller applikation, som foretager en forespørgsel mod en NSP-service. Når man ombytter et id-kort i STS'en, placeres id-kortet under SOAP Body elementet. Når man medsender et id-kort ifm. kald af NSP-services placeres det under SOAP Header elementet.

Attributter

Et id-kort består af en mængde attributter som anvendersystemet udfylder. En del af disse attributter bliver verificeret af STS, og nogle bliver valideret af komponenterne. Verifikationen i STS gennemgås i næste hovedafsnit.

• Navn: En identifikation af den person/organisation som id-kortet skal repræsentere. Hvis der ikke angives et navn anvender Seal enten brugerens CPR-nummer eller organisationens id.
• Id: Et internt, unikt id, der genereres af Seal.
• Oprettet: Det tidspunkt id-kortet er oprettet og derved gyldigt fra.
• Udløber: Det tidspunkt id-kortet udløber.
• Udsteder: Navnet på den instans, der har udstedt id-kortet. Hver STS-service har sin egen streng. Det er det muligt for anvendere at angive denne, når der genereres et id-kort.
• Autentifikationsniveau: Ved brug af STS er der kun to valide muligheder for autentifikationsniveau; 3 hvis der er tale om et systemid-kort signeret med et VOCES-certifikat eller FOCES-certikat, eller 4, hvis der er tale om et brugerid-kort signeret med et MOCES-certifikat.
• Organisation: Navnet, typen og et id for den organisatoriske enhed som id-kortet repræsenterer. Typen kan være CVR-nummer, en SKS-kode, et yder-nummer eller et p-nummer (Produktionsenhedsnummer).
• IT System: Navnet på det system der initierede forespørgslen. Dette er en fritekst, der kan indsættes af anvendersystemet og vil blive bevaret i det STS signerede id-kort. I nogle tilfælde bruges denne værdi af NSP-komponenter. F.eks. bruges værdien af NAS til at identificere et Pullpoint.

Hvis der er tale om et brugerid-kort er følgende attributter også tilstede

• Bruger: CPR-nummeret, fulde navn og email-adresse på den person som id-kortet repræsenterer.
• Rolle: Den firecifrede uddannelseskode som brugerens autorisation har. Koderne i autorisationsregistret er et subset af uddannelseskoderne fra Danmarks Statistik. Som eksempel kan nævnes at uddannelseskoden 7170 bruges for læger og 5166 bruges for sygeplejersker.
• Autorisationsid: Det autorisationsID som brugerens autorisation har. En anvender har en eller flere autorisationer, hvert med et unikt ID og en uddannelseskode.
• Ansættelse: Den ansættelse i organisationen som brugeren har. Denne værdi er en fritekst og bevares i det STS-signerede id-kort.

Certifikat og signatur

Når et id-kort signeres, enten af anvenderen eller af STS, bliver certifikatets offentlige nøgle lagt ind på id-kortet og kortet signeres med certifikatets private nøgle. Seal-bibliotekerne udfører disse opgaver for een. Hvis man ønsker at vide hvordan det praktisk foregår, så er hele processen beskrevet i "Den Gode Webservice" [DGWS].

Verifikation

Når STS'en modtager en signeringsforespørgsel verificeres id-kortet og anvenderens certificat i flere skridt. Disse skridt er kort beskrevet i de følgende afsnit, og er yderligere uddybet i STS dokumentationen. Verifikationen betyder at komponenter kan stole på korrektheden af de nævnte attributer, hvis id-kortet er signeret af STS'en.

Gyldighed

Et id-kort er kun gyldigt i en bestemt periode. STS'en tjekker derfor at denne periode er oplyst på id-kortet og at det indeholder kaldstidspunktet. Dette gøres for at sikre at man ikke kan udstede et id-kort, der først bliver gyldigt en gang ude i fremtiden.

Et id-kort kan maksimalt være gyldigt i 24 timer, derfor tjekker STS at den ønskede gyldighedsperioden ikke er længere end 24 timer.

Certifikat

Det certifikat, som anvender har brugt til at signere id-kortet i forespørgslen, skal være signeret af Nets DanID's rodcertifikatet (eller af et af krydscertifikaterne). Da der findes flere gyldige sæt af disse (test og produktion), er det vigtigt at anvender har styr på hvilket sæt den kaldende STS er en del af.

Spærrelister

Selv om et certifikat er korrekt udstedt til føderationen, kan det godt blive nægtet adgang. Dette sker ved hjælp af en såkaldt blackliste, der indeholder certifikater, der ikke længere må anvendes. Denne liste vedligeholdes som en del af certifikatinfrastrukturen og anvendes af STS til at afvise certifikater, der f.eks. er blevet kompromiteret eller på anden måde har mistet deres autoritet.

CVR-nummer

STS verificerer at det angivne CVR-nummer matcher det CVR-nummer, der er angivet i certifikatet.

Personnummer

Hvis forespørgslen indeholder et brugerid-kort tjekkes at det angivne personnummer matcher det personnummer, der blev brugt da medarbejdercertifikatet blev udstedt. Verifikationen anvender en ekstern webservice til at finde det personnummer der er knyttet til CVR/RID-nummeret i certifikatet. Hvis der ikke var tilknyttet er CPR-nummer til certifikatet ved udstedelse, så kan dette certifikat ikke bruges til at få et signeret id-kort.

Autorisation

Hvis forespørgslen indeholder et brugerid-kort, så laves der et opslag i autorisationsregisteret for at finde den autorisation, som brugeren anvender. Hvis der er angivet en rolle og/eller et autorisationsID i forespørgelsen, anvendes disse til at udvælge autorisationen. I "STS Anvender dokumentet" er udvælgelsesalgoritmen beskrevet i detaljer. Den følgende liste beskriver de gængse situationer med angivelse af autorisation. Disse situationer er også indeholdt i medfølgende eksempler.

• En bruger med en autorisation: hvis en bruger kun har en autorisation kan denne angives eller helt undlades og dermed lade STS vælge den ene.
• En bruger med flere autorisationer: anvendere skal her angive nok information for STS til at finde en entydig autorisation.
• En bruger uden autorisationer: her skal anvendere undlade at angive en gyldig autorisation.

Den konkrete udformning af forespørgelsen til STS kan ses i eksemplerne.

Definitioner og referencer

Dokument historik

Signering af id-kort

Adgang

Snitfladebeskrivelse og brug

Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services inden for en føderation [SOSI] på sundhedsdatanettet.

Snitfladen SecurityTokenService er en legacy udgave af NewSecurityTokenService. I NewSecurityTokenService overskrives NameID/AlternativeIdentifier, hvilket vil sige at anvender ikke kan bestemme indholdet heraf.

Snitfladerne beskrives detaljeret her:
STS - Guide til anvendere - Signering af id-kort 

Medarbejder-Billetomveksling

Adgang

Snitfladebeskrivelse og brug

Formålet med omvekslingen er:

At tillade web-løsninger, hvis anvendere er logget på via NemLog-in anvendere af NemLogin at kalde foretage DGWS-kald, som kræver SOSI id-kort, ved at veksle en eksisterende OIOSAML-assertion udstedt af NemLog-intil et id-kort, som efterfølgende kan anvendes til opslag af webservices hos f.eks. NSP eller FMK.

At tillade anvendere af id-kort at foretage kald i NemLogin federationen, som kræver OIOSAML assertions, ved at veksle et eksisterende id-kort til et OIOSAML-assertion.

At tilbyde borgeren login-funktionalitet via en OpenID connect server, hvor et såkaldt JSON Web Token (JWT) udstedt til borgeren og signeret af OpenID serveren herefter kan veksles til

Snitflade OIOSaml2Sosi beskrives detaljeret her:
STS - Guide til anvendere - Medarbejder-Billetomveksling til signeret id-kort

Snitflade Sosi2OIOSaml og  JWT2OIOSaml

Dokument historik

...

Sammenskrivning af oprindelige anvendergudier og yderligere informationer

Signering af id-kort

Adgang

...

/sts/services/NewSecurityTokenService

/sts/services/SecurityTokenService

...

Udstedelse af STS-signeret id-kort.

Snitfladebeskrivelse og brug

Formålet med STS er at sikre identiteten af og autorisere brugere der ønsker at tilgå services inden for en føderation [SOSI] på sundhedsdatanettet.

Snitfladen SecurityTokenService er en legacy udgave af NewSecurityTokenService. I NewSecurityTokenService overskrives NameID/AlternativeIdentifier, hvilket vil sige at anvender ikke kan bestemme indholdet heraf.

Snitfladerne beskrives detaljeret her:

STS - Guide til anvendere - Signering af id-kort 

...

Medarbejder-Billetomveksling til OIOSAML

Borger-Billetomveksling

Adgang

Snitfladebeskrivelse og brug

Formålet med omvekslingen er:

At tillade web-løsninger, hvis anvendere er logget på via NemLog-in anvendere af NemLogin , at kalde foretage DGWSIDWS-kald, som kræver SOSI id-kortIDWS identitytoken, ved at veksle en eksisterende OIOSAML- eller JWT-assertion asserteion udstedt af NemLog-intil et id-kortin til et identitytoken, som efterfølgende kan anvendes til opslag af webservices hos f.eks. NSP FSK eller FMK.

At tillade anvendere af id-kort af identitytoken at foretage kald i NemLogin federationen, som kræver OIOSAML assertions, ved at veksle et eksisterende id-kort identitytoken til et OIOSAML-assertion.

...

Snitflade OIOSaml2Sosi beskrives detaljeret her:
STS - Guide til anvendere - MedarbejderBorger-Billetomveksling til signeret id-kort

Snitflade Sosi2OIOSaml og  JWT2OIOSaml beskrives detaljeret her:

STS - Guide til anvendere - Medarbejder-Billetomveksling til OIOSAMLIDWS

Fejlbeskeder

Behandling af forespørgsel

...