This document discusses the priorities and planned work for OpenStack Identity (Keystone) in the Kilo release, including improving specifications, addressing technical debt, enhancing testing, continued work on federated identity, hierarchical multitenancy, improving tokens, and changes to API extensions.

1. OpenStack Identity
Kilo Update
Morgan Fainberg
Identity PTL
IRC: morganfainberg

2. 2
To facilitate API client authentication, service discovery,
distributed multi-tenant authorization, and auditing.

3. 3
‣ Improve upon the specification process, ensure all major
initiatives have an associated specification
‣ Work more closely with the Operators and Deployers of
Keystone to ensure their needs are met
‣ Work towards eliminating the accrued technical debt in the
Keystone code base
‣ Improve the Operator, User, and Deployer experience
Keystone Kilo Priorities

4. 4
‣ Continue to clearly support interoperability between major
OpenStack releases
‣ Improve all python-*client libraries with the Keystone Client
Session object/class
‣ Keystone Client CLI is frozen, new CLI development occurs
in OpenStack Client
‣ Keystone V2 API frozen, not yet deprecated
Continued Stability and Functionality

5. 5
‣ Restructure testing layout to be more logical
‣ Develop and utilize Functional Test suite
‣ Include more 3rd Party CI
‣ Improve testing coverage
‣ Elimination of the git-download of python-keystoneclient for
the test suite
Testing Enhancements

6. 6
‣ Continue building on the success of Federated Identity and
improve the user and deployer story around it
‣ Keystone-to-Keystone (via SAML2) Federated Identity
moved from experimental to stable
‣ Improved Documentation around all forms of Federated
Identity deployment
‣ Full test coverage for all supported forms of Federated
Identity (SAML2, ADFS, Keystone-to-Keystone, OpenID
Connect, ABFAB)
‣ Will utilize 3rd Party CI where possible
Federated Identity

7. 7
‣ As of Kilo-1, Hierarchical Multitenancy is in-tree.
‣ Continued development and improvements around HMT
through the Kilo cycle
‣ “Reseller” use-case to be developed in the Kilo cycle
‣ Shared resources through the hierarchy
‣ Limit visibility and resource access within the hierarchy
Hierarchical Multitenancy (HMT)

8. 8
‣ Cleanup technical debt around token providers
‣ Clear and strictly enforced interface for custom token providers
‣ Provide at least one provider that does not require token
persistence (eliminates token-table bloat)
‣ Eliminate the need for the complete catalog to be in the token
‣ Further develop token “constraints” (limitations on how the token
can be utilized)
‣ Full support for Revocation Events and deprecation of revocation list
Tokens: Persistence, Size, and Constraints

9. 9
‣ Keystone API will no longer have in-tree “extensions”
‣ APIs and functionality will be one of three classes
‣ Stable
‣ Experimental
‣ Out-of-Tree
Changes in “API Extensions”

10. 10
‣ Better support for centralization of Policy.json files in
Keystone
‣ Keystone Team to assist in maintaining policy.py
(oslo.policy)
‣ Support for “dynamic” policy files
‣ Same default rules across all projects
‣ Elimination of hard-coded “is_admin” rule
‣ Move to a better RBAC default policy definition
OpenStack Policy and Policy.json