The oauth2_mtls_token filter has been added for accepting or denying
incoming requests containing OAuth 2.0 certificate-bound access
tokens that are obtained from keystone identity server by users
through their OAuth 2.0 credentials and Mutual-TLS certificates.
Co-Authored-By: Hiromu Asahina <hiromu.asahina.az@hco.ntt.co.jp>
Depends-On: https://review.opendev.org/c/openstack/keystoneauth/+/860614
Change-Id: I49127d845954ad6eab39e6e6305948ef0e4ed7b5
Implements: blueprint support-oauth2-mtls
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
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
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
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
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
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
When using service tokens and kerberos, the REMOTE_USER will be the
service user, and hence the token bind confirmation will always fail to
validate the client user's token, making it impossible to use token
binding with service tokens. This patch adds a test to expose the issue
and fixes the problem by only validating the token binding for the
service token when both tokens are in the request.
Change-Id: I7ba2283e8e58b89f1e42bc738c7e77284321e3a5
Closes-bug: #1413433
With the release of keystoneauth we should use that instead of
keystoneclient in auth_token middleware.
Change-Id: Id0876e90a1373ba31e4ec23d5275618149ca36d1
keystonemiddleware should get functional testing eventually like
the other keystone repos, so move the existing (unit) tests to
keystonemiddelware.tests.unit.
Change-Id: I7d5b1120fc5dc225fdd037b592a7914bde3f1ac2
sunyonggen