RolesDuring our advisory services engagements, the topic of role management always comes up as one would expect, and it quickly turns into a room divider. Some clients consider role management as a utopian approach to identity management that consumes multiple cycles yielding limited results; others passionately embrace it, often to the point where it conflicts with taking action in other Identity and Access Management (IAM) initiatives that could derive immediate or greater value.

So I figured it would appropriate to state an opinion on this topic.  But rather than writing yet another article on role management, a topic that has really given analysts and other bloggers (some of which are really good) a big canvas to get creative with, I would like to take a “from the trenches” approach based on my experience in the Role Management space.

Why Roles to Begin With?

So why should we care about roles? Why do we need to introduce yet another buzz word into the IAM space?  Aren’t we happy with identity federation, federated provisioning, etc.?  The reality is roles have been one of the oldest topics in the IAM glossary.

Are you familiar with the term RBACRBAC?  This concept has been around a security construct for application development since 1992.  Some may recall (or God forbid have even read) NIST’s RBAC model in 2000.  The unfortunate fact is while extremely elegant and necessary, roles were, from the onset, characterized as complex and difficult, and were not really conceived with identity administration in mind.  This stigma has remained through present day.

From my viewpoint, roles are an essential construct in any IAM initiative – whether one formally admits it or not, that helps organizations scale administratively as the number of users, individual entitlements or access rights grows; often exponentially over time. Role management is just managing user authorization data.  How many entitlements or access rights exist in your organization? Thousands? Millions?  Do you really think you can manage millions of correlations in a spreadsheet or in your head?

So, allow me to philosophize; from a Cartesian perspective: roles need to exist simply because at some point, people (administrators) can no longer keep track of all of the various access right permutations possible given an ever growing universe of entitlements and individuals.

From this basic notion, you can start to derive more business-oriented variants of the same idea, and spin it; - something that the IAM industry as a whole has done very well - to the extent that now, there is confusion about why we needed roles to begin with.  You may have heard of roles as being needed to provide the ability for business stakeholders to map defined business functions to logical and physical access definitions, or roles being necessary to detect and resolve Segregation of Duties (SOD) violations that arise by assigning conflicting access rights (according to business rules) to the same individual, and so forth.

Another important fact is most applications (at least commercially available Enterprise ones) have been developed with RBAC in mind.  Hence, organizations trying to manage access for their user base will need to account for this, particularly if they have deployed an ERP system with thousands of access rights (often referred to as roles, entitlements, responsibilities, etc.)

So based on the facts above, one should conclude roles are a necessity for any IAM initiative.

“No way! We don’t want to do Role Management here, we aren’t ready…”

Ever hear this? …By now, I may have lost half the readers of this blog – which means you are either a family member or a co-worker feeling guilty for not supporting me.  Thank you, I appreciate your support ;-)

Seriously though, in my opinion, organizations that make statements like the one above typically mean that they have not yet derived a formal role management approach for managing accesses, and that implementing a role management system will be too daunting and cost-prohibitive, and that they would be better suited by delaying any role management initiatives.

That makes a lot of sense, but let’s face it, organizations are in the business of role management (just as much as they are in the business of managing users) whether they like it or not.  And, as organizations grow and evolve, the business of managing access gets more and more challenging.  Therefore, I believe that organizations are better off admitting role management is inevitable from the onset.  Once a consensus for this has been established, energy should be spent on how to formally tackle it as part of an overarching IAM roadmap.

Some Symptoms that Reveal the Need for Role Management

User Cloning

Here are some common symptoms that expose the need for role management, derived from experience:

  • As part of your on-boarding or access request process, the requester, typically a manager, makes requests that reads “Please setup Mike with the same access rights as Tom” – some organizations have a “user cloning” option in their access request process (or system).
  • Your business users complain that requesting access for someone is too complicated and daunting, since they need to write down or select specific options to give the user access, gibberishwhich is in some sort of gibberish or cryptic language that cannot be understood.
  • Another symptom is if you suffer from access accumulation syndrome (an auditor’s favorite): users accumulate more and more access rights during their tenure with the organization, and there is no way to remove previous access that’s no longer required.  Unlike good wine, this problem does not get better with time. You can validate this by asking the member with the longest tenure in a particular business function to inventory what he/she has access to, then repeat the request for the person with the shortest tenure who performs the same business function.  If they differ substantially, then you might benefit from a role management system.
  • A different twist of the previous symptom (and also an auditor’s favorite): when someone changes departments, you do not know whether you effectively removed all of the access the person no longer needs.
  • As a manager, you have a contractor on your team that needs access to a system, but you are not sure if contractors are allowed access to it.  In this case, you may be able to submit the request, but you don’t know whether it will be approved or not.

In Part 2 of this 2-part article, we will provide and discuss some practical suggestions on how to approach role management without breaking the bank.


Frank Villavicencio

Frank Villavicencio