Virtual Identity Dialogue

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.

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.

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.

A couple of weeks back I got this comment from Pam (which I found exciting since I've been reading her work on Infocard).

---

I'm interested that you only talked to the mechanism of modeling information cards/OpenID in LDAP - and not the data model.   Seems to me the schema is pretty important too?

To my knowledge, there is no commonly used/understood schema for the storage of data stored during information card and/or OpenID transactions - I think it would be useful to create & promote such a thing, and to do it soon, before everybody creates their own. 

Just my 0.02c :)

Cheers,

Pam

---

Personally I don't think this is that big of an issue. This is because we have been dealing with this via SAML for a long time so I guess it just feels like an "old" problem to me.

Identity Providers - for identity providers they are likely going to pull this data from an LDAP source anyway. A virtual directory can help because it will make it easier to aggregate data from across repositories in the enterprise/organization and do any data transformation.

Service Providers - for service providers it can be a bit more tricky but it is at least partly a business issue not a technical one. The business issue is what do you want to do with the attributes. This is not a simple answer. 

For example - imagine you are an online florist. And you want to take advantage of this user-centric stuff to help manage both promotion codes and the order processing. For promotion codes, you might start using OpenID for example as a simple way to establish the business relationship. For this - you only really want to use OpenID to help make it easier to do the promotion code exchange instead of having to have people remember obscure codes. In this case, you don't really care about the data, you just want the establishment that they have come to you from one of your partners.

However, for remembering/tracking customer visits they may want to use user-centric system so they can avoid managing passwords. In this case - the attributes you do want to keep - at least temporarily. And by having them in LDAP makes it easier to use them by other applications.

In that scenario - you could choose to link to an LDAP record and thus it becomes "permanent" or you could choose to just make the data "transient" and let it be refreshed on each visit.

In either way directory virtualization helps because you can simplify mapping of the user-centric attributes to whatever LDAP schema you want (or have). For transient data  - you will want the data to be truly transient and not persistent. To accomplish that - you should use an in-memory data storage system such as Oracle Virtual Directory plus Oracle TimesTen. TimesTen is Oracle's in-memory relational database. This would provide simple to manage, low-latency data store that is easy to configure to be truly transient. By combining with OVD - you can leverage standard LDAP integration with both the "user-registration" (even if that is just on-demand data load by your user-centric SP code) and access control.

Most of June and July has flown by. And of course the time I had to actually blog - we were upgrading the blog system so by the time it was live - I didn't have time.

Anyway - I think Clayton covered pretty much most of what I would have said at high level on the meta-directory feud.

One element I would point out in this continuing quest by James and others that seem to live in a world where AD is the one and only directory and I guess never have to deal with customers or subsidiaries or mergers or acquisitions (or maybe all of their kids college funds are only in MSFT stock??) - the fact is that for many organizations, there are attributes that are mastered in HR that may not exist elsewhere.

For example - cost center and manager. You might want to use that information to make an authorization decision on.

While you can - via provisioning system like OIM copy that data into AD - by doing so means you now burden your  Windows admin on managing the data. Which has its own implications - for a single department, it might be manageable. But for an organization that is spread over multiple locations - that data must be replicated and that can take several minutes or hours.

Frankly there isn't any reason for this.

You could simply use identity virtualization to link (what we refer to as a split profile) your username & password in your enterprise directory (like AD) to the record in the central HR system. This could be pulling data from HR or it could be reading it from OIM.

The benefit of this is that you only have to manage, secure and make highly-available that data in a single location. Worried about what happens if that system is down for upgrade or concerned the database isn't optimized for queries -then you can use Oracle TimesTen (aka 11g DB In-Memory cache) to offset this.

And because you are leveraging identity virtuailzation it makes it easier to secure access to the sensitive data because you can specify which applications are making queries on the data and then periodically audit them to insure they are following your rules. But my belief is that if the data is available as a service - people won't copy it because it will be easier to just use it on the network.

During the upgrade to the new blogging system I got this question via the comment system:

"How should relationships be modeled in LDAP? How would you model roles and resources in order to form an entitlement in LDAP? How should OpenID, Live, CardSpace, etc be modeled in LDAP?"

I will answer each question separately:

Q1 - How should relationships be modeled in LDAP?

A1 - Most of the time relationships are modeled using Groups. You can do this either using static groups (e.g. groupOfUniqueNames) that requires members to be stored in the uniquemember attribute OR you can use dynamic groups. Dynamic groups use an LDAP query (specified as an LDAP URL) to determine membership. OVD provides a plug-in that can make dynamic groups look like static groups which makes dynamic groups easier to use by client applications

---

Q2 - How would you model roles and resources in order to form an entitlement in LDAP?

A2 - Currently roles are most often mapped as LDAP groups. That being said we are working to make it easier to allow customers to specify roles based on objects besides groups as part of our Identity Governance Framework implementation. Resources can be exposed as either groups or a custom object. Entitlement is a very broad area. Coarse grain entitlement can be done via groups (most common case). Oracle Entitlement Server (our XACML based fine grained authorization product) allows to do finer-grained entitlements.

---

Q3  - How should OpenID, Live, CardSpace, etc be modeled in LDAP?

A3 - There is no special requirements here because they are just different mechanisms of representing identity attributes. Your OpenID or CardSpace service needs to read data from either existing source or perhaps write into an enterprise source. LDAP is a natural system because it is widely deployed and understood. Benefit of OVD is that it can simplify the mapping of the attributes. And in the longer-term the IGF Attribute Services API will make it even simpler by providing mapping at the object level. For example  as a developer, you could write a ShopperCardSpace object that represents the attributes provided by a shopper via CardSpace. Then OVD (which will be our IGF Attribute Service provider) will support taking that object and letting the administrator map it to the proper sources. If the data has no current home and/or should not be permanently  stored - it's possible to put it into a transient storage system like Oracle TimesTen. That way the data is available to be used by applications within the enterprise without requiring the data to be constantly retrieved from CardSpace in particular if the application cannot interact with CardSpace (e.g. a legacy application that can only do LDAP, a back-end BPEL process reading via SOAP, SIP servlet starting a click-to-call application).

A few weeks ago - Dave Kearns wrote a piece revisiting an earlier discussion between him, Kim Cameron of Microsoft and our own Clayton Donley.

The initial question from Kim Cameron was:
--
"Sometimes an application needs to do complex searches involving information 'mastered' in multiple locations. I'll make up a very simple 'two location' example to demonstrate the issue:

'What purchases of computers were made by employees who have been at the company for less than two years?'

Here we have to query 'all the purchases of computers' from the purchasing system, and 'all employees hired within the last two years' from the HR system, and find the intersection."

--

Clayton final summary was:

--

" The real solution here is a combination of virtualization with more standardized publish/subscribe for delivery of changes. This gets us away from this ad-hoc change discovery that makes meta-directories miserable, while ensuring that the data gets where it needs to go for transactions within an application."

--

Dave was a bit shocked at Clayton's reply since to him it sounded like a cache and that is not something we normally advocate with the virtual directory.

Except that what Clayton is talking about is a bit different.

What we are working on enabling is to allow client applications to register their queries with the virtual directory in way so that they could get the responses in a manner different than simple client/server. For example they could issue a command to OVD that allowed OVD to put the responses onto an Enterprise Service Bus. So for example - it could be possible that applications that were interested in the result of this query - could attach themselves to the bus and see the results. Furthermore, OVD could even be monitoring HR system so that when new employees met this criteria - it could add new results to the bus.

The benefit of this is that for applications that truly needed to know this, could listen for these updates. This makes it easier than say for example some type of central service that must know who to write to each type of application in the organizational environment.

It would be the further blending of identity services with SOA which is where the modern enterprise is going.

And to be candid - you could do most of (if not all of ) this today - it just would require more manual work than we would like.

Oracle blogs will be migrating to a new platform.  And this is going to take a couple of weeks.

But all of the content (except for the comments) should make the migration.

Looking forward to a new and improved system.

One of our tasks for the past fiscal year (Oracle FY is from June until May) was to work on getting my internal FAQ into Metalink.

That project is now complete. Many thanks to Irina in support who took care of the conversion.

Note.566569.1 -- FAQ - OVD Performance, Load-Balancing and Scalability

Note.565523.1 -- FAQ - Join Adapters

Note.577982.1 -- FAQ - OVD with Enterprise User Security

Note.577977.1 -- FAQ - Plug-In Documentation

Note.567775.1 -- FAQ - Monitoring OVD

Note.566566.1 -- FAQ - Database Adapters

Note.580444.1 -- FAQ - Oracle Access Manager

Note.580442.1 -- FAQ - Data Transformation

Note.580440.1 -- FAQ - OVD Training

Note 602230.1 -- FAQ - Miscellaneous
(Lots of stuff here) -- (FYI, still waiting on Metalink to make it available).
Note 554126.1 -- FAQ - Application Integrations


By publishing this to Metalink - it makes it more accessible to a wider audience. We did debate putting elsewhere like Oracle Wiki or OTN but decided on Metalink because that is the one spot still accessed most frequently by customers, partners, support and sales when looking for information on Oracle software.

It also makes it easier for development, myself and support to update these documents (and the other near 100 OVD related notes).

James McGovern asked more questions including this.

"- Virtual Directories: What role should a virtual directory play in an
Identity metasystem? Should virtual directory be a standalone product
in the new world and simply be a feature of an STS? If an enterprise
were savage in consolidating all directory information into Active
Directory, why would I still need virtualization?"

[MEW] I think my answers from our last exchange answer this question.

Now are the rest of the questions:

"protocols:Nowadays, the folks over at the Burton Group such as Bob
Blakely, Dan Blum and Gerry Gebel have put together the most wonderful
XACML interoperability events. The question that isn't addressed is if
I am building an enterprise application from scratch, should I
XACML-enabled, think about integrating with STS, stick to traditional
LDAP invocation or something else?"

[MEW] Most enterprise architects are familiar with how abstract security using features that range from official standards like JAAS to de-facto standards like Apache modules to various application frameworks (including .NET and ACEGI) that facilitat this. And then encourage implementers of such entities to support XACML. Oracle (and BEA) have demonstrated XACML support and we're building support for it into our future products.

"Entitlements: One missing component of the discussion is
authorization and their is somewhat too much focus on identity.
Consider the scenario where if you were to ask my boss if I am still an
employee, he would say yes as he hasn't fired me yet. Likewise, if you
ask him what are all of the wonderful things I can access within the
enterprise, he would say that he has no freakin clue, but as soon as
you figure it out, please let him know. Honestly, even in my role,
there are probably things that I can do but shouldn't otherwise have
access to. So, the question becomes how come the identity conversation
hasn't talked about any constructs around attestation and authorization?"
[MEW] Oracle Role Manager is explicitly designed to help solve the problem of determining what enterprise roles there are, translating those into IT roles which then result in system privileges. It then integrates with a provisioning system (like Oracle Identity Manager) so that access is maintained based on hire/termination/change-of-enterprise-role status. Additionally Oracle Adaptive Access Manager (OAAM) provides for a risk-based access control solution that can authorize actions based on your context and environment (e.g. you normally only try to pay move money between 7-9pm EST from IP address 192.168.1.55 but if suddenly you get a request to do this at 5am from an IP in outer Elbonia, it can do wide range of activities such as requiring you to call a phone number and answer security questions to help verify it's you).

"Workflow: Have you ever attempted to leave a comment on Kim Cameron
blog? You will be annoyed with the registration/workflow aspects. The
question this raises in my mind is what identity standards should exist
for workflow? There are merits in this scenario for integrating with
the OASIS SPML standard, but I can equally see value in considering
BPEL as well."
[MEW] I don't think this is a standards problem as much as a usability problem. For example compare mobile web life before iPhone to after the iPhone. Prior to iPhone - mobile web was usuable but painful because of multiple-clicks. One of the really great things of iPhone/iPod Touch is not that it has Safari (though it helps) but being able to put commonly used Web apps in reach of a single-click (which happens to be a touch). Both systems use the same core standards (HTML and Hyperlinks) just one is more usable than the other. Personally, I think SPML or BPEL is fine, but they are really focused on what happens after you hit the Submit button. The UI component of the workflow is going to be driven by other standards (such as in 11g SOA TP4 preview we can use convert BPEL Human Workflow tasks  to ADF Task Flows which can help make it easier to have a usability guru work their magic).

"Education: Right now the conversation regarding identity is in
the land of geeks and those who are motivated to read specifications.
There is a crowd of folks who need things distilled, the readers digest
version if you will. Traditionally, this role is served by industry
analysts such as Gartner and Forrester. What would it take for this
guys to get off their butts and start publishing more thoughtful
information in this space?"
[MEW] Nobody wants to read specs. I've probably read more identity specs than almost anyone on the planet and I hate reading them. This is why we at Oracle are focused on application-centric security and security as a service. Developers and applications should just be able to depend on calling an API or service & have it "Do the Right Thing".

"Conferences: When do folks think that the conversation about
identity will occur at other than identity/security conferences? For
example, wouldn't it have been wonderful if Billy Cripe, Craig Randall and Laurence Hart where all talking about the identity metasystem in context of ECM?"
[MEW] Why would they want to talk about identity at their conference? After all I bet they don't talk about any other core service component at their conferences either - meaning when was the last time they talked about DNS? It's just not something they want to care about and frankly, they shouldn't care about. This is the core of Oracle Security As A Service concept - developers learn to leverage identity as a service and use proper API calls (e.g. the biz dude says "only managers can access this document" so the developer makes a standard API call that leverages a policy service that in effect says " if (userIsInRole("manager")) { fetchDoc(x)}") then applications won't be maintaining their own identity information and there won't be a need for wondering why ECM conferences don't talk about identity.