On Mon, Dec 9, 2013 at 9:08 PM, Adam Young <ayo...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev