Van RBAC naar ABAC deel 2

Aan de rol

 

Weg met de rol! Dat is eigenlijk al een poosje mijn motto. Dat kan natuurlijk niet zomaar. We zijn in ons land net een beetje aan de rol en dat is helemaal niet verkeerd. Alleen al het streven naar meer beheersing van autorisaties is prima. Echter, zoals vorige keer beschreven, een rol is niet de meest efficiënte of flexibele manier van autorisatiebeheer. Een rol is eigenlijk een concept dat bedacht is om een pragmatische vertaling te kunnen maken van bedrijfsfuncties naar technische permissies. En dat vergt wat gedachtensprongen.

Een van de gedachtensprongen is dat we kijken naar wat iemand moet doen om daaruit af te leiden wat iemand nodig heeft: Is iemand debiteurenbeheerder, dan krijgt hij of zij de autorisaties om debiteuren te beheren. Heeft iemand meer taken, dan krijgt de autorisaties die voor de verschillende taken nodig zijn.

Maar dat is echt wel een enorme gedachtensprong. Eigenlijk moet je net andersom redeneren: wat moet er gedaan worden en vervolgens wat is daarvoor nodig. Aan welke kwaliteitseisen moet de uitvoering voldoen. En dan gaat het zowel om de eisen ten aanzien van de uitvoerende, als aan de eisen ten aanzien van autorisaties. Dat lijkt een futiliteit, maar het is een fundamentele omdraaiing van het autorisatiemodel. Eigenlijk zou het dus zo moeten gaan:

Binnen het financiële proces moeten gegevens van debiteuren worden beheerd. De eisen die aan dat proces worden gesteld zijn:

  • opleiding om het beheren van debiteuren te begrijpen en uitvoeren
  • ervaring in het omgaan met debiteuren in zowel de organisatie als in verkoop- en incassoprocessen
  • organisatieonderdeel waar het beheer plaatsvindt
  • locatie kan relevant zijn, misschien vanwege specifieke privacy aspecten
  • tijdstip – zowel van de dag (mag het beheer buiten kantoortijden plaatsvinden?) als in relatie tot andere transacties
  • device, want tegenwoordig kan dat ook met een privé mobieltje...

en misschien nog zo wat kwaliteitscriteria waarmee een proceseigenaar kan garanderen dat de verwerking op de juiste manier plaatsvindt.

Bijvoorbeeld dat de uitvoerende niet zijn eigen gegevens mag beheren en dat in het proces nooit twee kritische taken achtereenvolgens door dezelfde persoon mogen worden uitgevoerd, jawel, het beruchte begrip Functiescheiding moet hier worden geadresseerd!

En als je al zoveel kwaliteitscriteria vastlegt, dan is het helemaal niet relevant om te weten wie de taak mag uitvoeren, als die uitvoering maar voldoet aan die kwaliteitseisen. Je hoeft dus niet vast te leggen wie, welke identiteit de autorisaties mag krijgen, je moet alleen kunnen vaststellen dat iemand die de taak moet uitvoeren voldoet aan de vereiste kwaliteitscriteria die gelden ten aanzien van de uitvoering van die taak.

Fundamenteel

Een fundamenteel andere manier van denken. We gaan niet uit van de rol van een gebruiker van een informatiesysteem, maar van de eigenschappen, competenties en context van de uitvoering en van de uitvoerende. En dat zijn dan attributen van iemands identiteit of context. En als die attributen overeenkomen met de vereiste kwaliteitscriteria die in de vorm van meetbare eisen is vastgesteld, dan is er een match en dan pas mag die persoon de taak uitvoeren.

Maar buiten de toevallige match, zou het natuurlijk zomaar kunnen zijn dat iemand die de rol debiteurenbeheer heeft gekregen, ook nog eens voldoet aan de kwaliteitscriteria. Maar dat betekent dan dat al die kwaliteitscriteria op voorhand bekend zijn bij de organisatie die iemand aanstelt binnen een rol: het proces van roltoekenning moet dan volkomen in overeenstemming zijn met het autorisatiebeheer. Ik ben die in dat geval bedoelde werkwijze in de praktijk niet tegengekomen.

Als je dat uitgangspunt van autorisatiemanagement doorgrondt, dan blijkt het wel heel logisch, maar levert dat ook wel vragen op:

Waar komen die attributen vandaan? En hoe weten we of die attributen juist zijn? Laat ik daar een volgende keer dieper op ingaan. Maar uitgaande van een huidige RBAC architectuur kunnen we wel al een migratiescenario van RBAC naar ABAC uitdenken. Want eigenlijk zou het wel mooi zijn als we op een pragmatische manier over kunnen stappen op federatieve toegangstechnieken en single sign-on. En daar hebben we een ‘digitale identiteit’ en ‘attributen’ voor nodig, in plaats van accounts en rollen.

Migratie

Zoals de vorige keer geschreven, is RBAC gericht op het verstrekken van autorisaties ten behoeve van taken die iemand moet uitvoeren. Als we er nu van uitgaan dat iemand die de taken moet uitvoeren al daadwerkelijk aan de kwaliteitscriteria van de proceseigenaar voldoet, dan is te stellen dat iemand die de rol krijgt dus *impliciet* de juiste attributen heeft. Dan zouden we, even pragmatisch bezien, die rol als een aggragatie van attributen kunnen beschouwen. De rol is dan zelf eigenlijk ook als een attribuut te beschouwen. Onze debiteurenbeheerder heeft niet alleen de rol, maar ook is debiteurenbeheer een attribuut van zijn identiteit. De migratie van RBAC naar ABAC is op dat punt puur een technische migratie:

In plaats van inloggen in de applicatie met een gebruikersnaam en wachtwoord, maakt iemand nu verbinding via een federatief protocol, SAML, met daarin een digitale identiteit en een attribuut, namelijk die oude rol. Als de applicatie nu dat bericht goed kan interpreteren, dan is inloggen met een account en autoriseren op basis van een rol, niet meer nodig. Voor de migratie van de applicatie betekent dat eigenlijk alleen aanpassing van de inlogfaciliteit, want het autorisatiemodel wijzigt niet.

Hybride ABAC model

Een dergelijk model is te beschouwen als een Hybride ABAC model. Hybride in de zin dat autorisaties nog steeds aan rollen zijn gekoppeld, maar dat moderne federatieve technologie wordt toegepast. Hybride betekent dat een RBAC autorisatiemodel wordt gehanteerd, maar dat de aan ABAC ten grondslag liggende techniek, namelijk federatie, wordt ingezet. Het hybride model is dus een pragmatische oplossing om over te stappen van de traditionele naar de moderne technologie.

Als je dan toch die kant op gaat, dan moet er natuurlijk aan de huidige architectuur wel een ‘Identity provider’ aan (bijv) Active Directory worden toegevoegd, omdat zo’n component het SAML-bericht moet genereren (denk aan ADFS, simpleSAMLphp, Ping, WSO2 of Gluu). Daar gaan we later op in. Maar volgende keer eerst iets meer over attributen en informatiebeveiliging.