This patch removes the policy file now that policy in code has merged
and we now have all the default policy from policy.json in code. In
addition it refactors a couple of tests to use the in code policy
instead of the policy.json file when testing.
Depends-On: Ib1d9a51a78e2a84a3d7294dc8782605a681fa9e8
Change-Id: I23136627cb095015352b8eb09c31b2b2f1ce315f
Implements: blueprint policy-in-code
This commit does the following:
- Moves default grant policies into code
- Moves default implied_role policies into code
- Moves default policy policies into code
- Moves default role policies into code
- Moves default role_assignment policies into code
- Moves default token_revocation policies into code
Change-Id: I8c35ee7fdb0b9005038936895686abb0f1e027a6
Partially-Implements: bp policy-in-code
This commit does the following:
- Moves default credential policies into code
- Moves default domain policies into code
- Moves default ec2_credential policies into code
- Moves default group policies into code
- Moves default project policies into code
- Moves default user policies into code
Change-Id: I8bd0fa342cdfee00acd3c7a33f7232fe0a87e23f
Partially-Implements: bp policy-in-code
Adding the beginning implementation for registering and using
default policy rules in code. Rules are defined in the new
policies module and added to the return list __init__.py.
Default policies can now be maintained in code and registered
via listing mechanisms in the policies module. As we go, we
can remove the duplicated default policies from our policy.json
file.
This commit specifically:
- Creates a new module called `policies` to hold our in code defaults.
- Ensure we pass our in code policy list to our policy ENFORCER.
- Add base policy module for common policy rules.
- Add service default policy module for policy rules.
- Add endpoint default policy module for policy rules.
- Add regions default policy module for policy rules.
partially-implements blueprint policy-in-code
Co-Authored-By: Richard Avelar csravelar@gmail.com
Change-Id: Ic47b1e8b0d479032d8a7b9891ed9800be7036d94
Currently any user can list revocation events, this data contains
IDs for users and projects. It should not be made available to
any user that is able to authenticate, it should be an admin
only API call.
Change-Id: I4290163c67c84ef0e1a2f6ee967ddf2acb2c3212
Closes-Bug: 1649446
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
"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
Current policy.json allows a user to do get_project on their current
project (taken from the token), but does not allow the same for
get_user and get_domain. This extends the behavior to get_user and
get_domain.
This is also necessary for the openstackclient changes under
https://review.openstack.org/#/c/311206/ to work for users and
domains with the default policy file.
Change-Id: Ia20e7f109c7b032be99154c84a80d882b9a77ba3
Closes-Bug: #1561599
Currently, for global roles, cloud admin has full CRUD permissions
for roles, although a domain or project admin can read roles
(i.e. Get or List). This remains the case.
For domain specific roles, in addition to cloud admin, the domain
admin also has full CRUD permissions for the domain specific roles
of their own domain (but no permissions to see any domain specific
roles from other domains). In addition, a project admin can read
(i.e. Get or List) the domain specific roles from their domain
(but again no permissions to see any domain specific roles from
other domains).
Partially Implements: blueprint domain-specific-roles
Change-Id: I53499f164bfa4d3e65b70b9586b6fe0d71b60f41
Previously to issue GET /project a user needed
at least project_admin level of permission. With
this change, a user can issue GET /project by just
having a role on the project.
Change-Id: I9d23edc22eb88d0b21ab8968dfbe63661220a6fd
Closes-Bug: 1535878
CRD for implied roles.
Iplied roles are expanded in token issue and validation responses.
Explicitly forbids creating a rule with admin as the implied role to
avoid escalation of privileges.
Co-Authored-By: Henry Nash <henryn@linux.vnet.ibm.com>
implements: blueprint implied-roles
Change-Id: I812843adb9a1748fb471325797dad80e1baea565
The whitelisted configuration options, that are supported as part
of the domain specific configuration functionality, can now have
their defualt values read via the Identity API.
DocImpact
Change-Id: I9b1073f4d43c69f03fc920eee2712305524c1300
Implements: blueprint domain-config-default
This patch adds the API routing (and appropriate REST API
tests) to call the manager support for listing role
assignments for a tree of projects that was implemented in
the earlier patch.
In order to support the required policy rule, the protection
wrapper for filter list calls was extended to support a callback
(in the same way that the regular protection wrapper already did).
Implements: bp list-assignment-subtree
Change-Id: I3495c7cab3b40811b2722ac7d70ddda30410b62b
The policy rule for get_trust is misleading for operators
since it is not used by the trust controller.
Change-Id: I885ccbafef8bb9ca73ca6fab110176291bb3a542
Closes-Bug: #1444748
Add missing routing mapping to "list_endpoint_groups_for_project".
Now that mapping has been corrected, adding back the policy rule
"identity:list_endpoint_groups_for_project" in the sample policy
file.
Change-Id: Iedc0622cd472d630346b7ae8e662ab88de6c52cb
Closes-Bug: #1421968
There was no documentation that showed the mapping between the
actions in the policy file to the REST operation. The mapping is
now shown in the sample policy.json files.
DocImpact
This info also needs to be in an admin guide.
Closes-Bug: 1424496
Change-Id: I7c973068ec1a62d39287f926b71ba61de0566f58
Currently, policy.json and policy.v3cloudsample.json only check if
the user from token matchs the user from url. However, we should
also check if the user owns the credential.
Change-Id: I5c8bbb6736b028d6cb693d2a35e018f28caeaa57
Closes-Bug: #1417366
Closes-Bug: #1417522
Building on previous patches, this adds the public API support
for domain configurations being stored in the database.
Partially Implements: blueprint domain-config-ext
Change-Id: Idcd37a55a1179ef9be088323414cd76e7bfcd6bb
The "identity:check_role_for_trust" was defined in the sample
policy files but there is no actual mapping for it, so setting
a value for this target has no effect. If or when the
mapping gets added then this target must be added back in.
Fixed the double protected call in "get_role_for_trust" by changing its
call to a private unprotected version of "check_role_for_trust".
Also, marking the public version of "check_role_for_trust" as deprecated
for future cleanup.
Change-Id: I1c2b1186e37e31eaf556f81db686cc362768a5ae
Closes-Bug: #1421966
The "identity:list_endpoint_groups_for_project" was defined in
the sample policy files but there's no actual mapping for it, so
setting a value for this target has no effect. If or when the
mapping gets added then this target must be added back in.
Change-Id: I1843bf61681944ae82c3325e0bb00c32ca8f1c16
Related-Bug: 1421968
The `identity:get_endpoint_group_in_project` target was missing
from the sample policy files. It's defined in
keystone.contrib.endpoint_filter.routers for
GET /OS-EP-FILTER/endpoint_groups/{endpoint_group_id}/projects/
{project_id}
Change-Id: I15dd3965743a567918d7781b9831640745f70efc
Closes-Bug: 1421971
For new Keystone2Keystone federation usecase Keystone needs to
manage trusted Service Providers. This patch implements
CRUD API calls for that.
Implements blueprint: k2k-service-providers
Change-Id: I69673045009926365803a89a2e4b0d892d841ed6
The Endpoint Filter extension has been extended to support Endpoint
Grouping which provides a dynamic endpoint attribute filtering capability
that is directly associated with a project.
Change-Id: I7b628ac565f58077ff7521458cc1d02b3bf47d29
implements bp multi-attribute-endpoint-grouping
The controller level of the extension is really just a
marshalling function, with the exception that it is responsible
for catching any delete notification events for the entities
that are part of endpoint policy associations.
Implements: bp endpoint-policy
Change-Id: I4c5e9e9cff392f917a9d79a798ff72df2f48e6d1
These routes are purely based on your current authentication and bridge
the gap between what is available in the standard identity-api for
fetching scope targets based on user_id and what is required for the
federation APIs.
Implement /auth/projects /auth/domains and move /catalog to
/auth/catalog
Change-Id: I464c0ca5cc9f250d593340e9563de45b077dd4cd
Implements: blueprint auth-specific-data
Base API for reporting revocation events.
The KVS Backend uses the Dogpile backed KVS stores.
Modifies the places that were directly deleting tokens to also generate
revocation events.
Where possible the revocations are triggered by listening to the notifications.
Some places, the callers have been modified instead. This is usually due to
the need to iterate through a collection, such as users in a group.
Adds a config file option to disable the existing mechanisms that support
revoking a token by that token's id: revoke_by_id. This flag is necessary
to test that the revocation mechanism is working as defined, but will also
be part of the phased removal of the older mechanisms. TokenRevoke tests
have been extended to test both with and without revoke-by-id enabled.
Note: The links aren't populated in the list_events response.
SQL Backend for Revocation Events
Initializes the SQL Database for the revocation backend.
This patch refactors the sql migration call from the CLI
so that the test framework can use it as well. The sql
backend for revcations is exercized by test_notifications
and must be properly initialized.
Revoke By Search Tree
Co-Authored-By: Yuriy Taraday (Yoriksar)
create a set of nested maps for the events. Look up revocation by
traversing down the tree.
Blueprint: revocation-events
Change-Id: If76c8cd5d01a5b991c58a4d1a9d534b2a3da875a
Implement an EC2 Controller that returns a V3 token when invoked
via the V3 pipeline. Moved all code except the `authenticate` method
into a common base class mixin. `authenticate()` has become an
abstract method. Shared code from `authenticate()` was moved into
`_authenticate()`.
V3 specific router definition added that makes use of the new V3
specific controller.
For upgrade purposes:
* The paste.ini for keystone will need to be modified to include
the new V3 ec2credentials in the pipeline as is documented in
the updated sample paste.ini.
* Policy.json updated to provide rules for the new V3 EC2credential
CRUD as show in the updated sample policy.json and
policy.v3cloudsample.json
For authentication that occurs via the V3 ec2credential system,
the response auth_method (encoded in the token) will be
"ec2credential". This should have no impact on using
or consuming the token itself but can be used to identify if
the token was issued via the Ec2ControllerV3.authenticate
method.
The V2 version of ec2credential controller has been marked
as deprecated to keep in line with the rest of the V2 API
being deprecated (slated for removal in K).
DocImpact
UpgradeImpact
Change-Id: Iaf1e05a1beef481385c6eb19d7f54cdc84b5b5df
Closes-Bug: #1269947
bp: deprecated-as-of-icehouse
This patch will support authentication via SAML 2.0 assertions.
A new authentication plugin will allow external users to authenticate
with keystone, provided the incoming assertion is valid.
The file keystone/contrib/federation/controllers.py was extended with two
new controllers.V3Controller classes:
*) DomainV3 which handles /v3/OS-FEDERATION/domains API call and returns
list of domains a user can access based on the provided list of groups.
*) ProjectV3 which handles /v3/OS-FEDERATION/projects API call and returns
list of project a user can access based on the provided list of groups.
Change-Id: I89f70e3a24e825e21580772c088c6fd5c44f3b63
Implements: blueprint saml-id
This adds entries to policy.json for v3 region CRUD including a refactor
around the create_region* methods such that there only needs to be one
entry in policy.json for both API methods (POST /v3/regions and PUT
/v3/regions/{region_id} are both enforced by 'identity:create_region').
This also corrects the HTTP response code on create_region (from 200 OK
to 201 Created) by explicitly setting it and makes the tests a bit more
dynamic.
Closes-Bug: 1272496
Closes-Bug: 1272501
Change-Id: Icaa9b005788b50342d5fdb334055f5fad25436d9
Add a mapping implementation for the federation extension.
This will allow a set of rules to be added, that map
relationships between identity providers and keystone
api spec: https://review.openstack.org/#/c/59848/
Implements: bp mapping-distributed-admin
Change-Id: Iab93dc6759f195fecd88dcdf1c635c81ad59165a
The sample policy files were using the old style for rules.
This changes the policy files to use the new policy language
for rules.
Change-Id: I532b941c9b14b68b449e2cd7165d01a1f1031b05
Closes-Bug: #1152662
This changes the default policy.json to prevent users from changing
their own attributes such as password, name, or default_project_id.
Closes-Bug: 1237989
Change-Id: I7de5fff3d72a76b78113e289c57a9fac2096395f
We need to call controller.protected for most of the oauth_calls.
With the exception of the public ones (create_request_token,
create_access_token, and authenticate_access_token).
Also need to update the policy.json accordingly.
fixes bug 1231709
Change-Id: Ica111aa3ed82499d2de50d472754a0b5b3c5cc71
OS-EP-FILTER Implementation
There are new methods to create endpoint and project associations.
A full CRUD API to assign projects to endpoints as well as
the ability to check all the projects associated with a given
endpoint.
The association is used to pick what endpoints are visible
for the given project and a filtered catalog is built
accordingly.
During a project-scoped token request, if project-endpoint
associations have been created, the returned catalog will only
list the project linked endpoints.
blueprint endpoint-filtering
Change-Id: Idaa7f448a67e3bae01ba12686be37ba058183cf6
Add support for the GET /role_assignment call as a first step
to making role_assignment a first class entity.
This patch also enables v3 collection filtering to match against
attributes of entities being returned in the list, using the same
dot notation (e.g. user.id) that we already support for policy file
checking against filters.
Limitations:
- The current implementation uses the standard v3 collections wrapper
mechanism for filtering. Given the potential numbers of role
assignments in a large system, this may have performance and resource
impacts. A future improvement would pass the filters into the
driver layer to keep the internal assignment processing to a minimum.
- The LDAP backend is not currently supported
Implements bp get-role-assignments
Change-Id: I6ff2ea780e39d7097a88214fbb3ddee1b924c30c
Ubuntu