Talking Identity

It has been quite a while since my last post. The period coming out of Catalyst is always busy, as it tends to generate a lot of good discussion that starts influencing the work we are doing. I have been neck deep in discussions over the future of our product offerings, so this has been the first chance for me to come up for some air. Take it as an indication of how much work we are doing at Oracle to solve your identity management needs.

Though late, thought I would share some of my thoughts on this years Catalyst conference. The week always generates interesting dialogue about what is going on and where the industry is (and more importantly, should be) heading. As expected, a lot of attention in the IdPS track was devoted to user-centric identity. However, two sessions that impressed the most were ones that tried to slow down the juggernaut that is user-centric identity by asking some extremely relevant questions.  These were Mike Neuenschwander's session on "Thinking Outside the Domain", and Bob Blakley's talk on "Idenity and Community in Human Society". The latter was particularly though provoking in how, by applying principles of social and corporate behavior onto the discussion around digital identity, he came to the conclusion that an identity metasystem comprised of identity providers is actually a bad thing. Instead, he proposed, what is needed is a meta-identity system, in which a new player is the Identity Oracle (loved his choice of name) that aggregates identity data much like a provider; but instead of becoming a distribution center for that data, it becomes a service that provides metadata to the parties that need it, without passing on the actual data. This makes the identity data an asset for the oracle, and therefore incents it to protect it (unlike the identity provider model), something that is missing in all current metasystem models. Excellent stuff.

Oracle's hospitality suite at Catalyst was a big success, drawing in the crowds that were interested in seeing what we are doing. It was also my first chance to see everything on our IdM portfolio in one room. I managed to spend a lot of time discussing IdM in general, and enterprise IdM in particular, with some very smart people, and left with quite a few ideas and a lot more questions in my head.

Some of the recent discussion in the identity world has been focused on a topic I have spent considerable amount of time mulling - what exactly is user-centric identity, and how does it apply in the enterprise. I will be posting the thoughts and findings about that discussion here in the coming days and weeks.

...we need to understand what user-centric identity is.

That is the current state of discussion in the identity community. Many people are debating what user-centric identity is. Is it an architecture, is it a design philosophy, or is it a set of business agreements governing user interactions in certain systems? During the course of the debate (still on-going), the only thing to become clear is that it is still early enough in the evolution that everyone has their own definition. That is why you will probably see a lot of products emerge in the market that claim to be user-centric, yet have very little in common.

A recurring theme in the discussion is that user-centric identity is about giving the user control of their identity. The question is "how"? One persistent topic of debate is whether "user-centric" is the same as "user-in-the-middle" in the context of identity flows. In other words, to be user-centric, is it necessary that all identity flows involve the user in the middle of the flow, providing the explicit go ahead before the identity data can cross some domain boundary? The reasonable answer would seem to be "No", since putting the user in the middle would create a scalability issue gated on the capacity of the user to respond. Imagine having to approve every single identity flow that occurs pertaining to you. It also creates issues of responsiveness and timeliness around flows that happen while you sleep, while your email server is down, etc.

Digging a bit deeper, it would seem that "user-centric" identity is about creating an "agent-in-the-middle" architecture for identity systems. An agent (usually automated) for the user sits in the middle of the identity flow, analyzing the flow request and determining how to handle the response. The determination would be based on policies defined by the user. It may require the agent to bring the user in for an explicit approval, or it may automatically approve or reject the flow based on previous user preferences (similar to the user checking the box that says "do not ask me again"). It may also apply a configured rule or policy to the identity flow that determines the action to take - ask user, approve, reject.

The agent could be the IdP, or some other kind of identity system. There seems to be a lot of skepticism about whether IdP's would ever be in a position to act in the users best interest. In some cases, it could be a self-asserted IdP. However, in all cases, it enables automated decision making while not preventing user involvment, preventing user control from becoming user headache.

What all this means in the corporate world is still to be seen. An interesting side effect of this discussion is that people have actually started to examine the impact of the "user-centric" notion on federation, even debating what exactly constitutes federation.

This promises to be an interesting debate, with the outcome having the potential to impact the way we interact with systems in our daily life. Stay tuned.

I received a very interesting observation from Mark MacAuley (http://identitystuff.blogspot.com) in response to my last post about role management.

Another thought here - how does an organization engineer out laziness? In a
former position I was doing implementations of (unnamed) product and
inevitably when the topic of roles came up I saw just about everything from a
10,000 user account with 30,000 roles (literally) to so many authoratative
sources, I recommended that they just start over. In any case, what drives a lof
the dirty data is laziness, in my opinion. It is far easier (in labor and
political capital) to just create a new role than to map to an existing role or
worse take it to committee to get set up.

Mark's experience points to one of the top reasons why role management projects fail - role proliferation. And what he attributes to laziness, I attribute to the lack of a well defined role management process. This is where the role definition process I brought up in my last post, and the role lifecycle tools become critical.

The role definition process adds discipline to the act of creating roles by making sure that roles are being defined correctly and are being kept up to date. It does this by using the right mix of tools, data and procedure.

A good role mining tool will not only suggest new roles, but also suggest enhancements to existing roles as new business needs are added into the mix. And elements of role lifecycle management bring in additional discipline. Role attestation ensures that appropriate individuals are tasked with making sure that the roles in existence are still relevant and valid. Role re-factoring analysis looks for possible convergence points and synergies across different roles. Good role mappings between enterprise, departmental and application roles allows for the creation of a scalable model that does not push the problem (and numbers) up to a higher level than necessary.

One thing that Mark also points out is the politics involved in roles (an d identity management in general). While a good role architecture that takes the various strata of roles - enterprise, department and application - does help a little, it is ultimately a problem that can only be solved through a combination of teamwork, business rules and corporate standards. And an understanding of the benefits that good role management will bring to all.