Roles are dead. Long live roles!
I was working on role engineering (and the precursor to the more glamorously named AI lead entitlements analytics) 15+ years ago and some common well worn themes were emerging even back then:
- beware there dragons (and role explosion)
- finding role “owners” was tough
- applying role descriptions was tough (and causes the issue above..)
- it was easier to create new roles than manage existing ones
- role and entitlement reviews lacked context
- due to the lack of context ^^ entitlement reviews were “check box”
- role model tied tightly to business structure – making change fragile and “breaking”
These issues still exist. Ask any large programme owner for RBAC. Simultaneously ask any programme owner for IGA and ask a 50/50 question “is your project in distress?”. That would be an interesting poll result. So why are roles and role based access control so bad? Well that perhaps is not the right question, but the above consequences of particular RBAC projects are well known and have resulted in cyclical re-engineering of entitlements management platforms in many medium to large sized organisations.
Roll forward to 2023. Many organisations have faced significant technological, social and competitive challenges in the past 5 years. Digital transformation. Building online communities with consumer/customer identity (and all the complexity of privacy preservation and compliance…). The Covid-19 pandemic altering how we worked – literally overnight. Increased interdependence between organisations with complex supply chains and joint-ventures now common. How can RBAC fit into this modular and agile landscape?
The Cyber Hut in one of our community polls asked the question “Which Identity Component Will Die in 2023?“. We did this in January 2023 and 105 responded with the following result:
So RBAC came 3rd out of four. Not bad going. Many clearly thought on-prem directories were closer to the technological cliff edge than our trusty roles. However the results perhaps don’t indicate the entire picture here. OK, roles have issues, but they are a) a known entity and b) can command a large collection of best practices, consultants and support network. These things are important. In the last fifteen years there have been numerous different approaches to authorization start to emerge. Not all of these are replacements for RBAC, but certainly take on access control use cases in various different guises. So we have started to think about:
- API access control with OAuth2
- Claims based access control based on OIDC id_tokens
- ABAC – attribute based control using both identity data for the subject and data labelling attributes on the object
- PBAC – policy based access control with centralised management and distributed enforcement
- ReBAC – relationship based access control based on graph technology to provide more power with respect to how to traverse access linkages
- OPA – open policy agent, whilst not a standard, has proliferated the infrastructure access control space by being open source and lightweight
- Zero Trust! – been a while since this buzz word was mentioned (drink!) but ZT has a huge reliance on identity and authorization and organisations are catching up to the fact that authZ is cool again.
So most organisations are likely using one or more of the above approaches to access control – not to mention home grown solutions and other more esoteric concepts. So are any of the above in a position to take the crown as the industry’s most hated/loved access control model?
So in early July The Cyber Hut turned to the community again asking – “Which access control model is your organisation using?“
So again the poll is limited – and perhaps leading the witness a little – but RBAC is still by far the leading access control model being used. The remaining alternatives essentially jockeying amongst themselves for 2nd place. Why so? A few things to consider. Firstly RBAC has been around a long time. Yes it certainly has some issues, but equally that may also be a result of the vast number of projects that have or are using roles in some way. Whilst ABAC is arguably just as old, it seems many organisations are not using it in vast numbers. Why so? Perhaps complexity to get started, but perhaps more likely it also requires similar detailed knowledge of business processes and data governance requirements for it to be successful.
More recent approaches such as PBAC and ReBAC are likely just not as well known – from both a technical perspective as well as how well they can be integrated into existing business structures, personnel and workflow points of view.
So where does this leave us all?
So RBAC has a bad rep. Role explosion and governance issues are costly to repair and re-engineer and often lose sight of the business problem being solved. However, alternatives such as PBAC and relationships, very likely require roles as a foundation. By switching the focus and success criteria of the role model may well actually see its position in the business value chain change.
Think of this a little like the ageing football (yes football not soccer) centre forward instead of retiring entirely, merely drops deeper into midfield with support coming in the form of pacey wingers to help them out. Their role (pun intended) changes. Instead of trying to score all the goals, they score some goals and set up others for success.
Can RBAC play this position? By perhaps measuring success in a more coarse grained way (linking users to business functions for example) and overlaying with attributes, graph analysis context, managed by policies can roles actually be a powerful tool for managing business change? Instead of RBAC having to handle the mass minutiae of fine grained entitlements association as well as real time context (both of which drivers for role explosion and make access reviews cumbersome..), move the more exotic, agile and complex use cases to other technologies that are more well suited.
The above is just an example and doesn’t get into the world of authorization enforcement (the PEP world) which is likely to be distributed, engaging with a multitude of asset types (see APIs, microservices, cloud, IoT, data..). But we can start to see how by leveraging more specific access control features and tooling can actually take the pressure off the RBAC model. Let RBAC do the coarse grained (perhaps 80%) and allow the last mile fine grained (20%) be handled differently?
Pulling out roles entirely for a large (or even medium) sized deployment is unlikely to be signed off. Maybe just let the big old RBAC dog sleep in a slightly less energetic position?