This can create a race condition for long running services that reuse
their token (eg. Kubernetes Cinder CSI plugin) in this case for
example:
1 [user] Asks nova to attach a volume to a server
2 ...the user's token expires
3 [user] Asks cinder if the volume has been attached
4 [nova] Asks cinder to attach the volume
In step 3 the token is marked as invalid in the cache and step 4 fails
even if allow_expired is true
Closes-Bug: #1987355
Change-Id: Ice8e34440a5fe1baa370646ed70b5e085c4af70e
In [0] the ``interface``option was added in order to allow the Identity
endpoint that is being used when validating tokens to be
configured by the deployer. Change the default to using the internal
endpoint, as that should be what most deployments will end up using.
[0] https://review.opendev.org/651790
Depends-On: https://review.opendev.org/651492
Closes-Bug: 1830002
Change-Id: I0ce8b6d8cd408c7fac8107972e7be70839e337fb
Now that we no longer support py27, we can use the standard library
unittest.mock module instead of the third party mock lib.
Change-Id: Idc319f3f8a3ddd57cba91e4cefc66dbb18d5cc22
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This change removes v2.0 functionality from
keystonemiddleware, as well as associated tests.
Partial-Bug: #1845539
Partial-Bug: #1777177
Change-Id: If47e90085d8a59c52fb23876dc329cd4f0b05ef0
This change replaces the usage of keystoneclient exceptions in the
auth_token_middleware unit tests to use the ConnectFailure exception
from keystoneauth.
This is part of the process of removing keystoneclient from
keystonemiddleware.
Change-Id: Ie00fc310728c319faf2cfdfb651f0c7a8f48d757
Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future.
The usual offset is +15 years, because that is how long I expect some software will be used in some places.
This showed up failing tests in our package build.
See https://reproducible-builds.org/ for why this matters.
This makes it expire 1 year in the future to model realistic tokens.
Change-Id: I73bde68be53afff4e8dff12d756b8381f34b2adb
This commit adds a validation step in the auth_token middleware to check
for the presence of an access_rules attribute in an application
credential token and to validate the request against the permissions
granted for that token. During token validation it sends a header to
keystone to indicate that it is capable of validating these access
rules, and not providing this header for a token like this would result
in the token failing validation. This disregards access rules for a
service request made by a service on behalf of a user, such as nova
making a request to glance, because such a request is not under the
control of the user and is not expected to be explicitly allowed in the
access rules.
bp whitelist-extension-for-app-creds
Depends-On: https://review.opendev.org/670377
Change-Id: I185e0541d5df538d74edadf9976b3034a2470c88
Keystone server no longer supports PKI/PKIZ. This change removes
keystonemiddleware's support of PKI/PKIZ and associated code.
Change-Id: I9a6639a2aa3774be61972d57f38220f66fd5c0e8
closes-bug: #1649735
partial-bug: #1736985
Currently auth_token middleware does not concern identity endpoint
update since service catalog is not updated after service having
auth_token middleware started.
Add invalidation logic when EndpointNotfound exception occurs so
that auth_token middleware can be notified of sevice catalog update
without restart.
Change-Id: I631ee1538883d732fe3987b172d987f703dad5c0
Closes-Bug: #1813739
With keystone's move to eliminating pki, pkiz, and uuid tokens the
revocation list is no longer generated. Keystonemiddleware no longer
needs to attempt to retrieve it and reference it.
Change-Id: Ief3bf1941e62f9136dbed11877bca81c4102041b
closes-bug: #1361743
partial-bug: #1649735
partial-bug: #1736985
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
DiscoveryFailures can happen for a variety of reasons, ranging
from service misconfiguration to a keystone outage to a transient
network failure. If we don't catch and handle the failure here,
it will almost certainly cause something further up the WSGI stack
to send a 500 Internal Error (and likely log a traceback).
A log line like
Unable to validate token: Could not find versioned identity
endpoints when attempting to authenticate. Please check that
your auth_url is correct. Unable to establish connection to
http://keystone:35357: HTTPConnectionPool(host='keystone',
port=35357): Max retries exceeded with url: / (Caused by
NewConnectionError('<urllib3.connection.HTTPConnection
object at 0x7fc53e22e050>: Failed to establish a new
connection: [Errno 111] ECONNREFUSED',))
should be plenty enough for an operator to assess the situation;
I don't need a 29-frame traceback.
Change-Id: I946388c09b2ca0230d2cef009c679a7ac7c8398f
Keystonemiddleware attempts to parse user/service tokens and populate
request headers for other services to consume. This information is
important for services looking to build oslo.context objects from
request environments.
Change-Id: I0717c2a5207a647999b4f9bcdf11f728984f0812
Closes-Bug: 1766731
Based on the RFCs[1], in http header, a string of text is parsed
as a single value if it is quoted using double-quote marks.
This patch change the single quote to double quote in the header
"WWW-Authenticate" which is returned when 401 error raises.
[1]: https://tools.ietf.org/html/rfc7230#section-3.2.6https://tools.ietf.org/html/rfc7235#section-2.1
Change-Id: I524c93d30607ea6ab70de92ceea207ee77f34c25
Closes-bug: #1762362
When handling timeouts talking to the keystone server, you may see log
messages like
authtoken: Bad response code while validating token: 408
authtoken: Token validation failure.
<traceback>
AttributeError: 'NoneType' object has no attribute 'text'
Since there's no response from the server when keystoneclient raises
RequestTimeout [1], the `response` attribute is understandably None.
Now, only log the response text if there's text to log. Additionally,
log the response message (as well as status code) to provide as much
context as we can for the error.
[1] https://github.com/openstack/python-keystoneclient/blob/3.15.0/keystoneclient/session.py#L469
Change-Id: Id400e4c38d07cbe7e1866dd572a17fc54c31e82a
Previously, we'd set _http_request_max_retries to 0, but that attribute
was removed in 1.3.0. Now, test runs are several seconds faster when
tests are executed serially.
Related-Change: Id092e8f42f843dbfbc1c30589b50ba341ccf4aae
Change-Id: I61d9b9617b1118d0696435d028bbda7a6c119bf8
When the keystonemiddleware is used directly in the WSGI stack of an
application, the 503 that is raised when the keystone service errors
or cannot be reached needs to identify that keystone is the service
that has failed, otherwise it appears to the client that it is the
service they are trying to access is down, which is misleading.
This addresses the problem in the most straightforward way possible:
the exception that causes the 503 is given a message including the
word "Keystone".
The call method in BaseAuthTokenTestCase gains an
expected_body_string kwarg. If not None, the response body (as
a six.text_type) is compared with the value.
Change-Id: Idf211e7bc99139744af232f5ea3ecb4be41551ca
Closes-Bug: #1747655
Closes-Bug: #1749797
The authtoken middleware has been printing warning log messages to
the API logs for all services, reporting unexpected conf keys. This
was traced back to paste.deploy adding 'here' and '__file__' and
both gnocchi and panko adding 'configkey' keys in wsgi apps though
these do not actually exist in the conf file. This change allows
for those keys without printing a warning that unnecessarily
confuses operators.
But it's kind of a hack, especially the configkey bit. We shouldn't
have to know about gnocchi/panko specifics like this. And it doesn't
address the comment in the bug about what is seen for ironic. So I
think there will still be more to do here.
Change-Id: I678482309c7dd35ce147bebf13ebefc84251fe91
Partial-Bug: 1722444
Use the new oslo.cache library instead of using memcached directly.
This keeps the old options around and will continue to use those in
preference to the oslo.config library as there is no way to test whether
oslo.cache was explicitly configured to use that in preference.
Currently there are no messages or anything to deprecate the old options
until we've had a chance to test it in production environments.
Closes-Bug: #1523375
Change-Id: Ifccacc5db311ad538ce60191cbe221644d1a5807
Co-Authored-By: Nicolas Helgeson <nh202b@att.com>
The [keystone_authtoken]/auth_uri middleware parameter has been causing
extreme confusion amongst operators and developers ever since the
keystonemiddleware started accepting keystoneauth plugin parameters
including auth_url. The two parameters look identical and yet have
completely different meanings and are both required. This patch
deprecates auth_uri and renames it to www_authenticate_uri, which more
accurately describes the WWW-Authenticate header it is configuring and
is dissimilar to any other keystone_authtoken middleware parameter. This
also renames the internal variable names for consistency with the config
option.
Change-Id: I0cf11da3d395749df28077427689fdafc8a6b981
In keystoneauth a workaround was implemented for when the discovery
document has an invalid scheme and host for its URLs[1]. This broke
keystonemiddleware's tests, revealing that keystonemiddleware was, in
one case, validating the wrong URL, and in another mocking the wrong
one. This patch updates the tests so that they are more accurately
representing how keystoneauth works.
Why should we change it here instead of reverting the keystoneauth
change? The URLs in the discovery document aren't validated in real
life, so the only URLs that can be trusted are the ones the user has
accessed, such as the auth URL. Keystoneauth is right to fix the URLs,
and the bad mocks in keystonemiddleware are only evidence that the tests
were wrong, not that the mocked URLs would have worked in real life.
[1] https://review.openstack.org/#/c/494194
Closes-Bug: Closes-bug: #1718945
Co-Authored-By: Colleen Murphy <colleen@gazlene.net>
Change-Id: I94d6dd1839bd1f662e70c5fb739695685e839a82
This patch is to replace assertEqual(False, A) with assertFalse(A), which
the latter is more straightforward and easier to understand.
Similar to a merged patch https://review.openstack.org/#/c/473749/
Change-Id: I899fe822e4a37dda8e14b9c1dfd31c07b7d24000
When the option is unknown to auth_token and it's value can't be
converted, this patch adds a warning log.
Change-Id: I818708cc19488030b80daa2b01b9f8622632f7eb
The constants of log levels were added in the 1.8 version
of the oslo.log library.
So we can replace all usage of system logging module
with log module from oslo.log
Change-Id: I97a1d913b543dc9dbd4d228b04adbdf7ee320df5
When a service token is present we should bypass the expiry checks and
pass the allow_expired flag to the server. This will let the server
return expired tokens.
This has a very basic policy enforcement that is not backwards
compatible with the current (sensible) default. We will need to discuss
how we can make this work.
Implements bp: allow-expired
Change-Id: If3583ac08e33380f1c52ad50d7d5c74194393480
Include the X-Service-Token along with the X-Auth-Token for any requests
made with the user authentication plugin. This indicates that the
request came from another service rather than the user.
Implements: bp allow-expired
Change-Id: Ib8db4bcfc49c2598dcacdd1dd2222e78c2459af7
We've finally got to the point where tokens are abstracted to the point
where we don't actually need to test by content what version of token it
is. Rejoice and remove the helpers.
Change-Id: Ia968ea68a9731c2a8f6a120acf697b30a2fcef8b
Oslo-incubator has been deprecated. The only thing that we use from it
is the memorycache which is hopefully going away soon. Copy this
memorycache code into the _cache module so that we can refactor it as
necessary without worrying about oslo-incubator.
Involves some minor cleanups for pep8 fixes and making functions
private.
Change-Id: I7a19d4ded8b538b6ea02e4a08068c863705194a3
This is the start of a cleanup of some of the audit middleware code.
The test changes are because this reorders the test execution order and
some of the global project tests were setting long lasting state.
Change-Id: I7a5576c1f497b9a43420f66c9e511cf6f280b62e
To do policy enforcement around admin projects we need for auth_token
middleware to pass this information down to context objects.
Closes-Bug: #1577996
Change-Id: Ic680e6eaa683926914cf4b2152ec3bb67c6601ff
Move all the auth_token middleware user_agent calculation into config
and only expose the user_agent property.
Change-Id: Ia6833845262c4de87ef95079de24d264e06f54fc
The _conf_get ugliness in auth_token middleware has been around for a
long time now to handle the abstraction from different oslo.config
options and the paste overrides. This logic is now also being needed in
other middlewares. Extract this into a common config object that has a
better interface and is easier to work with.
Change-Id: I8b8a1427bc527e43bb1baec25a881d93df3f93cc
Starting with v4.5.0, if a token is found to be cached, but is cached
with an invalid state, the middleware attempts to log a debug message
indicating as much.
However, the logger it attempts to use does not exist and results in
an AttributeError. As a result, this yields HTTP 500 responses once
the invalid token gets cached and is attempted to be used again,
rather than the expected 401.
This fixes the reference and adds a test to ensure the expected log
entry ends up in the logger so that this condition in
AuthProtocol.fetch_token now gets coverage.
Change-Id: Ie391973ea5893531c0b590ffba2d9de7f7f19d94
Closes-bug: #1584289
Thomas Goirand