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?
Never miss an update by following us and subscribing to our monthly newsletter!