[FEATURE] Multiple Simultaneous LDAP Authentication Requests with 2FA

[bluemellophone]

We are using your middleware between the browser and restricted HTML content. Suppose the authentication cookie expires while the browser has old HTML content from before the expiration. In that case, the browser may initiate a cascade of layered authentication requests to the same protected endpoint for various assets (fresh HTML + updated versions of cached files + images). When this happens, the LDAP authentication is triggered for each asset simultaneously.

This is not an urgent problem for basic LDAP deployments, but more advanced setups with two-factor authentication (e.g., Duo) can subsequently trigger several simultaneous alerts and their required 2FA notifications.

Is there a way to sequence multiple requests to the same LDAP resource before successful or failed authentication, where any pending requests for the same client or requesting IP inherit the decision of whichever LDAP response is received first? The issue we are experiencing is a single browser refresh will trigger a dozen LDAP requests and, therefore, a dozen layered 2FA notifications in less than a second.

[wiltonsr]

@fcinqmars, What do you think about this feature?

[fcinqmars]

Could probably be added. I would probably lock on the LDAP resource and client info on re-auth to hold the concurrent requests until the authorization decision is made. Some sort of locking cache could work.

If the session cookie is valid, no need to lock/hold, so performance shouldn't really be affected.

I think the challenge will be to determine what client info we want to use. If the clients are behind a NAT or if Traefik is behind a proxy or Docker, the client IP might not be all that reliable.

[Bremma]

Will add on that this issue has been affecting the use of this plugin for me. We are using FreeIPA with OTP and I am using ldapauth with Traefik to host a loadbalancer to a set of Kibana instances.

I have been able to work around this with a combination of a longer cacheTimeout period, and by advising users to access the base load balancer page (eg dev-lb.system.corp.com, not dev-lb.system.corp.com/) when authenticating or re-authenticating (eg the token has timed out and the user is prompted for a new authentication).

Will be keeping an eye on this and can help test on my systems as able!