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

Joseph Heck
Adam Young
Adam Young
Series goal:
Accepted for grizzly
Milestone target:
milestone icon 2013.1
Started by
Joseph Heck
Completed by
Thierry Carrez

Related branches



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:,topic:trusts,n,z

Addressed by:
    roles mean membership

Addressed by:

Gerrit topic:,topic:bp/trusts,n,z

Addressed by:
    membership to role conversion

Addressed by:

Addressed by:
    flatten payload for policy

Addressed by:
    Clean up error reporting on middleware errors.

Addressed by:
    Convert api to controller

Gerrit topic:,topic:master,n,z

Gerrit topic:,topic:trust-with-tests,n,z

Addressed by:
    Expand v3 trust test coverage

Gerrit topic:,topic:trust-test24,n,z

Gerrit topic:,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.