JDK-8261605 : java.net.Authenticator cannot handle Negotiate or Digest authentication
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2021-02-11
  • Updated: 2021-02-26
  • Resolved: 2021-02-16
Related Reports
Relates :  
JDK-8229962 - java.net.http.HttpClient authentication does not work with proxy tunnel
Relates :  
JDK-8262027 - Improve how HttpConnection detects a closed channel when taking/returning a connection to the pool
Description
The java.net.Authenticator class supports Basic authentication only.  If there is a requirement to support Negotiate authentication (Kerberos) with the java.net.http.HttpClient, an Authenticator cannot be used. The calling code must handle the 401 response and generate the required Authorizaiton headers.

However use of Authenticator is _required_ if a proxy server requiring authentication is in use with https:// URLs - the proxy authentication headers must be set on the CONNECT call to the proxy.  Once an Authenticator has been set on HttpClient for use with a proxy, it becomes impossible for the calling code to handle Negotiate authentication.
Comments
Closing as Not An Issue: It is possible to handle both proxy-authentication (407) and server authentication (401) manually by supplying the proper Proxy-Authorization and Authorization headers to the request builder - using an HttpClient with no Authentcator. This work both with http and https (proxy tunneling). See also note above about enabling/disabling proxy authorization schemes.
16-02-2021
Please do close. Apologies for a non-bug and wasted time but I do now know how to do what we need in current Java versions.
16-02-2021
One simple resolution could be to provide a method on HttpRequest.Builder to set headers explicitly for use with a proxy server. These would be used with the CONNECT method when proxying for HTTPS. Then the client can handle the 401 and 407 responses manually and deal with whatever authentication methods it cares to.
16-02-2021
Just tested with Java 15 - I that the Proxy-Authenticate header _is_ sent with the CONNECT method. Apologies, I was assuming same behaviour as in 1.8. Seems that it is possible to handle both 401 and 407 manually.
16-02-2021
It should already be possible to deal both with 401 and 407 manually if you don't provide an Authenticator. Also - if you're attempting to authenticate with a proxy - please note the following: The java.net.HttpClient, like HttpURLConnection, honors the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties. From the Release Notes for JDK 8 and JDK 8 Update Releases https://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html "core-libs/java.net Disable Basic authentication for HTTPS tunneling In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemes networking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line. Additionally, the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively." see also: JDK-8210814 PS: if the problem persists, could you try with a more recent version (e.g. Java 15)?
16-02-2021