[9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP
authentication scheme if negotiate process failed for some reason, and a
user didn't specify SPNEGO or Kerberos in "http.auth.preference" system
property. But no fallback happens if, for example:
- an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
- first, a user provides correct Kerberos credentials, and a connection
is successfully established with Negotiate scheme
- then, a user provides wrong Kerberos credentials, but correct Basic
credentials
This fix updates HttpURLConnection to try another authentication scheme
negotiate process failed, and SPNEGO and Kerberos schemes are not
preferred. The fix may be shorter, for example:
if ( serverAuthentication != null || inNegotiate &&
!"negotiate".equals(AuthenticationHeader.authPref)) {
, but I thought that some logging might be helpful.
Also added a test which checks this and a couple of other scenarios work
fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
Artem
Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
Thanks for handling Artem. I'll leave the main review to someone more
knowledgeable with http authentication schemes but can I suggest that
your print the AuthenticationHeader.authPref string out with the
"Negotiate process failed, fallback" logger message. It's a useful
variable to capture.
Regards,
Sean.
On 07/10/2015 12:19, Artem Smotrakov wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP
authentication scheme if negotiate process failed for some reason, and
a user didn't specify SPNEGO or Kerberos in "http.auth.preference"
system property. But no fallback happens if, for example:
- an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
- first, a user provides correct Kerberos credentials, and a
connection is successfully established with Negotiate scheme
- then, a user provides wrong Kerberos credentials, but correct Basic
credentials
This fix updates HttpURLConnection to try another authentication
scheme negotiate process failed, and SPNEGO and Kerberos schemes are
not preferred. The fix may be shorter, for example:
if ( serverAuthentication != null || inNegotiate &&
!"negotiate".equals(AuthenticationHeader.authPref)) {
, but I thought that some logging might be helpful.
Also added a test which checks this and a couple of other scenarios
work fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
Artem
Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
I will look into this. Busy on something else at the moment.
Do you think this would happen in reality? There weren't a lot of fallback in
HTTP auth, IMO, is that because in most cases username and password are the
same for all schemes, and if one fails, we believe the pair is wrong and there
is no need to try another. Negotiate was picked as a special case because
configuration could go wrong even if the username and password are correct, and
we provide a fallback.
For example, what about fallback from Digest to Basic? Could the digest
credentials be provided correctly at first and wrong later? What would happen?
I haven't read the HttpURLConnection class for a long time and I could be wrong.
Thanks
Max
> On Oct 7, 2015, at 7:19 PM, Artem Smotrakov
> wrote:
>
> Hello,
>
> Please review this for 9.
>
> According to [1], an HTTP client should try to use another HTTP
> authentication scheme if negotiate process failed for some reason, and a user
> didn't specify SPNEGO or Kerberos in "http.auth.preference" system property.
> But no fallback happens if, for example:
> - an HTTP server supports both Negotiate (via Kerberos) and Basic
> authentication schemes
> - first, a user provides correct Kerberos credentials, and a connection is
> successfully established with Negotiate scheme
> - then, a user provides wrong Kerberos credentials, but correct Basic
> credentials
>
> This fix updates HttpURLConnection to try another authentication scheme
> negotiate process failed, and SPNEGO and Kerberos schemes are not preferred.
> The fix may be shorter, for example:
>
> if ( serverAuthentication != null || inNegotiate &&
> !"negotiate".equals(AuthenticationHeader.authPref)) {
>
> , but I thought that some logging might be helpful.
>
> Also added a test which checks this and a couple of other scenarios work fine.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
> Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
>
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
>
> Artem
Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
Hi Sean,
Sure, it may be useful to print it out. I will update the webrev.
Artem
On 10/07/2015 05:28 PM, Seán Coffey wrote:
Thanks for handling Artem. I'll leave the main review to someone more
knowledgeable with http authentication schemes but can I suggest that
your print the AuthenticationHeader.authPref string out with the
"Negotiate process failed, fallback" logger message. It's a useful
variable to capture.
Regards,
Sean.
On 07/10/2015 12:19, Artem Smotrakov wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP
authentication scheme if negotiate process failed for some reason,
and a user didn't specify SPNEGO or Kerberos in
"http.auth.preference" system property. But no fallback happens if,
for example:
- an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
- first, a user provides correct Kerberos credentials, and a
connection is successfully established with Negotiate scheme
- then, a user provides wrong Kerberos credentials, but correct Basic
credentials
This fix updates HttpURLConnection to try another authentication
scheme negotiate process failed, and SPNEGO and Kerberos schemes are
not preferred. The fix may be shorter, for example:
if ( serverAuthentication != null || inNegotiate &&
!"negotiate".equals(AuthenticationHeader.authPref)) {
, but I thought that some logging might be helpful.
Also added a test which checks this and a couple of other scenarios
work fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
Artem
Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
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.
...
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.
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.
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
On 10/07/2015 05:39 PM, Wang Weijun wrote:
I will look into this. Busy on something else at the moment.
Do you think this would happen in reality? There weren't a lot of fallback in
HTTP auth, IMO, is that because in most cases username and password are the
same for all schemes, and if one fails, we believe the pair is wrong and there
is no need to try another. Negotiate was picked as a special case because
configuration could go wrong even if the username and password are correct, and
we provide a fallback.
For example, what about fallback from Digest to Basic? Could the digest
credentials be provided correctly at first and wrong later? What would happen?
I haven't read the HttpURLConnection class for a long time and I could be wrong.
Thanks
Max
On Oct 7, 2015, at 7:19 PM, Artem Smotrakov wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP authentication scheme if
negotiate process failed for some reason, and a user didn't specify SPNEGO or Kerberos in
"http.auth.preference" system property. But no fallback happens if, for example:
- an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
- first, a user provides correct Kerberos credentials, and a connection is
successfully established with Negotiate scheme
- then, a user provides wrong Kerberos credentials, but correct Basic
credentials
This fix updates HttpURLConnection to try another authentication scheme
negotiate process failed, and SPNEGO and Kerberos schemes are not preferred.
The fix may be shorter, for example:
if ( serverAuthentication != null || inNegotiate &&
!"negotiate".equals(AuthenticationHeader.authPref)) {
, but I thought that some logging might be helpful.
Also added a test which checks this and a couple of other scenarios work fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
Artem
Re: [9] RFR 8138953: HttpURLConnection doesn't fallback to another auth scheme if negotiate process failed
Please see updated webrev
http://cr.openjdk.java.net/~asmotrak/8138953/webrev.01/
Artem
On 10/07/2015 06:51 PM, Artem Smotrakov 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.
...
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.
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.
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
On 10/07/2015 05:39 PM, Wang Weijun wrote:
I will look into this. Busy on something else at the moment.
Do you think this would happen in reality? There weren't a lot of
fallback in HTTP auth, IMO, is that because in most cases username
and password are the same for all schemes, and if one fails, we
believe the pair is wrong and there is no need to try another.
Negotiate was picked as a special case because configuration could go
wrong even if the username and password are correct, and we provide a
fallback.
For example, what about fallback from Digest to Basic? Could the
digest credentials be provided correctly at first and wrong later?
What would happen?
I haven't read the HttpURLConnection class for a long time and I
could be wrong.
Thanks
Max
On Oct 7, 2015, at 7:19 PM, Artem Smotrakov
wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP
authentication scheme if negotiate process failed for some reason,
and a user didn't specify SPNEGO or Kerberos in
"http.auth.preference" system property. But no fallback happens if,
for example:
- an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
- first, a user provides correct Kerberos credentials, and a
connection is successfully established with Negotiate scheme
- then, a user provides wrong Kerberos credentials, but correct
Basic credentials
This fix updates HttpURLConnection to try another authentication
scheme negotiate process failed, and SPNEGO and Kerberos schemes are
not preferred. The fix may be shorter, for example:
if ( serverAuthentication != null || inNegotiate &&
!"negotiate".equals(AuthenticationHeader.authPref)) {
, but I thought that some logging might be helpful.
Also added a test which checks this and a couple of other scenarios
work fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138953
Webrev: http://cr.openjdk.java.net/~asmotrak/8138953/webrev.00/
[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/net/http-auth.html
Artem
RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(net)
Hello, Actually I am searching through the JBS for low hanging fruits. Right now i am looking through the openjdk-sources and try to evaluate if i can make something about JDK-5108778. Please find my webrevs for the jdk(net) repos at: http://cr.openjdk.java.net/~sebastian/5108778/net/webrev.00/ The changes are javadoc only. For some general discussion on regression-tests for this please find the thread in discuss[0][1] and for the general suggestion to make more wrapper-type-constructors deprecated find [2] at core-libs-dev. [0] http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html -- Sebastian
