Role Based Access in the Enterprise

October 9, 2007 by mabatche.

I have recently been thinking a lot about role based access in large enterprises. I have personally been involved in quite a few Role Based initiatives, and I got to thinking.. Given the typical bureaucracy that goes along with a large corporation, and given the somewhat disjointed nature of roles in most organizations, can one actually achieve *true* role based access?

I think it depends on what your definition of roles is.

Roles - The Problem:
The trouble with IDM solutions and Role Based Access, is that every vendor out there tells you.. “Sure, we do role based access.” I have even had a few vendors tell me that they will come in and figure out what my roles are for me, and then work with that.
Where I think most fall short, is that in every large company I have ever been to, they don’t know what their own roles are… let alone have some external entity figure it out for them.
The real problem is that a “role” can be anything a company defines it as. It can be something as simple as pay-grade = ROLE or something as complex as your practice+group+pay-grade+manager-reporting-relationship+tenure+location = ROLE. So, as you can see, I think a “role” is a relative thing.
This trouble around roles is where I think most IDM/Role projects fail.

Technology:
Most companies focus their time on the technology behind IDM/Roles and not enough time figuring out what roles mean to their organization. (I have found myself guilty of this at times).
Technology is great, but in the end when doing IDM projects, the technology is just a means of getting your data pushed around from one place to the other. The data is the truly important piece to the IDM puzzle. If you understand your data, the technology is simple. If you don’t, then you’re doomed to have a terrible IDM implementation.

The Data:
I would venture to say, the most large enterprises have a good idea of what they are paying their employees, but, when asked what their employees roles are or what makes up that role, they might not have an answer.
When creating a Role Based Framework, you have to be able to define what makes up a role in its entirety. So, an example might be and Administrative Assistant, what is needed to fulfill this particular role? A File and Print account? An eMail account? Financial reporting Account? PeopleSoft Account? Special access to Admin databases? A home Directory? Special Access for their location?
- As you can see, a simple role like Administrative assistant can become very complex. Imagine having to do this for a company that potentially has thousands of roles?

This is why I think Roles (as they are talked about today) are not achievable on any kind of scale. While some may disagree with me here, I think if done on a large scale, roles are just too messy this way.

Self Service:
Many IDM vendors are pushing the concept of self-service as a way to help the problem of roles/access provisioning by taking out the middle man and allowing data owners to do their own approval and access granting. I think this is a great concept and can be a good fit in any organization of size. But, self-service has a problem as well.. That is, knowing who the data owners actually are.
Most big organizations have a hard time pulling this off as well. Over the years data owners change, data changes, where data lives changes so if there were owners of the data in the beginning, chances are.. They don’t know who they are now.

Recommendation:
So, if you find yourself working on one of these Role projects at a large shop, before you even start talking about technology you need to ask yourself and the organization the following questions:
1 - Do you already have a rock solid idea of what your roles will look like and what each role *means*?
- Not just what the role name is, you need to know exactly what it means data wise and access wise when someone gets that role applied to them.

2 - If the answer to #1 is no, then the conversation needs to turn away from technology and turn into a matter of exploration to determine if its even possible to figure out what roles are, given current data. Often you will find that given the data, roles are not definable. If this is the case, the the conversation usually turns into.. let’s make up some roles.

I think the right place to be when thinking about roles is somewhere between knowing your roles completely, and providing self-service.
I think that if you can get to a point where you have say, 10-20 general roles out of 1000, and those general roles provide 80% of the people the access they need from day one, then you have succeeded at roles. After you figure out the general roles, then you can add self-service to catch the rest of the 20% that you couldn’t automate in the first place.

So, basically after all this rambling, I think what I’m trying to say is…

1 - Generalize your roles. Being too specific just makes things way to complicated.
2 - Knowing that you generalized, you need to provide a way to make up for the difference. This is where I think providing self-service and workflow comes into the picture.

So, once again, sorry for the rambling.. just had to get it off of my chest.

Posted in Uncategorized | 2 Comments »