[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Mapping at what level?

I started to write a response to this thread but it became so long and potentially so orthogonal that I did a blog post instead inspired by this thread.

If you are interested it's at: http://xditao.blogspot.com/2007/03/higgins-idas-and-xdi.html

I will be happy to pull the contents back into this list if that is preferred on this list and you think it is relevant enough.

All the best,

Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale

If you don't have an i-name yet use this link to visit one of our partners and buy one:



"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

03/13/2007 04:41 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
Re: [higgins-dev] Mapping at what level?

I think I'd rather see the JNDI CP do the bare minimum.  That is, I would have it do no name mapping because a Higgins cuid is after all, a string.  JNDI names always have string representations.  Some minimal mapping (even if configurable) needs to be done for attribute types and subject types because the Higgins datatype for those is URI -- thus they at least need the <scheme> : <hier-part> elements.  JNDI uses strings for attribute types, and when JNDI DirContexts typically use string values to represent the object class type.
If CP deployers dislike the fact that they can't do name-mapping with a standalone JNDI CP, they should co-deploy the _javascript_ Policy CP or equivalent to get name mapping.

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 3/13/07 12:57 PM >>>
Marc, Duane, et. al.,

So, after getting the feedback and investigating things a bit more, maybe I should propose a new option, #5 -- Simple and straightforward mapping scenarios handled by the CP, however the CP chooses, with more complex things handled by a higher level CP.  Maybe Marc and Duane were just voting for option #1.  Having a CP be "ignorant" of anything beyond what the remote source gives it is basically option #1.  However, I believe that the basic tenet of IdAS is that the CPs are supposed to present a consistent face to the IdAS user and what I was implying earlier was that option #1, I believe, violates that tenet.  That is, the CP MUST do SOME mapping.  So, maybe that's option #5.

I think Marc is suggesting that we do simple, straightforward, though inflexible configuration options that do get the basic job done.

With respect to name mapping, this is, in fact, what we've already done in the JNDI CP to date.  There are two configuration elements which define what to tack on to the front (say, "cn=") and what to tack onto the back (say, ",ou=people,dc=wag,dc=bandit-project,dc=org") of the subjectID passed in.

With respect to attribute mapping, we could do the exact same kind of inflexible configuration elements.  They'd say "here's what you tack on the front of the LDAP schema to make it look like a Higgins OWL type".

Personally, I'd like to be more flexible (and, frankly, less ugly) than that, even for the simple scenarios.  After I wrote my message this AM, I looked at what Duane had toolkitized and it's actually quite easy to add a _javascript_ PDP to any provider.  In fact, the Open ID CP is already using that code for some special PDPs of its own.  So, that is also contributing to my desire to try what we'll now call "option #5".  I guess it's still option #1 but with the JNDI CP choosing to implement it's "simple" mappings via option #4.  Each CP would basically follow the principles Marc is describing and choose it's own method to follow the basic tenets of IdAS.  I don't know what the performance footprint difference would be but the default policy for the JNDI CP on these would be very simple so the execution would not be the issue.  I would also cache each PDP I support so I'm not too worried about this being a huge performance cow especially in light of the flexibility I'd get.  Implementing the JNDI CP this way would also allow me to support the CardSpace scenario (a very "simple" deployment from the CP perspective) without requiring the _javascript_ Policy CP.

If someone comes asking for more complex policy, mapping, conversion, transformation, etc.  We'll rely on a higher level CP such as the _javascript_ Policy CP and add support for more complex things there.

Any comments, questions, modifications on this approach?  


>>> "Marc Boorshtein" <mboorshtein@xxxxxxxxx> 3/13/2007 11:21 AM >>>

Based on my experience writing and deploying virtual directory
infrastructure (~ 2 years writing & deploying virtual directory
infrastructure for octet string (now oracle) and ~ 2 dozen deployments) I
found that any type of adapter should be self contained and be "ignorent" of
anything beyond a mapping from the remote source (ldap, db ...).

For instance I'll apply this idea to the JNDI CP:

1.  the name it gets can be mapped into a DN.  so for instance the JNDI CP
assumes that the username is the rdn of a pre-defined DN structure.  This
should always be the case.  If this is not the case a "higher level" cp
should be responsible for making sure that this works.  For instance, lets
say the username is an email address.  The higher level mapping would then
get the users uid based on the email and pass the uid down to the JNDI cp.

2.  The JNDI CP only knows how to translate LDAP attributes to Higgins
attributes.  There is a standard mapping (perhaps extensible).  Lets say
there needs to be a composite attribute based on the givenName and sn (maybe
not the best example for an LDAP CP, but better for a JDBC based CP).  The
JNDI CP should not be responsible for generating this attribute because it
doesn't know it exists in the remote resource.  The mapping CP would be
responsible for
    A. making sure that all responses for the attribute are fulfilled
    B.  making sure that any request for the attribute are properly
handled.  For instance a request for "cn" should actually be a request for
givenName and sn.  The filter "(cn=Joe Smith)" should actually be

Taking the above approach offers several advantages:
1.  CPs are easier to implement as they do not concern themselves with
anything by the remote resource and mapping it back into the local context.
2.  Its easier to create a "library" of mappings that can be re-used across
several CP implementations

As you mention above, integrating the mapping into the CP would cause a lot
of headaches and requiring a _javascript_ based mapper could really hurt
performance.  What if there was a common mapping utility library for
simplistic 1-1 mappings that CP developers could utilize?  This way they
don't have to code mapping management into their CP while still being able
to keep it simple.

higgins-dev mailing list

higgins-dev mailing list