There have been a number of us on this list asking for clarification & better documentation on LDAP attribute resolution & mapping for 4.x . My last attempt was in July to get clarification on the issue in reference to mapping a principalIdAttribute to a queried LDAP attribute with no response from the community or developers (no offense to either.)
I agree, the docs erronously point to older 3x LDAP context docs that no longer apply, but that¹s about as far as I got. Luckily I¹ve had other projects put our CAS upgrade on the back burner, but I wanted to let you know you¹re not alone in this matter. Good luck, ‹ Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University On 8/28/14, 2:06 PM, "David A. Kovacic" <[email protected]> wrote: >All, > >After much trial and error I believe I have LDAP attribute retrieval >under 4.0.0 working, at least I am seeing searches in our LDAP logs. >Unfortunately, I am unsure how to verify if CAS is indeed storing those >values it gets back in the principal as it is supposed to, or if it is >just silently discarding them. In short, is there some way to dump the >principal after authentication, or some other way to tell if the >attributes have been properly stored. I am doing a straight 4.0.0 >deployment to production from rubyCAS so I have no 3.5.2 experience (or >production server) to fall back on. My deadline for deployment is fast >approaching, and the concentration of answers in cas-user seems to be >all for 3.5.2. I at least am starting to get slightly desperate..... > >If someone can PLEASE take a look here and tell me how to verify or not >whether this is now actually correctly working. If you can at least >point me in the direction so I can do my own debugging, I would >appreciate it. > >For those others that have been struggling with this, here's what I did >to get this working: > >From the ldapAuthenticationManager bean" > > <bean id="ldapAuthenticationHandler" > class="org.jasig.cas.authentication.LdapAuthenticationHandler" > >p:principalIdAttribute="uid" > ><!-- This seems to need to be the LDAP attribute to search on --> > 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="uid" value="user" >/> <!-- This maps CAS "user" to >LDAP "uid" does this go in the principal??? --> > <entry key="mail" value="mail" /> > <entry key="cn" value="displayName" /> > <entry key="eduPersonPrincipalName" >value="eduPersonPrincipalName" /> > </map> > </property> > </bean> > >This is the definition of the "primaryPrincipalResolver" that seems to >finally be working: > > <!-- > | Resolves a principal from a credential using an attribute >repository that is configured to resolve > | against a deployer-specific store (e.g. LDAP). > --> > <bean id="primaryPrincipalResolver" > >class="org.jasig.cas.authentication.principal.PersonDirectoryPrincipalReso >lver" >> > <property name="attributeRepository" ref="attributeRepository" /> > </bean> > > <!-- > Bean that defines the attributes that a service may return. This >example uses the Stub/Mock version. A real implementation > may go against a database or LDAP server. The id should remain >"attributeRepository" though. > +--> > <bean id="attributeRepository" > >class="org.jasig.cas.persondir.LdapPersonAttributeDao" > ><!-- NOTE: Do NOT use >org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao --> > p:baseDN="${ldap.authn.baseDn}" > >p:searchFilter="uid={0}" > ><!-- For some reason using a property defined in cas.properties does NOT >replace the variable --> > p:searchControls-ref="searchControls" > >p:connectionFactory-ref="searchPooledLdapConnectionFactory" > ><!-- Using the same pooled connection for authentications --> > p:resultAttributeMapping-ref="resultAttributeMap" >/> <!-- Originally had a >queryAttributeMapping-ref in here as well --> > > ><!-- removing the queryAttribute.... got things working --> > > <util:map id="resultAttributeMap"> > <entry key="uid" value="user" /> > <entry key="mail" value="email" /> > <entry key="cn" value="displayName" /> > <entry key="eduPersonPrincipalName" >value="eduPersonPrincipalName" /> > </util:map> > > <bean id="searchControls" > class="javax.naming.directory.SearchControls" > p:searchScope="2" >/> <!-- This sets >subtree searches --> > >This is what we are seeing now in our LDAP logs....... >This is the search by the authenticaion special user to get the DN of >our test user (floober) >[28/Aug/2014:16:00:45 -0400] conn=10371 op=2 msgId=3 - SRCH >base="o=cwru.edu,o=isp" scope=2 filter="(uid=floober)" attrs="1.1" >[28/Aug/2014:16:00:45 -0400] conn=10371 op=2 msgId=3 - RESULT err=0 >tag=101 nentries=1 etime=0 > >This is the actual authentication BIND test >[28/Aug/2014:16:00:45 -0400] conn=10368 op=1 msgId=2 - BIND >dn="uid=floober,ou=Delegated Accounts,o=cwru.edu,o=isp" method=128 >version=3 >[28/Aug/2014:16:00:45 -0400] conn=10368 op=1 msgId=2 - RESULT err=0 >tag=97 nentries=0 etime=56 dn="uid=floober,ou=delegated >accounts,o=cwru.edu,o=isp" > >As far as I can tell this search populates the principalAttributeMap >from the authentication handler. Note that uid is requested twice - >once for the "principalIdAttribute" property and once to map it to the >principal name of "user" - hopefully this does not break anything since >the and LDAP search with repeated attributes will only return the >attribute once. >[28/Aug/2014:16:00:45 -0400] conn=10368 op=2 msgId=3 - SRCH >base="uid=floober,ou=delegated accounts,o=cwru.edu,o=isp" scope=0 >filter="(objectClass=*)" attrs="uid uid mail cn eduPersonPrincipalName" >[28/Aug/2014:16:00:45 -0400] conn=10368 op=2 msgId=3 - RESULT err=0 >tag=101 nentries=1 etime=0 > >This seems to be the "attributeRepository" search. An entry is returned >with the proper attributes, so this >>>SHOULD<<< be properly populating >the attribute repository and the principal. >[28/Aug/2014:16:00:45 -0400] conn=10371 op=3 msgId=4 - SRCH >base="o=cwru.edu,o=isp" scope=2 filter="(uid=floober)" attrs="uid mail >cn eduPersonPrincipalName" >[28/Aug/2014:16:00:45 -0400] conn=10371 op=3 msgId=4 - RESULT err=0 >tag=101 nentries=1 etime=0 > >Thanks, >Dave > > >-- >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
