Skip to main content

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

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.

Well, just to clarify I think that the IdAS should have a standard as
how to name attributes.  For instance most virtual directories manage
this by standardizing on LDAP concepts (entries, multi value
attributes and DN based names).  The CP should be responsible for
mapping to this standard.  In addition to mapping to the IdAS standard
data representations there may also be application specific mappings.
My example of mapping cn from givenName and sn is such an example.
These types of application mappings should be specific to a deployment
and shouldn't be the responsibility of a CP.


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.


Again to clarify.  The JNDI CP assumes that the username is the RDN of
an LDAP DN.  What if (as is the case with AD) that the rdn is not a
username?  AD uses the cn as the rdn attribute while samaccountname is
used for the username.  In this scenario a mapping cp would need to
get the CN attribute based on the value of the samaccountname
attribute supplied by the user.  (I currently disagree with this
design, but thats another discussion).  So the point of my original
analogy is that the CP is "ignorent" to a degree of the application
while performing the needed mapping for the common IdAS
infrastructure.


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


Not sure I follow.  My thought would be more like a config file (or
maybe part of the CP cfg?)  that says ldap:cn=idas:http://..... this
can be utilized as a tool for simple mappings and the author of the CP
is responsible for anything more complex.

The main point I am trying to make is that there are two uses of the
word "mapping" here.  The first is the mapping from the local resource
to the IdAS and the second is the mapping of an applications needs to
what data stores may provide.  The first is perfectly acceptable (and
should be expected) to be required by any CP.  The second is where I
see a JS based CP most useful.

Marc


Back to the top