Publish Box goes here

Overzicht

Official URL: https://cumuluz.org/fhir/system-authentication/ImplementationGuide/org.cumuluz.system-authentication				Version: 0.1.0
Draft as of 2026-07-17				Computable Name: CumuluzSystemAuthenticationIG

Zorgaanbiederauthenticatie en -autorisatie

Deze Implementation Guide beschrijft een technisch profiel in wording voor authenticatie en autorisatie tussen systemen van zorgaanbieders. Het doel is dat een bronhoudende zorgaanbieder kan vaststellen:

• welke organisatie een systeemaanroep doet;
• voor welke organisatie, resource en doel toegang wordt gevraagd;
• of de aanvrager de juiste cryptografische sleutels bezit;
• of token en request onderweg niet naar een ander endpoint kunnen worden verplaatst of opnieuw gebruikt.

De beveiligingsflow is generiek. BgZ en eOverdracht zijn use-casevoorbeelden, geen verschillende authenticatieprotocollen.

Status: de guide combineert internationale standaarden met expliciete Nederlandse profielkeuzes. Zij is geen ongewijzigde IHE IUA-implementatie en nog geen formeel vastgesteld landelijk conformiteitsprofiel.

Kernflow

1. Het clientsysteem kent de doelorganisatie en zoekt haar vertrouwde registratie op.
2. Die registratie bindt de organisatie aan issuer, tokenendpoint, resourcebasis, JWKS en certificaatgegevens.
3. Het clientsysteem authenticeert zich bij de authorization server met mTLS en een private_key_jwt.
4. Het vraagt met een Rich Authorization Request (RAR) toegang tot één aangewezen resource voor een bepaald gebruiksdoel.
5. De authorization server controleert identiteit, certificaat, autorisatie en DPoP-proof en tekent alleen de geaccepteerde details in het access token.
6. Het clientsysteem controleert het ontvangen token en roept uitsluitend de geregistreerde en geautoriseerde resource aan.
7. De resource server valideert token, DPoP, requestbinding en beleid opnieuw voordat zij de FHIR-response over mTLS terugstuurt.

Geen enkel bewijs is op zichzelf voldoende. Het beveiligingsmodel legt uit hoe registratie, clientcertificaat, assertion, token, DPoP en TLS elkaar aanvullen.

Wat dit profiel wel en niet regelt

Dit profiel regelt systeemauthenticatie, technische autorisatie, token-/requestbinding en beveiligd transport tussen zorgaanbieders. Het vervangt niet:

• lokale authenticatie van een zorgprofessional;
• mandatering namens de zorgaanbieder;
• patiënttoestemming of behandelrelatie;
• inhoudelijke FHIR-profielen en terminologievalidatie;
• doelbinding en beleidsbeslissingen buiten de meegegeven technische context.

Die voorwaarden kunnen toegang aanvullend beperken. Een technisch geldig access token is dus geen zelfstandig bewijs dat zorginhoud mag worden gedeeld.

Hoe deze guide gelezen wordt

Lees eerst het beveiligingsmodel en de actoren en vertrouwensrelaties. Daarna volgen de drie technische lagen:

1. clientauthenticatie;
2. autorisatie en access token;
3. DPoP en transportbeveiliging.

De end-to-end flow brengt deze lagen vervolgens samen. Validatie, fouten en audit beschrijft het fail-closed gedrag. Profiel en standaarden maakt zichtbaar wat standaardbasis, profielregel, referentiekeuze of open ontwerpkeuze is.

Referentie-implementatie

De repository bevat een uitvoerbare Kotlin/Ktor-implementatie en een Prototype-adapter voor vertrouwde gegevensuitwisseling. De code demonstreert echte JOSE-cryptografie, mTLS, replaycontrole en FHIR-verkeer. De workbench toont per stap gesanitiseerd netwerkverkeer, claims en beslisregels.

Deze implementatie bewijst dat de beschreven flow uitvoerbaar is; haar applicatiestructuur is niet voorgeschreven. Zie Referentie-implementatie en workbench voor de mapping naar code en UI.

Publicatieschil en payloadversie

De guide gebruikt een FHIR R4-publicatieschil omdat SUSHI 3.x geen STU3 ImplementationGuide-package genereert. Het beveiligingsprofiel definieert geen klinische R4-profielen. De synthetische runtimevoorbeelden blijven FHIR STU3 en worden niet als R4-conformanceartefacten gepubliceerd.