The concept of Identity
Management has always sounded very logical, practical and useful from the
start. What’s not to appreciate? Users get one interface for Self-Service.
Approvers get one interface to approve or decline all kinds of requests. The support
team uses one interface to manage all user accounts, on various systems,
whether to unlock accounts or to reset passwords or perhaps even provide
additional services. The whole user lifecycle can be managed from one system,
roles assigned, permissions revoked. The time, energy, effort saved is huge.
The list of good things Identity Management brings is probably endless.
Then why do most
companies struggle to implement a viable Identity Management solution? Is it
the lack of technology? Are the current vendors unable to provide a framework
that addresses consumer needs? Is it difficult to gather the information and
find common understanding across all departments and all application owners? Is
it that converting business needs into a technical implementation is just too
difficult? Or is it all of the above?
Let’s take an example.
Company XYZ wants to implement workflows to request access to applications. In
theory, it sounds quite simple. Anyone who has tried to create the business
rules that support all use cases knows: it’s never that simple. How are users
managed? Who approves on the first level? Does Department ABC follow the same
rules while granting access as Department PQR? If not, then do we set up
different sets of rules for every department? How long will that
implementation take? Otherwise, should we come up with the rules to be followed
from now on, with this Identity Management implementation? If so, will end
users like the change? Let’s face it, although the advent of technology has
made us more accepting of change than before, we still try to avoid it as much
as possible. Things should stay as they were. Many end-users would prefer to
call the helpdesk and request rights instead of figuring out where to go, which
link to click, which application to select from a list, which specific rights
and roles to choose and submit. Isn’t picking up the phone and asking for the
same thing easier? On the other hand, will Application Owners be ok with giving
up the power so that the Identity Management solution automatically creates
accounts for users, if the request is approved? Or would they instead prefer to
know who is getting what access and decide when it is granted? Will they feel
less essential to the functioning of the company if certain tasks can be
automated?
Let’s take another
example. If Company XYZ has 50 departments with over 500 different job titles
and or job codes, how many Business Roles should be created that cover at least
80% of the employee’s rights and permissions across the 100 applications used
most frequently by the employees? Of course, all vendors now provide features
where one click of a button and these roles are generated automatically; the
data is mined in the most practical way. It will even suggest new roles if new
rights and permissions are detected. But how do you get the most accurate data
from all the applications, and create these roles when many definitions change
regularly, the data is not of good quality and there is no pre-defined set of
rules or logic that decide when and why a user should be given a set of
permissions?
Of course, there are
hundreds of successful IdM implementations, there is no denying that. But can
those implementations truly be called successful? More importantly, do those
implementations continue to be successful? Is manual intervention still needed
at several points during a user lifecycle? Are they able to keep up with the
growing company needs?
Since there is a lot of
talk about the cloud these days, it’s very likely that many companies will want
to use IaaS (Identity as a Service). However, moving to the cloud still does
not solve the basic problems faced by any Identity Management implementation.
What are your thoughts? Is implementing an Identity Management solution
challenging for you?
