IdP 3 ldap authent vs resolving

Youssef GHORBAL youssef.ghorbal at
Fri Apr 1 19:25:17 EDT 2016

> On 02 Apr 2016, at 00:59, Cantor, Scott <cantor.2 at> wrote:
>>> 	Just quick assertions to verify if I got things right.
>>> 	- By default LDAP auth connections are poold and pool default
>> settings are handled by idp.pool.LDAP.xxxx properties.
>> My testings are showing that this is true (tcpdump). Authentication uses one
>> of the pool member connection
>> But for attribute resolution, it’s a new connection that is created (and closed)
>> each time.
> Let's be clear: properties are never the *actual* setting of anything. The properties are always plugged into a bean. If that's a system bean, it means that the only supported way of configuring something is the property, but if the bean is in a user file, then the property is strictly a convenience you can take or leave. The majority of properties are used in user space, so are entirely ignorable/removeable. It's personal preference.
> I increasingly dislike them as a deployer, but they are very useful to federations that are delivering customized "config sets”.

That’s clear !

>> So I’m expecting to see only 3 tcp connections. Am I missing something ?
> If the pool has a large max size or is a type of pool that keeps growing, I don't think the initial pool size has anything to do with the size at some other point in time.

I’ll monitor the active tcp connections to the directory and see how things evolve over time. But the DEBUG message talking about pool size of “3” still confuses me.

>> Not really, it seems to be some magic for the pool creation for auth that
>> translates seconds/minutes to ISO period format. Using
>> idp.pool.LDAP.blockWaitTime directly in a <ConnectionPool>
>> (<dc:ConnectionPool blockWaitTime=%{idp.pool.LDAP.blockWaitTime} … )
>> will raise an exception for example.
> If you're talking about duration syntax, if anything that would work in the resolver and not in the authentication beans.


Just to be honest, what confused me was that for some good reasoning the default configuration for LDAP authentication was a pooled connector. On the other hand the attribute resolver example (attribute-resolver-ldap.xml) was not pooled (and in my head I was like : "the same people with the same reasoning would end up with the same conclusion" and I was pretty sure that the example was in fact a pooled connector, where in fact it was’nt) 


More information about the users mailing list