<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 9:08 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
<br>
On 12/09/2013 05:34 PM, Steven Hardy wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi all,<br>
<br>
I have some queries about what the future of the ec2tokens API is for<br>
keystone, context as we're looking to move Heat from a horrible mixture of<br>
v2/v3 keystone to just v3, currently I'm not sure we can:<br>
<br>
- The v3/credentials API allows ec2tokens to be stored (if you<br>
create the access/secret key yourself), but it requires admin, which<br>
creating an ec2-keypair via the v2 API does not?<br>
<br>
- There is no v3 interface for validating signed requests like you can via<br>
POST v2.0/ec2tokens AFAICT?<br></blockquote></div></blockquote><div><br></div><div>I thought both of these were "accidentally" introduced in v3 by including the ec2 middleware in the v3 pipeline by default back in grizzly? Essentially making them undocumented APIs. I haven't tested it myself.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- Validating requests signed with ec2 credentials stored via v3/credentials<br>
does not work, if you try to use v2.0/ec2tokens, should it?<br></blockquote></div></blockquote><div><br></div><div>What's the blocker / what doesn't work?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So my question is basically, what's the future of ec2tokens, is there some<br>
alternative in the pipeline for satisfying the same use-case?<br>
<br>
The main issues we have in Heat:<br>
<br>
- We want to continue supporting AWS style signed requests for our<br>
cloudformation-compatible API, which is currently done via ec2tokens.<br>
<br>
- ec2 keypairs are currently the only method of getting a non-expiring<br>
credential which we can deploy in-instance, that is no longer possible<br>
via the v3 API for the reasons above.<br></blockquote></div></blockquote><div><br></div><div>As mentioned below, access keys don't necessarily expire, and can be utilized without storing a user identity (you just need to store an OAuth access key & secret key). When generating OpenStack tokens, they impersonate they user who delegated authorization.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What is the recommended way for us to deploy a (non expiring) credential in<br>
an instance (ideally derived from a trust or otherwise role-limited), then<br>
use that credential to authenticate against our API?<br>
</blockquote>
<br></div>
X509.<br>
<br>
The issue, as I understand it, is that there is no user object to back that credential. You don't have a user to execute the trust.<br>
<br>
Note that you should not be deriving a credential from a trust, you should be linking a trust to a credential.<br>
<br>
The KDS code base has a similar problem. We need a longer term credential service for internal components of Open Stack. KDS is going to do it with symmetric keys, which might serve your needs. This is usually done via Kerberos in enterprise deployments.<div class="im">
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
My first thought is that the easiest solution would be to allow trust<br>
scoped tokens to optionally be configured to not expire (until we delete<br>
the trust when we delete the Heat stack)?<br>
<br>
Can anyone offer any suggestions on a v3 compatible way to do this?<br>
<br>
I did start looking at oauth as a possible solution, but it seems the<br>
client support is not yet there, and there's no auth middleware we can use<br>
for authenticating requests containing oauth credentials, any ideas on the<br>
status of this would be most helpful!<br></blockquote></div></blockquote><div><br></div><div>The current implementation basically requires you to exchange an OAuth access token for an identity v3 token -- we don't have middleware to validate OAuth-signed requests like we do for identity API tokens (auth_token).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote></div>
OAuth is short term delegation, not what you need.</blockquote><div><br></div><div>Expiration of access tokens is optional:</div><div><br></div><div> <a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-oauth1-ext.md#create-access-token-post-os-oauth1access_token">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-oauth1-ext.md#create-access-token-post-os-oauth1access_token</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks!<br>
<br>
Steve<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>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>