Page Comparison

...

In eerdere versies van koppeltaal worden de credentials door middel van een client_id en een geheime sleutel gerealiseerd. In SMART on FHIR backend services wordt gebruik gemaakt van JWT Profile  for OAuth 2.0 Client Authentication rfc7523. In dit profiel wordt een JWT token als bewijs van de client authenticatie (client assertion) meegegeven. De authenticatie gebeurt niet op basis van een geheime sleutelgedeeld geheim, maar op een asymmetrische sleutelpaar. Dit sleutelpaar wordt door de cliënt gegenereerd. Het sleutelpaar bestaat uit twee delen; een geheim deel en een publiek deel. Een dergelijk sleutelpaar wordt een public / private key genoemd. De publieke sleutel kan enkel gebruikt worden om een ondertekend bericht mee te controleren, enkel de geheime sleutel kan gebruikt worden om te ondertekenen. Zo wordt dit in rfc7523 ook toegepast. De geheime sleutel wordt gebruikt om het JWT token te ondertekenen, de publieke sleutel om deze te validereren. Dit heeft  een aantal grote voordelen ten opzichte van een gedeeld geheim. In het geval van een gedeeld geheim moet het geheim altijd gedeeld worden, met het risico van mogelijk verlies van het geheim. In sleutelpaar kan gemakkelijk gegenereerd worden en het geheime deel hoeft nooit de omgeving te verlaten. Verder is het mogelijk meerdere actieve sleutelparen te hebben, zodat indien een omgeving uit meerdere instanties bestaat, iedere instantie een eigen sleutelpaar kan genereren. Omdat bij de publicatie van de publieke sleutels gebruik gemaakt  wordt van JWKS (TODO, link invoegen), kunnen sleutels gemakkelijk en snel vernieuwd worden.

...

Het access_token bestaat net als de client credentials uit een JWT token. Hoe dit access_token er uit ziet ligt vast in koppeltaal. Door de inhoud en structuur van het access_token vast te leggen ontstaat een ontkoppeling van componenten. Een willekeurige FHIR service kan, indien deze de autorisatie service vertrouwt, de inhoud van het token direct vertalen naar toepasbare restricties. Hiervoor is een syntax vastgelegd die de permissie vertaald naar een waarde van het  scope veld. De keuze voor de standaardisatie van het token is voor de schaalbaarheid van Koppeltaal van belang.Deze restricties worden vastgelegd in de scope van het JWT token. De syntax die voor deze scope wordt gebruikt is de SMART Scopes syntax. In koppeltaal wordt enkel gebruik gemaakt van System-level scopes, omdat de toegang wordt verstrekt aan applicaties. De formattering van deze syntax wordt bij de toepassing toegelicht. 

De scope in het token request

...

JWKS is geen eigen standaard, maar komt voor in de OAuth 2.0 Authorization Server Metadata standaard als optionele URL. In de praktijk is het pad <base_url>/.well-known/jwks.json en bevat het document een JSON structuur met in de “keys” waarde een lijst van JSON Web Keys (rfc7517). In koppeltaal wordt deze URL gebruikt door de autorisatie service en optioneel de applicaties, zowel module als portal, om de public keys bekend te maken.

Het access_token

...

en de

...

SMART Scopes syntax.

Het access_token vervult een speciale rol in koppeltaal. Het token bevat de rechten van de applicatie op basis van de toegewezen rollen. Het access_token wordt ondertekend door de autorisatie service, die op zijn beurt de publieke sleutel bekend maakt via een JWKS url. Verder wordt de waarde van het azp veld gevuld met de client_id van de applicatie. De velden in het access token zijn als volgt gemapped:

...

De scope bestaat uit een lijst van permissies. Zoals eerder aangegeven kent een permissie een lijst van devices op basis van de scope, resource en actie. De scope kan zijn, alle devices (ALL), alleen je eigen device (OWN) of een selectie aan devices (GRANTED). Een permissie is opgebouwd uit de volgende formaat:

<device(s)>/<resource(s)>.<actie(s)>

Devices en permissies

Zoals regels in de SMART Scopes syntax. Deze regels worden opgebouwd vanuit de regels uit  permissie matrix van beschreven in (TODO: link matrix). Deze regels bestaan uit:

• De devices. Zoals beschreven kan de scope ALL, OWN of GRANTED zijn. In het perrmissiefomaat wordt de volgende mapping gemaakt:

  • ALL: *
  • OWN: de eigen device logical id
  • GRANTED: een lijst van device logical ids, gescheiden door een komma.

Resource

• De resource wordt gevuld met het resource type, bijvoorbeeld ‘Patient’. Er mag  een wildcard ‘*’ gebruikt worden om alle resources aan te duiden. De resource MOET altijd als PascalCase gezet worden.

Actie

• De actie MOET één van de volgende twee opties zijn:

  1. Minimaal één van de onderstaande letters. De letters MOETEN lower-case zijn en hebben GEEN vaste volgorde.
     • 'c' (Create),
     • 'r' (Read),
     • 's' (Search)m
     • 'u' (Update),
     • 'd' (Delete)
  2. ‘*’ (wildcard, ALL)

Deze permissieregels worden in de de SMART Scopes syntax als volgt gemapped:

system/<resource>.<actie(s)>?resource-origin=<device(s)>

In een scope regel kan een type resource worden weergegeven, of een wildcard. Meerdere acties en devices per regel zijn mogelijk.

Scope voorbeelden

...