Talking Identity

It has been a long time since my last post. The fact that it coincided with the holiday season shouldn't lead you to think that I was enjoying some well deserved time off. It has, in fact, been quite the opposite. Things have been really busy in the identity management group recently, and I have been working hard on some interesting problems that will influence the future direction of the OIM product. Hopefully I will be able to share the results of that work with all of you really soon.

January is the month when everyone comes out with their predictions for the coming year. Since this post is coming in at the tail end of January (hopefully I will get it out in time to keep that statement true), I toyed with the idea of doing my own post on trends in the identity management space. But having read quite a few of those over the last month, I think anything I could possible say has pretty much been covered already.

Next week is the RSA Conference. And this year, Oracle is planning on showcasing its move into identity management in a big way. Everyone has been talking about the way in which Oracle has aggressively moved into a leadership position in the space (just check out Burton's report on the identity management landscape for 2007). So it comes as no surprise that everyone is curious to know how Oracle will approach the future.

I therefore decided on a different tack. Instead of trying to predict what will happen in 2007, I decided to share my thoughts on what I feel are the main philosophies that will drive the work our team will be doing this year. This is not meant to be a complete list, and I cannot stress enough that these are my personal thoughts (I have been told to make that very clear). It will be interesting to hear if you think there is anything else that should be at the top of our minds.

So here goes...

Convergence: This is the big one. For a long time, the main demand from the market has been the integrated IdM suite. But in a world where services will be the main way in which identity technology is consumed, it is actually the next progression that we need to be looking at. Having multiple products that are able to interoperate is good, but that still leaves the model open to redundancy and maintenance headaches. Simply changing all those products into a service is also not good enough. And more and more concepts are making their way into every aspect of identity management. If I define a SoD policy in my provisioning system, why should I have to re-define it in my authorization service? Convergence of these various products into a unified construct that supports multiple service modules will help eliminate some of the management nightmares that make project managers pull their hair out, and make life a whole lot simpler. Which leads me to my next topic - simplification.

Elegance (aka Simplicity without Loss of Functionality): All too often, the words simplicity and flexibility seem to be mutually exclusive. This is especially true for IdM products. Proof-Of-Concept engagements in the IdM world often come down to a decision between a product that can solve the use case and a product that is easier to manage. But there is no reason why the two can't be brought together in an elegant way.

Privacy: The strong desire individuals have for privacy led to the birth of user-centric identity as a new IdM methodology, and enterprise IdM is still struggling to work out what this means for it. However, one thing is sure. We cannot continue to develop identity management software without building in support for privacy controls that provide better protection and management options to the people whose identities are at the core of these products. And as enterprises themselves become more aware of their responsibilities in this area, they will demand the kind of frameworks that the recently announced IGF standard aims to support.

Strength: The tagline for Oracle's Fusion Middleware suite includes the word "Unbreakable". To me, the word reflects the multiple facets of what our identity products need to be - secure so they can't be compromised, adaptable so they can deal with any kind of customer use case without bending and powerful so they can gracefully deal with the increased usage that identity services are going to be subject to.

Well, those are the keywords that will be guiding at least my efforts in evolving our products. In my next post, I will finally get around to the animated discussions that my comments about role management vs. provisioning set off, and how the philosophies I talked about above (one in particular) will impact what we will do about it. And if you happen to be attending the RSA Conference, drop me a line and maybe we can get together for a chat.

I'm here at the annual RSA Conference, and it is just as busy as every year. Everyone who is anyone in security is here, which is why certain vendors are conspicuous by their absence (talk about reverse marketing), but that's a different issue.

Every year, it seems like one topic is at the top of everyone's mind, and this year that topic seems to be protection against attacks - by hackers, identity thieves and malware. The sessions dealing with these topics seem to be getting the most attention and drawing the biggest crowds.

So one could call it either unfortunate or timely that news is coming out about the worst hacker attack on the internet's infrastructure in recent years. Read the story here and draw your own conclusions.

I attended a session titled "Delivering Security Integration with Compliance" by IBM's Stuart McIrvine. During the session, he laid out the various governance frameworks for IdM (SOX, COSO and COBIT among others) and detailed how IBM's Tivoli family of IdM products could be used to implement them as part of an IdM practice. As he explained the features of some of the products, an interesting audience question came up in the context of user account reconciliation and rogue/orphan account detection. The question posed was "how do you figure out and correlate the account [say account 'jsmith2345'] with the identity [John Smith] it belongs to".

The answer that he gave puzzled me. His answer was that it is based on matching of a common attribute tracked on both the account and the identity. This could be an employee id, a social security number or some other attribute that makes sense.

The reason the answer puzzled me is that we rarely see this approach working in reality. It is true that enterprises are realizing the benefit of establishing some kind of common attribute, as it makes the whole process simpler. This is one of the big drivers behind username standardization and the synchronization mechanisms that provisioning products (like Oracle Identity Manager) have to support. But there are still the realities of the current enterprise environment that need to be dealt with. The existence of this sort of common attribute is still quite rare. Other conditions may also preclude such approaches. The same person may have multiple accounts in a system, which would prevent the existence of unique common attributes. Also, attributes like employee id and SSN are increasingly viewed as secure, private attributes that must never be propagated to other systems, and therefore cannot be used as a common attribute. And administrators still end up creating accounts in an ad-hoc fashion that doesn't really get forced to comply with a corporate policy.

In this context, a very real solution is the use of pattern recognition based matching. OIM (among other provisioning tools) has supported this for a number of years now, allowing more common attributes like username and full name to be the basis for owner matching. Using a pattern matching rule, the system can identify that the account with username 'jsmith2345' belongs to John Smith because it follows the pattern 'First character of First Name + Last Name + random numeric string'. OIM allows you to specify multiple patterns that an application can follow, and will use all of them as necessary.

Now pattern recognition by itself cannot be completely deterministic. For instance, there may be both a John Smith and a Jane Smith in the environment, both of which will get identified based on the above pattern. These cases require that there be appropriate management processes and tools to deal with these exception cases in a delegated fashion. In the case of OIM, the reconciliation manager provides just these kind of tools as part of the deployment. Using this, the delegated administrators in charge of the targets can be notified of these exception conditions, and they can examine the data, do their own investigation, and take appropriate action. One of our customers even turned this into a unique end-user driven account claim process, that helped them clean up extraneous accounts in their systems quite rapidly, thus achieving a key goal in their compliance plans.

Once again, this illustrates how important it is to remember that enterprise environments are fairly fluid, and the need to handle exception cases is actually quite common. So the IdM tools that you use must be able to provide you with flexible and adaptable tools that can help minimize the occurrence of exception cases, and elegantly handle the exception cases that do arise.

I attended a very informative session entitled "Enterprise IAM Challenges - A Practical Approach to RBAC" given by Jeff Bardin, the CISO at Investors Bank and Trust. It was a frank, open account of his experience leading a team on an IAM project that took his previous employer from a failed audit to a successful delivery of compliance objectives. He talked about how his team tackled three main problem areas - employee on-boarding, RBAC and user provisioning.

The team used a variety of tools (including, to my surprise, the Thor Xellerate product, now Oracle Identity Manager) to clean up roles across systems, folders and files, simplify the employee on-boarding process, introduce user provisioning, and bring order to what he termed "identity chaos". Some of the numbers were very impressive - going from about 320K unused datasets in RACF to 90K, going from about 12000 userids to just less than 6000, and so on.

He described some project management techniques (such as mapping out the new employee process as swim lane and contact point diagrams in order to identify the pain points and inefficiencies) that are fairly simple to understand, yet don't seem to be employed that often. He detailed cost savings achieved from three sources - directory synchronization, password management and user provisioning. Their approach to RBAC was to centrally administer but locally enforce RBAC policies. They created global roles based on a combination of functional (truly related to job function), geographic and affiliation (employee, consultant, temp) criteria.

While Jeff's session did not identify any revolutionary approaches to solving the identity problem, it was one of the most complete and thorough descriptions of a large IAM project undertaking. If you were at the conference but unable to attend his session, check out his session presentation (which was made available to all conference attendees).

Jeff's work at his previous employer proved so successful that he received the RSA Conference 2007 award for "Excellence in the Field of Security Practices" on Monday, an award his previous boss nominated him for after he had already left the company. Now that shows how impressive the job he did was.

In my last post, I talked about Jeff Bardin's excellent session about the reality of successfully deploying an enterprise IAM infrastructure. During his session, he touched upon one of the more interesting problems that we see in enterprises today - the "Model-As" problem.

Jeff was referring to a practice that is very common in a lot of enterprises today. When a user is getting created and provisioned in the enterprise, system administrators and/or managers basically rely on a common short cut. Instead of trying to figure out what privileges that a new user Bob should have, they essentially say "give Bob all the privileges that Alice has, because Bob has the same job as Alice". As Jeff so articulately pointed out, the result is the propagation of bad or unneeded privileges from one user to another. One can easily see how privileges that Alice accumulated over her lifetime of service end up in Bob's profile, even if some of those privileges were legitimately assigned to Alice only for a short period of time, after which they should have been taken away. And as we are learning, enterprises are actually quite fluid and the privileges that a user has actually reflects how much a user's actual responsibilities differ from the base definition of their "job".

This is the "Model-As" problem, also known within our group as the "Copy User" problem. It becomes a problem because it assumes that the privilege environment is pristine, and that everyone has only those privileges that they should have. It also assumes a highly rigid enterprise where two people doing the same job will essentially do the same things and remain the same from a privileges perspective.  In most complex enterprises, that is not true, and the result is an unnecessary explosion of compliance violations and privilege creep.

The solution, as Jeff pointed out, is actually quite simple - RBAC. The model-as problem exists because it is the poor man's RBAC model. In the absence of true role management, and role based provisioning, the manager is forced to identify a model user that is, in essence, the description of the role(s) that the new user needs to be assigned. Bringing in RBAC and role-based provisioning can help clean this up by providing the necessary abstraction and control to the environment. Assigning an ad-hoc or short-lived privilege to Alice no longer pollutes the role definition, and therefore eliminates scope creep. It also allows the administrator to change the role-privilege definition once and apply it everywhere, without having to go and track the model-as patterns and chains. In Jeff's words, it brings sense and order to the "identity chaos" that exists in the enterprise.