Dear Akihiro, thanks a lot for your input, we will wait for such projects to progress further until we take the scoped tokens approach then. In the meantime we will revert to the deprecated (original) json rules and deploy the policy.v3cloudsample.json so that we could add two new roles (cloud_admin and project_admin) Thanks once again On 16/03/2021 01:33, Akihiro Motoki wrote:

Hi,

Horizon does not support the system-scoped token yet as of Victoria and coming Wallaby.

Horizon talks with various services. Some services support the system-scoped token and some do not. It is not easy to handle such kind of mixed situations. As of Victoria, keystone and nova support the system-scoped token but other services do not. We can fall back to the project-scoped token with admin role, but many considerations are still needed. This is the reason of the slow progress in horizon.

Victoria horizon also does not understand deprecated policy rules defined as policy-in-code. This was addressed in Wallaby, so we can use the same version of policy.yaml in keystone and horizon. However, horizon still does not handle the system-scoped token and horizon still depends on deprecated rules (rather than the system-scope aware rules). The horizon team recognizes this is the most important feature gap and will do the best to address it in Xena cycle.

Thanks, Akihiro Motoki (irc: amotoki)

On Tue, Mar 16, 2021 at 8:02 AM Luke Camilleri <luke.camilleri@zylacomputing.com> wrote:

...

Hi Everyone, we had sent an email to this mailing list last week on an issue that we are having which we thought was being generated by keystone but on closer inspection it seems that this is coming actually from Horizon policy files.

We would like to implement OpenStack using the scope based approach (v3) so that we could keep the main roles (reader,member and Admin) and use the scopes to differentiate the targets.

We have implemented the below settings in /etc/keystone/keystone.conf:

enforce_scope = true enforce_new_defaults = true

All works well with the cli and the scopes except Horizon. We constantly receive errors in /var/log/keystone.log like:

2021-03-15 23:15:55.772 1611435 WARNING keystone.server.flask.application [req-a89277a2-8fb2-4fcb-b337-e76a73bb3af9 1405ecf1ff7f4e4188648dbd1fb84c07 c584121f9d1a4334a3853c61bb5b9d93 - default default] You are not authorized to perform the requested action: identity:validate_token.: keystone.exception.ForbiddenAction: You are not authorized to perform the requested action: identity:validate_token

but the same command (for example an "openstack domain list") works well from the CLI.

We could identify the issue coming from the policy files shipped with the dashboard at /etc/openstack-dashboard/<policies.json> as the rules within these policies are not scope based and in json format while according to the roadmap it seems that yaml is being used for the policy files and they should be scope based.

When we try to convert the files to json to then upgrade them (to use the scope syntax) we receive the following errors:

#oslopolicy-convert-json-to-yaml --config-file /etc/keystone/keystone.conf --namespace keystone --output-file keystone_policy.yaml --policy-file keystone_policy.json Traceback (most recent call last): File "/bin/oslopolicy-convert-json-to-yaml", line 10, in <module> sys.exit(convert_policy_json_to_yaml()) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 599, in convert_policy_json_to_yaml conf.output_file) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 451, in _convert_policy_json_to_yaml scope_types=default_rule.scope_types) File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1239, in __init__ scope_types=scope_types File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1154, in __init__ self.description = description File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1251, in description raise InvalidRuleDefault('Description is required') oslo_policy.policy.InvalidRuleDefault: Invalid policy rule default: Description is required.

We believe that converting such files to yaml and then upgrading them for scope based access (v3) should solve our issues based on the fact that if we disable the enforce _scope and enforce_new_defaults we can have a fully functional setup (but not scope based) which defies the initial objective

Thanks in advance for anyone that may be able to assist with this issue