> memberOf is an operational attribute and so I know when I want to return
> it using ldapsearch, I have to specifically request it.
>
I'm fairly certain the implementation details are irrelevant. As long as
you have the privileges to view the attribute and it's among the requested
attributes (or you did not specify any, which results in all of them), it
should come back in the response.
> <bean id="attributeRepository"
> class="org.jasig.cas.persondir.LdapPersonAttributeDao"
> p:connectionFactory-ref="searchPooledLdapConnectionFactory"
> p:baseDN="${ldap.resolver.baseDn}"
> p:searchControls-ref="searchControls"
> p:searchFilter="uid={0}">
>
Believe I see the problem. The security context of this search is either
anonymous or using a service credential; in either case it's not the
security context of the authenticating user needed for the overlay. In
other words it's not visible to you.
You should be able to use the additionalAttributes property of
LdapAuthenticationHandler to fetch attributes and add them to the principal
at authentication time. In that case you're bound as the user, which should
satisfy the overlay. Then you'll need to use a static PersonAttributeDao to
simply define stub properties for the attributeRepository. The real values
come from the principal. That's advanced configuration that is not
documented anywhere, but most of the difficulty is with PersonDirectory
components, not CAS ones per se. I have a StaticPersonAttributesDao
component I can share with you if you get stuck, but it's pretty easy to
implement PersonAttributesDao.
M
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
