Enterprise IDM: Part 3: Roles

11 Nov 2005 While deciding for the Enterprise Identity Management prject, the order that the role-based access control promises seems to be one of the most attractive bits for the customer. It looks like all the current chaos will yield place for the role-imposed order. And order is good, isn't it?

You, as an implementer has it quite easy: the composition of roles is a customer's task. You cannot possibly see to all the nuances of department organization to set it up. But if customer is willing to pay an enormous pile of money, you can do it anyway. Am I right? :-)

But it is a whole different story for the customer. When he starts to design the roles, the underlying chaos will be uncovered. Bit by bit. There are employees that should do the same work (and therefore be in the same role), but they differ in one little privilege. And business unit will argue to the death that it is exactly the way as it should be. Well, to keep it clean, you create two roles. And then there are employees that have access to lots of different systems. You create a role for each of these systems, to keep it systematic. And there are employees that do not fall to any category ... and all that is multiplied, if you want to keep your role design clean and build a role hierarchy.

You will soon realize, that you have two or three times the number of roles than the number of employees. Now, it looks like you would spend all your effort on role-maintenance instead of employee-maintenance - the role system as just as dynamic as is the employee base. That's pretty different from the solution as it was described by sales people: "you will just assign an employee to the role and that's it". But, there are ways out of this. At least partially.

The first option is to get a harmonic agreement. You may try to negotiate the role structure with business units. But the outcome may vary. You may end in the endless war with business units that will help noone. Or you may end up with roles too broad - each role will have a lot of unnecessary privileges. That will contradict the minimum privilege and need-to-know principles. I have heard about the extreme, that each system has only three roles: administrator, poweruser and user. This can keep the management overhead to minimum, but how it goes with the security policy? But even that may be worthy. I hear the words "business first" much too often.

The second option is to leverage the power of human resources department and company organizational structure. You may create a role for each work position. Assign employees to these roles automatically and manage only the roles. If someone wants to add a privilege, he must ask to add this privilege to his work position, not to him personaly. And you may set up work processes to make this process harder to achieve by creating a maze of reviewers and approvers. The people will think twice before they embark on the process of changing the role structure and you will get only the "serious" requests. If you have "standardized" organization, where most employees has well-defined positions this may work for you. I have reports from medium-sized companies that this approach works quite well. But to initialize this mechanism you will need to make some kind of "brutal bootstrap", the kind of "great chinese revolution" approach. On the day zero-1 all works in old, chaotic way. During weekend, on the day zero you will change the system and disable all the "old ways" of doing things. On the day zero+1 all works the new way. Guess what happens? (Hint: you should better chcek that the helpdesk is oprating, well staffed and motivated). Very risky approach.

Or there is a third way. Load all your existing employee data from all of your systems to the centralized store. Try to figure out which account belong to which employee using some kind of reconciliation. If you get the reconciliation rules right, you may get as high as 80% success ratio. Once you have all the accounts in the store, you may start to analyze them and slowly create the roles for employees with similar privileges. You may enlarge the role when it feels fine, or call the affected employee and talk with him if he really needs the "exceeding" privilege. Sooner or later, you will end up with a structure that is role-based with a handful of exceptions. This looks like ideal approach, but .... it takes ages. Even if you have 80% success ratio with reconcilation, it still leaves a lot of accounts (20% of the average number of users per system times the number of systems) that are not reconciliated. And that number can be very high in large and/or complex enterprises. And that's only the beginning. Try to sort out who whould belong to what role manualy. Really hard and endless work. But this approach does not disturb the business in any significant way. And hence it may be worth considering.

No moral this time. I must admit that I do not know the exact solution, if any exist at all. I feel that in practice we will need the combination of all three approaches. Or maybe entirely different approach. Maybe the rule-based mechanisms will behave better that the role-based? But who can tell? All IDM projects around here are too young. This kind of role-related issues takes a long time to reveal their real results.

Does anyone really knows the answer to the "Role Explosion Problem"? Any insights appreciated.