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
During an upgrade, a node running this code may need to handle a
persisted token (UUID, PKI, or PKIZ) created without this attribute.
Closes-Bug: 1630259
Change-Id: I0c5959b6491bb13a02eb1b9b7e7e37d2f2d73f85
As per OpenStack licensing guide lines [1]:
[H102 H103] Newly contributed Source Code should be licensed under
the Apache 2.0 license.
[H104] Files with no code shouldn't contain any license header nor
comments, and must be left completely empty.
[1] http://docs.openstack.org/developer/hacking/#openstack-licensing
Change-Id: I51a413acf6e63fb47418d8746aed5c7aac05f2d6
This patch adds password history validation to the change_password
(self-service) backend method.
backport: newton
Closes-Bug: #1628692
Change-Id: I6a21eb355a60b96da0615e64f57fa64289c0221e
Throughout much of the v3 authentication tests, you'd see calls
directly into the token_provider_api. While this was convenient
because the backends were loaded automatically, it makes changing
the implementation of the backend harder because we're relying on
it in the tests by coding to it directly, instead of just testing
the behavior through the API.
This commit makes it so that all calls to validate a token actually
use the token API instead of passing tokens directly to the
token_provider_api, exercising a request from the controller to the
backend... no cheat days here!
Change-Id: I5e792831dc808270f91f2c343e93e44a653b8676
This patch reorders the APIs listed in the api-ref doc for v3 users so
that we have APIs documented in the following order:
- list users
- create user
- show user
- update user
- delete user
- list user groups
- list user projects
- change passwd
The rationale behind the change is that we want the order of API docs
for all resources to be consistent and easy to navigate. This patch
reorders the users APIs so that:
- Plural form of resources comes always come before singlar form because
it has a unique URI;
- APIs about a specific resource (usually with an ID) are documented
in the order of CRUD (create, retrieve, update and delete);
- All other helper APIs are documented at the end and they are grouped
based on resource URIs when appropriate.
Change-Id: Ie594a45a51064a5f9089e2663bd970f10707ffaa
Following OpenStack Style Guidelines[1]:
[H203] Unit test assertions tend to give better messages for more
specific assertions. As a result, assertIsNone(...) is preferred over
assertEqual(None, ...) and assertIs(..,None)
[1] http://docs.openstack.org/developer/hacking/#unit-tests-and-assertraises
Change-Id: I9b0cedae367798ce282b0229c135b3f4a72f353a
By default oslo.cfg sets the default values as None.
Thus, there is no need to explicitly do this.
Trivial-Fix
Change-Id: I5b822021a1fe83be3755791278df6b4f498e6fef
The _get_token_ref() method in keystone.token.controller did some
unnecessary checks and duplicated logic for checking the belongsTo
query parameter. The belongsTo query parameter wasn't possible since
the query parameter was never passed to _get_token_ref().
This commit cleans up the method and consoldiated the logic.
Change-Id: I097b0547b4395b016f80f03d97460ceda49fc8c6
The belongsTo query parameter is only supported by the v2.0
token validation API. It would check the ID of the project passed
to the belongsTo parameter against the project a token was scoped to.
This commit corrects the implementation, tests, and adds
documentation. It also moves the check to keystone.token.controller
since belongsTo is a v2-ism and doesn't belong in the
keystone.token.provider.
Closes-Bug: 1627085
Closes-Bug: 1626794
Change-Id: I4a06a498112b81093d7e5ef3142bb1e2d0f78138
Forbids implication between domain-specific roles from different domains
Change-Id: I9d3b9747df04b425f8c708bb3436569f2baf47c8
Co-Authored-By: Steve Martinelli <s.martinelli@gmail.com>
Co-Authored-By: Mikhail Nikolaenko <mnikolaenko@mirantis.com>
Closes-Bug: #1590583
The null key for credential encryption tests certain encryption
behavior when a key repository doesn't exist locally. If you were
to run these tests locally with a key repository created in the
default location (`/etc/keystone/credential-keys`) the tests would
fail.
This commit makes the null key tests override the key_repository location in
config, but doesn't actually create the repository - so the null key is infact
tested.
Change-Id: I9c970cd846da2f9d52547ecb7271a20791fb3301
The default behavior when a method is called on an object is to call
the implementation in the superclass. So no need to override a
method just to call the superclass implementation.
This makes the code less confusing because readers will wonder what
the code doing here when it doesn't do anything.
Change-Id: If2a5e694114a97d989f88c16691062dbd7215427