LDAP DN parameter in attribute-resolver.xml IDPv4 file
Tommaso Gallo
gallo.tommaso at gmail.com
Sun Nov 21 01:02:03 UTC 2021
Hello,
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" />
<ValueMap>
<ReturnValue> student </ReturnValue>
<SourceValue partialMatch = "true"> students </SourceValue>
</ValueMap>
<ValueMap>
<ReturnValue> staff </ReturnValue>
<SourceValue partialMatch = "true"> non_teachers </SourceValue>
</ValueMap>
<ValueMap>
<ReturnValue> member </ReturnValue>
<SourceValue partialMatch = "true"> students </SourceValue>
<SourceValue partialMatch = "true"> non_teachers </SourceValue>
</ValueMap>
</AttributeDefinition>
<AttributeDefinition id = "eduPersonScopedAffiliation" xsi: type = "Scoped"
scope = "% {idp.scope}">
<InputAttributeDefinition ref = "eduPersonAffiliation" />
</AttributeDefinition>
Thank you all for your answers and suggestions.
Best regards.
Tommaso
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