Open Stack

On Mon, Dec 9, 2013 at 9:08 PM, Adam Young <ayoung at redhat.com> wrote:

>
>
>
> On 12/09/2013 05:34 PM, Steven Hardy wrote:
>
>> Hi all,
>>
>> I have some queries about what the future of the ec2tokens API is for
>> keystone, context as we're looking to move Heat from a horrible mixture of
>> v2/v3 keystone to just v3, currently I'm not sure we can:
>>
>> - The v3/credentials API allows ec2tokens to be stored (if you
>>    create the access/secret key yourself), but it requires admin, which
>>    creating an ec2-keypair via the v2 API does not?
>>
>> - There is no v3 interface for validating signed requests like you can via
>>    POST v2.0/ec2tokens AFAICT?
>>
>
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.


>
>> - Validating requests signed with ec2 credentials stored via
>> v3/credentials
>>    does not work, if you try to use v2.0/ec2tokens, should it?
>>
>
What's the blocker / what doesn't work?


>
>> So my question is basically, what's the future of ec2tokens, is there some
>> alternative in the pipeline for satisfying the same use-case?
>>
>> The main issues we have in Heat:
>>
>> - We want to continue supporting AWS style signed requests for our
>>    cloudformation-compatible API, which is currently done via ec2tokens.
>>
>> - ec2 keypairs are currently the only method of getting a non-expiring
>>    credential which we can deploy in-instance, that is no longer possible
>>    via the v3 API for the reasons above.
>>
>
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.


>
>> What is the recommended way for us to deploy a (non expiring) credential
>> in
>> an instance (ideally derived from a trust or otherwise role-limited), then
>> use that credential to authenticate against our API?
>>
>
> X509.
>
> 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.
>
> Note that you should not be deriving a credential from a trust, you should
> be linking a trust to a credential.
>
> 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.
>
>
>
>
>
>> My first thought is that the easiest solution would be to allow trust
>> scoped tokens to optionally be configured to not expire (until we delete
>> the trust when we delete the Heat stack)?
>>
>> Can anyone offer any suggestions on a v3 compatible way to do this?
>>
>> I did start looking at oauth as a possible solution, but it seems the
>> client support is not yet there, and there's no auth middleware we can use
>> for authenticating requests containing oauth credentials, any ideas on the
>> status of this would be most helpful!
>>
>
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).


>  OAuth is short term delegation, not what you need.


Expiration of access tokens is optional:


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


>
>
>
>
>> Thanks!
>>
>> Steve
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/0cdb5f95/attachment.html>