...

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:

<devices>/<resource>.<actie>

Devices en permissies

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.

...

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 kan zijn: 'read',  'write',  'update', 'delete' of ‘*’ zijn. De wildcard wordt gebruikt om alle acties toe te staan.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.
   1. 'c' (Create),
   2. 'r' (Read),
   3. 'u' (Update),
   4. 'd' (Delete)
2. ‘*’ (wildcard, ALL)

Scope voorbeelden

Het verkrijgen van toegang in stappen

...

• De module applicatie haalt het smart configuratie op bij de FHIR service (.well-known/smart-configuration). Dit statement bevat de volgende endpoints: 
• token_endpoint
• De applicatie genereert een JWT token op basis van de private key met de volgende velden:
• iss: de client_id van de applicatie
• iat: de timestamp now()
• jti: een unieke waarde voor deze aanvraag, UUIDs zijn hiervoor geschikt.
• exp: de timestamp now() + 5 minuten
• De applicatie benadert het token_endpoint endpoint met de volgende parameters in een application/x-www-form-urlencoded  POST request:
• scope
• grant_type: `client_credentials`
• client_assertion_type: `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`
• client_assertion: het gegenereerde JWT token uit de vorige stap.
• De autorisatie service ontvangt het token, daarbij onderneemt hij de volgende stappen:
• Op basis van de domeinconfiguratie wordt de juiste JWKS URL opgehaald om de token te valideren.
• De token wordt gevalideerd op basis van de kid en de keys beschikbaar in de JWKS URL.
• De client_id wordt gekoppeld aan de juiste Device in de FHIR resource service.
• In de domeinconfiguratie wordt de juiste rol(en) opgehaald, deze resulteert in een lijst van permissies.
• De autorisatie service genereert een access_token met de volgende waarden:
• iss: de base url van de autorisatie service
• azp: de client_id 
• iat: timestamp now()
• exp: timestamp now() + 5 min
• scope: de lijst van permissies, geformatteerd volgens het door koppeltaal vastgelegde formaat.
• De autorisatie service geeft het volgende JSON geformateerde antwoord:
• access_token, het JWT token uit de vorige stap.
• token_type: altijd ‘bearer’
• expires_in: idem als de iat uit de JWT
• scope:  idem als de scope uit de JWT
• De applicatie kan nu de FHIR resource service benaderen door gebruik te maken van de access_token. De access token wordt  in het request in de Authorization header meegegeven in het volgende formaat:
  
  Authorization: Bearer {{access_token}}
  
  
• De FHIR resource service ontvangt de access_token en valideert deze door middel van de JWKS URL van de autorisatie service. Deze is in de .well-known/smart-configuration van de FHIR resource service beschikbaar.
• De  FHIR resource service interpreteert de permissies zoals deze in de scope zijn weergegeven en beperkt de  toegang van de applicatie op basis van deze permissies.

Voorbeelden

[code]

Links naar gerelateerde onderwerpen

...