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.PersonDirectoryPrincipalResolver"
>
<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 cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
