Van RBAC naar ABAC deel 4

Hier met die attributen!

In de vorige blogs (deel 1, deel 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.

In bovenstaande afbeelding zijn verschillende migratiestrategieën te zien:

- Traditioneel wordt ingelogd met gebruikersnaam en wachtwoord (die in de Usertabel van een systeem worden beheerd).

- Als de applicatie dat toestaat, dus als er een serviceproviderfunctie is toegevoegd, kan op diverse punten toegang worden verleend. Als in het SAML bericht alleen een gebruikersnaam staat, kan gebruik worden gemaakt van Single Sign-on. Als de applicatie de mogelijkheid biedt, dan zou ook de ‘RBAC-rol’ in het systeem in het SAML bericht worden opgenomen. Dat betekent dat de applicatie die niet zelf hoeft af te leiden: hybride ABAC.

- De meest geavanceerde optie is dynamische autorisatietoewijzing op basis van ABAC. Dit vergt wel een applicatie die dit model ondersteunt, een applicatie die gebruik kan maken van externe kennis, externe autorisatieregels.

De volgende keer gaan we dieper in op de techniek van de IdP en de SP. En proberen we de roadmap verder in te kleuren.