Page History

...

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 supportsag på som indeholder metadata som beskriver klienten der skal oprettes eller modificeres (link). Metadata vedhæftes som JSON til sagen. 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.

...

{
  "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"]
} 

...

Sikkerheds profil

NSP Keycloak følger FAPI 2.0 (se https://openid.net/specs/fapi-security-profile-2_0-final.html) med yderligere indskrænkninger af profilen:

• NSP Keycloak anvender OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (

...

• se https://datatracker.ietf.org/doc/html/rfc8705)
• Der anvendes OAuth 2.0 Pushed Authorization Requests (se https://datatracker.ietf.org/doc/html/rfc9126)
• Der anvendes Proof Key for Code Exchange by OAuth Public Clients (PKCE) med code_challenge_method "S256" (se https://datatracker.ietf.org/doc/html/rfc7636)

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

Verifikation af tokens

Verifikation af tokens som udstedes af NSP Keycloak skal foretages ved hjælpe af NSP Access Handler (se NSP Access Handler - Leverancebeskrivelse)

Typiske fejl man kan opleve som anvender

Kald til token og PAR endpoint 

Client_id er ukendt

Hvis der angives en ukendt client_id returneres en HTTP fejl 401 med teksten "{"error":"invalid_request","error_description":"Authentication failed."}" 

Ikke tilladte scopes

Hvis der anmodes om scopes som ikke er tilladte returneres en HTTP fejl 400 med teksten "{"error":"invalid_request","error_description":"Invalid scopes: EDS user/AuditEvent.rs"}"

Forkert mTLS certifikat

Hvis der anvendes et forkert mTLS klientcertifikat eller hvis subject i metadata ikke er angivet 100% korrekt returneres en HTTP fejl 401 med teskten "{"error":"invalid_request","error_description":"Authentication failed."}" 

Ikke tilladt redirect_uri

Hvis der angives en redirect_uri som ikke er tilladt returneres en HTTP fejl 400 med tekesten "{"error":"invalid_request","error_description":"Invalid parameter: redirect_uri"}"Hvordan identificerer man som anvender disse fejl