This change hides the AccountLocked exception from being returned
to the end user to hide sensitive information that a potential
malicious person could gain insight from.
The notification handler catches the AccountLocked exception as
before, but after sending the audit notification, it instead
bubbles up Unauthorized rather than AccountLocked.
Co-Authored-By: Samuel de Medeiros Queiroz <samueldmq@gmail.com>
Change-Id: Id51241989b22c52810391f3e8e1cadbf8613d873
Related-Bug: #1688137
The repo is Python 3 now, so update hacking to version 3.0 which
supports Python 3.
Fix problems found.
Update local hacking checks for new flake8.
Change-Id: Ic440219814ee0c2b98217e9a821f38f5baf482ec
The current initiator object for CADF notifications does not include
the username of the user who initiated the action, which leads to
issues when using an LDAP backend and not having a direct way to
map a username to a user id.
This change makes it so that the initiator object for CADF
notifications always contains the username for a user as well
as the user id. This follows along with the CADF standard
for OpenStack[0].
[0] https://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.1.0.pdf#page=12
Closes-Bug: #1856904
Change-Id: I833e6e0d7792acf49f816050ad7a63e8ea4f702f
This change adds 'application_credential' as a
'data/security/credential' CADF type, so that upon creating the CADF
payload the target URI is set to a valid type and not to 'unknown'.
Change-Id: I201ce5983409d99cbcaf0f0081be857b3194fa79
This reverts commit ebac8330d8.
Using the glob that I had not yet had enough coffee to do correctly is a
better solution, and allows us to fix new failures in 1.6.0 which would
break us again when 1.6.1 was released.
Change-Id: Ica473ba71b224cdc0acf815f82d534b6c70a7f54
This change stops keystone from emitting a notification when the
resource is the root domain <<keystone.domain.root>>. Currently
nothing should be invoking the root domain as an initiator outside
of tests, once the root domain is properly exposed this can be
removed.
Change-Id: Ic8bfd57a7e6e44342cf3748a6be3824de5aed1a0
Enhance CADF notifications with request ID and global request ID
for easier requests tracing.
Change-Id: I9bc1b29464b76e7d37f73e22062f31231046a496
Closes-Bug: #1801095
Convert the projects API to Flask native dispatching.
Change-Id: I3406284acfb7950b701f6a98a3a173a427415f97
Co-Authored-By: Morgan Fainberg <morgan.fainberg@gmail.com>
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
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
This change sets the initiator id as the user_id for
authentication events. The notificiation initiator id would
be set to a random UUID by default, which makes auditing the
identity of the user who is authenticating difficult. This
also adds the user_id as well for auth events for consistency.
Also removes the WIP unit-test header to verify that this
change works as intended.
Change-Id: I511a03eada22c66847bd1502b16cbd2c34b1b35d
Closes-Bug: #1780503
The token provider listened for specific callbacks from the
federation and oauth APIs. These were mainly for token invalidation
and token persistence removal. Now that the sql token driver and uuid
token provider have been removed, we can remove the need for
persistence notifications.
Instead, both of these cases can use a generic token cache
invalidation callback. This makes the token provider Manager simpler
because it only has to listen for a single internal notification to
invalidate the token cache, instead of multiple. It also makes the
code sending the notification easier to understand because it's
clearer about what it's doing.
Change-Id: I3281a013ce2764872dda8c183c4e9851974e1d14
The INVALIDATE_USER_TOKEN_PERSISTENCE and
INVALIDATE_USER_PROJECT_TOKEN_PERSISTENCE callbacks were meant to
clean up invalid tokens from the token storage layer. Now that the
sql token driver has been removed, we don't need them any more. This
commit removes those notifications and refactors the places where
notifications are still needed, making them more specific and not
eluding to token persistence.
This commit also removes a significant amount of logic from the
assignment API that used to notify the token API when assignments
were deleted. This made sense when tokens were written to disk
because there was an opportunity to invalidate them when users were
removed from projects. This is no longer needed since we do
validation online and we don't persist tokens anymore.
Change-Id: I100b7416e8ba61eb4ea2c2eb4962e952a53ea388
Since the users table has a foreign key to the projects table[1], users
must be deleted before the domain can be deleted. However, the
notification emitted from the domain deletion comes too late, and
keystone runs into a foreign key reference error before it can delete
the users. This patch addresses the problem by adding a new internal
notification to alert the identity manager that users should be deleted.
This uses a new notification rather than the existing notification
because the existing one is used to alert listeners that the domain
deletion has been fully completed, whereas this one must happen in the
middle of the domain delete process.
The callback must also only try to delete SQL users. The LDAP driver
doesn't support deleting users, and we can't assume other drivers
support it either. Moreover, the foreign key reference is only a problem
for SQL users anyway.
Because our backend unit tests run with SQLite and foreign keys do not
work properly, we can't properly expose this bug in our unit tests, but
there is an accompanying tempest test[2][3] to validate this fix.
[1] https://github.com/openstack/keystone/blob/2bd88d3/keystone/common/sql/expand_repo/versions/014_expand_add_domain_id_to_user_table.py#L140-L141
[2] https://review.openstack.org/#/c/509610
[3] https://review.openstack.org/#/c/509947
Change-Id: If5bdb6f5eef80b50b000aed5188ce7da4dfd1083
Closes-bug: #1718747
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
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
This change removes exceptions that are never thrown during
authentication due to them being related to password validation
and are caught/handled elsewhere from this change:
https://review.openstack.org/#/c/396752/
Change-Id: Iab49986ec41028da5c0d45f83c0037c07434c744
This adds a reason to the CADF event notifications that are emitted
for the following events related to PCI-DSS:
- Change user passwords/passphrases at least once every X days
- Limit repeated access attempts by locking out the user ID after
not more than X attempts
- Do not allow an individual to submit a new password/phrase that
is the same as any of the last X passwords/phrases he or she has used
- Passwords/phrases must meet the specificed regex
- User attempting to change password early
Implements: bp pci-dss-notifications
Co-Authored-By: Tin Lam <tinlam@gmail.com>
Change-Id: Ia678d25bdfa151c95483f5fcb77853184fbecfd1
The audit initiator is basically a context with all the information
about the current operation available. This information is all gathered
from the request and context so we can simplify its generation by moving
it onto the request object.
Change-Id: If91eacd3e07e0d9cd825f92b06c0ac819b3daf8c
The v2 authenticate command is one of the last to still accept a context
dict because it has a lot of tie in with tests and notifications. Fix
all these so that authenticate can work with a request.
Change-Id: I07a2985fea7f71001c4a48d396167ea0e3a2a8f8
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
These are basically the only configuration options in keystone defined
outside of keystone/common/config.py, so the only goal here is to
centralize them into one place.
Change-Id: I1369fd7835b31e57a094d07deb6a1aacc1d314b5
If we use logging lib to initialize a logger, the logger won't be
applied the oslo.log config options.
Also the library oslo.log provides compatibility for log levels.
Change-Id: Ib36fb60b3eaa56413865ee46a20f11c520af7d8c
Currently tox ignores D401.
D400: First line should end with a period.
This change removes it and make keystone docstring compliantwith it.
Change-Id: I9a9520e69701718ff471eebbcc52199dacdd9c68
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
Information of the observer in the CADF notification was only two of
the "typeURI" and "id".
So, add the ID of the identity service as a "identity_id".
Change-Id: I579ad3051f784a6411f6f7af636c2c91d75c7425
Closes-Bug: #1428946
The usage of oslo_messaging.get_transport is not meant for
notifications; And oslo_messaging.get_notification_transport is
favored for those means. So this change introduces the usage of that
function.
If the settings for the notifications are not set with the
configuration that's under the oslo_messaging_notifications group,
this will fall back to the old settings which are under the DEFAULT
group; just like this used to work.
Change-Id: Id1f89c89fa23d19e9229af7e80df179b6e17a635
The @notifications.internal decorator was recently removed in favor of inline
notifications. It was also the only method in keystone's notification framework
that used the notification.py:ManagerNotificationWrapper class, so that was
removed as well.
Change-Id: Ia5efbd9d9e3c1fad324dd7be84b2987048edb650
This change allows us to send internal notifications inline instead of invoking
them from decorated methods.
Change-Id: I659546b2cdd27bedaa694cb009d371f504765a72
Previously, keystone didn't have the ability to send notifications for
actor/target relationships due to the structure of the payload. The payload was
always expected to be the ID and type of one entity. In notifications that have
relationships (like adding or removing users from groups), it is useful to know
who was added to what.
This commit introduces the ability to send information about who was added or
removed from an entity.
Change-Id: Iea4437a265f1910a1171b9bcac99d853f5015440
Partial-Bug: 1552639
This was used in the resource API but not tested. This patch makes it so that
the resource API uses the preferred inline statement method of sending
notifications with:
notification.Audit.disabled()
Change-Id: I7da7847817b024bb3be9d2501b0939029e41354f
These decoratoes were only used in test_notification.py an nowhere else in
keystone. All other created, updated, and deleted notifications are issued with
`notifications.Audit.<operation>` instead of the decorated methods.
Change-Id: Ifc032952a84a54a56845dfc8baf747c920f318a9
This patch will allow certain notifications for events in
Keystone to be opted out. Opting out may be a desired way of
doing this since most keystone deployers will likely like
to by default have all audit traces.
Change-Id: I86caf6e5f25cdd76121881813167c2144bf1d051
Closes-Bug: 1519210
The oslo.utils reflection module/code handles more variations
of where a class name may come from (on python 2 and python 3)
so its usage allows getting more accurate class names so we might
as well use it.
Change-Id: I94a1f522755ec76b9b48b881c42b65a7c4c3860f
pycadf now has more strict validation for IDs, specifically, it tests to
make sure they are UUIDs. In a multi-domain configuration this fails
since the public ID that is generated by keystone is not an actual UUID.
Change-Id: I1fd13bd7a7fe037bd0e1b7d6fb0214460ff7c963
Closes-Bug: 1521844
Co-Authored-By: Steve Martinelli <stevemar@ca.ibm.com>
For role assignment notifications there were two notifications
being emitted. We deprecated the original notification event_type
in Kilo and can now remove it in Mitaka. Also update a reference
of the old event_type in the notification docs.
implements bp removed-as-of-mitaka
Change-Id: I42e68d2b95014fb7500a709de6ecbd8e5f93bac4
There were warnings printed when docs were generated:
docstring of keystone.assignment.core.Manager.create_grant:8:
ERROR: Unexpected indentation.
These are because the docstrings were not valid rst. The docstrings
are corrected.
In the case of create_grant, the problem is that the docstring of
the wrapper was used, so @functools.wraps is added so that the
docstring of the function is used rather than the wrapper. Also,
the wrapper's docstring was incorrectly formatted.
Also, corrected other issues with docstrings.
Change-Id: Ide6a85365f71330bf4caa24babc3bfe56174fc0f
Gage Hugo