Virtual Identity Dialogue

Hard to believe we're already marching through the first week of August. Between vacation and the usual "catch-up" after vacation, haven't had much time to blog.

But I wanted to let people know that we will be having OVD customers present at the upcoming DigitalID World conference.

They will be presenting as part of the panel "Lessons from Successful Virtual Directory Deployments" - Wednesday, September 10, 11:25 a.m.

Many of you may have read this post from Gerry Beuchelt of Sun talking about how to protect Sun employees using their OpenID R&D project.

Among the advice - make sure systems are patched, verify the DNS of your ISP is working properly and to double-check the hostname of their OpenID provider.

That is a tall order even for the most technical people. I mean I'm a geek among geeks and I don't think I could accomplish those steps.

But it does give me an opportunity to write about how strong authentication and risk-based access control could help here. Currently we have a product (Oracle Adaptive Access Manager) that provides both functions.

OAAM allows you to use a virtual keypad to enter username and password credentials. This virtual keypad includes such features such as using a background image that you chose (or perhaps chosen for you in an internal environment). It also has other features such as a timestamp, showing a key phrase in the image and the image moves every time it is refreshed. Also the keypad can be virtualized (e.g. driven by your mouse) so that it makes it darn near impossible for a keyboard logger to capture your password.

If more OpenID providers used something like OAAM then it would be much harder for a rogue OpenID provider to be configured.

Additionally risk-based access control (another OAAM feature) would help OpenID relying parties make better access control decisions for a linked OpenID. For example based on prior activity it could assign risk factors (e.g. normally you accessed from an IP in Dallas, but now we're seeing IP access from Outer Elbonia, maybe we should alert a customer care rep to call you before moving that money).

These same principals could also be applied to any other federation scenario including SAML or Liberty based federation like we provide via Oracle Identity Federation.

Of course OAAM has benefits within enterprises who are not using OpenID or SAML but I just wanted to point out some tangible steps people could do to help secure OpenID beyond training people to become DNS engineers.

OOW is coming up and of course I will be there. Besides being able to find me at our booth, I will also be presenting at the conference.

This year I will be presenting at the main conference with one of our customers - The State of Delaware.

The presentation is:

Session ID: S298925
Session Title: Using Oracle Virtual Directory to Integrate Microsoft Active Directory, Oracle Database, and Oracle Applications
Track: Identity Management
Room: Golden Gate C3
Date: 2008-09-24
Start Time: 13:00

The State of Delaware will be going over their implementation of OVD with PeopleSoft. And I will be providing the general overview of OVD & identity virtualization.

I am also planning on presenting at the Unconference. I say planning because unlike the traditional OOW conference, nobody knows who is going to present or when until each morning when people post the topics & get slotted. I think it's useful for getting topics posted that are emerging or emerge during the conference itself that otherwise wouldn't have a forum. It is however, slightly confusing to the uninitiated since I had to spend a day with management last week explaining to them that I couldn't guarantee when or where my Unconference presentation would be delivered :).

The Unconference presentation will most likely be our first demonstration of our "Identity Beans" API. Identity Beans is our current internal name for our implementation of the IGF Attribute Services API. I wouldn't say "internal name" to mean "code name". Rather a reflection of the need for a less wordy name for "IGF Attribute Services API" which the IGF team also recognized. I had dinner with Prateek Mishra last week and we bounced around a couple of other ideas including perhaps having one name for the Oracle Java implementation and another for the API specification.

The quick summary on Identity Beans is that this an API that we believe will make it simpler to use identity attributes. Barring some unforeseen issue this is the API that Fusion application security will use to access the identity information exposed by Fusion applications (such as HR ) and automatically linked with the enterprise directory (in most cases we assume this will be AD).

This is the API that will generate CARML mapping files - though we will likely ship with a set of pre-defined mapping for Fusion apps data. And while it does generate CARML (or can generate it's code from a CARML file) - the goal is that this is like the XML mapping files in Hibernate or Toplink - there for application consumption only. Nobody should ever see (or edit by hand) XML in our GA release.

I will be blogging more about "Identity Beans" over the next few months which will show how this makes secure identity development quicker and easier.