© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I want to provide a holistic view of the work keystone has done to fix this issue.
We fixed this by consuming scope-types [0] and implementing a unified approach to default roles [1]. We also audited our API and separated system-specific APIs from APIs intended for project and domain users. We updated our default policies to reflect intended usage and tracked everything in separate and smaller bug reports [2][3].
As of the Train release keystone supports nine role and scope combinations by default. These roles and scopes give system, domain, and project users support for "reader," "member," and "admin" functionality.
We plan to document all the APIs these personas can access in keystone. We also plan to graduate our API testing to Tempest in some way, shape, or form. This will make it easier for projects to leverage testing utilities if they take the same approach we did.
Everything keystone used to develop this functionality is available for other projects. Mainly, oslo.context, oslo.policy, and keystonemiddleware know how to expose all authorization information necessary to fix this issue. Developers can feel free to reuse the approach keystone used and reference keystone as an example.
[0] https:/
[1] https:/
[2] https:/
[3] https:/