Multiple ldap DataConnectors returning attributes wit the same name

[Douglas E. Engert]

On 6/5/2013 5:14 PM, Cantor, Scott wrote:
> On 6/5/13 4:02 PM, "Douglas E. Engert" <deengert at anl.gov> wrote:
>>
>> I would like to have two LDAP DataConnectors that both need to return a
>> CN attribute.
>> How can I have one return CN as the attribute and the other return some
>> other name so the two attributes don't get mixed up?
>>
>> I may be missing something simple, but is there a way to add a prefix
>> to the name of the attributes listed in one of the <ReturnAttributes>
>
> Not that I'm aware (if there is Daniel will know, or you'll find something
> in the vt-ldap docs about it). There definitely is nothing in the IdP
> itself.

Did not find any info in their docs, and no one from vt-ldap has responded.

>
> I think what you'd normally end up doing to work around it is to generate
> attribute definitions based on each connector individually, and then
> depend on those definitions in whatever higher level definition needs both.

What it appease is each data connector will add its cn(s) to the cn basic attribute.

This appears to be a limitation in the data connector logic i.e. assuming that the
LDAP attributes returned map directly to Shibboleth basic attributes of the same name.

>
> I'm assuming you do actually need both in one higher level definition.
> Otherwise just limit your dependency in a particular case to one connector
> or the other, and CN should be only what comes back from that connector.

This exercise in using a second data collector goes back to my note
of 6/3/2013 "Limiting admin identities to selected SPs" where the second
data collector is retrieving the restrictions being placed on the
user in order to do what Scott said on 6/3/2013:

  "Excluding data from a Success response is a much more straightforward
   way to support an application's error handling then using a status code."

In our case, the only common attribute between the 2 data collectors is cn.
This may not be a big problem for us, as it looks like we really don't need
the cn for the user, but need the cn(s) from the second data connector.


>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444