Versions Compared

Key

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

...

De FHIR resource service autoriseert elke binnenkomende CRUD request. Elke request MOET middels de volgende logica geautoriseerd worden:

Image Added

  1. Wanneer een request binnenkomt kan de volgende informatie opgehaald worden:

    InformatieHoe op te halen
    <resource_type>Dit kan bepaald worden aan de hand van de URL. De eerste waarde na de slash van de base FHIR resource service bevat altijd het Resource type. Bijvoorbeeld /Patient , /Patient/2  of /ActivityDefinition 
    <action>Dit wordt bepaald aan de hand van het type HTTP request. GET → Read, POST → Create, PUT → Update en DELETE → Delete
    <resource-origin>Indien de request geen Create betreft, gaat het altijd om bestaande resources. Deze hebben per definitie een resource-origin extensie die aangeeft wie de eigenaar van de resource is. Deze waarde MOET van de gepersisteerde entiteit(en) gehaald worden. Wanneer een entiteit geüpdatet wordt, wordt de resource-origin  waarde dus van de te updaten versie afgehaald.


  2. Indien de <action> een create is:
    1. hoeft de resource-origin niet geverifieerd te worden. Deze mag niet zelf gezet worden, maar wordt automatisch gezet door de server. Daarnaast is een create permissie altijd in de context van de OWN permissie. Het is niet toegestaan om Resources namens een andere applicatie aan te maken.
    2. Zoek voor een scope in de context van <resource_type> of "*" (all) EN action met letterlijke tekst "create" of "*".
      1. Bijvoorbeeld bij een create van een Patient  zijn de volgende scopes valide (in dit geval is de logical id van de resource-origin  12, deze wordt niet gebruikt):

        ScopeUitleg
        12/Patient.createSpecifieke create permissie op de Patient  resource voor Device/12 
        12/*.createDevice/12  mag alle resources aanmaken
        12/Patient.*Device/12  mag alle acties uitvoeren op Patient  resources


  3. Indien de <action> GEEN create is, gaat het altijd om bestaande resources. Deze hebben per definitie een resource-origin extensie die aangeeft wie de eigenaar van de resource is. Haal de Resource(s) op en verifieer de resource-origin waarden.

    Zoek een permissie op in de access_token.scope bij de geauthoriseerde applicatie-instantie aan de hand van

    CRUD-actie en Resource type

    de logical id van de resource-origin, de <action> en <resource_type>. Bijvoorbeeld voor een UPDATE op een ActivityDefinition  wordt gezocht naar de volgende reguliere expressie:

    Code Block
    (\*|(?:\d+|,*)+)\/(?:ActivityDefinition|\*)\.(?:update|\*) 


    Image RemovedImage Added
  4. Indien niet aanwezig: FHIR resource service respond met een 403 Forbidden.
  5. Indien ‘actie CREATE' OF ‘scope ALL': Applicatie is geautoriseerd. Ga verder met aanmaken Resource.
  6. Controleer de scope (let op dat de access_token.scope  enkel de logical id van de Device  bevat):
    1. OWN : Verifieer dat de resource-origin waarde van de Resource overeenkomt met de Device van de geauthenticeerde applicatie-instantie. Indien dit niet het geval is: respond met een 403 Forbidden.
    2. GRANTED: Verifieer dat de resource-origin waarde van de Resource voorkomt in de lijst van geselecteerde Devices op de permissie. Indien dit niet het geval is: respond met een 403 Forbidden.

...


Search Narrowing

Wanneer alle resources opgehaald worden voor een specifiek type, bijv. GET /Patient, mogen enkel de resources teruggegeven worden waar de applicatie-instantie leesrechten op heeft. Dit wordt door de FHIR resource service opgelost met een interceptor. De oplossing dient de huidige query-parameters te filteren en uit te breiden in het geval dat de permissie scope niet ALL is.

...