Migrating from RBAC to ABAC (Part 1)

A long time ago I wrote the following statement on my LinkedIn profile: "RBAC is EOL". And in my not so youthful overconfidence I mentioned this during an intake with a potential customer, who asked me how they could introduce Role Based Access Control (RBAC) as conveniently as possible. That talk never materialized into an assignment…

‘RBAC is EOL’ clearly was a premature statement. I must admit Role Based Access Control is far from End-Of-Life. Rather, in practice, we see RBAC becoming more popular and we see more and more organizations starting RBAC projects. Following on the heels of financials and government, other industries are becoming aware of the need to address authorization management. IAM projects and RBAC solutions are increasingly embraced and most of the major information systems, such as SAP, Oracle EBS, CODA, EPIC, Salesforce, Chipsoft, have been built in such a way that RBAC is the de facto authorization model. RBAC is a well-known, but not well understood, way to think about authorizations and access control. Surely I can help customers with that, of course ;)

Why on earth do we use RBAC?

RBAC promises to be a simple access control model, but it’s very difficult in theory, here’s a link to the original NIST publication: http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

But also in real life RBAC is very complex. Let me explain why RBAC should be EOL.

First let me explain why we use RBAC: Ease of operation.

Yes, really, that's really the only reason that we use RBAC. It is an easy understandable method to grant access to read a file, a record or to allow access to a location for a person. It’s also easy to control access: you can find out if a person has access, you may well be able to explain why that is the case and whether the granted access is correct.

Because of use of the concept of a 'role', we can disconnect an 'authorization' from a 'someone'. That saves a lot of administration. If two employees have to perform the same tasks, they need to have the same authorizations. If we give both persons the same ‘role’, then they have the same permissions, at least if the permissions that are required for execution of those tasks are bound to that same role. If someone else is assigned the same role, that person will also get the same permissions. So it's really a lot easier to grant permission by assigning roles than to provide the individual authorizations to everyone separately. We start having problems when there are roles within roles, nested roles: In that case it’s getting foggy what authorizations a person effectively has. The best thing about direct assignment of authorizations is that it’s much easier to show what permissions someone has effectively. You can tell right away after all. Not that we gain much insight because after all, we still have to interpret all these granted permissions once again for every individual assignment of authorizations. Role management does make life easier.

But by just managing roles we’re not done yet. On the contrary. There is not one single type of role, there are different kinds of roles and different levels of roles and of course there are nested roles. There are roles in an organization and there are roles in applications. No, these are not the same!

There are lots of roles in an organization. And there are also positions in an organization. Positions in an organization result in a view of an organization for providing a wage to employees and it a position is created in the hierarchy of an organization. But roles are a view on combined activities within an organization, our way of organizing authorizations. It may look like a position, but it is not.

And here the difficulties start. Is there a relation between a position and a role. Is there a hierarchy? Can people have more than one position and more than one role? Can roles be shared between departments? And do all identical positions result in the identical roles? So, as you can see, the easy concept is getting a bit less easy.

In RBAC, roles are assigned in order to grant authorizations to perform certain tasks. Roles are in fact a set of tasks carried out by a person. A credit manager uses the financial system (the debt management part of course), Office365 (the share of his or her department perhaps?), the intranet, perhaps a module in a CRM system. In addition, a credit manager must have access to the sales administration, e-banking environment, the general ledger. But there are other roles with overlapping authorizations, roles for people that have an almost similar set of applications, but with different access within. That means that an authorization cannot be related to a single person. Here the perceived advantage of RBAC disappears.

Tasks

Now, who decides which tasks our staff with the role credit management has to execute? The hierarchical manager of our employee. And perhaps there’s also a process owner. But these managers have a different focus… the line manager obviously wants optimal performance within his department, but the process owner has different requirements, such as competent, capable and high-quality staff and separation of duties within the process. This can result in conflicting interests. A line manager wants to perform as many operations with a full occupancy, but the process owner wants a high-quality high governance process.

However, there is still another important player: the system owner. The line manager may well want an employee to perform various tasks, but that collection of tasks should be supported in the information system in the same way. What if the role model developed in an information system conflicts with the organization roles and process roles? This is not a theoretical issue, this happens every day in every organization.

Authorizations

Last but not least: what effective authorizations are there in a role? Employees in AGSAPAX-IAM-DEB-Linux-WS seems to get access to GRXACZP-LEDG02Q-File Transfer-RW. Is this? Who knows if this access rule (the kind you see in a lot of Excel sheets) is permitted? And is this authorization granted explicitly or implicitly? Who's in that group? Is that correct? Is that authorization still accurate and up to date? Is the authorization not too broad? How much do these rights cost? Who granted such access rights? Who linked these authorizations to the role? Has this been approved?

In my experience there are dozens more of these question. And they all lead to the same conclusion: the RBAC model may look like a practical access management method, but it is not. There are so many complications that have to be managed, that it’s hard to be in control.

Done with complaining. What are we going to do about it?

In part 2 in this series we start migrating from roles to attributes, my holy grail and I’ll introduce a hybrid ABAC model.

(this blog first appeared in Dutch at https://www.cqure.nl/kennisplatform/van-rbac-naar-abac-deel-1)