Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 gedeeld geheim, maar op de ondertekening van een bericht met 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 JWT token mee te controleren, enkel de geheime sleutel kan gebruikt worden om het JWT token te ondertekenen. 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. Het is 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

Het access_token bestaat net als de client credentials uit is een JWT token. Hoe dit access_token er uit ziet ligt vast in koppeltaal. Door de inhoud en structuur van in het  het access_token de toegangsegels van de applicatie die het token aanvraagt vast te leggen ontstaat een ontkoppeling van componentenontstaat een ontkoppeling tussen FHIR resource service en de autorisatie service. De gegevens die nodig zijn om toegang te verlenen liggen vast in het access_token en hoeven niet verder uitgewisseld te worden. Een willekeurige FHIR service kan, indien deze de autorisatie service vertrouwt, de inhoud van het token direct vertalen naar toepasbare restricties. 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. 

...

Omdat de applicaties in het koppeltaaldomein toegewezen rollen hebben, die naar permissies vertaald worden en in het scope veld het access_token worden vastgelegd als autorisatieregels, is er voor de scope in de aanvraag voor een token voor een applicatie lastig te vullenvan weinig belang; de waarde wordt gevuld met de rol die het domein de applicatie heeft toegekend. Om deze reden is het toegestaan de waarde * te gebruiken voor het verkrijgen van alle toegestane permissies in de aangevraagde scope. Indien de applicatie om enkel een specifieke scope vraagt, mag de autorisatie service de uitgegeven scope hiermee beperken. 

...