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
This reverts commit 3d46c8a5d9.
In the last commit, the foreign key constraints between the project
table and other tables were dropped, which allows us to restore the
configurability of the resource driver.
Change-Id: Iba4951e2d3965be5acec705385967d312456f1c7
Add in support for immutable roles and projects (including domains).
If the immutable option is set for a role or a project that
resource may not:
* Be Deleted
* Be Updated, except to change the value of "immutable" from
`True` to `False` or `None` (None explicitly unsets the
resource option).
* For projects (and domains), project tags cannot be created,
updated, or deleted.
The immutable check is performed at the manager layer allowing
for exceptional code-cases to work directly with the driver.
Change-Id: I2027b1235a260b7ae5d66cbd6c369773d9e99876
Partial-bug: #1823258
This allows domain_ids to match across distinct Keystone
deployments The domain_id is used to create unique
identifiers with the mapping backend. When this
option is used, mapped user identifiers can be
consistant across different Keystone servers.
closes-bug: 1794527
Change-Id: I100bca162e71a9d394ed5787b976b13b1e57987f
The request input format validation now is handled by jsonschema
check. The clean file is useless now.
Change-Id: I9806722cca8bcd1d4c73618cf1b36107929d37b0
The unit test uses sqlite for test which closes db foreign keys
function by default. This patch enabled the sqlite foreign keys
function for unit test by default.
The "project" table is a self referencing FK table(id <-> domain_id
column). So when the FK is enabled, there must exists a root record
before insert data to this table. It's <<keystone.domain.root>>.
Usually, the <<keystone.domain.root>> recored is inserted into the
table once operators run "keystone-manage db_sync" command when
deploy Keystone. But the unit test code doesn't run this command,
it initialise the db schema by reading sqlalchemy object model, so
the <<keystone.domain.root>> record is missed. Then we can't create
any project record, it'll raise FK error.
So in this patch, before creating any projects in the test, we must
ensure the <<keystone.domain.root>> record exists first.
Change-Id: I565d12395ca39a58ba90faf8641a9e02d986aeb9
Closes-Bug: #1744195
This patched removed some redundant "get_project" calls when
deleting projects/domains.
Change-Id: Ife4dd18962077bac30fa1cecf7621cc86a62929c
Closes-bug: #1764282
When deleting a project, the limits belong to the project should
be deleted as well.
Change-Id: I5f7eed9bf4f69cb7d79e44acac27c6c5881be22e
Closes-Bug: #1779903
Add a check function for project hierarchical tree check
when starting Keystone. If the tree depth exceed the
enforcement model's depth, fail to start keystone process
Change-Id: I4ce6a48505b8b9688bbdd18ee46ce035ee0938ed
bp: strict-two-level-model
when a hierarchical limit enforcement model is deployed
by keystone, the project hierarchical depth should
not break the limit model as well.
This patch updated the project depth check function
to fix the problem.
bp: strict-two-level-model
Change-Id: I695fedcf83bdca2946a2c5d876052c02b0f63810
Add include_limits filter for get project to support
fetching project hierarchy limits.
This filter should be used together with "subtree_as_list"
or "parents_as_list" filter
bp: strict-two-level-model
Change-Id: Ib602887c92b89be0ffec1394a3076f5dd5671511
Without it, listing projects results were missing project on which the
user had an inherited role.
Change-Id: If8edb3d1d1d3a0dab691ab6c81dd4b42e3b10ab3
Closes-Bug: #1780159
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
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: Id0305ce4e782dc8e8977dc7f802110148da2c901
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
With the removal of the V2.0 API in Queens, this functionality
was only used with the v2 resource controller and can now be
removed. Also removed the associated tests.
Change-Id: Id0503bc0610cff5fb635cd021088658bc06aef26
This change adds the tags attribute of project into the resource
manager. This change builds off of the backend logic.
Change-Id: Ie988b7a2065f0ecdb8ec953a1d01f5e3cbd67a1b
Partially-Implements: bp project-tags
Co-Authored-By: Jaewoo Park <jp655p@att.com>
Co-Authored-By: Nicolas Helgeson <nh202b@att.com>
Depends-On: I00f094a5584be40ab477cbf680a5f6d1afb4d21b
Depends-On: I5f8e4a53089b9fcc38084bb958d09f63ccc59d2a
When is_domain is false, the project must contain a valid
domain_id and parent_id. We check the domain_id specified
is consistent with the domain of its parent.
The log messages is not very clear, this patch optimize it.
Change-Id: Ie83d295f036f94d36c9dfa88ae03e074cdfd9810
This change has been implemented to avoid the need to backport
signficantly impactful Foreign Key dropping backports.
Resource is highly relational data and it makes sense to allow the
use of FKs from other subsystems to project/domains.
Change-Id: Ic3831d1c7ae41fe4d406d60a013770cc1258584f
Listing projects and domains for a user based on their role
assignments was noted as being really slow, especially when users
have a lot of assignments. This commit implements caching to mitigate
the issue while we continue to investigate ways to speed up the
assignment API.
Change-Id: I72e398c65f01aa4f9a37f817d184a13ed01089ce
Closes-Bug: 1700852
The revocation API was listed as a dependency of the resource API,
but it was never used. If it was no longer being used, we shouldn't
make the resource API load it.
Change-Id: Ia70064dce20a0bebf7b31a6b895ea0e5a0248480
partial-bug: 1671887
This patch addresses a bug and adds group_members_are_ids to the
whitelist to allow for use in `keystone-manage domain_config_upload`
Change-Id: Ifa8d0d723e90be16888859bfa2b0804a0b183877
Closes-Bug: 1670382
Code moving users, groups, and projects between domains has been
removed and errors consolidated at the manager level (instead of
the controller level).
Change-Id: I73e77cc6dd5081d25dcd85ff2d2a61555829066d
bp: removed-as-of-ocata
Removed LDAP write support and removed the configuration options
*_allow_create, use_dumb_member, dumb_member, allow_subtree_delete.
Also removed the driver logic related to dumb_members, tree deletion
and their respective tests.
Write functionality is still present because our tests depend on it,
but it's hidden behind a toggle which the tests set to enable it.
Co-Authored-By: Gage Hugo <gagehugo@gmail.com>
Co-Authored-By: Steve Martinelli <s.martinelli@gmail.com>
Implements: bp removed-as-of-ocata
Change-Id: I13eada3d5c3a166223c3e3ce70b7054eaed1003a
We deprecated this functionality during the Mitaka release and staged
it for removal in Ocata. Let's remove it!
A note for reviewers. Some of the logic for allowing projects to
update their domain_id was implemented in the resource Manager().
As a result, there were several tests that tested the manager
directly. Now that we're removing the logic for allowing
``domain_id`` to be update, we can rely solely on the
``_require_matching_domain_id()`` method in the
keystone.common.controller module. This short-circuit check will
return a 4XX response code for all requests attempting to update the
``domain_id`` of an entity. Since this is all completely isolated
in the controller layer, we can remove the logic from the resource
Manager specifically as well as the tests. This change looks like
we're removing a bunch of tests from
keystone.tests.unit.resource.test_backends but we're actually just
relying on more basic tests in test_v3_resource.
Change-Id: Iad0eba66e7ddc9497205af60671451a385d0de58
Closes-Bug: 1653472
Add an API for retrieving password requirement information from
``keystone.conf``. This should be used by user interfaces and clients
if/when they enforce PCI-DSS requirements.
Change-Id: I4c405da3a59e510cda5b46222cc3a20d568c7437
implements: bp pci-dss-password-requirements-api
The _option_dict() method relies on oslo_config to look up
configuration options and their values. It had an if statement
handling the case where the group passed into the method didn't
exist in registered config, and _option_dict() would throw a
UnexpectedError. Fortunately for us, this isn't something that
can happen with how oslo_config works. If the provided group doesn't
exist, oslo_config will throw an exception for us, saving us the
hassle.
This commit removes the case and relies on tests from a previous
commit (Ia2695628d19190f422ba079cc77e2d5e0e86c63b) to ensure nothing
broke.
Change-Id: Ie550555d2e07752ff9d2e8b71854c62e1681165d
partially-implements: bp pci-dss-password-requirements-api
As I was getting familiar with the domain config API, I noticed a
cool little nugget of a method nestled within get_config_default().
The _option_dict() method will go through and parse the configuration
information for a given group and option. This will be really helpful
when we go to implement the password requirements API, since we'll be
reading configuration information in a very similar way.
This commit bumps _option_dict() outside of the get_config_default()
method, officially making it a class method of the domain config
Manager(). This commit also add some unit tests, verifying its
behavior.
Change-Id: Ia2695628d19190f422ba079cc77e2d5e0e86c63b
partially-implements: bp pci-dss-password-requirements-api
The trust without a valid project is useless and will no longer
be active since the id of project is a random number and only
assigned when it created.
The patch invalidate the trust if the related project is deleted.
Change-Id: I51214c46ef5332c159b1e18bbd7046d12aba4a65
Closes-Bug: #1622310
Previously, keystone had logic to default the resource backend,
without providing a default through configuration. This behavior was
removed and we should provide a sensible default for the resource
backend.
This commit defaults the resource backend to `sql` since that is
the only backend keystone currently supports. We also leave a warning
saying there isn't any reason to change the default unless a deployer
is writing a proprietary or custom resource backend.
Change-Id: Ic193eab397a0f10cdf86dec1816aec9da86f1ab8
Partial-Bug: 1630435
Alone with the enabling of schema validation for V2 API, the property
validation has been handled in controller level, property validation
based on clean.py in manager level is no long needed for creating a
project since schema validation is enabled for both V2 and V3.
The patch removes the call from `clean.py` and remove the relevant
testcases since we already have the testcases both in
`test_validation.py` or `test_v2_validation.py`.
Partially implements: bp schema-validation-extent
Change-Id: I9d2ea60d496d83372109ca227ee2091850de0213
This will invalidate the token cache when a domain is disabled. As a result,
trust-scoped tokens that have a trustor or a trustee in a disabled domain will
have to rebuild the authorization context instead of just retrieving it from
the cache.
Change-Id: I3f6b528c64a07980422d82c8ab5b5d4f9b01485c
Closes-Bug: 1532280
When create user using API it is possible to use a domain_id which
does match the created domain_id since mysql per default is not
case sensitive and returns the domain_id to be valid. In e.g.
liberty this breaks cli keystone v2 user list actions when a user
with a DEFaULt domain has been created.
With this change the domain_id is being validated with what provided
with the API call in get_domain.
Change-Id: I028b2add3067e6fb9aa3f33eb8fe10d8ebace006
Closes-Bug: #1594284
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
Several places were doing things between when a cached resource was
changed and when the cache was invalidated, which could lead to
problems, e.g. if the code in between the two raised an exception,
or if an audit event resulted in the resource being requeried before
the cache was invalidated. Review comments on the original patch also
pointed out that audit events would not be sent in some exeption cases.
This change does cache invalidation as quickly as possible after a
change and uses try/finally logic to ensure that audit events will
be sent even in exception cases.
It also removes a stale TODO and an unnecessary duplicate assignment
removal in the affected code.
Change-Id: If9a91da42818fe37c975f86be47a2e49da356e41
Vishakha Agarwal