The Dual Nature of a Role
Similar to a butterfly/caterpillar a Role is one thing, with two very different faces.
Why are roles so difficult?
Recently two former colleagues in the IAM Space asked me separately "Why are roles so difficult?". It's a common enough question that I'm surprised that I haven't seen anyone answer. There are multiple reasons and I will address as many of them as I can in upcoming blog posts but I’m going to start by addressing the primary reason why IAM Professionals underestimate the difficulty of an RBAC project: They view it as a software configuration or mathematical exercise.
If you're an IAM practitioner you've likely seen or heard of roles before and the explanation of what they are is simple. They're bundles of access that are granted to individuals when certain criteria are met. This same definition can be applied to any form of Access Consolidation, RBAC, ABAC, FGA others etc... are all combinations of access and criteria that differ only in their numbers and where in the Enterprise software stack they're implemented. You may have even taken a course on how to create roles within your IAM toolset. The technical implementation of a role is deceptively simple, select access, select criteria, publish to test, prove it works and then move it into production.
If the creation of a role is simple, then the creation of roles, the implementation of an RBAC program should be simple also, but If you're reading this you probably already know otherwise. If you're new to this then know that the failure states of RBAC programs are both numerous and likely. A Role is simple, an RBAC program is not, and the single greatest reason why RBAC programs fail is due to a failure to understand that the complexity of creating a role that adds value to an organization is not the same thing as the complexity of creating a role in an IAM tool. One is a software configuration the other is an intra-party agreement between multiple parties within different parts of a business who may have dramatically different objectives, professional viewpoints and professional languages. In terms of understanding the difference between creating a role and a role program a useful analogy is to consider role creation as akin to hammering a nail, whereas an RBAC program is a construction project. You need to learn the former to do the latter, but the latter is so much more.
The simple nature of the role creation interface in most IAM systems hides the complexity required in achieving this consensus and the limited training readily available to cover its usage also hides the complexity behind an RBAC effort. To understand this complexity, you have to realize that an implemented role changes the way in which end-users request, approve and certify access. It changes the professional duties of others in a way that they will have to agree to. That agreement needs to be achieved for every role that is created. A successful RBAC program is not merely a software configuration project, it is also a consensus manufacturing project designed to convince all parties involved to agree to a change that will save their organizations a lot of time and money. Software configurations and consensus building are very different domains and for your RBAC Program to succeed it needs to account for this. You will need to meet with the stakeholders responsible for end users access and ask them to accept your proposed changes to how access is managed, it is worth it but it is also a very different task from what IAM professionals may be used to, especially if they came to their current professions through software development or configuration tracks.
This is what we do at Thornton Data Services. We assist with the creation of your consensus building factory, which includes the software configuration outputs it creates, but it's a lot more than that, there's project socialization, end-user training, review artifacts and review meetings all required to ensure the Role adds value to the organization without adding risk. If you'd like to find out how an RBAC Implementation can help your organization save a lot of time and money, please reach out to me at john@thorntondataservices.com and we'll schedule a free hour consultation to find out if access consolidation is right for your organization.
