[Openstack] State of OpenStack Auth

Jorge Williams jorge.williams at rackspace.com
Wed Mar 2 14:49:01 UTC 2011


We can certainly try your suggestions but I think the path of least resistance is to support an existing authentication scheme.  You're right in stating that the semantics are extremely close to cookies.  I'd note that http auth schemes almost always work in the exact same way -- that is client keeps track of the data, you get the header on every request, etc.

-jOrGe W.


On Mar 2, 2011, at 8:17 AM, Soren Hansen wrote:

2011/3/2 Jorge Williams <jorge.williams at rackspace.com<mailto:jorge.williams at rackspace.com>>:
1)  Weak support in HTTP client libraries.

a) This surprises me. I definitely remember using cookies with several
different http libraries.

b) There is *no* support for the current alternative, since it's
something that was made up for this particular purpose. If people use
http libriaries that do support cookies, they get Rackspace Cloud API
auth support for free. If not, they simply have to do it manually in a
manner elmost identical to what they have to do now, except with a
different HTTP header name.

 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.

What if we supported cookes on the server side, but noted in the API
docs that broken clients can pass the it as the X-Auth-Token header?

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.

401 sounds reasonable. If the client says it Accepts: text/html, we
could redirect it somewhere useful. If not, just leave the response
empty. How does that sound?

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 would certainly work. I was just specifically wondering why we're
doing something that has semantics extremely close to cookies, yet
don't use cookies. Whatever it is we do that makes it possible to do
stuff directly in a browser sounds great to me. :)


--
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/



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 at rackspace.com, and delete the original message. 
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110302/b7b23336/attachment.html>


More information about the Openstack mailing list