Talking Identity

People always ask if OIM can be deployed in an SMB environment. Given that most of our initial customers were large enterprises that were putting complex deployments in place, it was very hard to provide good references for this question. No longer. IDC just released a report profiling the IdM implementation Silicon Image has done using OIM. Silicon Image Inc. is a 400+ employee company that is a leader in architecture and semiconductor implementations for the secure storage, distribution, and presentation of high-definition content in the consumer electronics and personal computing/display markets. The focus of their IAM project was meeting compliance regulations and increasing security in their environment.
You can access the report here.

The Director of Technology Services for Silicon Image, Kenny Gilbert, joined Ed King, Director of Product Management for IdM at Oracle, at a session about their deployment during OpenWorld last year. It was one of the best IdM sessions we had, a frank and open discussion about the challenges that SMBs face in the IAM arena. Kenny's discussion resonated with the brave souls that turned out for the 8am session, as it had a lot of them nodding their heads in agreement with his frank description of the issues they were having without an IdM infrastructure. The ungodly hour of the session may have kept many from attending the session, but this report can now fill them in.

A few months ago, I wrote a post in which I took issue with the statement that "Role Management will become the focus of Compliance". My objection kicked off a flurry of responses from various folks, expressing opinions that covered the gamut. I received a lot of responses disagreeing with me, with quite a few of those being from people in the role management business (no surprises there). To be fair though, some of them were quite balanced and articulate.

Maarten Stultjens (of Bhold company, which is a vendor of RBAC solutions) agreed with Roberta that role management systems will become the central point of compliance shortly. But he further qualified his perspective: "of course (this is) 'only' with regard to authorization management. The main reason for this is not so much the IT perspective Nishant is mentioning in his blog, it is the business perspective which is driving Role management systems. To find patterns and get these approved via attestation is an IT perspective towards authorization management."

Now, one thing I take great pride in is my being able to always maintain a business perspective of the IAM problem. I have never thought of it as an IT problem (but one that requires and impacts IT infrastructure). So I promptly challenged Maarten to duel for besmirching my reputation (Just kidding).

Maarten further elaborated: "The main reason why role management systems are so important to achieve compliance with regard to authorization management is that role management systems are able to (1) store and maintain the company policies and (2) enforce these policies (through provisioning engines or manually) and (3) audit if the policies are actually implemented. Compliance is all about 'defining a policy', 'enforce the policy' and 'proof that the policy is implemented'. There is nothing to audit when there is no clear policy. Sometimes we - IT people - overrate ourselves by talking about compliance and audit. This is the job of auditors."

Again, I have no argument with the statement that RM systems are "important" to achieving compliance, just with the notion that they are the focus. Roles have long been viewed as the Holy Grail of IAM - true role-based identity management will solve all problems. But like the Holy Grail, it is really hard (nearly impossible) to achieve. So I tend to have approach blanket statements with some perturbation. I don't disagree with Roberta or Maarten on how important role management is to compliance. I just want the message to be balanced, and not get exaggerated to the status of "all important".

Looking at Maarten's position, I agree with point (1), but disagree with (2) and (3). RM systems will not be able to do those because they present only a partial picture of the reality of a business. If I can simplify an example to make my point, it is fairly common for people to be given privileges in an ad-hoc, but entirely proper, manner. This is invariably done through a request-based, approval enforced mechanism that today is handled by provisioning systems (OIM, for instance). These privileges are therefore out of policy, yet are not exceptions. And a role management system should not have to deal with this kind of scenario (even if it could).

Yes, compliance is the job of the auditor, but an auditor is only as good as the tools they are given, which is where the various IAM solutions come in. Auditors care about the roles because knowing the roles a user has tells them about what access the user has and does not have. But they also care about the out-of-policy privilege grants, and want to know that the correct procedures for approving, tracking and attesting those privileges are being followed. They care that audit trails are being maintained, and that there are no loopholes in the business processes.

Another person sent me an email saying "Role management is vital method to achieve compliance while user provisioning is a method to deliver proper user- and permission-information to distributed environments and applications. (yes, UP also collects information from distributed sources for the centralized Role Management)". This points out one of the main misconceptions that I have been trying hard to fight, and which is probably at the core of the misunderstanding of the space. Too often, provisioning is viewed simply as (to quote) "the bus to deliver this user-permission information, with all required attributes, to all those environments where it is needed." This really is the IT-centric view. Provisioning systems today (OIM in particular) are actually much more of a business solution than an IT solution, providing rich policy definition and enforcement, and end-user and administrative request-based, approval driven tools for managing privileges in a fluid business environment.

To me, role management is an essential part of IAM. In fact, in today's environment it is probably the most important part of a compliance-driven IAM solution. It should not, however, be the focus of a IAM-based compliance project. Any good IAM strategy must be a mix of role-based, rule-based and request-based management (think of the old 80-20 rule, just broken down to 50-30-20), with a good overlay of audit and compliance tools. At Oracle, we feel that Identity Administration, Provisioning and Role Management are the three pillars on which (the newly emerging) identity GRC tools are overlaid to provide the foundation of a good identity audit and compliance practice.



(Of course, knowing how IAM is constantly evolving, I am sure we will be adding more "pillars" to this diagram soon, so take this position with a pinch of salt)

This is driven by the reality of modern business - one that is fluid, ever-changing and way too complex to only codify in the structured system that role-based management represents. Over the last few years, I have dealt with a number of customers that have made the effort to incorporate role management into their IAM projects. Invariably I encountered the following:

• No one agrees on the definition of a role
• Most of them only manage to use roles in a limited manner

The mantra of the day is balance. I think Dave Kearns response to my post was best: "While I do agree that RBAC is the 'wave of the future' and is, indeed, necessary to good IdM and compliance, I think of it as being one of the foundations of compliance, not the tool that compels or insures compliance. And certainly not a tool for attestation..."

About a month ago now I did a post about account reconciliation capabilities that I believed were necessary to make reconciliation practical. My post was triggered by a session I attended by IBM's Stuart McIrvine, during which he answered a question about ways to correlate identities by saying it should be done based on common attributes.

At the time I pointed out that this seemed to be a big product gap, as a critical element is the ability to use pattern matching. Well, I received quite a bit of feedback on that, correcting Stuart's (and by extension, mine) misconception. The fact is that ITIM does support pattern recognition.

Ian Yip wrote:

IBM Tivoli Identity Manager can handle the pattern recognition matching you
speak of. This is defined within the relevant adoption rules used for
reconciliation.

Tim (no last name) sent me this comment:

ITIM does actually support the functionality you discuss in your article. As
well as the 'shared attribute' or alias type matching it also has a scripted
component which allows you to script any relationship you wish (regular
expression or otherwise).

In my view, this has revealed one of the dangers of trying to turn an industry conference session into a product pitch. The people who speak at conferences don't have the time (and sometimes the hands-on knowledge) to provide a detailed and accurate representation of their products, causing this kind of confusion. Ian said it best:

I suppose this is what IBM gets for sending high level marketing types without
the deep product knowledge to speak at conferences. They sometimes get caught
out when answering questions :-)

While these comments did correct my understanding, they also got me (and a few other folks) thinking. Is there another (better) way to do identity correlation, that is not based on common attributes or pattern matching? After all, administrators don't always follow the correct patterns. Shekhar Jha also mused:

The way I would interpret this is that two separate set of people came up with
multiple ways (attribute matching, pattern matching)to solving the same problem
of hopefully being able to map 80% of the accounts (It would be interesting to
see a study published on how effective each of these techniques are). Well
exceptions are so common (is that an oxymoron?) that all the provisioning
product have to deal with them in some way or the other.

So, does anyone know of any better ways to deal with this problem? One of our customers, Toyota Financial Services, came up with an innovative self-service account claiming mechanism that has worked very well in their environment. I believe some of the other provisioning products out there actually support this mechanism out of the box (this capability will be productized in Oracle Identity Manager in an upcoming release; the TFS implementation was customized solution). Are there other ways that are some combination of technology and process? Let me know.

By the way, it seems that there are some issues with features and controls on my blog. Thanks to a number of emails from readers, I realized a while ago that my post archive has not been working. Also, seems that the comments people posted to my blog are not being handled correctly. I put in place a control that said only the comments I approve should show up. This is primarily because a number of comments I receive are intended by the poster as a private request for information or guidance, and I get quite a bit of spam as well. However it seems that the approved comments are not showing up as links, but can be found if you search for them. Worse, comments that I haven't approved show up if you search for them. So I have some housecleaning to do.

If you know of any other issues with my blog, let me know. There may be some kinks in the system that need to be worked out. And unlike my personal blog which I control, this one is a corporate IT system, so fixing things takes time.

I'm back from a trip to Oracle HQ, where I was attending our 2nd annual Identity Management Customer Advisory Board conference. The 3-day event is the zenith of a continuous process that combines quarterly meetings with 1-on-1 discussions to provide all involved a valuable platform to gather, discuss and align our vision of all things identity.

Apart from the actual act of trying to get to San Francisco (flight snafus), the week was really good and productive. Unlike last year, when customers were anxious about the acquisitions of Oblix and Thor, this year's board was a relaxed group that is (finally) comfortable with the idea of being Oracle customers. That is not to say that they were about to let up on us. They came ready to drive the future of Oracle's IdM products and the future of their own deployments.

There were a lot of questions about our progress in making the suite come together in a more cohesive manner. The sessions presenting our roadmap were fairly interactive. We had a number of customer's present case studies of their own deployments, and it provided great insight into the differences in philosophies and approaches to solving some fairly complex problems. Compliance topics, especially SoD, were discussed quite a bit, with the stress being on making IdM work with the SoD capabilities customers already have or are putting together. There was also good interest in the work that Oracle is doing on the IGF.

Some of the key messages that came through loud and clear were:

• Everyone knows that identity management is still a very difficult solution to deploy (at least at enterprise-scale). The message to us was to continue our efforts in making the overall process of deploying IdM manageable and scalable.
• There was a big demand for additional flexibility in configuration and customization capabilities.
• Role-based identity management continues to be of interest, but at the same time continues to suffer from the divergent implementation philosophies and interpretations.
• Identity Services (in various shapes and forms) are a big part of enterprise roadmaps. In fact, a significant number of enterprises are moving beyond the ad-hoc model they had so far and looking at creating structured identity services projects to serve the needs of an increasingly large and vocal (internal for now) consumer base.
• There was a lot of interest in understanding our strategy for Fusion, especially with respect to our impact on the Oracle Applications suite. And there was a smaller group that was interested in the possible convergence of ERP and IdM.

We also heard an interesting anecdote about just how firmly entrenched identity (and identity services) is becoming within the enterprise. One of our customers told us about being approached about an "identity-enabled" elevator system. The idea is that swiping a smart card upon getting into an elevator would take you directly to the floor you are allowed to access. Don't know more details than that, but the resulting discussions about the identity services needed to enable such a concept were quite interesting. As was the discussion about de-provisioning a user while they are still in the elevator :)