"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.
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
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.
Deprecate our custom usage of the HTTP_X_FORWARDED_PROTO header in
favour of a standard middleware shared across all services. This will
enable us to support the newer forwarding standards.
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.
Domain admins (with a domain scoped token) could not list members of
groups in their domain or groups of a user in their domain.
This was due to 2 reasons: the v3 policy rule
'identity:list_groups_for_user' was not evaluating the users domain
and the identity controller method protections of 'list_users_in_group'
and 'list_groups_for_user' were not providing the required targets for
OSprofiler is an Oslo library dedicated to enable cross-service
OpenStack profiling. This makes possible to trace the OpenStack
request through all projects supporting the library, where the
profiling is enabled, and generate JSON and HTML human-readable
reports, describing what time was spent on which operation, e.g.
API or DB request.
This change inclues the following:
* Add settings for OSprofiler wsgi middleware
This middleware is used for 2 things:
1) It checks that person who want to trace is trusted and knows
secret HMAC key (that is specified in paste.ini).
2) It initalize profiler in case of proper trace headers
and add first wsgi trace point, with info about HTTP request.
* Init profiler on start in both cases (httpd or eventlet)
* Adding new conf group for profiler (to enable/disable)
* By default osprofiler is disabled
* Adding trace point for all DB (sql) calls. For proper format and
result oslo.db enginefacade module needs to be updated.
To test (old variant, will be changed with new commit to the
$ . amdminrc # you should be admin user/tenant to fetch profiling data
$ keystone --profile SECRET_KEY user-list
$ osprofiler trace show --html --out result.html <TRACE_ID>
Old python-keystoneclient change: https://review.openstack.org/#/c/114856/
Python-openstack client change: https://review.openstack.org/#/c/255861/
Default values for CORS middleware have been moved from paste.ini
into oslo's config generator. All configuration options in use will
now live in one place.
It's deprecated to have admin_token_auth after build_auth_context,
so move admin_token_auth before build_auth_context.
Also, for safety in the code handling the deprecated configuration,
only do the admin_token check if admin_token is not the default.
Building on the support for domain specific roles, this final
patch in the series adjusts the policy rules for grants using
domain specific roles in the v3cloudsample.
In addition, a release note is provide for the domain specifc
Implements: blueprint domain-specific-roles
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
Partially Implements: blueprint domain-specific-roles
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.
This adds the headers necessary for tokenless auth to the latent
configuration parameters of oslo's CORS middleware. It ensures
that an operator does not have to know additional magic
configuration properties just to make auth work.
Updated the relevant config options for Token signing
and deprecated the simple_signing_cert extension that
is only used for support of the PKI/PKIz providers.
This patch makes the public facing Router used in
the PASTE-INI emit a deprecation warning and moves
the login into the token subsection and always
attaches it to the V3 Service object this is part
of the effort to move all extensions (deprecated
or not) into core.
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 <email@example.com>
implements: blueprint implied-roles
The admin_required rule as currently defined is equivalent to the
admin_or_cloud_admin rule. If you have the admin role, both wil pass.
If you do not have the admin role, neither will pass. This makes the
policy file simpler and more consistent by removing