...
| # | Eis | FHIR service | Bron applicatie | Domein |
|---|---|---|---|---|
| 001 | Op resources, M.U.V. de conformance statement en CapabilityStatement, in de FHIR resource service wordt toegang verleent op basis van de regels van de toegangsbeheersing. | x | ||
| 002 | Er is een ontkoppeling tussen de autorisatie service en FHIR resource service, dit betekent dat beide niet direct met elkaar communiceren. In plaats daarvan worden de autorisatieregels in het access_token met een vastgelegde syntax vastgelegd. | x | ||
| 003 | In koppeltaal wordt gebruik gemaakt van Role Based Access Control (RBAC) | x | ||
| 004 | Iedere applicatie krijgt binnen het Koppeltaaldomein (applicatie-instantie) een client_id toegekend, dit is de logical identifier van een Device resource. De client_id MOET een nieuwe random UUID v4 zijn. Deze logical identifier MOET als system de volgende system hebben: httpshttp://koppeltaalvzvz.nl/client_fhir/NamingSystem/koppeltaal-client-id. Iedere applicatie heeft een Device entiteit in de FHIR resource service. Elke entiteit die door een applicatie wordt aangemaakt krijgt een resource-origin metadata veld waar een referentie in staat naar de bijbehorende FHIR Device entiteit. | x | ||
| 005 | Iedere applicatie binnen het domein (applicatie-instantie) krijgt enkel één rol toegekend, deze rol is gekoppeld aan een set van permissies. Rollen en permissies MOETEN beschikbaar gesteld worden op het niveau van applicatie-instanties. | x | ||
| 006 | Iedere permissie bestaat uit de FHIR resource waar deze van toepassing op is, de actie (Create (C), Read (R), Update (U) of Delete (D) actie.), en de scope. De scope bestaat uit OWN, alleen de eigen resources, GRANTED, een toegekende lijst van eigenaren, of ALL, alle eigenaren. Zowel OWN als GRANTED worden vertaald naar Device referenties op het moment dat de autorisatieregels worden opgesteld. | x | ||
| 007 | Een Create permissie MOET altijd de scope OWN zijn | x | ||
| 008 | De autorisatie van de applicatieinstantie op de FHIR resource service gebeurt door middel van het SMART backend services protocol. | x | ||
| 009 | Het SMART backend services protocol vereist dat applicaties zich identificeren, in Koppeltaal doen we dit met JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication (rfc7523). Dit houdt in de elke applicatie een of meerdere keypairs genereert, de public key deelt en elk request naar de autorisatie service voorziet van een ondertekend JWT token om zich zo te identificeren. | x | x | |
| 010 | Na de autorisatie van de applicatie krijgt deze een access_token, dit access token bevat de client_id van de applicatie in het azp veld en de autorisatieregels als scope veld. | x | ||
| 011 | Voor het autoriseren van de applicatieinstantie doet de FHIR resource service op basis van de regels in de
Waar Type kan zijn het type (Person, Task) of Waar de operaties bestaan uit de acties als omschreven door FHIR. Waar de | x | ||
| 012 | De resource-origin extensie MOET toegevoegd worden aan de Resource bij het aanmaken van een Resource. | x | ||
| 013 | De resource-origin extensie MOET gezet worden bij een PUT van de Resource indien deze niet aangeleverd wordt. | x | ||
| 014 | De resource-origin MAG meegegeven worden met een PUT van de Resource, maar mag NIET veranderd zijn. | x | x | |
| 015 | Bij het zoeken van resources mogen enkel de resources worden geretourneerd in het resultaat die aan de autorisatieregels voldoen (Search Narrowing). | x | ||
| 016 | Bij het versturen van updates van een Subscription moeten de autorisatieregels worden toegepast; het is niet de bedoeling dat er een subscription wordt uitgevoerd als de partij geen toegang heeft. | x |
...