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.
Responses (0)
A friend of mime has an interesting problem. He provides pre-paid services
and wants to give away free accounts with small credit to allow people to
test the service. To keep the cost down, he wants to bring up a
self-registration web form that will automatically create the account.
And the problem is: how to stop users to sign for a test
account ever again and again and thus abuse the "free sample" service?
I've recently found Dan Blum's