da5932affc
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
10 lines
421 B
YAML
10 lines
421 B
YAML
---
|
|
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.
|