LDAP DN parameter in attribute-resolver.xml IDPv4 file

Tommaso Gallo gallo.tommaso at gmail.com
Sun Nov 21 01:02:03 UTC 2021

finally after many tests I was able to import the DN parameter into the
"attribute-resolver.xml" file: ou = xxx, dc = aaa, dc = bbb associated with
the authenticated user.
Now I can distinguish my users using the "ou" field present in the DN
parameter, and I was able to release the "eduPersonAffiliation" and
"eduPersonScopedAffiliation" attributes by distinguishing them, using the
value of the "ou" field.
The solution was to create an InputDataConnector in the
"attribute-resolver.xml" file of my IDP that would use the "entryDN"
attributeNames in the LDAP as follows:
<InputDataConnector ref = "myLDAP" attributeNames = "entryDN" />
and then I proceeded to associate it with the attribute that I intended to
define, in my case "eduPersonAffiliation".
Below is an example of what I did:

<AttributeDefinition id = "eduPersonAffiliation" xsi: type = "Mapped"
dependencyOnly = "true">
    <InputDataConnector ref = "myLDAP" attributeNames = "entryDN" />
        <ReturnValue> student </ReturnValue>
        <SourceValue partialMatch = "true"> students </SourceValue>
        <ReturnValue> staff </ReturnValue>
        <SourceValue partialMatch = "true"> non_teachers </SourceValue>
        <ReturnValue> member </ReturnValue>
        <SourceValue partialMatch = "true"> students </SourceValue>
        <SourceValue partialMatch = "true"> non_teachers </SourceValue>

<AttributeDefinition id = "eduPersonScopedAffiliation" xsi: type = "Scoped"
scope = "% {idp.scope}">
    <InputAttributeDefinition ref = "eduPersonAffiliation" />

Thank you all for your answers and suggestions.
Best regards.

Il giorno lun 15 nov 2021 alle ore 19:46 Cantor, Scott <cantor.2 at osu.edu>
ha scritto:

> On 11/15/21, 1:39 PM, "users on behalf of Peter Schober" <
> users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at>
> wrote:
> >    (Unless I misunderstood the question.)
> One of us did. My interpretation was that it's not possible for whatever
> reason after authentication to do searches for attributes using just the
> canonical principal name, and so the DN had to be obtained explicitly out
> of the results of authentication.
> But now that I write that out....that doesn't make sense. If that were the
> requirement, then the right answer would be to make the DN string the
> canonical principal name for the IdP.
> So you're right...if you can search the directory, then....search the
> directory for the DN.
> -- Scott
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20211121/122f92bf/attachment.htm>

More information about the users mailing list