#	Eis	FHIR service	Bron applicatie	Domein
001	Op resources, M.U.V. Implementation Guide, 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, deze MOET gelijk zijn aan de logical identifier van een Device resource. De relatie `client_id` is voor de Device reference Device/<client_id>. Deze logical identifier MOET als system de volgende system hebben:http://vzvz.nl/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 `grant` van het access_token, hier wordt gebruik gemaakt van de V2 scopes uit de SMART app launch. Deze kent het volgende formaat voor koppeltaal: `system/<Type>/[cruds]?resoucre-origin=<Device1,Device2>` Waar Type kan zijn het type (Person, Task) of `*` Waar de operaties bestaan uit de acties als omschreven door FHIR. Waar de `resoucre-origin` bestaat uit een komma gescheiden lijst van Device referenties, en kan worden weggelaten voor type ALL.	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

Koppeltaal documenteert een matrix van meest voorkomende rollen die gebruikt worden in koppeltaal. Deze matrix is informatief, maar kan gebruikt worden als startpunt voor het beheren van rollen en rechten.

Browser not supported