RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

[Michael Osipov]

On Tue, 8 Feb 2022 13:51:57 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened?
> 
> It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server.

Let me add a few points for consideration from my usecases, since I don't use any password-based authentication with SASL and Active Directory only:
* `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not properly populated, CRL misconfigured, etc. Will an exception also thrown here?
* `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I am thinking whether fail fast is reasonable. SPN not registered, next server might have. replay/out of sequence, etc.

> In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only.

But the auth is part of the LDAP message as well since the auth does not happen out of band. I would expect that any non-transport issue should fail fast.

> Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768?

Not really, I virtually never had problems, thought might need annotations when this does not work, see above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043