Move AuthContextMiddleware to keystone.server.flask.request_processing
to be more in line with the other internally defined middleware.
Change-Id: I25b6a88f4b0dc3af306360ee4e5ec0abfe3cf812
Partial-Bug: #1776504
Normalizing filter has been converted to a flask-native style
middleware instead of leaning on the old application logic from
Webob. We also now strip all trailing slashes, not just a single
traling slash.
Test Changes:
* test_url_middleware now tests the new middleware directly instead
of leaning on webob and fake requests.
Change-Id: I5f82817b61a9284b97cf6443105107150d4a1757
Partial-Bug: #1776504
Replace the JSON Body middleware with flask-native before-request
function.
The body filtering and storing data in
request.environ['openstack.params'] was not used in the code base and
has been dropped.
Test Changes:
* JSON Body middleware has been removed, no testing of the removed code
* JSON Body Before Request Method has been implemented and associated
testing (mirroring the JSON Body middleware code).
* Test entry points no longer looks for JSON Body middleware.
Change-Id: I84491865870b6bf2b8f094b524ee8b77510f0054
Partial-Bug: #1776504
Convert the /auth paths to flask native dispatching.
A minor change to additional_urls was implemented to ensure all
urls are added at once instead of individually (causing an over-
write issue within flask as a single resource may only have a
single set of URL mappings).
Alternate URLs now support adding alternate JSON Home rel links.
This is to support the case of OS-FEDERATION auth routes moving
to /auth. The old JSON Home entries must exist but reference
the new paths.
This port includes the following test changes (needed due to the
way flask handles requests and the way requests are passed through
the auth system):
* Implemented keystone.common.render_token (module)
containing render_token_response_from_model and use it instead
of keystone.common.controller.render_token_response_from_model.
Minor differences occur in render_token_response_from_model in
the keystone.common.render_token module, this is simply
for referencing data from flask instead of the request object.
* Test cases have been modified to no longer rely on the auth
controller(s) directly
* Test cases now use "make_request" as a context manager
since authenticate/authenticate_for_token directly
reference the flask contexts and must have an explicit
context pushed.
* Test cases no longer pass request objects into methods
such as authenticate/authenticate_for_token or similar
methods on the auth plugins
* Test cases for federation reference the token model now
where possible instead of the rendered token response.
Rendered token responses are generated where needed.
* Auth Plugin Configuration is done in test core as well.
This is because Auth controller does not exist.
NOTE: This is a massive change, but must of these changes
were now easily uncoupled because of how far reaching auth
is.
Change-Id: I636928102875760726cc3493775a2be48e774fd7
Partial-Bug: #1776504
This commit removes the original KeystoneToken object in favor of the
new TokenModel object. Since we have a token provider that knows how
to deal with TokenModel object, we don't really need another object
that uses reflection at all.
Closes-Bug: 1778945
Change-Id: I778cab0a6449184ecf7d5ccfbfa12791be139236
This module was a hodge-podge of common utility methods and a basic
implementation of the token provider API interface. In theory, if
something should be done for all providers, we should try and pull
it into a higher layer, like the token provider Manager. This makes
things easier to share without having to worry about reimplementing
something if we override a specific method of the interface. This is
the pattern we're working towards with the TokenModel object.
It was also home to the V3TokenDataHelper, which was ultimately
responsible for making sure the token API contracts were honored. Now
that we've moved token behavior into the TokenModel and the
representation of a token into the controllers, we don't need this
anymore. We should be able to make this much more clear and clean up
the interfaces for people providing their own token providers.
Partial-Bug: 1778945
Change-Id: I6f069c8c94e625ae553e9b41f0c54fd25bad9408
Since we're no longer supporting persistent tokens in tree and we
removed the uuid token provider, it's the perfect time to clean up a
good amount of confusing technical debt.
The token provider API is historically known for being confusing.
This is mainly because the reference that is intended to be returned
to the user is modified all up and down the API. Different parts of
the API use the reference to invoke call hooks in other method making
the code hard to debug. In order to fully understand how tokens are
built, you need to understand where and how tokens are modified by
different layers of the API according to a specific contract of the
authentication API. Another big problem is that it couples the actual
reference of how a token looks too closely to the business logic for
tokens. Which means you have to write a ton of code if you ever want a
token to look differently, like you would if you wanted to support a
new API version.
A token should be an object that the managers and controllers can
query and reason about. From there they should be able to build token
responses accordingly. This will make the actual token provider API
much simpler because it needs to know less about API contracts that
are the responsibility of the controllers. This should lead to simpler
interfaces when new token providers are added, or maintained out of
tree. This also makes it less likely for APIs to behave differently
based on what token provider is configured by being explicitly
building the token reference in one place.
This commit ports the token business logic out of the
keystone.token.providers.common module and into a dedicated token
object, or model. This will result in a cleaner interface between the
token providers and the token provider API. A subsequent patch will
remove the unused code across the token provider API.
Partial-Bug: 1778945
Change-Id: If9ded94e65bacb0d06f5225bb36f659dc7bb8355
Token bind operations were deprecated in Pike with UUID tokens and
staged for removal in Rocky.
https://review.openstack.org/#/c/428388/
This change does keep a configuration option around since it was not
officially deprecated with the rest of the token bind functionality.
The option is being officially deprecated in this commit and
additional context about the change was added to the help text for the
option.
bp removed-as-of-rocky
Change-Id: I7a42408893c782bcc20fb40ebba5f2d8af9da6a5
This patchset removes the lingering code that supported paste.deploy
that is obsolted by the loader wrapped around keystone's use of Flask.
* The keystone-paste.ini file has been removed.
* All options have been removed (without deprecation) as they are no
longer referenced.
* The TokenAuthMiddleware code (with deprecation warning) has been
removed as it was only provided to ensure compatibility with paste.ini
files that were not updated (ensuring not breaking a deployer that
did not update paste.ini file to remove it from the pipeline).
* Paste deploy entrypoints have been removed.
Change-Id: I35064a440ef718f50c7e644e8b2d56a99c3ec74f
The entire purpose of this confusingly named middleware is to take token
values out of headers and put them into a dictionary. There's no point
in this, we have a request class that can abstract this for us.
Deprecate the middleware, it's unnecessary.
bp: deprecated-as-of-rocky
Change-Id: I09310bab6bd728127288ba4c3cf8f884a31e2b98
This commit exposes the necessary bits to expose system-scoped
token authenticate and validation via the API
bp system-scope
Change-Id: I572a8e48953f493d521fd2aa00007df46e562e2e
as "admin_token_auth" is removed from paste file. some related contents
are useless and shoud be removed also.
Change-Id: Ia2263eda93559603a31d9a492e5501424613188e
bp: removed-as-of-queens
Refactors all of keystone's dependency injection to maintain a
single centralized repository of instantiated objects. This
means that we are no longer having to resolve order. All
objects that need to reference the various manager APIs simply
do so via the __getattr__ built into the Manager common object
or the ProviderAPIMixin object.
This is also the first step towards correcting our tests to
where they cannot run "load_backends" multiple times.
This forces any/all managers to properly run super()
as the way to register the api is via __init__.
This eliminates all use of the @dependency.requires and
@dependency.provides decorators, simplifying the objects
all around.
Any instantiations of a Manager after keystone is running
will now generate an error, ensuring everything for keystone
is running before handling requests. An exception is for
CLI and CLI tests, as the CLI may directly instantiate
managers and will not lock the registry.
Change-Id: I4ba17855efd797c0db9f4824936b49e4bff54b6a
Up to now, middleware/auth.py was overwriting the oslo
context generated from keystonemiddleware with a
dictionary that simulated the values of
oslo-context directly pulled out of the token.
As oslo-context gains logic, Keystone has started
to diverge from the rest of the projects that use
oslo-context.
Change-Id: Ie93392f8aabddf8c963b9cb08aaa006d28d37e22
When things go badly and we turn on debug logs, we start seeing this
message about a missing auth token for every auth request. To the
untrained eye, it looks like the culprit when you are debugging auth
problems. In reality, it usually just means the initial POST
/auth/tokens request was sent, which does not include the X-Auth-Token
header. This log adds more confusion than clarify, so this patch removes
itin favor of a code comment.
Change-Id: I4657523a170607d664b73ac1f1ab44d7f1460b33
Closes-bug: #1726736
common/authorization.py seems to be the canonical local for all our
information relating to auth parameters. The header definitions should
really be there as well.
Change-Id: I20d5cc94a55dd8936b5fe376ebbabd69909bb4dd
I'm guessing these two links were maintained as part of a larger
refactor some time ago, however there's really no reason to maintain
these references in multiple places. Remove them.
Change-Id: I9a3a6a3b59e0591a47d52512742995d56958e6bf
Make the error state message more explicit when the admin_token_auth
middleware is still in the paste-ini. This is an error, the operator
must remove the elements from their keystone paste ini or the deletion
of the code (in Queens release) will result keystone to fail to run.
This is an error in the config. If the operator is using the default
paste-ini form keystone, this error should not occur in Pike. If
the paste-ini is managed via CMS (e.g. Ansible) it is likely the
config must be changed.
Change-Id: Id40a7161574c879aa5c948b94173308a03d4c240
Officially deprecate the admin_token_auth in the paste-ini. The
functionality has been merged into auth_context_middleware. This allows
for a smoother removal of the admin-token functionality down the line.
The AdminTokenAuthMiddleware now does nothing if in the pipeline
except emitting a log.error.
This also removes the ADMIN token from the paste-pipeline itself
implements bp: removed-as-of-pike
Co-authored-by: Morgan Fainberg <morgan.fainberg@gmail.com>
Change-Id: I57586ccfa0ad1309cc806d95377dc1ecad015914
fetch_token is an implementation of a method from auth_token middleware.
As we need to add new features to auth_token middleware we may need to
add new information to the fetch_token method which keystone won't
understand immediately.
We define on the auth_token middleware side that an implementation
should ignore any unknown keyword arguments passed to fetch_token to
allow this to change.
Implements bp: allow-expired
Depends-On: I7312beb7cdd9527d959d6b7a94c6bfc6bf3c5952
Change-Id: I0cd4c414e496b99b01b3f7f19027f4cf92d17d71
Fixing keystone's policy dict is going to be a big effort. Until then we
can just add the is_admin_project flag from the context so that at least
we can enforce policy on it as other projects do.
Change-Id: I2f6731f0bfe00ae77a20a5c3015948b9ba2a191e
Related-Bug: #1602081
Regardless of persistence requirements or format, let's perform
token validation one way.
This simplifies the validation path of the token provider API.
Change-Id: Idb5de4459fd8bf83973ed74fccc275a64873c88c
The token provider has about 3 different ways to validate a token.
This since all 3 methods validate tokens in a very similar way we
should consolidate the behavior by collapsing the calls.
This is an effort to simplify the token provider API.
Change-Id: I32b94ce6fad29774d32639459fd17691ba427520
The check has been deprecated since Mitaka release and the use of
admin token has been covered by admin_token_auth middleware.
bp removed-as-of-ocata
Change-Id: I24bddc942482288b85070a89b4c84084e6a5b337
This reverts commit 9bbb0ce7a8.
The minimum version for keystonemiddleware is now 4.2.0, see [1] for
the change in keystone's requirements file. It mirrors the global
requirements.
The previous commit provided a bandaid solution if an old
keystonemiddleware was installed, we no longer need this bandaid.
[1] https://review.openstack.org/#/c/373750/
Change-Id: I09b9cfe2350114b5414aef9e0ef3c2bb6b26f3b8
On keystonemiddleware 4.0.0 the base class is called
_BaseAuthProtocol, which was later changed to BaseAuthProtocol.
Due to this change keystone would not work with the 4.0.0
version, while it was still accepted in the requirements.
This fixes it by providing a fallback to the old naming
Change-Id: I859a2d15e63c8c857b0bcbb15c757b716c8c43ba
Closes-Bug: 1623091
Add more information from the auth_context dict to the request context
object and start the process of converting code over to using the
context instead.
Change-Id: I3a5d8af30834873dfc7a10464a22355f379ebbcf
Keystone has shipped with the auth_context middleware in the pipeline
now for a number of releases. In newer parts of the code we rely on it
for auth information and in others we don't.
A prime example of this is the @protected handlers, if the auth_context
middleware isn't present it rebuilds this information. This is yet
another place where keystone validates a token.
Set a flag on the context to indicate that the request was validated by
auth_context middleware and raise Unauthenticated if not. This
essentially requires deployments to have the middleware enabled and
reduces validation to that point. This will help unify the code that is
behind a protected endpoint as we can rely on the context.
Change-Id: Iceca967e5bf698df13da28d0875c441f2a980e90
So in the effort to standardize our usage of components add the
oslo_request object to the request so that we can actually use it.
We subclass request as there will be information there that we will want
to keep in addition to the standard auth params.
Whilst there seems to be a lot of contexts floating around this is
transitional. The split will end up very similar to today except instead
of an unstructured context_dict we will have a webob.Request for request
related params, and instead of an unstructured auth_context dict we will
have an oslo_context.RequestContext.
Change-Id: I1a96233ee3deebdb143645b4be3a7b4068b2b165
keystone.common.config is 1200+ lines of super dense, merge-conflict
prone, difficult to navigate, and finicky to maintain code. Let's follow
nova's lead and break it down into more manageable modules.
This patch creates a new Python package, keystone.conf, and moves all of
our configuration options into it, mirroring nova's nova.conf package.
There are a couple special modules in keystone.conf introduced here as
well:
- keystone.conf.__init__: This causes all of Keystone options to be
registered on import, so consumers of keystone.conf don't have
races with config initialization code while trying to use
oslo_config.cfg.CONF directly (keystone.conf replaces all uses for
oslo_config.cfg.CONF in keystone).
- keystone.conf.base: Keystone's [DEFAULT] group options. I'd prefer
this to be called 'default.py', but I'm just copying nova's lead here.
- keystone.conf.opts: The entry point for oslo.config itself.
- keystone.conf.constants: There are a few constants (deprecation
messages, default paths, etc) that are used by multiple configuration
modules, so they need to live in a common place.
Change-Id: Ia3daffe3fef111b42de203762e966cd14d8927e2
Currently tox ignores D401 (401: First line should be in imperative mood).
This change removes it and make keystoneauth docstring compliantwith it.
Change-Id: I136cf810f47c4c19f29216907a63f226930b5082
Partial-Bug: 1570049
Reuse the validation logic that is already present in auth_token
middleware. Once this is present keystone can start to reuse the same
helpers that are created from auth_token middleware that the other
services rely on.
For now there is still some redundancy, like for example bind checking
is now enforced in auth_token middleware and in keystone. These can be
removed in later commits because they will require test changes.
My intention after this is to start to more directly integrate this with
oslo.policy and start to standardize the way auth is handled from
auth_token middleware to enforcement. Doing this work here means that we
get keystone to try out policy changes first.
Change-Id: I6592ea2865863c9ace1304b06d73a917c3a1b114
Use a request local cache, where possible, to offload requests
to the backend.
Change-Id: I8b744f75f21e9dd669a735a7717fd0d044d6d8ed
Depends-On: I6d1d28f5b974e79d44d1e86ea53c666e3f5771df
It's deprecated to have admin_token_auth after build_auth_context,
so move admin_token_auth before build_auth_context.
Also, for safety in the code handling the deprecated configuration,
only do the admin_token check if admin_token is not the default.
Closes-Bug: 1549371
Change-Id: I2607e718ecd50eb605a1e4bbfb3862e3968b6484
The AuthContextMiddleware shouldn't be re-implementing the
AdminTokenAuthMiddleware but using the request environment
context setting that the admin token middleware sets up.
This makes it so that admin token handling is in one place
rather than duplicating it and allows for an alternative
implementation of the admin token middleware.
The old behavior is left in place as deprecated to be removed
in a future release.
ReleaseNotesImpact
- The paste.ini file is changed to put the admin token
middleware first so that the auth context middleware can use
the results. It's deprecated to have the admin token
middleware after the auth context middleware.
Closes-Bug: 1473553
Change-Id: I658213699ac4af0abd08f893d9cf18ef0af5827d
Deprecate the admin_token_auth middleware in favor of using
keystone-manage bootstrap
Change-Id: Ib4ca153af2855911f9261081e7e442dfbc28f652
bp: deprecated-as-of-mitaka
bp: bootstrap
The RequestBodySizeLimiter was deprecated in Kilo and should be
removed in Mitaka.
implements bp removed-as-of-mitaka
Change-Id: I34596a02fa936bb455a12177d8959c113e777b17
Morgan Fainberg