Autorisatie-terminologie is een puinhoop: Laten we het oplossen

RBAC en ABAC beschrijven op welke data een beslissing is gebaseerd: een rol of een attribuut. PBAC beschrijft hoe die beslissing wordt genomen: via een centrale policy-engine in plaats van logica die in de applicatie is ingebakken. De één gaat over de vorm van de regel; de ander over waar de regel leeft en wie deze evalueert.

Naar mijn mening is het behandelen van deze termen als concurrerende opties hetzelfde als het vergelijken van een recept met een keuken.

Deze nuance probeerde één specifieke verwarring op te lossen, maar liet een groter probleem ongemoeid: PBAC is niet de enige term die op deze manier verkeerd wordt gecategoriseerd.

  • Mandatory Access Control (MAC) en Discretionary Access Control (DAC) worden ook vergeleken met RBAC en ABAC, hoewel ze beschrijven wie de regels beheert en niet hoe de regels eruitzien.
  • Access Control List (ACL) en Relationship-Based Access Control (ReBAC) worden in dezelfde adem genoemd als "autorisatiemodellen", terwijl de één waarschijnlijk een speciaal geval is van de ander, afhankelijk van welke bron je raadpleegt.

De terminologie rondom autorisatie is gedurende decennia ontstaan binnen onderzoek naar toegangscontrole, identity-vendors en standaardisatie-instanties. Veel van deze termen beantwoorden verschillende vragen, terwijl ze de taal van één enkele vraag gebruiken: "Welk model is dit?"

Dit artikel generaliseert het onderscheid tussen model en architectuur tot een volledige taxonomie. In plaats van te vragen "welk autorisatiemodel gebruikt dit systeem?", wil ik vijf specifiekere vragen stellen over elk autorisatiesysteem, elke vraag onafhankelijk beantwoorden, en pas daarna kijken waar bekende labels zoals RBAC, ABAC, MAC en PBAC daadwerkelijk landen. Als de termen ophouden met met elkaar te concurreren zodra ze op de juiste as zijn geplaatst, is dat een teken dat de assen correct functioneren.

Het kernprobleem van autorisatie

Autorisatie beantwoordt één vraag: mag dit subject deze actie uitvoeren op dit object? Denk aan een gebruiker die een bestand leest, een service die een API aanroept of een proces dat naar een database schrijft. Elke autorisatiebeslissing kan worden teruggebracht tot dit drietal: subject, actie, object.

In het simpelste denkbare systeem hoeft er geen beslissing te worden genomen, omdat er geen scheiding is tussen de partij die vraagt en de partij die beslist. Stel je een eigen dagboek voor in een lade in je eigen kamer. Je wilt het lezen, dus je opent de lade en leest het. Niemand hoeft je toestemming te geven, omdat er niemand anders bij betrokken is: het willen en het krijgen zijn dezelfde handeling.

Echte systemen blijven zelden zo simpel, omdat het object waartoe toegang wordt gezocht meestal toebehoort aan meer dan één belanghebbende. Leg datzelfde dagboek in een huis met huisgenoten, of verplaats het naar een archiefkast van een bedrijf, en het beeld verandert onmiddellijk. Niet iedereen die de lade wil openen mag dat, en iemand moet per geval beslissen wie dat wel en wie niet mag.

Een resource server doet precies dit werk voor software. Een multi-tenant SaaS-applicatie, een interne API of een cloud storage bucket die door tientallen services wordt benaderd: ze hebben allemaal iets nodig dat naar een verzoek kijkt en beslist of dit wordt gehonoreerd. Dat "iets" is waar dit artikel over gaat, en het blijkt meer bewegende delen te hebben dan een enkel woord als "RBAC" of "PBAC" kan vatten.

Hoe een autorisatieverzoek wordt verwerkt

Als we een enkel autorisatieverzoek volgen door een resource server, ontstaat er een consistente reeks fasen, ongeacht de specifieke technologie: er komt een verzoek binnen, de server verzamelt context over de gebruiker en de resource, en een policy evalueert die context aan de hand van een regel. De evaluatie produceert een besluit (toestaan of weigeren), en de server dwingt dat besluit af door het verzoek door te laten of af te wijzen.

Dezelfde vijf fasen komen voor in vrijwel elk autorisatiesysteem:

  1. Definitie: Iemand definieert de regels. Een ontwikkelaar hardcodeert een controle; een securityteam schrijft een policy; een eigenaar van een resource stelt deelrechten in op zijn eigen bestand.
  2. Vormgeving: De regels krijgen een concrete vorm. Een conditional in applicatiecode; een JSON-document; een XACML-policy; een rij in een spreadsheet die wordt geëxporteerd naar een database-tabel.
  3. Informatievoorziening: Er is data nodig om het besluit te voeden. De rol van de gebruiker; de afdeling in een database; het tijdstip van de dag; de relatie tussen de vragende gebruiker en de eigenaar van de resource.
  4. Besluitvorming: Er wordt een besluit berekend. De regel en de data worden samen geëvalueerd, wat resulteert in 'allow' of 'deny'.
  5. Handhaving: Het besluit wordt afgedwongen. Er moet daadwerkelijk worden gehandeld naar het resultaat: het verzoek blokkeren of doorlaten.

Deze vijf fasen komen overeen met een vocabulaire dat al langer bestaat in de architectuur van toegangscontrole:

  • Policy Administration Point (PAP): wie de regels definieert.
  • Policy Information Point (PIP): welke data het besluit voedt.
  • Policy Decision Point (PDP): waar het besluit wordt berekend.
  • Policy Enforcement Point (PEP): waar het besluit wordt afgedwongen.

Er is een gerelateerde, meer academische inkadering uit een systematische literatuurstudie uit 2022 door Mohamed, Auer, Hofer en Küng. Zij beschrijven een ladder met vier niveaus: een autorisatiestrategie (discretionair, obligatoir of hybride) staat boven een autorisatiemodel (de subjecten, objecten en andere componenten waar een systeem over redeneert), wat weer boven een autorisatiepolicy (de concrete regelinstantie) staat. Parallel hieraan wordt een toegangscontrolemodel (de logica voor het besluit) afgedwongen door een toegangscontrolemechanisme (de daadwerkelijk draaiende software). Dit is een rigoureuze manier om te zeggen wat dit artikel ook betoogt: strategie, model, policy en mechanisme zijn afzonderlijke lagen, en het samenvoegen ervan is waar de terminologie in de war raakt.

Geen van deze vijf fasen vertelt op zichzelf of een systeem "RBAC is" of "PBAC is". Elke fase is in feite een aparte vraag met een eigen set antwoorden. Dat is de basis voor de onderstaande classificatie.

Een consistente classificatie

Zes assen dekken de bovenstaande vijf fasen (waarbij de Autorisatiepolicy is gescheiden van het Autorisatiemodel, aangezien een model door meer dan één soort concreet policy-artefact kan worden geïnstantieerd). Elke as heeft een klein aantal veelvoorkomende antwoorden, en elke bekende term (ACL, RBAC, ABAC, ReBAC, MAC, DAC, PBAC) is in werkelijkheid een antwoord op één specifieke as, niet een label voor het hele systeem.

Een handige manier om de zes assen onderscheidend te houden is een metafoor uit de rechtspraak: een wetgever stelt regels op, de regels worden opgeschreven als wetten, rechtbanken wegen die wetten af tegen de feiten van een zaak, en de politie voert het vonnis uit. Vervang "rechtssysteem" door "autorisatiesysteem" en dezelfde zes taken verschijnen hieronder.

1. Autorisatie-administratie: wie stelt de regels vast?

Voordat een regel kan worden geëvalueerd, moet iemand de autoriteit hebben om deze te schrijven. Deze autoriteit kan gecentraliseerd zijn of verspreid, onafhankelijk van wat de regels daadwerkelijk zeggen.

  • Gecentraliseerd: een securityteam of beheerder definieert regels voor iedereen. Dit is het patroon achter MAC (Mandatory Access Control): toegang wordt bepaald door een centrale autoriteit, niet door de eigenaar van de resource.
  • Gedecentraliseerd: de eigenaar van een resource beslist wie anders toegang krijgt. Dit is DAC (Discretionary Access Control): het klassieke patroon van "deel dit bestand met deze mensen".
  • Hybride: sommige regels komen van een centrale autoriteit, andere van individuele resource-eigenaren, die over elkaar heen liggen.

De literatuurstudie van Mohamed et al. bevestigt dat administratiestrategie echt onafhankelijk is van het autorisatiemodel: een rolgebaseerd systeem kan centraal worden beheerd, door de eigenaar worden beheerd, of beide, en het blijft in elk geval RBAC.

2. Autorisatiemodel: welk type data drijft het besluit?

Zodra de autoriteit is vastgesteld, is de volgende vraag waar de regel over redeneert: het specifieke type informatie dat bij elke uitvoering wordt gecontroleerd.

  • Identiteitsgebaseerd (ACL): het besluit controleert of het specifieke subject op een lijst staat die aan het object is gekoppeld.
  • Rolgebaseerd (RBAC): het besluit controleert of het subject een rol heeft die de gevraagde permissie is verleend.
  • Attribuutgebaseerd (ABAC): het besluit controleert attributen van het subject, object, actie of de omgeving tegen een regel (bijv. afdeling = "finance", securityclearance $\geq$ "secret", tijd tussen 09:00 en 17:00).
  • Relatiegebaseerd (ReBAC): het besluit controleert de relatie tussen subject en object, vaak door een graaf te doorlopen (bijv. is deze gebruiker een lid van het team dat dit document bezit?).

Het is eerlijk om toe te geven dat deze categorieën vloeiend in elkaar overgaan. Afhankelijk van de bron kunnen ACL en RBAC worden beschreven als speciale gevallen van ABAC.

3. Autorisatiepolicy: welke vorm heeft de regel?

Zodra er een model is gekozen, moet dit worden vastgelegd als een concreet artefact:

  • Hardcoded conditionals in applicatiecode.
  • Een gestructureerd document (JSON, YAML) dat tijdens runtime wordt geladen en geïnterpreteerd.
  • Een declaratieve policy-taal die speciaal is gebouwd voor autorisatie, zoals XACML, Rego (Open Policy Agent) of Cedar.
  • Een rij in een database-tabel.

Deze as is belangrijk omdat twee systemen hetzelfde autorisatiemodel kunnen delen (beide zijn RBAC), maar volledig kunnen verschillen in onderhoudbaarheid en auditeerbaarheid, puur door de manier waarop de policy wordt uitgedrukt.

4. Autorisatie-informatie: waar komt de relevante data vandaan?

Een regel is slechts zo goed als de data waarop deze wordt geëvalueerd. Het is belangrijk om te scheiden waar de regel van afhangt en hoe het systeem die data daadwerkelijk verkrijgt:

  • Ingebouwd (Wired in): de data is al beschikbaar in de normale request flow van de applicatie.
  • Token-gebaseerd: de data komt aan als claims in een JWT of soortgelijk bewijs, ingevuld door de identity provider bij uitgifte.
  • Opgezocht (Looked up): de applicatie raadpleegt op het moment van besluitvorming een database, directory of externe service.
  • Omgevingsfactoren: de data beschrijft de context van het verzoek zelf (tijd, locatie, apparaatstatus, netwerk).

5. Autorisatiebesluit: hoe en waar wordt het besluit berekend?

Wanneer de regel en de data beschikbaar zijn, moet er iets de evaluatie uitvoeren. Waar dit "iets" leeft is een vraag over architectuur, niet over de regel zelf:

  • Ingebakken in applicatiecode: een if-statement of een framework-native permissiecontrole inline met de business logica.
  • Een speciale bibliotheek of module: de beslissingslogica is gescheiden, maar draait nog steeds binnen het applicatieproces.
  • Een centrale policy-engine: een aparte service die context ontvangt en een besluit teruggeeft, vaak gedeeld door veel applicaties.

PBAC bevindt zich hier, niet op de as van het "autorisatiemodel". Het centraliseren van het besluitpunt in een policy-engine is een architecturale keuze. Een PBAC-engine kan rolgebaseerde regels, attribuutgebaseerde regels of een mix daarvan evalueren. Daarom is PBAC geen concurrent van RBAC of ABAC; het beantwoordt een andere vraag.

6. Autorisatie-handhaving: hoe en waar wordt het besluit afgedwongen?

Een besluit is alleen relevant als er naar gehandeld wordt. Handhaving kan op verschillende plekken plaatsvinden:

  • Ingebakken in applicatiecode: hetzelfde codepad dat het besluit nam, voert het ook uit.
  • Dedicated middleware: een component op framework-niveau onderschept het verzoek op basis van het besluit.
  • Gedistribueerde handhaving: een gateway, sidecar of proxy dwingt besluiten af aan de rand van het netwerk (network edge), onafhankelijk van de applicatie zelf.

Net als bij de besluitvorming is dit architectuur, geen model. Een systeem dat ABAC-besluiten afdwingt via een API-gateway en een systeem dat ABAC-besluiten afdwingt via inline middleware zijn beide onmiskenbaar ABAC.

Alles samenbrengen

Een volledige beschrijving van een echt autorisatiesysteem is een tuple over alle zes de assen, niet één enkel woord. "RBAC" zegt iets over de as van het autorisatiemodel en niets over de andere vijf assen. Een autorisatiesysteem kan bijvoorbeeld bestaan uit:

  • Gecentraliseerde administratie (MAC)
  • Rolgebaseerd model (RBAC)
  • JSON policy-documenten
  • Token-gebaseerde informatie
  • Een gedeelde policy-engine (PBAC-architectuur)
  • Handhaving op gateway-niveau

Dit is een coherente, veelvoorkomende real-world setup, en elk label is gelijktijdig accuraat, omdat elk label een andere vraag beantwoordt. De verwarring in de meeste discussies komt voort uit het kiezen van één label per systeem en dat als uitputtend behandelen.

Conclusie

Het terminologieprobleem in autorisatie is niet dat het veld een gebrek aan vocabulaire heeft. Integendeel, er is te veel: MAC, DAC, RBAC, ABAC, ReBAC, ACL, PBAC en meer. Het probleem is de gewoonte om dit allemaal te behandelen als één platte lijst van "autorisatiemodellen" waaruit gekozen moet worden, terwijl de meeste van deze termen helemaal niet met elkaar concurreren.

Het scheiden van de vragen helpt op een zeer praktische manier bij het kiezen van een aanpak voor een echt systeem:

  1. Kies het autorisatiemodel op basis van waar uw toegangsregels natuurlijk van afhangen (rollen, attributen, relaties).
  2. Kies apart de architectuur (waar besluiten worden genomen en afgedwongen) op basis van uw operationele beperkingen (hoeveel services de policy moeten delen, hoeveel latentie u kunt tolereren, wie regels moet auditeren of wijzigen).

Dit zijn twee aparte beslissingen met twee aparte sets afwegingen. Het samenvoegen tot één keuze ("we doen PBAC" of "we doen RBAC") maskeert vaak de helft van wat er daadwerkelijk besloten moet worden.

***

Referenties

  • Is Policy-Based Access Control (PBAC) an Authorization Model?
  • A Taxonomy of Modern Authorization Models
  • The State of the Union of Authorization
  • A systematic literature review for authorization and access control: definitions, strategies and models. International Journal of Web Information Systems, 18(2/3), 156-180. https://doi.org/10.1108/IJWIS-04-2022-0077