Who’s Who in the Zoo? Roles Management as the Key to Identity, Access, and Compliance

I may have a tendency to oversimplify things, but doing that can often give you the clarity you need to understand them.

Take “identity management” for example. Sometimes when people use the term they really mean identity and access management. Sometimes they’re thinking of it specifically in terms of compliance. Sometimes they’re thinking of it in terms of provisioning or whatever.

I think that identity management and all the things that go along with it really boil down to “roles management.” And to take that a little further, even though there are “role manager” systems out there - we even have a “roles-based” provisioning product - I don’t think that roles are primarily about technology.

At its core, role management is about relationships; it’s not just “Who am I?” but “Who am I to this organization?” To some companies, for example, I’m a vendor because I sell Novell solutions. That’s the relationship I have with them. To Novell, I’m an employee. To Skype or Salesforce or NetFlix, I’m a customer. These relationships define my role in this or that organization and my role will determine what I can and can’t do within their ecosystem.

Roles are the fabric of the enterprise and figuring out the roles and building out the policies that govern them has to happen before you implement any technology whether you call it identity management, access management, or even roles management.

Unfortunately, when companies started investing in identity management five or so years ago, I don’t think many realized this. The end result was that they purchased a system that they thought would solve a lot of different problems for them - problems which have just gotten bigger, by the way - and it didn’t turn out as they had envisioned it. Why not?

I think part of the reason that these systems didn’t necessarily live up to the hype was that organizations thought about identity, access, compliance, etc. as technical problems. Based on that, they ended up assigning a project manager or someone in a similar role to oversee purchase and implementation and basically missed the whole roles piece.

But roles are central to this issue and they are not technical in nature. In fact, the question of “Who has access to what when?” has to be answered by the business and the whole process of defining roles and then assigning privileges based on them can get very political. It’s too much to ask of IT, in my humble opinion.

To illustrate my point, consider this analogy. In a hospital, you have multiple roles and in terms of hospital operations, its pretty clear who can do what. Doctors can operate, orderlies can’t. Nurses can administer meds but people in admitting can’t. The whole set-up is very hierarchical.

On top of this hierarchy, you have regulatory requirements like HIPAA and someone has to figure out how to make the hierarchy work within regulatory and other constraints (which might mean telling a doctor, “No, you can’t access patient records via your Blackberry while you’re riding the subway”).

Now, you’ll notice that I haven’t mentioned identity or access or any of that stuff, which is my point. Roles and privileges come first. Technology enables you to do pretty powerful things in terms of automating these roles and privileges, but it cannot create them. The business has to take care of that.

Which is why I say that roles management is the key to successful identity management, access governance, and all the rest of it. You tell me, am I just oversimplifying things?

| Follow us on Twitter | Follow us on Facebook