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
Then `enable` config option of trust feature is depreacted in
Queens. Remove it in Rocky now.
Change-Id: I186b49471cb774e161ff4c35c9879a0a4fa9538f
bp: removed-as-of-rocky.
When checking the current effective trust roles, the current
implementation creates a list from a set, then iterates over the
list to find a single id's existance in the list.
This change keeps the list as a set and utilizes the set
collection's speedier existance check to see if a trust_role_id is
present in the list of current_effective_trustor_roles. This removes
the casting back into a list, as well as a redundant list iteration.
Change-Id: I63ffbcc294e77b96f7a302543d335d3cb630090c
This patch removes the rest of the v2.0 specific code which was being
maintained exclusively due to a copy-paste issue with the deprecation
warning on the EC2 controller(s). With sign off from TC members
we have removed all of the bits except those exclusively tied to
the paste.deploy removal. All paste.deploy specific changes will
be removed in a future patch.
With the conversion to Flask, none of the v2.0 legacy controllers
left were wired up to routes that could be accessed.
Change-Id: I959dac0d0dd2e667982383e1e3d52ab28c4c1e2e
The _verify_token_ref() method is a dead section of code that was
last called in:
I62cc1d5efbe0869fd0e501aaa9405ff0b0da0e5e
This commit removes the method since it is no longer called anywhere
and hasn't since the Icehouse release.
Change-Id: I1b6ed09e9c9ad9214cd6e2c0f5849bb8550fbf3f
Without this patch, the token formatter does not have enough data to
construct a token created with an application credential. This means
that if the token cache is disabled or expired, when keystone goes to
create the token it will not find any application credential information
and will not recreate the application_credential_restricted parameter in
the token data. This patch creates a new Payload class for application
credentials so that the application credential ID is properly persisted
in the msgpack'd payload. It also adds more data to the token data
object so that the application credential ID and name as well as its
restricted status is available when the token is queried.
Co-authored-by: Lance Bragstad <lbragstad@gmail.com>
Change-Id: I322a40404d8287748fe8c3a8d6dc1256d935d84a
Closes-bug: #1750415
Since the sql token storage mechanism was removed in Rocky, we no
longer need hooks in the token Manager to determine if a token needs
to be retrieved from or written to a backend somewhere. Instead, token
providers will need to handle storage requirements if they need them.
This will result in a cleaner token provider interface.
Change-Id: Icc095987d41e9c08de2f34dc657b08b98bd944e4
Previously, it was possible to validate a federated keystone token
after the identity provider associated by that token was deleted,
which is a security concern.
This commit does two things. First it makes it so that the token
cache is invalidated when identity providers are deleted. Second,
it validates the identity provider in the token data and ensures it
actually exists in the system before considering the token valid.
Change-Id: I57491c5a7d657b25cc436452acd7fcc4cd285839
Closes-Bug: 1291157
Add an auth plugin for application credentials and update the common
auth utilities to understand an auth method of 'application_credential'
and validate and scope accordingly.
By default, application credentials should not be allowed to be used for
creating other application credentials or trusts. If a user creates an
application credential with flag `allow_application_credential_creation`
then that application should be allowed to be used for creating and
deleting other application credentials and trusts. Ensure a flag is set
in the token if this property is set to allow this behavior.
bp application-credentials
Change-Id: I15a03e79128a11314d06751b94343f22d533243a
This commit exposes the necessary bits to expose system-scoped
token authenticate and validation via the API
bp system-scope
Change-Id: I572a8e48953f493d521fd2aa00007df46e562e2e
This change incorporates system-scope changes into the token provider
API. A subsequent patch will wire up the necessary controller bits
that expose the functionality via the API.
bp system-scope
Change-Id: I15ed4b96d3e0d78f85ca61a3d85274c770c4c7cf
This change converts the usage of self.<provider_api> to
keystone.common.providers_api.ProviderAPIs.<provider_api> in manager
and controller logic. This is the correct way to reference
providers from other managers and controllers now that dependency
injection has been eliminated.
Change-Id: I853dd2d1fec159316b3101750b87aae9368bac58
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
Keystone's performance degrades as the `revocation_event` table grows
in size. This patch reduces the total number of events written to the
table by not persisting events when a domain or project is disabled.
The main reason for persisting a revocation event when a project or
domain is disabled is to make sure tokens associated to those targets
are considered invalid. Instead of relying on revocation events, we
can check if the project or domain is enabled when we validate the
token. We take the same approach when we validate a user's role
assignments instead of relying on an ever-growing database table.
Co-Authored-By: Lance Bragstad <lbragstad@gmail.com>
Closes-Bug: 1524030
Change-Id: I76330567e0df2d9f2af88ef9b6b98b8c379e7406
The v2.0 token format is being removed in Queens as a result of
removing v2.0. This code is no longer needed and helps us simplify
the token provider logic in general.
Change-Id: I032f175b4e9baf69e4c26f72bd30ebd266625856
We were using a one-liner to prune duplicate role references from a
list of roles, but it didn't work in all cases. This reworks the
logic to pass the existing test case. I also added a comment
explaining why the logic we used previously doesn't work so we can
hopefully avoid the pattern in the future.
Change-Id: Id786d6463364ad8f4f02c22bb83221baac4b83d0
Closes-Bug: 1701324
This was only really used by the controller layer - so this commit
makes it so that it lives there.
Change-Id: I5670e3bb33792c48539f7c861a51ba2b52c6ea9d
In the process of refactoring most of the token provider API, I
proposed a patch that would raise an exception if a v2.0 token was
validated to prove nothing in keystone was currently validating v2.0
tokens. This commit removes the exception from the v2.0 validation
path because we will need to be able to validate v2.0 token during
and upgrade from Newton to Ocata.
The shim should remain in the token provider through-out the Ocata
release, but it can be removed as soon as Pike opens for development.
When deployments upgrade from Ocata to Pike, hopefully deployments
will no longer have any v2.0 tokens and they will all be considered
expired anyway.
Change-Id: I1e50aadee45e16b7bad64de446a6e66c6ad237da
Add text to raised Unauthorized and Forbidden exception to show the client
what happened.
Change-Id: Id5de16d446cf4fdacfefdad0523e84821e4fd72c
Closes-Bug: 1625120
Because of the previous commits, we should no longer be persisting
v2.0 formatted tokens. This commit leaves a comment in the code
to remind us to remove that if branch when Pike opens for
development.
Change-Id: I6df389be3c4a8af97a4edc5dd6958696d2635c2f
The metadata stuff in the token provider was there as a v2-ism.
This commit removes it from the token provider and leaves it's bits
in the v2.0 token controller.
Change-Id: I4b37289c06df2012ed4473227df5c309440af162
The issue_v2_token path used the format_token method. Since we no
longer have a separate path for v2 and v3 token issuance or
validation we can remove this method. It's not used anywhere.
Change-Id: I6ac3b17cc0e2fba647a800ddab546d194b6d1483
Since we don't have a reason to hold on to a version specific
token method name, we can rename it to be just issue_token.
Now the token provider interface has two intergral methods,
validate_token and issue_token. From a third-party perspective, this
makes it easier to maintain a proprietary token provider since it
eliminates a lot of version specific things from the provider
implementation. From a keystone perspective, we are isolating the
numerous token validation and issuance paths to a since route. This
will make understanding the code easier for other developers and
eventually easier to optimize.
Change-Id: I71a04b42e931338b8bd59e479636b6199c7c2d76
In a previous commit we made all calls to issue_v2_token use
issue_v3_token instead. Any tokens that needed to be represented
as a v2.0 token we translate using the V2TokenDataHelper class.
At this point nothing really uses the issue_v2_token method and it
can be safely removed. A subsequent patch will rename the
issue_v3_token method to just issue_token since we no longer need
to make a distinction between two different methods.
Depends-On: Ia51f28a70ae099f1ec93851d271db8556aced836
Change-Id: I7d3b583cbec9a095ab8cc20c5d6c0a6127e37068
This is following the same pattern we applied to the token validation
path by collapsing the v3 and v2.0 paths together. Here we are going
to use issue_v3_token and translate the response to a v2.0 format.
This is going to allow us the ability to simplify the token provider
interface, remove duplicate logic, and isolate specific v2.0 and v3
token-isms into specific areas.
One of the existing test cases changes to assert an Unauthorized
exception when a trustee is disabled, instead of a Forbidden exception.
The switch is because the behavior is consistent with regular users
trying to authenticate with a token when their user is disabled (a 401
is expected). We're making that behavior consistent when a trustee is
disabled.
A subsequent patch will remove issue_v2_token entirely.
Change-Id: I191ce36b2f11f7353e2e3d601af1bda96987613b
The token provider module (core) has a list of methods that are called
by backend modules. This patch moves those methods to the backend and
removes dependencies where backend code references code in the core.
Change-Id: I59dab2efc5b743508ee9ecebcdc7c07b9f66791d
Closes-Bug: #1563101
The new user attribute, password_expires_at, is not being returned
during auth; this patch adds it.
bp password-expires-validation
Change-Id: I1f17a849d9da4067d6be7d612c5a561bcb247ebb
This patch moves the token abstract base class out of core and
into providers/base.py, which is consistent with the other
backend drivers.
Change-Id: Icf22adb2ccfa0470bb61ceb7d6c90467f44da6c8
Closes-Bug: #1563101
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
Instead of using validate_v2_token, we can effectively use the
validate_v3_token method and translate the v3 response to a v2 one.
This is a step towards simplifying the token provider API.
Change-Id: Iccb8349e0710288adb107d55437a4ff50d074b1c
This makes it so that all v2.0 peristent tokens are validated using
the same technique that we use to validate non-persistent tokens.
As a side-effect, this change makes it so that trust-scoped tokens
can be validated against the v2.0 API.
Change-Id: Ide3e8b646c564cfd133bcadace8ad6c77bc4ea5e
Some token formats require persistence (uuid, pki, pkiz) while
others don't (fernet). Persistent tokens were typically validated
by returning the token reference as it was constructed at creation
time, essentially returning a cached version of the token.
Non-persistent tokens formats are unable to do this because they are
not stored anywhere (exactly as the name implies). This means the
token reference must be rebuilt from scratch every time a
non-persistent token is validated. The advantage of this approach
is that less revocation events are needed and token data is considered
accurate at validation time.
This commit makes it so that all token formats issuing v3 tokens
validate tokens by reconstructing them, instead of relying on
possibly stale data from creation time.
Change-Id: I9584ce9627a91666f4dba62eb46e593f2053193b
The rest of the token provider API uses issued_at for the creation
time of a token. The fernet token provider referenced this value as
created_at. This change makes the fernet provider use the same
convention as the rest of the token provider API.
Change-Id: I347e40252824a01e887a17ab591bd092e007aa2d
The validate_v2_token method previously had a try/except that would catch any
ValidationErrors and raise a NotFound along with logging an error message. It
turns out that there were no opportunities for a ValidationError to be raised
from within the validate_v2_token method, making the try/except unnecessary and
untested.
This patch removes the try/except completely.
Change-Id: I0277ae89c0f8551c7e795ec1331af7da06134102
The v3_to_v2_token() method in keystone.token.providers.common
accepted token_id as an option parameter. This is because it was
not always passed in on validation. This commit makes token_id
a required parameter of the method and fixes its usage to always
supply it.
Change-Id: I6cc9c7a0e306dbbad61c77caa07df00fb3fa7a97
This makes it so that when we validate a fernet federated token against v2.0
and raise an Unauthorized exception.
This is an effort to break https://review.openstack.org/#/c/258650 into
smaller, more reviewable pieces.
Co-Authored-By: Raildo Mascena <raildo@lsd.ufcg.edu.br>
Co-Authored-By: Adam Young <ayound@redhat.com>
Change-Id: I321e9e72bb31617b4ecf8ba1e0171dfc099b88c7
Partial-Bug: 1561054
Currently, in both unscoped and scoped federated tokens, the
username value in the token is equal to the userid and not to
the value of the username in the external identity provider.
This makes WebSSO login to show the userid of the logged-in
user in the Horizon dashboard, whereas before it was showing
the actual user name.
This patch fixes the value of the username in the federated
tokens, which will fix the WebSSO issue as well, since Horizon
looks at the username value and displays that as the logged-in user.
Closes-Bug: #1597101
Closes-Bug: #1482701
Change-Id: I33a0274641c4e6bc4e127f5206ba9bc7dbd8e5a8
This commit adds a check when rebuilding the authorization context of a
trust-scoped token to make sure that both the trustor and the trustee are in
enabled domains. With this patch the uuid token provider and the fernet token
provider give the same response when caching is disabled. If caching is
enabled, the fernet provider will still consider a trust-scoped token valid
even though the trustor/trustee is in a disabled domain. A subsequent patch
will fix the revocation event to make sure the token is removed from the cache
when a domain is disabled.
Change-Id: If3e941018d5c2c9bd22397e69f83b7bf92643340
Partial-Bug: 1532280
For some reason the _populate_token_dates() method was accepting trust as a
keyword argument, but it was never used in the method. This commit removes
trust as a keyword argument from _populate_token_dates.
Change-Id: I4e6219767b731218d4727f229772ff938a8e56f5
"Shadow users: unified identity" implementation:
Allow concrete role assignments for federated users. Currently,
federated users get roles from mapped group assignments. However, with
the shadow users implementation, federated users are mapped to
identities in the backend; thus, can be assigned roles.
This patch returns locally assigned roles with the mapped group roles
for federated users; allowing for authorization for those roles.
bp shadow-users-newton
Change-Id: I9a150ded6c4b556627147d2671be15d6a3794ba5
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
Add the is_domain flag in token response for project scoped tokens.
This flag represents whether the target project acts as a domain.
Co-Authored-By: Henrique Truta <henrique@lsd.ufcg.edu.br>
Co-Authored-By: Rodrigo Duarte Sousa <rodrigods@lsd.ufcg.edu.br>
Blueprint add-isdomain-to-token
Change-Id: Ic0bd0c6cf2c47680063752820a067cf40d47b184
By only setting is_admin_project in the token if it is true we are
unable to distinguish in policy enforcement if the admin project is not
defined in configuration or if the current scope is not the admin
project.
If the admin project is defined in config we should always set the
is_admin_project in the token either true or false so we can provide
backwards compatible policy files in projects.
Change-Id: Icdfc4f4792422af9d844004c2c92993c9065134d
Closes-Bug: #1577996
Lance Bragstad