Redactie - 23 oktober 2016

Van Role Based access Control naar Attribute Based Access Control

In de vorige blogs (deel 1deel 2 en deel 3) is aan de orde gekomen dat het gebruik van Rollen voor autorisaties niet het meest gelukkige is en dat we eigenlijk een ander mechanisme moeten gebruiken. Namelijk op basis van kenmerken van een gebruiker, toegang te verlenen aan een gebruiker. Het principe van ABAC (Attribute Based Access Control). Omdat effectief inzetten van ABAC herbouw van het applicatielandschap vergt, is het hybride ABAC model een pragmatische oplossing: de bestaande rollen kunnen in de vorm van attributen in een bericht worden verwerkt.

Wanneer het ABAC mechanisme wordt gebruikt voor het verstrekken van autorisaties, dan moeten die attributen wel ergens vandaan komen. Er is een ‘attribute provider’ nodig. Gelukkig hebben is die in de meeste gevallen al aanwezig wanneer wordt gemigreerd vanaf een RBAC situatie. Bij RBAC wordt gebruik gemaakt van Rollen om aan mensen autorisaties te verstrekken. Dat gebeurt natuurlijk al in de systemen waar mensen in werken, maar de rollen die medewerkers hebben, worden in de praktijk vooral al in de brom van groepslidmaatschappen binnen Active Directory vastgelegd.

Active Directory is een interessant fenomeen. AD vervult heel veel taken in een infrastructuur. Het is natuurlijk een directory, een register waarin alle gebruikers zijn vastgelegd en waarin van elke gebruiker verschillende kenmerken (‘attributen’) worden bijgehouden. Een directory is vooral bestemd voor het snel opzoeken van gegevens, de belangrijkste eis een een directory is dan ook het snel kunnen uitlezen. Het belangrijkste protocol dat daarvoor wordt gebruikt is LDAP (lightweight directory access protocol).

Maar AD is niet alleen een adresboek, het is ook een authenticatieservice: als iemand inlogt in Windows, dan worden de inloggegevens gevalideerd binnen AD: de versleutelde wachtwoorden en ook eventuele certificaten worden opgeslagen in de AD. Daarnaast bevat AD-autorisatiegegevens: toegang tot alle resources binnen het Windows platform wordt beheerd binnen AD: printers, computers, modems. Van al deze componenten is AD het beherende component. Een druk baasje, die AD en er zit steeds meer functionaliteit in.

Voor ons doel is dat lang niet allemaal nodig, maar sommige gegevens kunnen wel worden gebruikt om attributen uit af te leiden, de AD kan als een Attribute Provider (AP) dienen. En dat kan, omdat in RBAC-situaties de ‘rol’ die mensen binnen een organisatie krijgen, in AD kan worden vastgelegd. In de meeste gevallen gebeurt dat door accounts lid te maken van ‘groepen’ binnen AD. Medewerkers kunnen zo lid worden van de groep AG_AFAS als ze voor personeelszaken toegang moeten hebben tot AFAS. AG_ staat in dit geval voor Applicatiegroep. Dit een een veel gebruikte indeling binnen AD. Er zijn nog veel meer groepsindelingen denkbaar, maar er bestaat nu vast wel een beeld van waar we naartoe gaan…

Onze migratiestrategie is dus het omzetten van rollen naar attributen binnen een SAML bericht. Wat daarvoor naast de rol (die in AD kan worden beheerd) nodig is, is een Identity Provider (IdP). Dat is een component, een verantwoordelijkheid, een proces, waarmee onder andere een SAML bericht voor een Service Provider (SP) wordt gegenereerd. De IdP moet voor een gebruiker in de AD de kenmerken voor die gebruiker opzoeken en, volgens bepaalde afspraken, die kenmerken opnemen in een SAML bericht. Dat is een XML-formaat tekstbestand, waarmee security gerelateerde gegevens worden gedistribueerd. SAML staat voor Security Assertion Markup Language. Dat wil zeggen dat de beweringen (‘claims’) in het bericht door de IdP zijn gegarandeerd. Als de SP nu maar de IdP vertrouwt, dan zal de SP de beweringen, de claims ofwel de attributen, kunnen vertrouwen en dus ook gebruiken.

Laten we de casus even uitwerken. Het ERP-systeem van een organisatie is een systeem met een eigen gebruikersdatabase en een autorisatiemodel dat is gebaseerd op RBAC. En laten we voor de goede orde aannemen dat om dat systeem een schil is gebouwd met een API-service die SAML berichten kan interpreteren, de service provider. Het ERP-systeem kent verschillende bedrijfsfuncties die via de SP ontsloten kunnen worden, zoals een klantbeeld en een salarisbeeld.

Stel gebruiker Alice wil de business service ‘Salarisbeeld’ bekijken. In dat geval zal de SP aan de IdP vragen om het rolattribuut op te leveren op grond waarvan de SP die service beschikbaar zal stellen. Als de IdP bij Alice kan zien dat ze lid is van AG_AFAS, dan zal de IdP dat kunnen vermelden in het SAML bericht. Dat gaat natuurlijk niet altijd zomaar, want de SP zal vermoedelijk niet de naam AG_AFAS gebruiken om de autorisatie te verstrekken. Misschien moet iemand lid zijn van de rol Salarisverwerker om die autorisatie bij de SP te krijgen. In dat geval zullen de SP en de IdP in een afsprakendocument vastleggen dat de IdP het rolattribuut Salarisverwerker in het bericht opneemt. De IdP zal vervolgens het groepslidmaatschap AG_AFAS moeten vertalen in Salarisverwerker in het SAML bericht. De SP zal het ontvangen attribuut Salarisverwerker weer moeten projecteren op de autorisatietabel in het ERP systeem.

Het rolattribuut moet dus in het SAML bericht terechtkomen. Maar dan moet de groep AG_AFAS wel in de Active Directory zitten en moet Alice lid zijn van de AG_AFAS. Gelukkig is dat niet het grootste probleem, dat kennen we al heel lang, dat kan via de reguliere provisioning vanuit een IAM oplossing gerealiseerd worden. We moeten er alleen voor zorgen dat de rol ‘Salarisverwerker’ (die binnen het ERP systeem gedefinieerd is) in het IAM rollenbeheersysteem beschikbaar is en dat in het IAM systeem Alice aan die rol kan worden gekoppeld.

Door: André Koot, Lead IAM en Security consultant bij Nixu Benelux

Copaco | BW 25 maart tm 31 maart 2024 Trend Micro BW BN week 10-11-13-14-2024
Copaco | BW 25 maart tm 31 maart 2024