Klienter
NSP Keycloak understøtter 2 forskellige typer klienter
- Systemklienter
- Brugerklienter
Begge klienttyper er confidential clients i OAuth forstand
Systemklienter
En systemklient er en klient som via system-til-system-integration tilgår en EHMI service. Selvom klienten måtte foretage opslag på baggrund af en brugerhandling, er systemklienten defineret ved at brugerens identitet ikke er relevant i den givne kontekst og ikke kommunikeres til EHMI servicen. Eksempler på systemklienter er sundhedsadresseringsservicen som tilgår postkasseregisteret eller et fagsystem som tilgår forsendelsesstatusservicen
Brugerklienter
En fuld klient med brugerdelegering (eller bare brugerklient i det følgende) er en klient som foretager kald for en autentificeret bruger, hvis identitet kommunikeres til EHMI servicen som en del af tokenet, der indgår i kaldet. Klienten er defineret som ’fuld’ i OAuth forstand, idet den både kan autentificere sig selv og brugeren (via et webbrowser-baseret flow). Et eksempel på en fuld klient med brugerdelegering i en EHMI kontekst er backenden til en webapplikation som tilbyder søgninger i forsendelsesstatusservicen.
Oprettelse af klienter
Alle klienter oprettes og vedligeholdes ved hjælp af OAuth 2.0 Dynamic Client Registration Protocol (se https://datatracker.ietf.org/doc/html/rfc7591), Adgangen til at kalde client registration endpoint er begrænset til NSP administrationen. Dette betyder at anvendere af NSP Keycloak som ønsker en klient oprettet eller modificeret skal oprette en Jira sag som indeholder metadata som beskriver klienten der skal oprettes eller modificeres. Generelt er strukturen og tilladte felter beskrevet i RFC7591. NSP Keycloak understøtter (og kræver) dog nogle custom felter. Nedenfor er alle relevante felter for klient metadata til NSP Keycloak beskrevet.
| Metadata element | Beskrivelse |
|---|---|
token_endpoint_auth_method | Hvordan klienten autentificerer sig ved Authorization Serverens Token Endpoint. Sættes til den faste værdi tls_client_auth dvs. autentifikation på transportlaget via et (OCES) TLS-klientcertifikat. |
grant_types | Et array med en angivelse af hvilke OAuth flows klienten
|
client_name | Et sigende navn for klienten, som letter administrations- |
scope | En liste af OAuth scope værdier (adskilt med blank space) |
contacts | Et array med kontaktoplysninger (typisk e-mailadresser F.eks. "["support@firma.dk", "+45 1234 5678"]" |
tls_client_auth_subject_dn | Subject Distinguished Name fra OCES systemcertifikatet som anvendes som TLS-klientcertifikat. F.eks. "C=DK,2.5.4.97=#0c0e4e5452444b2d3936303234313430,O=Testorganisation nr. 96024140,SERIALNUMBER=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb,CN=System 1" Bemærk, at formatet på Subject skal følge RFC4514 (se https://datatracker.ietf.org/doc/html/rfc4514). Der kan med fordel tages udgangspunkt i ovenstående eksempel. Bemærk specielt at organizationIdentifier skal angives som OID 2.5.4.97 og værdien skal encodes som beskrevet i afsnit 2.4 i RFC4514. Der er lavet en detaljeret beskrivelse af hvordan Subject beskrives i denne encoding her 4. Design og Arkitektur beskrivelse#4.DesignogArkitekturbeskrivelse-FormatafSubjectp%C3%A5mTLSklientcertifikater (Der anbefales at OCES systemcertifikater ikke udstedes med et certifikatspecifikt UUID3, idet Subject Distinguished Name derved videreføres i uforandret form ved certifikatfornyelse og klientens registrering i Authorization Server således ikke skal ajourføres i forbindelse med certifikatfornyelse). |
redirect_uris | Skal kun angives for brugerklienter, men ikke for systemklienter.
|
audience | Ønsket audience ("aud" claim) i udstedte token. Tilladte værdier er
|
ehmi:eer:device_id | Skal kun angives for systemklienter med EDS scope. En angivelse af det device_id som stationen er registreret med i EER. |
ehmi:org_context | Skal kun angives for systemklienter med EDS scope. Et array af JSON objekter bestående af name (organisationsnavn), sor (SOR kode) og gln (lokationsnummer) som stationen sender/modtager meddelelser for. |
Eksempel på metadata for oprettelse af en systemklient:
{
"token_endpoint_auth_method": "tls_client_auth",
"grant_types": ["client_credentials"],
"client_name": "Dev - EHMI Systemklient",
"audience": "https://eds.ehmi.dk",
"scope": "EDS system/AuditEvent.crs",
"contacts": [
"døgnsupport@korsbæk.dk",
"+45 1234 5678"
],
"tls_client_auth_subject_dn": "C=DK,2.5.4.97=#0c0e4e5452444b2d3936303234313430,O=Testorganisation nr. 96024140,SERIALNUMBER=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb,CN=System 1",
"ehmi:eer:device_id": "c4b8d3ea-b187-426b-be77-bffd9f593d84",
"ehmi:org_context": [
{"name": "Frederiksbjerg Lægehus","sor": "1216891000016007","gln": "5790000135912"},
{"name": "Aarhus Sygehus","sor": "1216891000013002","gln": "5790000530906"}
]
}Eksempel på metadata for oprettelse af en brugerklient:
{
"token_endpoint_auth_method": "tls_client_auth",
"grant_types": ["authorization_code","refresh_token"],
"client_name": "Dev - EHMI Brugerklient",
"audience": "https://eds.ehmi.dk",
"scope": "EDS user/AuditEvent.rs",
"contacts": [
"døgnsupport@korsbæk.dk",
"+45 1234 5678"
],
"tls_client_auth_subject_dn": "C=DK,2.5.4.97=#0c0e4e5452444b2d3936303234313430,O=Testorganisation nr. 96024140,SERIALNUMBER=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb,CN=System 1",
"redirect_uris": ["https://ehmi-client.local:8443/login/oauth2/code/oauth-par"]
}
Sikkerhed
NSP Keycloak anvender OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (se https://datatracker.ietf.org/doc/html/rfc8705)
Token profil
NSP Keycloak udsteder tokens jf. “JWT Token Profile for Healthcare (JTP-H)”
I FAPI sikkerhedsprofilen er det påkrævet at benytte sender-constrained tokens (se afsnit 2.1.2), og
FAPI tillader såvel [OAuth-MTLS] som [OAuth-DPOP] mekanismerne til at realisere sender-
constrained tokens. I EHMI sikkerhedsmodellen anvendes alene OAuth-MTLS, hvor tokens bindes til
klienten i transportlaget. Se rationalet for valget i appendiks 4.2 Token-binding via applikations-
og/eller transportlaget.
Hvor FAPI profilen fastlægger sikkerhedsprotokoller og valideringsregler for aktørerne, der indgår i
OAuth flows, forholder den sig ikke til indholdet af de tokens som indgår i de forskellige flows.
Indhold af tokens tager derimod i EHMI afsæt i det danske sundhedsvæsnets profilering af [JWT]
tokens, se [JTP-H].
Sikkerhedsmodellen baserer sig på [NSIS] for de anvendelser, som involverer en menneskelig brugers
adgang til EHMI services1
. Adgang til EHMI services som udstiller følsomme persondata forudsætter
NSIS-sikringsniveau ’Betydelig’.
I dette kapitel præsenteres og gennemgås de elementer af profilerne, som er relevante for at
understøtte de overordnede brugsscenarier som relaterer sig til EHMI services. Læseren forventes
således ikke at have nærlæst FAPI og JTP-H profilerne.
Den konkrete anvendelse af den generelle sikkerhedsmodel i de tre EHMI services EDS, EAS og EER er
beskrevet i appendiks 7.
PAR og mTLS
Verifikation af tokens : Link til Access Handler og JTP-H
Top 3 fejl : mTLS fejl, illegal redirect, manglende scope
Hvordan identificerer man som anvender disse fejl