[Merge M55] [net/auth] Deal better with ERR_INVALID_AUTH_CREDENTIALS error.

[Merge M55] [net/auth] Deal better with ERR_INVALID_AUTH_CREDENTIALS error.

This merges e2257db89c38e2846d27a6de41a1ed4804ee5cab,
463ca4262fc277c5e724d02705ba1a61cbc4e849, and
1d50f4974f89eebc449b0b8747b299267504e7ed to the M55 branch. Commit
messages follow in reverse order:

TBR=asanka@chromium.org

[net/auth] Treat ERR_INVALID_HANDLE as a identity invalidating error.

BUG=648366
Review-Url: https://codereview.chromium.org/2507253002
Cr-Commit-Position: refs/heads/master@{#432922}
(cherry picked from commit 1d50f4974f89eebc449b0b8747b299267504e7ed)

[net/auth] Discard current handler token generation fails.

Errors that occur during token generation should be considered fatal for
that instance of HttpAuthHandler. I.e. the handler should not be used to
process any additional authentication challenges and definitely should
not be used to generate any tokens.

Why? Because, any external state associated with an HttpAuthHandler may
not in a consistent or known state. While we would like to write auth
handlers that revert to a known safe state after a token generation
failure, that is not trivial when dealing with external token sources
with unpredictable behavior. Hence we are going to take the safer option
of tearing down the HttpAuthHandler following such a failure event.

In the case referred to in https://crbug.com/648366, we were leaving the
HttpAuthSspiWin in a state where it was expecting a new token, but the
credential handle it was in posession of could no longer be used to
generate a new token. This resulted in an ERR_INVALID_HANDLE error.
Oops.

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

[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/+/ae36ee015f06bbc8f925ef391b720828bb893407

[asanka, 2016-11-18 18:47:58]

Description was changed from

==========
[Merge M55] [net/auth] Deal better with ERR_INVALID_AUTH_CREDENTIALS error.

This merges e2257db89c38e2846d27a6de41a1ed4804ee5cab,
463ca4262fc277c5e724d02705ba1a61cbc4e849, and
1d50f4974f89eebc449b0b8747b299267504e7ed to the M55 branch. Commit
messages follow in reverse order:

TBR=asanka@chromium.org

[net/auth] Treat ERR_INVALID_HANDLE as a identity invalidating error.

BUG=648366

Review-Url: https://codereview.chromium.org/2507253002
Cr-Commit-Position: refs/heads/master@{#432922}
(cherry picked from commit 1d50f4974f89eebc449b0b8747b299267504e7ed)

[net/auth] Discard current handler token generation fails.

Errors that occur during token generation should be considered fatal for
that instance of HttpAuthHandler. I.e. the handler should not be used to
process any additional authentication challenges and definitely should
not be used to generate any tokens.

Why? Because, any external state associated with an HttpAuthHandler may
not in a consistent or known state. While we would like to write auth
handlers that revert to a known safe state after a token generation
failure, that is not trivial when dealing with external token sources
with unpredictable behavior. Hence we are going to take the safer option
of tearing down the HttpAuthHandler following such a failure event.

In the case referred to in https://crbug.com/648366, we were leaving the
HttpAuthSspiWin in a state where it was expecting a new token, but the
credential handle it was in posession of could no longer be used to
generate a new token. This resulted in an ERR_INVALID_HANDLE error.
Oops.

R=mmenke@chromium.org
BUG=648366

Review-Url: https://codereview.chromium.org/2489883007
Cr-Commit-Position: refs/heads/master@{#432359}
(cherry picked from commit 463ca4262fc277c5e724d02705ba1a61cbc4e849)

[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 M55] [net/auth] Deal better with ERR_INVALID_AUTH_CREDENTIALS error.

This merges e2257db89c38e2846d27a6de41a1ed4804ee5cab,
463ca4262fc277c5e724d02705ba1a61cbc4e849, and
1d50f4974f89eebc449b0b8747b299267504e7ed to the M55 branch. Commit
messages follow in reverse order:

TBR=asanka@chromium.org

[net/auth] Treat ERR_INVALID_HANDLE as a identity invalidating error.

BUG=648366

Review-Url: https://codereview.chromium.org/2507253002
Cr-Commit-Position: refs/heads/master@{#432922}
(cherry picked from commit 1d50f4974f89eebc449b0b8747b299267504e7ed)

[net/auth] Discard current handler token generation fails.

Errors that occur during token generation should be considered fatal for
that instance of HttpAuthHandler. I.e. the handler should not be used to
process any additional authentication challenges and definitely should
not be used to generate any tokens.

Why? Because, any external state associated with an HttpAuthHandler may
not in a consistent or known state. While we would like to write auth
handlers that revert to a known safe state after a token generation
failure, that is not trivial when dealing with external token sources
with unpredictable behavior. Hence we are going to take the safer option
of tearing down the HttpAuthHandler following such a failure event.

In the case referred to in https://crbug.com/648366, we were leaving the
HttpAuthSspiWin in a state where it was expecting a new token, but the
credential handle it was in posession of could no longer be used to
generate a new token. This resulted in an ERR_INVALID_HANDLE error.
Oops.

R=mmenke@chromium.org
BUG=648366

Review-Url: https://codereview.chromium.org/2489883007
Cr-Commit-Position: refs/heads/master@{#432359}
(cherry picked from commit 463ca4262fc277c5e724d02705ba1a61cbc4e849)

[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/+/ae36ee015f06bbc8f925ef391b72...
==========

[asanka, 2016-11-18 18:47:59]

Committed patchset #1 (id:1) manually as
ae36ee015f06bbc8f925ef391b720828bb893407 (presubmit successful).