Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
Impala 3.4.0
-
None
-
None
-
ghx-label-14
Description
When SPNEGO was first implemented for both hs2 and the webui, the way we handled requests that did not include an "Authorization" header was to pass an empty string to gss-api and then return a "WWW-Authenticate: Negotiate <token>" where <token> was whatever was returned by gss-api.
This seemed to work with the clients it was originally tested with, curl and Knox, but it has been found not to work with some other clients. In particular, the following stack trace has been observed when using java's HttpURLConnection API:
Caused by: java.lang.NullPointerException
at sun.net.www.protocol.http.NegotiateAuthentication.nextToken(NegotiateAuthentication.java:252)
at sun.net.www.protocol.http.NegotiateAuthentication.setHeaders(NegotiateAuthentication.java:209)
at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(HttpURLConnection.java:2507)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1719)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
... 20 more
Through some experimentation and by comparing our behavior with other Hadoop components, I determined that sending the initial "WWW-Authenticate" with no token works for all (tested) clients. This is also consistent with the description of the SPNEGO protocol in this document: https://tools.ietf.org/html/rfc4559#section-4.1 which states "The initial WWW-Authenticate header will not carry any gssapi-data."