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.smotra...@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
