There's a HMAC-based generic signature authentication plugin patch which should meet your needs.
https://review.openstack.org/#/c/40036/ Now the hard part, code review. :) Guang > -----Original Message----- > From: Steven Hardy [mailto:[email protected]] > Sent: Monday, December 09, 2013 2:34 PM > To: [email protected] > Subject: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and > request signing > > 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? > > - Validating requests signed with ec2 credentials stored via > v3/credentials > does not work, if you try to use v2.0/ec2tokens, should it? > > 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. > > 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? > > 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! > > Thanks! > > Steve > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
