If I had to guess, I would assume that it's because the initial
connection retrieves the attributes that can be potentially passed back
as
the user ID value for the services? So for us this chunk of code looks
like:
<bean id="ldapAuthenticationHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="uid"
c:authenticator-ref="authenticator">
<property name="principalAttributeMap">
<map>
<entry key="uid" value="uid" />
<entry key="member" value="member" />
<entry key="mail" value="mail" />
<entry key="fullName" value="fullName" />
<entry key="workforceID" value="workforceID" />
<entry key="givenName" value="givenName" />
<entry key="sn" value="sn" />
<entry key="alternateCN" value="alternateCN" />
</map>
</property>
</bean>
And then there's a second chunk of code that's dedicated for the
attributes, which looks like this for us:
<bean id="attributeRepository"
class="org.jasig.cas.persondir.LdapPersonAttributeDao"
p:connectionFactory-ref="searchPooledLdapConnectionFactory"
p:baseDN="${ldap.baseDn}"
p:searchControls-ref="searchControls"
p:searchFilter="cn={0}">
<property name="resultAttributeMapping">
<map>
<!--
| Key is LDAP attribute name, value is principal
attribute name.
-->
<entry key="uid" value="uid" />
<entry key="member" value="member" />
<entry key="mail" value="mail" />
<entry key="fullName" value="fullName" />
<entry key="workforceID" value="workforceID" />
<entry key="givenName" value="givenName" />
<entry key="sn" value="sn" />
<entry key="alternateCN" value="alternateCN" />
</map>
</property>
</bean>
So ultimately we're pulling back the attributes in both places. I
would *assume* that this is to separate the "login" from the
"attribute" processes in case you want to pull your login from one
source and your attrs from a second one, but ultimately results in two
separate LDAP calls for folks who use a single source, which, IMO,
should be able to be combined. But I
guess if you were using database for auth and ldap for attrs, then this
would be necessary to have separated out.
This is what I observed from cranking up the logging levels on the
server -
I could watch in the DEBUG CAS logs that the attributes specified in the
configuration were getting picked up via the LdapAuthenticationHandler
when I logged in:
[org.ldaptive.auth.AuthenticationResponse@18963437::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS,
ldapEntry=[dn=cn=CMyers,ou=XXXX,o=XXXX[[uid[CMyers]],
[mail[[email protected]]], [sn[Myers]], [workforceID[#######]],
[givenName[Christopher]], [fullName[Christopher Myers]]],
responseControls=null, messageId=-1], accountState=null, result=true,
resultCode=SUCCESS, message=null, controls=null]
[2015-03-04 15:06:30,628] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [uid[CMyers]]
[2015-03-04 15:06:30,629] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [mail[[email protected]]]
[2015-03-04 15:06:30,629] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [fullName[Christopher Myers]]
[2015-03-04 15:06:30,629] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [workforceID[######]]
[2015-03-04 15:06:30,629] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [givenName[Christopher]]
[2015-03-04 15:06:30,629] DEBUG
org.jasig.cas.authentication.LdapAuthenticationHandler Found principal
attribute: [sn[Myers]]
but weren't stored or used anywhere. Then there is a second anonymous
call to search for the same attrSince this second call was anonymous, it wasn't
picking up the
non-public attributes that were picked up by the authenticated login:
[2015-03-04 15:06:30,630] DEBUG
org.jasig.cas.persondir.LdapPersonAttributeDao Created seed
map='{username=[cmyers]}' for uid='cmyers'
[2015-03-04 15:06:30,630] DEBUG
org.jasig.cas.persondir.LdapPersonAttributeDao Adding attribute
'username' with value '[cmyers]' to query builder 'null'
[2015-03-04 15:06:30,631] DEBUG
org.jasig.cas.persondir.LdapPersonAttributeDao Constructed LDAP search
query [cn=cmyers]
[2015-03-04 15:06:30,631] DEBUG
org.jasig.cas.persondir.LdapPersonAttributeDao Generated query builder
'[org.ldaptive.SearchFilter@-92255980::filter=cn={0},
parameters={0=cmyers}]' from query Map {username=[cmyers]}.
[2015-03-04 15:06:30,637] DEBUG
org.jasig.cas.persondir.LdapPersonAttributeDao Converted ldap DN entry
[cn=CMyers,ou=XXX,o=XXX] to attribute map {uid=[CMyers],
mail=[[email protected]], sn=[Myers], givenName=[Christopher]}
Chris
>>> "Borys Pogoreło"<[email protected]> 04/23/15 8:44 AM >>>
Hi,
> You may want to check out this project:
> https://github.com/robertoschwald/jasig-cas-examples-robertoschwald
Thanks, looks interesting and probably will help. I'll give it a try.
Why CAS is pulling attributes twice? This doesn't make sense.
> If you have the alternative of being able to provide a "master" user
to
> pull the attributes for users, you can refer to my notes when I ran
into
> a similar situation:
We're trying to get a separate account on this second LDAP which will be
able to use search at least. With this "master" user we may not have to
modify too much.
cheers,
Borys
--
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
