It's indeed practical but there are some shortcomings. Ping me off thread for any details. For the record, I was responsible for the signing implementation in EC2 and for the AuthN/AuthZ design for the Opscode platform (hosted Chef) and I'm looking forward to this conversation at the summit as well.
Cheers, Chris On Mon, Apr 18, 2011 at 4:30 PM, Michael Barton <[email protected]> wrote: > On Mon, Apr 18, 2011 at 12:15 PM, Eric Day <[email protected]> wrote: >> We'll also want to decide if we need a default mechanism for >> OpenStack deployments, and if so, what should it be. We had a >> discussion previously and I think it was somewhere between token >> and HTTP basic w/ SSL. The reason for this is we need to make sure >> different deployments are compatible. > > > I'm still gonna argue for key signing to be a first-class auth scheme. > It enables things that can't be done with token or basic auth, like > signed URLs and unencrypted requests. Both of these are desirable for > Swift, at the least. > > It kind of sucks that key signing (as least as implemented by the > EC2/S3 API) requires a key to be available to both sides in plaintext. > Public key crypto is one way to fix that, but I don't really know how > practical that is. > > -- Mike Barton > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > -- Christopher Brown, Chief Technical Officer, Opscode, Inc. T: (425) 502-5522, E: [email protected] IRC, Github: skeptomai Twitter: @skeptomai _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
