Based on your LDAP context source config, looks like users log in with
LDAP uid, so there's no point using the following principal resolver
that looks up UID given a UID. You should use instead the default
UsernamePasswordCredentialsToPrincipalResolver.
> <!--
> |
> CredentialsToLDAPAttributePrincipalResolver supports using an LDAP server
> for user lookup
> -->
> <bean
>
> class="org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver">
> <!-- The Principal resolver form the
> credentials -->
> <property
> name="credentialsToPrincipalResolver">
> <bean
>
> class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver"
> />
> </property>
> <!-- The query made to find the
> Principal ID. "%u" will be replaced by the resolved Principal -->
> <property name="filter"
> value="(uid=%u)" />
> <!-- The attribute used to
> define the new Principal ID -->
> <property
> name="principalAttributeName" value="uid" />
> <property name="searchBase"
> value="${ldap.searchBase}" />
> <property
> name="contextSource" ref="contextSource" />
> <property
> name="attributeRepository">
> <ref
> bean="attributeRepository" />
> </property>
> </bean>
Looks like you have a pretty standard directory config where the DN
contains the username users authenticate with. Consider the
FastBindLdapAuthenticationHandler for this case. It's faster and
doesn't require a manager DN/pass.
> <bean
>
> class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler" >
> <property name="filter"
> value="uid=%u" />
> <property name="searchBase"
> value="${ldap.searchBase}" />
> <property
> name="contextSource" ref="contextSource" />
> </bean>
The following context source is suitable for authentication, but is
wasteful for your attribute repository.
> <bean id="contextSource"
> class="org.springframework.ldap.core.support.LdapContextSource">
> <property name="pooled" value="false"/>
> <property name="urls" value="${ldap.URL}" />
> <property name="userDn" value="${ldap.BindDN}"/>
> <property name="password" value="${ldap.BindPW}"/>
> <property name="baseEnvironmentProperties">
> <map>
> <entry>
> <key>
>
> <value>java.naming.security.authentication</value>
> </key>
> <value>simple</value>
> </entry>
> </map>
> </property>
> </bean>
Consider a context source that uses object pooling for
non-authentication use cases such as the attribute repository:
<bean id="pooledEdIdContextSource"
class="org.springframework.ldap.pool.factory.PoolingContextSource"
p:minIdle="${ldap.pool.minIdle}"
p:maxIdle="${ldap.pool.maxIdle}"
p:maxActive="${ldap.pool.maxSize}"
p:maxWait="${ldap.pool.maxWait}"
p:timeBetweenEvictionRunsMillis="${ldap.pool.evictionPeriod}"
p:minEvictableIdleTimeMillis="${ldap.pool.idleTime}"
p:testOnBorrow="${ldap.pool.testOnBorrow}"
p:testWhileIdle="${ldap.pool.testWhileIdle}"
p:dirContextValidator-ref="edIdDirContextValidator"
p:contextSource-ref="contextSource" />
The only other issue I can think of is your DB pooling parameters, and
you can evaluate those in the context of a stress test. Start with
defaults, then see how changes affect throughput.
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