Doug, Did you ever get this working?
We were trying to do the same thing (we're also using OpenLdap), and ran into what sounds like the same problem. We did get something similar working, but we had to do some additional configuration on our LDAP server and use a different attribute name. I'm not clear on all the details, but our LDAP admin gave me this as a general reference: http://blog.oddbit.com/2013/07/22/generating-a-membero/ He said the key point was having to use a different attribute name, since memberOf is an operational attribute. I'll add that there were some issues with this new setup on our master server, it conflicted with something else, so we had to disable it there. If you do get this working, using the PersonAttributeDao as Marvin suggested, or something else, I'd appreciate hearing about it. But maybe this info will help you get it going similar to how we did it. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) [email protected] On Sat, 10 Jan 2015, Doug Campbell wrote: > Thanks Marvin for 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. I think I am not seeing this though. If I use the > manager account that is used to search the directory or the credentials of > the use who is logging in with ldapsearch, as long as I explicitly request > the memberOf attribute it gets returned. > 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. > Okay. I think I am beginning to understand. Are you saying that I should > put all my attributes that I want returned here: <bean > id="ldapAuthenticationHandler" > class="org.jasig.cas.authentication.LdapAuthenticationHandler" > p:principalIdAttribute="uid" > c:authenticator-ref="authenticator"> > <property name="principalAttributeMap"> > <map> > <!-- > | This map provides a simple attribute resolution mechanism. > | Keys are LDAP attribute names, values are CAS attribute > names. > | Use this facility instead of a PrincipalResolver if LDAP is > | the only attribute source. > --> > <entry key="ssoGUID" value="ssoGUID" /> > <entry key="givenName" value="givenname" /> > <entry key="sn" value="surname" /> > <entry key="memberOf" value="memberOf" /> > <entry key="uid" value="user" /> > </map> > </property> > </bean> and also define a stub like this to use in place of <bean > id="attributeRepository" > class="org.jasig.services.persondir.support.StubPersonAttributeDao" > p:backingMap-ref="attrRepoBackingMap" /> <util:map > id="attrRepoBackingMap"> > <entry key="uid" value="user" /> > <entry key="ssoGUID" value="ssoGUID" /> > <entry key="givenName" value="givenname" /> > <entry key="sn" value="surname" /> > <entry key="memberOf" value="memberOf" /> > </util:map> > </bean> When I did this I end up getting back just the values I specify > in the stub, not the values of LDAP. It seems like I must be getting close > but I my understanding is lacking. I appreciate you continuing to point me > in the right direction. Thanks! Doug > -- > 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 -- 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
