LdapPersonAttributeDao: source attribute to > 1 result attribute?

[Baron Fujimoto]

We're using LdapPersonAttributeDao in CAS 3.4.11's deployerConfigContext.xml
to return attributes for /samlValidate. Is there a way to configure it to
use the same source attribute to return more than one result attribute? That
is, we'd like to query "srcAttr" from LDAP and return its value as both
"resultAttr1" and "resultAttr2". Only one-to-one mappings are allowed by

<property name="resultAttributeMapping">
<map>
<entry key="srcAttr" value="resultAttr1"/>
<entry key="srcAttr" value="resultAttr2"/>
</map>
</property>

So that type of shenanigans doesn't work. Is there another way to
achieve this?
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Baron Fujimoto]

On Fri, May 06, 2016 at 04:51:33PM -1000, Baron Fujimoto wrote:
>We're using LdapPersonAttributeDao in CAS 3.4.11's deployerConfigContext.xml
>to return attributes for /samlValidate. Is there a way to configure it to
>use the same source attribute to return more than one result attribute? That
>is, we'd like to query "srcAttr" from LDAP and return its value as both
>"resultAttr1" and "resultAttr2". Only one-to-one mappings are allowed by
>
><property name="resultAttributeMapping">
> <map>
> <entry key="srcAttr" value="resultAttr1"/>
> <entry key="srcAttr" value="resultAttr2"/>
> </map>
></property>
>
>So that type of shenanigans doesn't work. Is there another way to
>achieve this?

Sorry to follow up my own post, but can anyone tell me if this is
achievable, or do I need to pursue some other non-CAS option? For example,
replicating the source attribute in LDAP seems like an unpalatable kludge.

[Daniel Ellentuck]

Hi Baron,

You can definitely get what you want without changing LDAP.  Referring to the Spring bean definitions, you could create a second personAttributeDao for your attributeRepository that adds in resultAttr2.  Or, to take it to the next level, if your requirements were more complicated and you wanted to do additional manipulation of the incoming attribute data, you could extend org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao to make it behave just like you want.

    Dan

Dan Ellentuck

Columbia University I.T.

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/20160510193746.GI766%40praenomen.mgt.hawaii.edu.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[Misagh Moayyed]

Let me ask: which of the following scenarios is what you're after:

1. Service A gets resultAttr1 and Service B gets resultAttr2
2. Service A may get both resultAttr1 and resultAttr2

I don't know why you would ever want 2, but if you answered 1, there is
this:
http://apereo.github.io/cas/4.2.x/integration/Attribute-Release.html#attribute-release-policy

See "Return Mapped".

This is a solution that solves the problem at release time.

[Baron Fujimoto]

Hi Dan,

Mahalo for the response. Do you know if there is an example of adding a
second personAttributeDao to the attributeRepository? We're currently
using an attributeRepository configuration based on an example from the
old Jasig wiki[*] that basically looks like:

<bean id="attributeRepository"
class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
<property name="contextSource" ref="contextSource" />
<property name="baseDN" value="${ldap.baseDN}" />
<property name="requireAllQueryAttributes" value="true" />

<property name="queryAttributeMapping">
<map>
<entry key="username" value="uid" />
</map>
</property>

<property name="resultAttributeMapping">
<map>
<entry key="srcAttr1" value="resultAttr1"/>
<entry key="srcAttr2" value="resultAttr2"/>
...
<entry key="srcAttrN" value="resultAttrN"/>
</map>
</property>
</bean>

I also note that this "attributeRepository" bean id is referenced in
CredentialsToLDAPAttributePrincipalResolver bean,

[*] <https://wiki.jasig.org/display/CASUM/Attributes>

Actually, upon further review of that page, I found the previously
unnoticed section (perhaps because our config was developed for <3.4.12)
which looks like it should do what we want.

<https://wiki.jasig.org/display/CASUM/Attributes#Attributes-Configuringmulti-valuedkeysupportforattributes>

However, after following those directions, the Services Management app
doesn't know about the myPersonId and personUid attributes, but only
myPersonIdSet (to use the documentation example)

Perhaps this is only available from version 3.4.12+ onwards?

[Baron Fujimoto]

I think 2. would suffice. But is that suggestion below specific to 4.x?
I'm using 3.4.11...

>To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/027101d1aafb%24d53ec930%247fbc5b90%24%40unicon.net.

>For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[Misagh Moayyed]

It is 4.x specific, yes.

> -----Original Message-----
> From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of
> Baron Fujimoto
> Sent: Tuesday, May 10, 2016 3:29 PM
> To: CAS Users <cas-...@apereo.org>
> Subject: Re: [cas-user] Re: LdapPersonAttributeDao: source attribute to >
> 1
> result attribute?
>

> user/20160510222908.GK766%40praenomen.mgt.hawaii.edu.

[Baron Fujimoto]

Whoops, typo in my config, the "multi-valued key support for attributes"
works after all. Mea culpa.

Mahalo for all the suggestions!