openstack team mailing list archive

[Jesse Andrews <anotherjesse@xxxxxxxxx>]

I agree that things should be pluggable, but OpenStack needs to have a default.  

Users need to know that they can point OpenStack client applications at OpenStack providers and it should work.

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).

Jesse

On Mar 2, 2011, at 7:34 AM, Jorge Williams wrote:

> Soren,
> 
> Really good question about why we didn't use cookies. There are two problems that I see with cookies.
> 
> 1)  Weak support in HTTP client libraries.  HTTP libs tend to not handle them at all or to not handle them correctly. In the Java world,  for example, java.net.* doesn't handle cookies very well. There are certainly other libs that handle them, but a whole bunch of software is built on top of java.net.* including some popular REST libraries.
> 2)  Say you make a request and don't include your cookie in it. A typical webapp will simply redirect you to a login form.  But what should happen in a REST API?  Should you get a 401?  I think it's a little fuzzy how we would handle this correctly.
> 
> If you want browser support -- and personally I think all of our APIs should be browser friendly -- I think the best approach is to support an establish scheme like HTTP Basic or Digest.  These schemes have great client lib support.  They are supported in a friendly way by browsers.  And they don't break HTTP semantics, so you don't get a redirect when you should be getting a request for credentials.
> 
> That said, I really feel we should take a pluggable approach to authentication so that we can let operators and clients decide what they need.
> 
> -jOrGe W.
> 
> 
> On Mar 1, 2011, at 3:08 PM, Eric Day wrote:
> 
>> On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote:
>>> 2011/3/1 Eric Day <eday@xxxxxxxxxxxx>:
>>>> Well, hopefully with a shared, modular service, we can add a token
>>>> module that uses cookies instead. :)
>>> 
>>> Sure :) I was just hoping to extract whatever wisdom might have been
>>> behind the decision to seemingly reinvent the concept of cookies.
>>> Perhaps there's some reason to avoid cookies I'm missing... Sorry,
>>> didn't mean to hijack your thread :)
>> 
>> That's what this thread is for, figure out what we have and what do
>> we want? :)
>> 
>> Perhaps Jorge or someone else on the Rackspace auth side can share
>> some reasons for the decisions?
>> 
>> -Eric
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp