Merge keystone delegation models to a single one with their capabilities merged.
Roles Assignments, OAuth tokens, and trusts all serve one single purpose: to delegate roles on the resource to the actor. Resource may be either project or domain, actor is a user or a group.
The current architecture does not maintain a chain of responsibility for tracking what user originally created the role assignment, nor does it have any means to restrict its usage. The trusts is more a workaround rather than the sole solution for its own use case.
A scoped token represents a short term delegation for performing the set of operations necessary to complete a single workflow. Access control is performed by matching token contents against policy criteria and by validation of the token itself via keystone call.
Unify Assignment, OAuth RequestToken and Trusts into a single, unified delegation model containing following information:
trustor: actor who delegates authorization scope
trustee: actor receiving a subset of trustor’s powers
sources: model-specific fields for ancestry chain tracking, maintained internally
sequence of delegations preceding the current one in the ancestry chain
sequence of agents that created every delegation in the ancestry chain
Agent is the user who actually created the delegation - not necessary the trustor of the parent one
strict_ancestry: flag, indicating whether to check that all agents and delegations in the ancestry chains are enabled
sealed: flag, prohibiting the possibility to create derivative delegation
executable: flag, indicating that actor is allowed to perform any delegated role - not only delegate it to the next actor, if sealed flag is set to False
roles to delegate
target: the resource (project or domain) the delegation is scoped to
expires (optional): time limiting the validity of tokens issued based on this delegation
remaining uses (optional): limits the number of tokens to be issued based on this delegation
Delegation will track the responsibility chain so that any delegation is always granted by some actor to another. To allow this keystone must maintain chain consistency: it must handle the cases where the chain is broken or changed.
Delegation revocation must be cascaded down.
A delegation must have an option to restrict it’s usage so that it can be used for defined workflow and nothing more.
Delegation model
| Field | Meaning/example |
|---|---|
| identifier | [uuid] |
| user_chain | trustor/agent/agent/.../actor(trustee) |
| delegation_chain | delegation/.../parent_delegation/this_delegation |
| strict_ancestry | “check, that everything user_chain and delegation_chain are referencing, enabled” |
| sealed | “do not allow further delegation” |
| executable | “can issue a token scoped to this delegation” |
| target | [resource(domain or project)] |
| expires | 2020/12/31T23:59:59 |
| remaining_uses | Amount of tokens yet to be allowed to be issued |
Delegation roles
| Role m2m |
|---|
| delegation_id |
| role_id |
When implied roles feature is landed it should be possible to delegate a scope holding the role considered implied to that specified in this m2m table. In case if role is domain specific this is to be respected automatically as the scope of the delegation is already restricted to the domain.
Leave everything as it is - it still works and still can be used.
Notifications will be sent as for assignment operations now:
Unified delegation has the following side effect: delegations created using the trust API, for example, can be accessed through the assignment API.
Exposing unified delegation through its own API should be followed by corresponding extension of python-keystoneclient library. This is not currently in scope.
Delegation logic doesn’t differ very much from that of assignment and trust, though performance tests must be done, as delegation should be used for token issuing and validation.
Delegations are stored using SQL backend, so using critical sections in any request involving a call to delegation manager or driver should be carefully tested to prevent deadlock.
To use unified delegation drivers for assignment, trust or request token instead of their own requires configuration change to driver parameter in the corresponding configuration sections and apply data migrations unifying existing delegation data.
Data from assignment, trust and oauth backends is to be merged into a single unified delegation backend, this will require specific migration scripts to be developed and applied on upgrade.
Developers should continue to use the existing APIs as designed. Future work will involve exposing aspects of the delegations to the end users of existing APIs.
Work items or tasks – break the feature up into the things that need to be done to implement it. Those parts might end up being done by different people, but we’re mostly trying to understand the timeline for implementation.
What is the impact on the docs team of this change? Some changes might require donating resources to the docs team to have the documentation updated. Don’t repeat details discussed above, but please reference them here.