Managing Relationships and Entitlements with LDAP

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

Comments:

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

Posted by Pamela on July 03, 2008 at 12:50 AM PDT #

I agree with Pamela Dingle that the data model of cardspace and how it can be persisted is vital. Would love for this to be your next blog entry.

Posted by James on September 29, 2008 at 04:56 AM 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