Ater the patch "Keystone to honor the "domain" attribute mapping rules."
It's not possible to assign domain specific roles to federated users
when the user domain is specify on the claim.
This patch aims to fix this, allowing to map non domain specific roles
and domain specific, if the domain is the specify on the claim.
Depends-on: https://review.opendev.org/#/c/739966/
related-Bug: #1887515
Change-Id: Ie3d7585cb9143686a93e4a19843698274475eaf6
Signed-off-by: Juan Pedro Torres Muñoz <juanp.95.torres@gmail.com>
We propose to extend Keystone identity provider (IdP) attribute mapping
schema to make Keystone honor the `domain` configuration that we have
on it.
Currently, that configuration is only used to define a default domain
for groups (and then each group there, could override it). It is
interesting to expand this configuration (as long as it is in the root
of the attribute mapping) to be also applied for users and projects.
Moreover, to facilitate the development and extension concerning
attribute mappings for IdPs, we changed the way the attribute mapping
schema is handled. We introduce a new configuration
`federation_attribute_mapping_schema_version`, which defaults to "1.0".
This attribute mapping schema version will then be used to control the
validation of attribute mapping, and also the rule processors used to
process the attributes that come from the IdP. So far, with this PR,
we introduce the attribute mapping schema "2.0", which enables
operators to also define a domain for the projects they want to assign
users. If no domain is defined either in the project or in the global
domain definition for the attribute mapping, we take the IdP domain
as the default.
Change-Id: Ia9583a254336fad7b302430a38b538c84338d13d
Implements: https://bugs.launchpad.net/keystone/+bug/1887515
Closes-Bug: #1887515
When a federated user authenticates, they are added to their
mapped groups during shadowing.
Closes-Bug: 1809116
Change-Id: I19dc400b2a7aa46709b242cdeef82beaca975ff3
This repo does not support Python 2 anymore, so we don't need
six for compatibility between Python2 and 3, convert six usage to Python
3 code.
Change-Id: Icba56808f38277b27af2ae5aac4b8507dee71b3b
It seems flask is providing a class which is kind of
hybrid between list & dict and provide this error
because of this. Providing a dict instead of the
werkzeug.datastructures.EnvironHeaders.
Closes-Bug: #1839393
Change-Id: Ic8e8e8153f4c812145ff3976c934c84f401f1019
Update the TOTP auth plugin so that it can be configured
to allow a passcode from a given number of windows back to
still work.
This gives TOTP some slighly better UX so by default at least
one passcode back will still work. Can be disabled, or more
windows added for clouds less worried about security and more
about clock drift.
Change-Id: I8ba4127a365392f0d0e9de5fd9c979750c354dc7
Closes-Bug: #1839577
Emit CADF notifications on authentication when the user_name or the
user_id is invalid (UserNotFound raised). This closes a minor security
gap in notifications.
Change-Id: If8b49b5dc49a4b0670fb81a493f50c77df7b4362
closes-bug: #1537963
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
Convert OS-FEDERATION to flask native dispatching.
NOTE: Two changes occured that impact testing in this patch.
* The JSON Home test now uses assertDictEquals to make it
easier to debug json_home document errors
* It was by general good luck that the overloaded relation
'identity_providers' worked as expected. The relation was
used for both '/OS-FEDERATION/identity_providers' and
the Identity-Provider-Specific WebSSO path. The change
to the JSON Home document and the tests make the
Identity-Provider-Specific WebSSO path now a relation
of 'identity_providers_websso' to more closely align
with 'websso' relation for
'/auth/OS-FEDERATION/websso/{protocol_id}'. While
this constitutes a minor break in our contract (the
output of the json home document) it was required to
ensure consistency and functionality. The alternative
is to not represent '/OS-FEDERATION/identity_providers'
(list endpoint) in the JSON Home document at all, instead
represent only the WebSSO endpoint.
Change-Id: If746c14491322d4a5f88fa0cbb31105f6d38c240
Partial-Bug: #1776504
Keystone uses translated strings both in
logging an exceptions. This is incorrect.
All strings that are passed to logging
should remain un-translated. This patch
addresses above issue.
Change-Id: Idf4f0bc1bd63eb8dc6dc61d8a49a9e2a93320474
Closes-Bug: #1777671
Originally, the "extra" in token data is generated by auth plugin
and then will be return to users within token data.
In Kilo, the "extra" in token data was deprecated[1], after that
if the auth plugin generate the "extra", a warning log will be
raised. To stop the warning, the auth plugins should stop
generating "extra" field.
After two releases, in Mitaka, the "extra" in token data was
removed[2], but the "extra" was still created by default as an
empty dict {}. Actually, "extra" should not be created any more
in Mitaka because Keystone has warned the auth plugins for two
releases.
Now in Rocky, it's safe enough to remove the "extra" from token
issue flow at all since it has never been used from Mitaka. The
only concern for the out tree plugins about the removal is that
if they still put "extra" into auth_context, Keystone will raise
KeyError. But can it be happened? Only if the out tree plugins
ignore the warning in Kilo, and still contain "extra" but never
use them from Mitaka. For most auth plugins which follow the
Keystone deprecation step, this patch is a silent change.
[1]: https://review.openstack.org/#/c/162662
[2]: https://review.openstack.org/#/c/249480
Change-Id: I828cc0ad3ac265abdfea2e1571806add128ae51e
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
Now that support for sql token storage and uuid tokens has been
removed, it doesn't make sense to still expose an API for listing
revoked tokens. Maintaining this behavior would require keystone to
persist non-persistent tokens, which defeats the purpose.
This change makes the API return either a 410 Gone or a 403 Forbidden
depending on configuration for backwards compatibility. Logic to
list revoked tokens was also removed from the token provider API
since it's no longer called by any controllers.
Change-Id: Ic7bcba148f0a062b144e6dfbe9693f2125008458
For the move to flask, and to ensure there are no test changes,
this changeset moves `validate_issue_token_auth` from controllers to
the auth.schema module (as it is clearly about validation).
Change-Id: I97e07cbebb4e97df4b38899037e97ce3f34b9e03
Partial-Bug: #1776504
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.
This change refactors the logic for obtaining methods from an
integer. Instead of creating a list of integers to later loop
through in order to create a list of methods, skip ahead to
creating a list of methods since we already have the int key and
can pull the method from the map.
Change-Id: I4fc5b23b8f82d0f475a0ca787f2df10af1ed7238
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
In get_user_unique_id_and_display_name() of
keystone/auth/plugins/mapped.py, the checking
of user dict's key "name" is not very strict.
So, we need to add more strict validation here.
Change-Id: Ib147e90e4076c1c2ca7a9fd1cf8d17ce3ddc5e34
Closes-Bug: #1711883
Basic conversion of Keystone's core application to flask framework.
This doesn't add much in the way of flask-specific-isms but should
get keystone running directly under flask. This implementation does
not use paste-deploy.
Change-Id: Ib4c1ed3f645dd55fbfb76395263ecdaf605caae7
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
The direct loading of drivers was deprecated in Liberty and noted
to be removed in Newton. This patch cleans up the deprecation and
fixes the unit tests. Some of the example request/response json
message bodies of the domain config API were also updated to the
correct way of loading a driver now.
bp removed-as-of-rocky
Change-Id: If3f4c2303da6e264e5e0d73280cc21fa01a3cfd4
We have a method that takes an integer and re-inflates it into a list
of authentication methods. This is because it's more efficient to
pass around an integer in a token's payload than a list of strings.
During the token validation process, we take this integer and run it
through a little process to reinflate it's value to a list of auth
methods that were used to obtain the original token.
The re-inflation process doesn't actually work in python3 because it
is coded to expect integers when dividing numbers, which is accurate
for python2. Python3 returns floats when dividing two integers, which
doesn't work with the logic to re-inflate the auth methods. For
example, in python 3::
>>> result = 5 / 4
>>> result
1.25
>>> type(result)
<class 'float'>
In python2:
>>> result = 5 / 4
>>> result
1
>>> type(result)
<type 'int'>
This commit introduces unit tests to prevent regression and includes
a fix so that the conversion works properly on python3.
Closes-Bug: 1758121
Change-Id: I627c2b353da0c35bb23bb40542a880fc6bacc4aa
When the federated rule contains 'email' in user and we should set
email for the federated user. Also, if the federated user changes the
email info, it should be chenged too.
Change-Id: Ib17172c34bd65d5236cbfc192b3a3f2b221411ef
Closes-Bug: #1746599
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: I44b21fe636926925c50b2116c85f20a6e7a11d00
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
Keystone has APIs for retrieving projects and domains based on the
role assignments a user has on projects and domains. We should
introduce similar functionality for system assignments. This will
make discovering system access for users and client easier.
bp system-scope
Change-Id: Iab577fcd1b57b8b5593c3f9d50a772466383a999
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
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
If the OS-TRUST:trust is not a dict when authenticating,
Keystone will raise 500 error. This patch add the
related schema check to avoid the error.
Change-Id: I575440fa507c5274e0c3bc09f4cfcb9b3d91a28c
Closes-bug: #1733754
When authenticate with "mapped" method, if users forget to add
"identity_provider" or "protocol" keypair, keystone will raise
500 error.
In this case, keystone should raise 400 error(ValidationError).
Change-Id: I85feb078b7fb2a5b091407fa69db7409a9c75199
Closes-bug: #1730270
Currently, bandit marks usages of SHA1 as insecure, which
results in false positives for instances of SHA1 in keystone.
However, keystone uses HMAC-SHA1 which is currently considered
secure as opposed to just SHA1 hashing.
This change marks a # nosec comment against the lines which
are triggering the false positives in Bandit in order to
tell bandit to avoid these instances of SHA1.
See [1] for HMAC-SHA1 discussion in keystone
[1] https://review.openstack.org/#/c/453365/
Change-Id: Ibb44db1f8727d014d186b412106d0cd4e2f4a6dd
Setting the default project is merely provided for convenience,
does not need exist project and grant any actual authorization
on it, This shouldn't be a warning.
At the same time, if the log message exposes to the users,
they know the identity authentication has already passed and
the used password is valid, which could be useful to an attacker.
Log warnings is not necessarily as locked down as debug log,
I think this would be fine as a debug log.
Change-Id: I85ed00ad3d08ed52b159d4da1526a006d72d9677
Juan Pedro Torres