Token trusts

Registered by Adam Young

 One issue that I've been asked about repeatedly is getting a token for an action in the future. Two use cases for this have come up:

1. HEAT and failover. It needs to move a virtual machine from one host to another.
2. Content production. Something generates a large file and needs to store it in swift.

In both cases, the users authorizes it at setup time to perform this action any time in the future, long after the token is expired.

To support this, add two new APIs. One is POST trust, and the other is GET trusts/{trust_id}

When POSTing to trusts, the user supplies a user that will be allowed to fetch a token at some point in the future.

When GETting tokens/trusts/{user_id} only the specified user will be able to fetch a token for the user that performed the trusted action.

We could potentially add an additional PATCH to modify a pre-auth arraingement. We would certainly want a DELETE.

The preauthentication id should be just a UUID. It should be useless to anyone but the user that creates it. No other user should be able to view it. The user should be able to enumerate her preauthentications, in order to view, modify, and delete them. /users/preauthentications

Blueprint information

Status:
Complete
Approver:
Joseph Heck
Priority:
High
Drafter:
Adam Young
Direction:
Approved
Assignee:
Adam Young
Definition:
Review
Series goal:
Accepted for grizzly
Implementation:
Implemented
Milestone target:
milestone icon 2013.1
Started by
Joseph Heck
Completed by
Thierry Carrez

Related branches

Sprints

Whiteboard

how are the pre-auth tokens scoped? Are they scoped to a tenant, to a service, to an endpoint?

-------
This seems to me like another case of delegation. The user (delegator) is authorising something (the delegate) to perform an action at sometime in the future when the delegate sees fit.
Do you agree? if so, then why are we inventing yet another piece of add on (spaghetti) to perform a function that has already been seen as being required? -- David
-------

Gerrit topic: https://review.openstack.org/#q,topic:trusts,n,z

Addressed by: https://review.openstack.org/19723
    roles mean membership

Addressed by: https://review.openstack.org/20289
    Trusts

Gerrit topic: https://review.openstack.org/#q,topic:bp/trusts,n,z

Addressed by: https://review.openstack.org/21327
    membership to role conversion

Addressed by: https://review.openstack.org/22715
    Trusts

Addressed by: https://review.openstack.org/22889
    flatten payload for policy

Addressed by: https://review.openstack.org/22892
    Clean up error reporting on middleware errors.

Addressed by: https://review.openstack.org/23016
    Convert api to controller

Gerrit topic: https://review.openstack.org/#q,topic:master,n,z

Gerrit topic: https://review.openstack.org/#q,topic:trust-with-tests,n,z

Addressed by: https://review.openstack.org/23057
    Expand v3 trust test coverage

Gerrit topic: https://review.openstack.org/#q,topic:trust-test24,n,z

Gerrit topic: https://review.openstack.org/#q,topic:datetime-fix,n,z

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.