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

[Artem Smotrakov]

Hi Max,

RFC 2617 [1] requires a user agent to use one of the challenges with the 
strongest auth scheme it understands (please see section 1.2):

...
    The user agent MUST
    choose to use one of the challenges with the strongest auth-scheme it
    understands and request credentials from the user based upon that
    challenge.
...

This RFC doesn't mention fallbacks. But Negotiate/Kerberos 
authentication requires remote KDCs (AD controllers) which may be 
temporary down for some reason. In this case, it may be better to 
fallback to another scheme in something went wrong with Negotiate. Just 
to be able to authenticate users if something is wrong with infra.

Taking into account the note about strongest auth scheme above, it might 
probably be better not to fallback to another schemes (like Digest -> 
Basic).

It is possible to use "http.auth.preference" system property to specify 
preferred auth scheme. But setting this property means that the only 
specified scheme should be used (no fallback should happen at all). 
Maybe we can add a method to HttpURLConnection which can set a scheme in 
case of fallback.

[1] http://www.ietf.org/rfc/rfc2617.txt

Artem

On 10/08/2015 11:41 AM, Wang Weijun wrote:
>> 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