Virtual Identity Dialogue

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).

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.

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.