Publish Box goes here

Implementeren en verifiëren

Implementeren en verifiëren

Deze checklist vertaalt de profielregels naar observeerbaar gedrag. Een vinkje betekent pas iets als de implementatie zowel het succespad als de veilige afwijzing kan aantonen.

Clientsysteem van URA-A

Configuratie en vertrouwen

• Leg eigen organisatie-identificatie, signing key en clientcertificaat afgeschermd en eenduidig vast.
• Resolveer URA-B alleen via een vertrouwde organisatieregistratie.
• Controleer dat issuer, tokenendpoint, JWKS en resourcebasis gezamenlijk bij URA-B horen.
• Valideer voor iedere HTTPS-verbinding hostname en certificaatketen.

Verificatiecriterium: een onbekende organisatie, afwijkend endpoint, onbetrouwbare JWKS of ongeldige TLS-peer stopt vóór gebruik van token of resource.

Tokenaanvraag

• Maak een kortlevende private_key_jwt met iss == sub == URA-A, exacte issuer-aud, geldigheid en unieke jti.
• Gebruik de RFC 7523 jwt-bearer URN als client_assertion_type.
• Verstuur RAR als losse authorization_details-parameter.
• Bind resource, RAR-location en doelorganisatie aan de vertrouwde registratie.
• Maak een verse tokenendpoint-DPoP-proof voor exacte methode en URI.
• Gebruik mTLS voor de tokenaanvraag.

Verificatiecriterium: requestinspectie toont de juiste parameters en gesanitiseerde headers; foutinjectie voor assertion, RAR, certificaat of DPoP levert geen access token op.

Token- en resourcegebruik

• Valideer handtekening, issuer, client, audience, tijd, geaccepteerde RAR, doelorganisatie, location en cnf.jkt.
• Roep alleen de geregistreerde en in het token geautoriseerde resource aan.
• Gebruik dezelfde DPoP-key als in cnf.jkt, maar een verse resourceproof.
• Neem methode, URI, tijd, unieke jti en ath op in de resourceproof.
• Gebruik Authorization: DPoP, DPoP-proofheader en mTLS.

Verificatiecriterium: ontbrekende claims, verlopen token, verkeerde key, afwijkende URI, replay en Bearer-downgrade stoppen vóór of bij de resource server.

Authorization server van URA-B

Clientcontrole

• Vereis mTLS en valideer het clientcertificaat.
• Resolveer clientorganisatie, signing key en geregistreerd certificaat uit de vertrouwensvoorziening.
• Controleer actuele certificaatstatus afzonderlijk.
• Valideer assertionhandtekening, iss, sub, aud, tijd en replay.

Verificatiecriterium: iedere mislukte clientcontrole resulteert in een veilige OAuth-fout zonder token of secretinhoud.

Autorisatie en uitgifte

• Parse en valideer resource en authorization_details.
• Pas eigen beleid toe op type, purpose, location en doelorganisatie.
• Valideer de tokenendpoint-DPoP-proof en replay.
• Teken alleen de geaccepteerde autorisatiedetails.
• Neem exacte resource-aud, clientclaims, tijd, jti en cnf.jkt op.

Verificatiecriterium: een token wordt uitsluitend uitgegeven wanneer alle client-, autorisatie- en DPoP-controles slagen; de claims tonen de geaccepteerde uitkomst.

Resource server van URA-B

• Vereis mTLS, Authorization: DPoP en een DPoP-proofheader.
• Valideer het access token onafhankelijk tegen de eigen issuerkey.
• Controleer client, audience, tijd, RAR, doelorganisatie en purpose.
• Controleer proofkey tegen cnf.jkt.
• Controleer htm, htu, iat, jti, ath en replay.
• Geef pas daarna de FHIR-response vrij.

Verificatiecriterium: een ongeldige of ontbrekende authenticatie levert een HTTP 401 met een passende WWW-Authenticate: DPoP-challenge; onvoldoende autorisatie levert HTTP 403. Beide bevatten een veilige OperationOutcome. Een succesvolle request levert alleen de geautoriseerde resource.

Logging en audit

• Gebruik een correlatie-id over de technische flow.
• Leg actor, actie, tijd en uitkomst in het eigen organisatie-auditspoor vast.
• Redigeer compacte assertions, access tokens en DPoP-proofs.
• Log nooit private keys, keystorewachtwoorden of andere secrets.

Verificatiecriterium: logs en audit ondersteunen reconstructie van de beslissing zonder herbruikbaar authenticatiemateriaal te bevatten.

Productiehardening

Vervang vóór productie:

• demo-CA en lokale keystores door beheerde PKI- en HSM-processen;
• in-memory replay door gedeelde, beschikbare opslag;
• lokale directory en statusservice door overeengekomen landelijke poorten;
• vaste localhost-URI's door geregistreerde productie-endpoints;
• in-memory audit door duurzaam, afgeschermd auditbeheer;
• synthetische Bundles door use-case-specifieke, gevalideerde FHIR-data.

Leg tevens sleutelrotatie, crypto-agility, rate limiting, monitoring, incidentrespons, privacybeleid, consent, behandelrelatie en operationele certificaatrevocatie vast.

Referentieverificatie

Backend, cryptografie en echte mTLS:

GRADLE_USER_HOME=$PWD/.gradle ./gradlew clean test build --no-daemon

Workbench:

cd ui
npm ci
npm run test:run
npm run typecheck
npm run build

IG:

cd ig
npm ci
./_genonce.sh

Alleen daadwerkelijk uitgevoerde tests gelden als bewijs. De referentie-implementatie koppelt de profielstappen aan code en workbench. Zij is geen certificering van landelijke conformiteit.