The only reason i've heard of for creating long term use tokens was for kerb environments in which one was operating remotely and could not authenticate to a KDC and so needed a long lived ticket to authenticate to services while outside of a KDC's trusted space.<br>
<br>For the use cases you are describing I wonder if what you really need is not a token but a new style of account entirely.  And by new I mean just a clarification of things like the api-paste.ini accounts.  A service account... or maybe a service ticket / token?<br>
<br>Just food for thought.<br><br><div class="gmail_quote">On Tue, Oct 9, 2012 at 7:16 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
1.  HEAT and failover.  It needs to move a virtual machine from one host to another.<br>
2.  Content production.    Something generates a large file and needs to store it in swift.<br>
<br>
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.<br>
<br>
To support this, add two new APIs.  One is POST preauthenticate, and the other is GET preauthenticate/{user_id}<br>
<br>
When POSTing to preauthenticate,  the user supplies a user that will be allowed to fetch a token at some point in the future.<br>
<br>
When GETting tokens/preauthenticated/{user_<u></u>id}  only the specified user will be able to fetch a token for the user that performed the preauthenticate action.<br>
<br>
We could potentially add an additional PATCH to modify a pre-auth arraingement.  We would certainly want a DELETE.<br>
<br>
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<br>

<br>
Comments?<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br>