OpenID, InfoCard and LDAP Schemas

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.

Comments:

You have outlined a good perspective. How about in your next blog entry, actually showing what classes, attributes, etc need to be created and how Oracle will be working to get inetOrgPerson or whatever classes extended industry-wide in a standards based way.

Posted by James on July 18, 2008 at 09:07 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today