[9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed

[Wang Weijun]

> On Oct 7, 2015, at 11:51 PM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
> 
> Hi Max,
> 
> HttpURLConnection obtains credentials for HTTP authentication from Authenticator [1] implementation. Only one authenticator can be set in JVM instance. It can have built-in credentials, or do some interactions with user to get them. Theoretically, it can provide different credentials depending on a user/application/etc. I don't know how it is used in real application, but it seems to be a possible situation. When I was looking into this, I found a tech note [2] which says the following about fallback
> 
> ...
> Fallback
> If the server has provided more than one authentication schemes (including Negotiate), according to the processing order mentioned in the last section, Java will try to challenge the Negotiate scheme. However, if the protocol cannot be established successfully (e.g. The kerberos configuration is not correct, or the server's hostname is not recorded in the KDC principal DB, or the username and password provided by Authenticator is wrong), then the 2nd strongest scheme will be automatically used. Attention : If http.auth.preference is set to SPNEGO or Kerberos, then we assume you only want to try the Negotiate scheme even if it fails. we won't fallback to any other scheme and your program will result in throwing an IOException saying it receives a 401 or 407 error from the HTTP response.
> ...

This was written by me. As I said in the previous mail, this is the only case where I think a fallback is worth doing.

> 
> As far as I understand, the current version of HttpURLConnection doesn't seem to follow this. That's why I think it needs to be fixed. Otherwise, the tech note [2] should be updated.

Not exactly. The tech note is mostly about config error and not about wrong credentials (see the e.g. line). It is quite rare someone provides wrong credentials for one scheme and correct ones for another. If it really could happen, we should consider a more generalized fallback and not only from Negotiate.

> 
> It doesn't look like a serious issue for me (that's why it is P3, or maybe it should be P4). Furthermore, it looks like nobody has had such a problem before because I didn't fine any bug about that at https://bugs.openjdk.java.net
> 
> According to [2], Digest -> Basic fallback should not happen.

Yes, according to the words. But we are talking about what the most correct behavior is.

Thanks
Max

> HttpURLConnection is quite smart, and if I understand correctly, we have only "http.auth.preference" and Authenticator.setDefault() to control HTTP authentication process. Maybe we can make it more configurable.
> 
> [1] http://docs.oracle.com/javase/8/docs/api/java/net/Authenticator.html
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
> 
> Artem