AMX - Bevoegdheden (Autorisatie Matrix) - [review]
- Bernard Stibbe
- Marcel Schrauwen
- Dick Donker
In een Autorisatie Matrix worden de toegangsrechten vastgelegd van de in gebruik zijnde applicatie instanties per domein. Deze rechten worden gekoppeld aan een applicatie rol en zijn meestal gebaseerd op het “need to know” principe.
Een resourceType kan dus aangemaakt (C-Create) worden, uitgelezen (R-Read) worden, aangepast worden (U-Update) of verwijderd worden (D-Delete), door iedereen (ALL), vergunners (GRANTED) of alleen de resource eigenaars (OWN) .
De volgende matrix is een autorisatie matrix, die per (basis) rol de rechten weergeeft op een resourceType die in Koppeltaal 2.0 gebruikt wordt.
Deze autorisatie matrix kan als basis dienen voor het verlenen van rechten aan nieuwe applicaties door ze aan een basisrol te koppelen, om zo toegang te krijgen tot Koppeltaal 2.0, om het vertrouwen in en tussen partijen en organisaties te bevorderen. Het moet inspelen op de behoeften van een breed scala aan organisaties in de zorg. We proberen hiermee inzicht te krijgen in de soort producten, en de omgang tussen de verschillende producten met risico's, zoals reikwijdte, locatie, bedrijfsmiddelen, afhankelijkheden en infrastructuur van Koppeltaal.
Basisrollen:
Autorisatie Matrix
(Systeem)rol /resourceType | ActivityDefinition | Task | Patient | Practitioner | RelatedPerson | EndPoint | Subscription | CareTeam | Organization | Device | AuditEvent |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Clientportaal | R(ALL) | C(), R(GRANTED), U(GRANTED) | R(ALL) | R(ALL) | C(), R(ALL), U(OWN) | R(ALL) | R(ALL) | R(ALL) | C(), | ||
| Behandelaarsportaal | R(ALL) | C(), R(ALL), U(OWN) | R(ALL) | R(ALL) | R(ALL) | R(ALL) | R(ALL) | R(ALL) | C(), | ||
| Beheerportaal | C(), R(ALL), U(ALL), D(ALL) | R(ALL), D(ALL) | R(ALL), D(ALL) | R(ALL), D(ALL) | C(), R(ALL), U(ALL), D(ALL) | C(), R(ALL), U(ALL), D(ALL) | R(ALL), D(ALL) | R(ALL), D(ALL) | C(), R(ALL), U(ALL), D(ALL) | C(), R(ALL) | |
| Zorg ondersteuning | C(), R(OWN), U(OWN) | C(), R(OWN), U(OWN) | C(), R(OWN), U(OWN) | C(), R(OWN), U(OWN) | C(), R(OWN), U(OWN) | C(), R(ALL) | |||||
| eHealth Module | C(), R(OWN), U(OWN) | C(), R(GRANTED), U(GRANTED) | R(GRANTED) | R(GRANTED) | R(GRANTED) | R(ALL) | C(), |
001. Één rol kan pas aan een applicatie instantie toegekend worden, als de applicatie geregistreerd is en een client_id voor één domein gekregen heeft.
002. De client_id wordt gemapt op de identiteit van een applicatie instantie (Device.identifier) binnen één domein
003. De rol 'Clientportaal' mag hier bijvoorbeeld dus Patient gegevens niet direct aanpassen, dat gebeurt dan via de rol 'Zorg ondersteuning'. (zie Autorisatie Matrix)
004. De rol 'Beheerportaal' beheren en verwijderen van resources en het primair uitgeven/activeren van 'Subscription' (abonnementen). De reden waarom dit alleen bij de rol 'Beheerderportaal wordt gelegd zijn:
a. Overzicht houden van alle resources binnen een domein
b. Voorkomen van performance problemen, afhankelijk van: #subscriptions, subsccription.criteria, #gebeurtenissen per tijdseenheid, data volume, etc. Lawine gevaar, doordat twee partijen op één zelfde gebeurtenis geabonneerd zijn en wat dan tot één zelfde gebeurtenis tot gevolg heeft.
005. Bij elke interactie, met de FHIR Resource Provider, MOET het toegangstoken meegestuurd worden.
a. Deze bevat het veld "azp: Authorized party - the party to which the ID Token was issued". Hiermee kan men de eigenaar (OWN) of vergunner (GRANTED) bepalen.
b. Deze bevat het veld "sub": Subject - de (technische) identifier van een gebruiker". Hiermee kan een applicatie instantie (Device) bepaalde logica uitvoeren, afhankelijk van het subject.
006. Toegangstokens worden alleen toegekend aan vertrouwde (en geïdentificeerde) Devices, die acteren in een bepaalde rol en hiermee wordt de toegang gecontroleerd tot de FHIR Resource Provider.
007. Elke resource bevat zelf de informatie over wie de originele eigenaar is van de resource, via het extended element 'resource-origin'. Deze wordt door de FHIR Resource Provider beheerd.
008. Bij het uitvoeren van een Read (GRANTED) op Task in het Clientportaal wordt "Search Narrowing" toegepast (zie ook: TOP-KT-015 - Search parameters - [vervallen, samengevoegd met TOP-KT-002]). Zo kan je als client zeggen "Geef mij alle Taken (Tasks)", en geeft de FHIR Resource Provider enkel die taken (Taks) die jij mag zien. Dit is dus bij de toegangsrechten met scope OWN of GRANTED.
009. Zowel een applicatie in de rol van 'Beheerportaal' als in de rol van 'eHealth Module' kan een ActivityDefinition resource publiceren. Echter de voorkeur gaat uit dat een applicatie in de rol van 'eHealth Module' zijn eigen ActivityDefinition publiceert.
010. Indien een applicatie in de rol van 'eHealth Module' geen verbinding kan opzetten met de FHIR Resource Server, kunnen de interacties uitgevoerd worden door een applicatie met de rol van 'Beheerportaal', die tevens dan de originele eigenaar is van de aangemaakte resources.
011. Een applicatie in de rol van 'eHealth Module' kan geen CRU interacties uitvoeren op de ActivityDefinition resource als deze applicatie niet de originele eigenaar is.
012. AuditEvent's mogen NOOIT aangepast en/of verwijderd worden. Wordt een aparte procedure voor gemaakt die ervoor zorgt dat AuditEvents gearchiveerd kunnen worden.
013. Wanneer er geen toegang verleend wordt is de response simpelweg "Unauthorized".
014. Belangrijke kanttekening: De Autorisatie Matrix is op applicatie rollen gebaseerd (RBAC= Role-Based Access Control) en dient bij voorkeur geen rechtstreeks vergunning te geven aan applicatie instanties (GRANTED). Nij rechtstreekse gunning wordt het beheer en onderhoud van de Autorisatie Matrix geïntensiveerd bij elke nieuwe applicatie instantie, waar men dan direct rechten aan kan toekennen.
015. VZVZ heeft een gewijzigd voorstel om de vergunnen (GRANTED) van applicatie instanties niet te gebruiken maar uitsluitend rechten te geven in de vorm van een groepslidmaatschap, "op basis van de rol die de applicatie wil vervullen binnen een domein en de daarbij behorende processen".
Zie aanbevelingen bij "BEB - Beheren van entiteiten en bevoegdheden - [review]".