Managing Relationships and Entitlements with LDAP
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Jul 03, 2008
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).