openstack team mailing list archive

[Michael Mayo <mike@xxxxxxxxxxxxx>]

> The problem with this logic is that you are optimizing wrong.  In a token based auth system, the tokens are valid generally for a period of time (24 hours normally with Rackspace auth), and it is a best practice to cache this.  Saying that you are reducing HTTP requests for 1 request that has to happen every 24 hours isn't saving you that much.

It depends.  If you're in a busy area of a big city with 1 bar of EDGE coverage on your phone, latency becomes your biggest connectivity issue.  So if you're only doing something with the API every 24 hours, auth could reasonably be close to 50% of the time you stare in frustration cursing your carrier.

For something that's doing a lot of things with the API (such as my apps), I agree with you.  Saving 1 request isn't that much of an improvement.  But I think a lot of people will want to use this differently than we do, particularly with swift.  Quite a few people are making iPhone apps that hard code their API Keys into the source code to offer some sort of social sharing functionality (uploading pictures, audio, video, or whatever), and what they see when testing without wifi is that uploading something is noticeably slower than doing it with S3 (which doesn't have an auth step; instead you sign the request).

Sure, if you cache the token, every upload after the first one will seem faster (for 24 hours) and probably comparable to S3, but why not make the first one fast too?

If I'm not making sense here, please let me know.  I don't want to troll this list or anything; just trying to suggest ways to make the API as nice as possible, particularly for mobile app developers.

Cheers!
Mike Mayo
@greenisus


> But back to the auth questions in general, I would like to comment on a couple of things that have come up:
> 
> 1.  Basic Auth - I'm not fond of this mainly because auth credentials (identification and secret) are sent, and have to be verified on every single request.  This also means that every endpoint is going to be handling the users' secrets for every request.  I think there is good precedent with no major service providers using basic auth (even including twitter moving away from basic auth, to OAuth)
> 
> 2. Signed vs. Token based auth - Why not support both?  It isn't that complex.  It is also interesting that OAuth v1 was signature based, while OAuth v2 has moved to a token based auth system, so there is broad support in the general community for both methods.
> 
> --
> Chuck
> 
> On Thu, Mar 3, 2011 at 2:59 PM, Michael Mayo <mike@xxxxxxxxxxxxx> wrote:
> I was thinking more of a "sniff someone's traffic and perform those same requests again" sort of attack.  But then again, I'm an iPhone guy and not a security expert :)
> 
> In the end, I'm simply advocating that we reduce the number of HTTP requests needed to get information or get things done.  Getting rid of the auth server call is a first step.  Future steps could be things like including child entities in responses (for instance, getting a server list also returning complete image and flavor entities).  Then perhaps we could allow creates and actions to happen on multiple entities ("create 10 servers" instead of calling "create server" 10 times, reboot a set of servers, etc).
> 
> How we reduce API calls isn't that important to me.
> 
> Thanks!
> Mike
> 
> 
> On Mar 3, 2011, at 12:52 PM, Jorge Williams wrote:
> 
>> 
>> I think you're overestimating the security risk in issue 3.  You're bank's website uses HTTPS.  In order to launch a successful man-in-the middle attack against it you would have to compromise the certificate authority.  Basic Auth with HTTPS against a single endpoint is pretty darn secure and no more secure than option 1.  The big advantage of 2 is that you can initiate conversations *without* HTTPS, there may be cases when you'd want to do that, but seeing that we have the potential to move passwords around when we create servers,  I don't see why you would want to go that route.  Using a token becomes important when we start talking about delegation, but let's not go there right now :-)
>> 
>> -jOrGe W.
>> 
>> 
>> 
>> On Mar 3, 2011, at 2:33 PM, Michael Mayo 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> My Vote (Assuming I Actually Have One)
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> Mike Mayo
>>> 901-299-9306
>>> @greenisus
>>> 
>>> 
>>> 
>> 
> 
> Mike Mayo
> 901-299-9306
> @greenisus
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 

Mike Mayo
901-299-9306
@greenisus