Unified model for assignments, OAuth and trusts

bp unified-delegation

Merge keystone delegation models to a single one with their capabilities merged.

Problem Description

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.

Proposed Change

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.

Alternatives

Leave everything as it is - it still works and still can be used.

Security Impact

  • Assignment, trust and OAuth1 request token storage is changed

  • New delegation API is introduced

  • Delegation search uses HTTP query parameters via hints

  • Policy should be changed to allow regular user to create a delegation using existing assignment API

  • Token content may change from the actual scope to mere reference to the delegation it is scoped to

Notifications Impact

Notifications will be sent as for assignment operations now:

  • created

  • deleted

  • disabled

  • updated

Other End User Impact

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.

Performance Impact

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.

Other Deployer Impact

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.

Mirgration impact

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.

Developer Impact

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.

Implementation

Assignee(s)

Primary assignee:

Alexander Makarov amakarov@mirantis.com

Other contributors:

Adam Young ayoung@redhat.com

Work Items

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.

Dependencies

  • This design is not currently dependent on other specifications.

  • This blueprint and the implied roles blueprint are related. Future work will build on the two specifications together.

  • This specification does not require any additional libraries.

Documentation Impact

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.

References