resolving attributes from a different OU- best approach?

[Flannery, Sean]

Thanks Martin and all.  We use OpenDS and it looks like it supports extensible match search, like your example.  I did some playing around with it and it definitely seems to work, I just need to play around with the regex a bit.  Thanks very much for the guidance.

Cheers



________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of Martin Haase <Martin.Haase at DAASI.de>
Sent: Tuesday, February 10, 2015 2:44 AM
To: Shib Users
Subject: Re: resolving attributes from a different OU- best approach?

Hi Sean,

Am 09.02.2015 um 18:26 schrieb Flannery, Sean:
> but I'm now wondering if I can just chain together DataConnectors and
> handle this via the Dependencies support, where one Ldap Data
> Connector loads the full profile of the person, including the officeID
> attribute (which is a DN to an office object) and another Ldap Data
> Connector loads the office from the officeID attribute and gets its
> description field and releases the value as a generated attribute on
> the person, i.e. the person has an attribute value for office as "East
> Cairo" rather than "ou=a80cb6744,ou=offices"
we did this in a number of projects. As Scott said, you can chain
DataConnectors via their dependencies. However, as far as I know you
cannot, query for the (base-)DN directly, so you'd need to split your
attribute's value (RegexSplit) and then put those variables in the
filter, like:

      <resolver:Dependency ref="splitOfficesAttribute" />
        <dc:FilterTemplate>
            <![CDATA[

(&(objectClass=OfficeObject)(ou:dn:=$splitOfficesAttribute.get(0))(ou:dn:=offices))
            ]]>
        </dc:FilterTemplate>
        <dc:ReturnAttributes>description</dc:ReturnAttributes>

This does work with OpenLDAP, I'm not sure if other LDAP implementations
support the "ou:dn:=value" syntax.

Regards
Martin
>
> Does this question make sense?  How do most people handle loading data
> from a different OU?  (I'm guessing the answer is- most people have
> that data in a readable format on the person object, but unfortunately
> that's not an option for the schema / data structure we have).

--
Dr. Martin Haase, Solutions Engineer

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-6
fax:   +49 7071 407109-9
email: martin.haase at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz