Dit blog is een onderdeel van de ‘Van RBAC naar ABAC’ serie. Eerder werden deel 1, deel 2, deel 3, deel 4 en deel 5 gepubliceerd. Het is aan te raden deze delen eerst te lezen voor verder te gaan met onderstaande tekst.

Afspraak

Een flinke bevalling, zo’n migratie bedoel ik. Het hybride ABAC model is een bruikbare methode om van een traditioneel applicatielandschap te migreren naar een modern federatief stelsel. Een belangrijk ontwikkeling is de steeds verder gaande decompositie van de toegangsfunctie. Waar traditioneel identificatie, authenticatie en autorisatie in een enkele applicatiecomponent werd afgehandeld, worden deze functies nu niet alleen uitelkaar gerafeld, maar wordt de autorisatiefuncties zelf ook nog verder uiteen gedecomponeerd. Hierdoor wordt het applicatielandschap extreem schaalbaar. Je kunt identiteiten van veel verschillende partijen toegang bieden, authenticatiemiddelen loskoppelen van het beheer van identiteiten en autorisaties afhankelijk laten zijn van allerhande in- en externe attributen.

Maar je moet dat stelsel wel vertrouwen. Niet elke identiteit is even betrouwbaar, niet elke identiteit mag dezelfde functies hebben. Daar moet iets voor geregeld worden, een afsprakenstelsel. En de partij die daarvoor verantwoordelijk is, dat is de Service Provider, die zich, min of meer, kwetsbaar opstelt. De SP moet immers de identiteiten (en attributen) van derde partijen vertrouwen. Het lijdend voorwerp, de SP, is leidend.

Bij een relatie hebben we dat stelsel, een federatieconvenant genoemd, in de volgende componenten gedefinieerd:

  • Aansluitvoorwaarden – onder welke condities mag een IdP aansluiten. Daarin worden niet alleen de definities van de dienst bepaald, maar ook de uitgangspunten waaronder identiteiten vertrouwd kunnen worden. Zo moet de IdP een betrouwbaar In-, Door- en Uitstroomproces hanteren.
  • Dossier Afspraken en Procedures – hierin wordt geregeld hoe IdP en SP met elkaar omgaan: Wie zijn de contectpersonen, maar ook hoe zijn processen als Change Management ingericht. Hoe worden bijvoorbeeld nieuwe rollen binnen de SP component toegevoegd een beschikbaar gesteld aan de IdP partij, of door de gebruikersorganisatie bij de SP aangevraagd.
  • Gegevenscontract – syntax en semantiek van de attributen in de SAML-berichten en Oauth tokens. Maar ook onder welke condities kan een IdP een rol toekennen aan een gebruiken. Denk aan afspraken rondom functiescheiding en kwalificaties van de gebruikers. Niet onbelangrijk is de vaststelling dat niet elke IdP dezelfde functies van de SP mag gebruiken. De SP moet dus weten wat de IdP is van een gebruiker en moet dus kunnen vaststellen welke rollen of autorisaties voor de betreffende gebruiker beschikbaar zijn.

Besluit

Het was een langere serie artikelen dan van te voren gedacht. En eigenlijk is er nog veel meer te zeggen over de migatie van RBAC naar ABAC. We hebben het niet gehad over federatie en identity proxies en federatie services. Maar eigenlijk is deze serie artikelen nog maar een begin om eens na te denken over de mogelijkheden om te migreren naar een moderne en beter passende methode van het op een gecontroleerde manier van verlenen van toegang. Prettige reis naar een nieuw applicatielandschap gewenst!