Veel organisaties zijn bezig met RBAC in meer of mindere vorm; verkenning, project, implementatie, vulling of beheer. We zien dat dit gestuurd wordt door normen als NEN7510, waarin voornamelijk staat beschreven dat je moet kunnen aantonen waarom iemand een autorisatie nodig heeft en hoe deze tot stand is gekomen. Inmiddels weten we dat RBAC niet een heilige graal is, maar dat veel implementaties stuk lopen door de te grote scope en complexiteit. We combineren RBAC liever met claim-based autorisaties op basis van workflow, waarbij de aanvragen voor extra autorisaties uit de organisatie komen en daar ook worden goedgekeurd en verwerkt.

Bij de implementatie van RBAC gaat het vaak om de vraag: hoe ver moet je gaan? Een goede start is om te beginnen bij de structuur van de organisatie en deze te verdelen in lagen. Als we een grote gemeente in Nederland (+- 7500 medewerkers) analyseren komen we tot de volgende verdeling:

  1. 25 diensten
  2. 100 afdelingen
  3. 250 teams
  4. 500 functies

Bovenstaande gegevens gelden als we per organisatielaag een dekking van 80% willen realiseren. Er zijn immers veel meer dan 500 functies, maar deze zijn niet interessant voor RBAC, we zijn alleen op zoek naar de top 80%.

Op basis van bovenstaande gegevens kunnen we de RBAC matrix wat betreft rollen vullen voor deze 4 organisatielagen, elk item in de organisatielaag is dan een rol. Je kunt je afvragen of het nut heeft om de functie-laag te vullen, want dan heb je het meteen over 500 rollen. Vervolgens gaan we van bovenaf, dus startend bij dienst, invullen welke autorisaties bij elke rol horen. Op deze manier vult het systeem zich dus steeds verder aan.

Wat we echter hierbij missen is een unieke combinatie van een medewerker. We hebben bijvoorbeeld gedefinieerd wat elke medewerker mag bij dienst X en wat alle medewerkers met functie Y mogen, maar we missen op deze manier een medewerker met de combinatie van dienst X en functie Y. Dit noemen we de sleutelrol. Een sleutelrol is dus een virtuele rol die altijd een combinatie is van organisatierollen. Bij de start van een RBAC systeem zijn deze rollen niet gedefinieerd, maar door links te leggen tussen organisatielagen komen deze rollen tot stand. Op deze manier is het mogelijk om licht te beginnen en het RBAC model steeds verder te laten evolueren.