Working around issue of load balancer idle timeout to LDAP data connector

[Fisher, Daniel]

> On Jul 6, 2024, at 1:17 AM, Baron Fujimoto via users <users at shibboleth.net> wrote:
> 
> We ultimately determined that this appears to be because the load balancer in front of our LDAP uses a 51 second idle timeout value for LDAP clients as part of its direct server return feature. We hypothesize that the clients utilize these LDAP pools, where they assume there are persistent connections available, but they may not use them with a frequency less than 51s idle timeout. This results in situations where the clients try to use the connections they assume are there, but the LB has already dropped the connection because the idle timeout has been exceeded.

This is a fairly common problem with load balancers. The LB is not tearing down the client connection and consequently the IDP doesn’t know the connection is defunct until it tries to use it.

> 
> For now we appear to have mitigated this problem by setting the validateTimerPeriod in our LDAP data connector definition in attribute-resolver.xml to 30 seconds, a value well below the LB's idle timeout value.
> 

This is the most common solution to this problem. A discussion with your LDAP administrator is probably in order. That sort of configuration would lead me to believe they do not want clients attempting to maintain persistent connections. So you’ll be fighting against that policy if you attempt to configure pooling in the IDP.

> Another approach we considered that ought to be reliable, would be if the connection were validated before use. It seemed like maybe validateOnCheckout might do this, but setting this to attribute to true in the LDAP connector does not seem to have the desired effect. Both the IdP and ldaptive documentation is ambiguous on exactly what Checkout and its relationship to the use of the connection is.

Setting validateOnCheckout can be a viable solution, although perhaps not a desirable one. This will validate the connection before it is used by the IDP. The default implementation will make maxPoolSize + 1 attempts to find a working connection, but will not execute longer than the blockWaitTime is configured. So if your entire connection pool is defunct it will dispose of all the connections attempting to find something that will work and you may still not get a working connection if that takes longer than blockWaitTime. But you can tune the maxPoolSize and blockWaitTime accordingly if you go down that path.

> 
> Another viable option would be to have the IdP retry/reopen the closed LDAP connection in this situation.
> 
> It appears the IdP supports (at least for LDAP Authn)
> - LDAP.autoReconnect (default = true): "Whether lost connections should be automatically reopened", but that doesn't seem to be happening here.
> 

This setting won’t help you. Auto reconnect works when the client detects that the connection has been closed. Since your load balancer isn’t tearing down the connection the client is unaware that the connection needs to be reopened.

—Daniel Fisher