Bug ID: JDK-8276959 Retrying a failed authentication on multiple LDAP servers can lead to users blocked

Type: CSR
Component: core-libs
Sub-Component: javax.naming

Priority: P4
Status: Closed
Resolution: Approved
Fix Versions: 8-pool,11-pool,17-pool,18,19

Submitted: 2021-11-10
Updated: 2022-02-08
Resolved: 2021-12-16

Summary
-------

When the authentication to an LDAP endpoint fails, do not retry authentication against other endpoints. Restore this behavior from the state previous to JDK-8160768.


Problem
-------

If the authentication to an LDAP endpoint fails because of providing wrong credentials (i.e.: a typo while entering the password), the OpenJDK client may automatically try on other endpoints without any different result expected. In addition to the resources spent, this situation can lead to the LDAP user blocked after exceeding the maximum number of authentication attempts.

Solution
--------

After getting an authentication failure on an LDAP endpoint, stop any further authentication attempts on other endpoints. The rationale behind is that the LDAP endpoint that responded with the authentication failure is alive and there is no need to keep trying.

Specification
-------------

From a specification point of view, there is no need to modify any public or internal APIs to implement this behavioral change because the methods `com.sun.jndi.ldap.LdapCtxFactory::getUsingURL` and `com.sun.jndi.ldap.LdapCtxFactory::getUsingURLs` already declare to throw a `javax.naming.NamingException` exception, and `javax.naming.AuthenticationException` is a subclass of it. The only difference is the change of behavior while iterating the URLs.

PR: https://github.com/openjdk/jdk/pull/6043

Thanks [~robm]; moving to Approved.
16-12-2021
This looks good to me. It corrects an oversight of my earlier fix. Martin is indeed correct that the failovers should not be used just to try to validate credentials that have already been rejected by a working endpoint.
16-12-2021
Moving to Provisional, not Approved.
15-12-2021
[~robm], since you worked on JDK-8160768, do you have any comments or concerns with this update?
15-12-2021
Thanks. Re-finalizing now.
13-12-2021
[~mbalao] No problem. I believe you can finalize now.
18-11-2021
Apologies for my misunderstanding of the process. Thanks for the feedback, I'll update the CSR.
17-11-2021
Moving back to Draft. [~mbalao], please have one or more other engineers review the CSR and indicate one or more releases in the fixVersions field before Proposing or (re-)Finalizing this request.
10-11-2021
[~mbalao] in principle you should get the CSR reviewed by a peer before finalizing it, and have them add their names in the CSR reviewers list (see reviewers box in the UI when you press on "Edit"). WRT to compatibility - isn't it possible that an environment in which the first server always fails to authenticate the user, and where the second server accepts the provided credential, would have returned a result before your change and will now fail after it? If that is a possible (even though unlikely scenario) - maybe it should be noted in the compatibility section of the CSR.
10-11-2021