Identity management is a pain in the backside
Do you work here? And other important questions
Workshop 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. ®
Identity management a misnomer
Here, what you're talking about is "access management", "privilege management", or whatever you call it. You don't really care about the employee's name, that's just a convenience, but you do care that his responsibilities map with the access he's granted. This is a "positive" mechanism because you pay him to do that stuff, and a "negative" because it should keep people out who should be kept out. In all but the most draconian secret services' systems the "make it work" bit is the most important, because the more repressive the system the more cumbersome it gets and the more it will get subverted, circumvented, ignored, breached, and so on and so forth.
Before talking technology ("biometrics", "tokens", "id cards", and so on), and even before considering privacy (which is usually and wrongly discarded in a corporate context), it would behoove us to consider just what we're trying to achieve.
Who do we trust, why, what are the consequences if that trust proves misplaced because someone overstepped, or got impersonated and they overstepped, what the damage is and how to contain and repair it. Sometimes it's easier to just repair or replace, sometimes that's quite impossible. I'm saying this because it's a hard problem and the assumptions that underlie it might well turn out to be poor ones, so revisiting how we got here isn't a bad idea.
5,000 identities is pretty small
You enterprises don't know how easy you have it. Universities run AAA systems a hundred time larger. We scoff at your mere 5,000 identities.
Seriously, best practice for AAA happens at unis. And the real work in establishing the identity and authorisation mechanisms you'll be using in business is happening there and at the big social networking websites.
Your assertion that automation is not of much value flies very much in the face of what we have learnt. You complain about password reset, but that is something very easily automated.
As for "under the radar" machines, that's a sign that you've made using your AAA system too hard for casual sysadmins to use.
This piece conflates identity with access management (and further confuses authentication and authorisation). I spend quite a lot of time having to explain the differences to business managers (in order to try and stay true to some shadow of our SOA principles). Unfortunately, I find business managers just point to some monolithic "identityandaccessmanagement" product from whichever vendor might have taken them to dinner, and expect it to plug, play and just work off the shelf (of course, none of them do, and so much time is wasted in educating goldfish).