Open Stack

On Thu, Mar 3, 2011 at 3:33 PM, Michael Mayo <mike at openstack.org> wrote:
> Here are my thoughts, as a client developer:
> 1. Hit auth server first for token, then hit compute and storage endpoints
> This is fairly simple, but there are a couple of problems with it:
> a. It's not very curl or browser friendly (you have to curl the auth server
> first and copy the token, which is annoying)
> b. It's a waste of an HTTP request.  That may not matter for most people,
> but in the case of something like a mobile client, it's a serious problem.
>  Network traffic is a very precious resource on cell phones, so if you can
> do anything to reduce the number of HTTP requests you need to do something,
> you should.  This is not only true for the OpenStack mobile apps I write,
> but also for developers making apps that need to use swift to upload content
> somewhere.

Good points above.

> 2. Signed requests
> This is a little more painful from a development standpoint, but it's not
> really that big of a deal.  The only downside to this approach is that it's
> not curl or browser friendly.  However, the upside of preventing replay
> attacks is pretty valuable.

Also good point :)

> 3. HTTP Basic
> HTTP Basic is great because it's super easy to use and it's curl and browser
> friendly.  However, replay attacks are possible so you open yourself up to a
> security issue there.

Yup.

> My Vote (Assuming I Actually Have One)

Yes, you have a vote, and yes, it counts.

> I think signed requests are the best option since it's more secure than HTTP
> Basic.  We could make an oscurl command line tool that would sign a request
> and behave exactly like curl.  That shouldn't be too hard.  But if that
> can't happen, HTTP Basic is the next best choice.  Requiring API users to
> get a new auth token every n hours via an auth endpoint kind of sucks,
> especially from a mobile client perspective.

Would the best option be if the OpenStack API supported both auth
mechanisms (signature, basic HTTP) and allowed the deployers to pick
which ones were best for which clients? For instance, if OpenStack
supported both auth mechanisms simultaneously, mobile apps could
choose signatures whereas other clients, say a simple web dashboard,
could choose HTTP basic auth an re-auth every N hours?

-jay

>
> On Mar 3, 2011, at 9:04 AM, Jorge Williams wrote:
>
>
> I agree with Greg here.  Signatures complicate life for our clients, they
> are not browser friendly, and I'm not really convinced that we need them. If
> we are going to have a default (and I think that we should) it should be
> dead simple to integrate with.   I would vote for basic auth with https.
>
> -jOrGe W.
>
> On Mar 3, 2011, at 9:40 AM, Greg wrote:
>
> On Mar 2, 2011, at 8:30 PM, Jesse Andrews wrote:
>
> I would prefer a signature based approach as the default (as signatures
> limits replay attacks; tokens allow an eavesdropper to make arbitrary
> requests if they obtain a token).
>
> On the other hand, signatures make simple things difficult, such as quick
> curl requests, dev testing, etc. The usual tradeoff of security and
> convenience.
>
> _______________________________________________
>
> Mailing list: https://launchpad.net/~openstack
>
> Post to     : openstack at lists.launchpad.net
>
> Unsubscribe : https://launchpad.net/~openstack
>
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> Mike Mayo
> 901-299-9306
> @greenisus
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>