Identity management is a pain in the backside

Identity management in the corporate environment is complex – not to mention, at the coalface, a pain in the backside.

In the real world in which you work, password resets are one of the most commonly cited causes of help desk stress – and that’s an identity management problem. People leaving the company and still having access to corporate systems? An identity management problem. Users stumbling onto a fileshare and finding a salary spreadsheet? Careless exec lost a phone and needs a new one? Identity management problems, both of them.

We can debate what exactly identity is, but in corporate environments things are relatively mundane: any person working for a company needs access to systems and services, which should be provisioned accordingly. As the person changes roles, as systems change and new devices get deployed, access rights will need to be added, revoked and modified.

Given that none of these challenges are particularly new, it would be comforting to think it was all sorted by now. A few years ago we conducted some research into system access, password control and provisioning. The scale of the problem was starkly illustrated by Figure 1 below, which showed how many applications users needed to access.

We asked what identity management might look like by now. At the time we predicted how much easier it would be when we stopped using passwords and upgraded to multifactor techniques in general, and biometrics in particular (Figure 2).

Perhaps you have done this. If you have, tell us if it has solved your problems, because most organisations have not. Meanwhile the complexity of identity management has increased – organisations are more distributed, data volumes are rising, and users expect to access more applications in more places. It’s a brave new world we’re heading into, but we’re riding on the same old, creaky ship.

The first step towards successful provisioning is to know what should be provisioned, and to whom. There is a triangle of relationships between people, the roles they occupy, and the systems, information and assets they are authorised to access, because you cannot authorise anything without defining who should be authorised, and why.

In the real world, we make assumptions. Most organisations have more assets in use than they formally know about; many deployments take place under the radar, without the IT department being aware of them. If you are not on top of this, you can’t reap the benefits of provisioning.

Second, provisioning is, by its nature, event-driven. From the “people” perspective, someone joins or leaves the company, or a changes role; meanwhile, from a systems-and-service perspective, this require modification to who needs access, and to what.

Third, provisioning is a process, not a one-off operation. You need someone who is responsible for putting reporting lines in place, conducting regular reviews, revisiting and even culling old access rights if you want a sustainable, process-driven approach.

It would be ideal if these problems could be automated away, but they can’t. Tools can help, but not if you don’t take into account best practice principles such as these. The goal posts never stop moving, and identity management becomes more complex – so if you want to slay your provisioning demons, be prepared for a long battle. Otherwise, back in the real world, they will just return to bite you on the backside.