> Now I’d like to know why it worked and why you’d want pooling to ever be > set?
This sort of pooling can be described as JNDI context pooling. The "pooled" property sets the "com.sun.jndi.ldap.connect.pool" system property to true; see http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html for more information. This is a very convenient way to perform LDAP pooling and is suitable for the case where one is using the same principal to perform operations. In the case of BindLdapAuthenticationHandler, you're using the admin user to perform the initial search for the DN of the authenticating user, then switching to the DN/password of the authenticating user for the following bind operation to verify credentials. You would _never_ want JNDI context pooling in that case because there is the possibility for escalation of privileges under certain circumstances. That said, you almost certainly want LDAP pooling for a production deployment. Spring provides an object-based pooling strategy as of 1.3.0, PoolingContextSource, and you would want to use that for pooling LDAP connections in CAS. We have tested this pretty thoroughly in our dev and pre-production environments and are very happy with it. 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
