Respect delay_auth_decision when Keystone is unavailable

The delay_auth_decision option has two main uses:

  1. Allow a service to provide its own auth mechanism, separate from
     auth tokens (like Swift's tempurl middleware).
  2. Allow a service to integrate with multiple auth middlewares which
     may want to use the same X-Auth-Token header.

The first case works fine even when the service has trouble talking to
Keystone -- the client doesn't send an X-Auth-Token header, so we never
even attempt to contact Keystone.

The second case can be problematic, however. The client will provide
some token, and we don't know whether it's valid for Keystone, the other
auth system, or neither. We have to *try* contacting Keystone, but if
that was down we'd previously return a 503 without ever trying the other
auth system. As a result, a Keystone failure results in a total system
failure.

Now, when delay_auth_decision is True and we cannot determine whether a
token is valid or invalid, we'll instead declare the token invalid and
defer the rejection. As a result, Keystone failures only affect Keystone
users, and tokens issued by the other auth system may still be validated
and used.

Change-Id: Ie4b3319862ba7fbd329dc6883ce837e894d5270c

1 files changed, 9 insertions, 0 deletions

diff --git a/releasenotes/notes/delay_auth_instead_of_503-f9b46bf4fbc11455.yaml b/releasenotes/notes/delay_auth_instead_of_503-f9b46bf4fbc11455.yaml
new file mode 100644
index 0000000..11ce28a
--- /dev/null
+++ b/releasenotes/notes/delay_auth_instead_of_503-f9b46bf4fbc11455.yaml
@@ -0,0 +1,9 @@
+---
+fixes:
+  - |
+    When ``delay_auth_decision`` is enabled and a Keystone failure prevents
+    a final decision about whether a token is valid or invalid, it will be
+    marked invalid and the application will be responsible for a final auth
+    decision. This is similar to what happens when a token is confirmed *not*
+    valid. This allows a Keystone outage to only affect Keystone users in a
+    multi-auth system.