[Merge-54][net/auth] Don't abort network transaction over non-permanent auth errors.

[Merge-54][net/auth] Don't abort network transaction over non-permanent auth errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG=648366
Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)

Committed: https://chromium.googlesource.com/chromium/src/+/4a2c7f5c92f114f0fbab7d8a5afe611b243fa286

[asanka, 2016-10-19 18:11:46]

Description was changed from

==========
[Merge-54][net/auth] Don't abort network transaction over non-permanent auth
errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG=648366

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)
==========

to

==========
[Merge-54][net/auth] Don't abort network transaction over non-permanent auth
errors.

A multi-round authentication handshake may break partway through with an
error that indicates that the credentials used were invalid. With GSSAPI
we've seen this come up when the underlying library attempted to
authenticate against an endpoint even though no valid credentials were
available to finish the handshake. On Windows, this is now possible
since KB3189866.

Due to the fact that the underlying libraries attempt to start the
authentication handshake, the HttpNetworkTransaction proceeds past the
point where the HttpAuthController accepts the challenge and picks an
identity to use for the handshake. However, when the time comes to
generate a token, which happens just prior to sending the next HTTP
request, the HttpAuthController fails the operation with an
ERR_INVALID_AUTH_CREDENTIALS error. The state machine can't proceed past
this error and the user ends up looking at an error page.

e.g.:

  C->S : GET something

  S->C : HTTP/1.1 401 You shall not pass
         WWW-Authenticate: Negotiate

  C->[underlying authentication library, hereafter called UAL] :
         "Can you authenticate to example.com?"

  [UAL]->C: "Sure thing. Here's a token to get started : [token1]"

  C->S : GET something
         Authorization: Negotiate [token1]

  S->C : HTTP/1.1 401 Need moar authentication
         WWW-Authenticate: Negotiate [token2]

  C->[UAL]: "example.com gave us [token2]. What should we do now?"

  [UAL]->C: "LOL. Who knows? Look a squirrel!"

  C: ...

  C: Shows ERR_INVALID_AUTH_CREDENTIALS to the user.

This should be considered a permanent error if there is actually no
other way to proceed. However, if there are other authentication schemes
to try, or if the initial authentication attempt was made using ambient
credentials and the scheme supports explicit credentials, then those
should be attempted next.

This CL changes the response of the network stack at the final step to
restart the network transaction by sending a request with no
Authorization header. This signals to the server that the client is
restarting the authentication handshake. It can then start over at which
point the client can attempt to use a different identity or a different
authentication scheme to proceed.

R=mmenke
BUG=648366

Review-Url: https://codereview.chromium.org/2382293004
Cr-Commit-Position: refs/heads/master@{#424563}
(cherry picked from commit e2257db89c38e2846d27a6de41a1ed4804ee5cab)

Committed:
https://chromium.googlesource.com/chromium/src/+/4a2c7f5c92f114f0fbab7d8a5afe...
==========

[asanka, 2016-10-19 18:11:47]

Committed patchset #1 (id:1) manually as
4a2c7f5c92f114f0fbab7d8a5afe611b243fa286.