openstack team mailing list archive

[Tres Henry <tres@xxxxxxxxxxxxx>]

Interesting! Nice job on jstack!

On Apr 26, 2012, at 12:50 AM, javier cerviño wrote:

> Hi all,
> 
> I'm glad to hear that there's a lot of interest in the implementation
> of Openstack JavaScript clients. Actually, in my group we're
> developing a "single page" application developed entirely in
> JavaScript, that widely supports Nova and Keystone APIs.  This work is
> part of a European Project called FI-Ware (http://www.fi-ware.eu/), in
> which we are currently using Openstack APIs.
> 
> We've modified Nova and Keystone installations by adding CORS support.
> We did it by implementing a kind of filter on their APIs. For doing
> this we used Adam's implementation
> (https://github.com/adrian/swift/tree/cors), and we adapted it to Nova
> and Keystone components. We also developed a JS library
> (http://ging.github.com/jstack/) that can be used by both web and
> Node.js applications, for example. This library aims to provide same
> functionalities as python-novaclient, adding support for Keystone API.
> 
> And finally we are copying Openstack horizon functionality, using JS
> library and other frameworks such as jQuery and Backbone.js to
> implement the web application. This web application is an
> "early-stage" work, but we will probably publish it by the end of this
> week. I will let you know the github link.
> 
> We didn't find much problems with CORS implementation and support in
> browsers.  For the time being, according to our experiments, the only
> web browser that is not usable at all with this technology is Internet
> Explorer, but we have tried it in Google Chrome, Safari and Firefox as
> well and we didn't have any problems.
> 
> Cheers,
> Javier Cerviño.
> 
> On 26 April 2012 06:28, Nick Lothian <nick.lothian@xxxxxxxxx> wrote:
>> 
>> 
>> On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung@xxxxxxxxxx> wrote:
>>> 
>>> Let me try to summarize:
>>> 
>>> 1.  If you are running from a web browser,  post requests to hosts or
>>> ports other than the origin are allowed,  but the headers cannot be
>>> modified.  This prevents the addition of the token from Keystone to provide
>>> single sign on.
>>> 
>>> 2.  There are various browser side technologies (JSONP, CORS) that get
>>> around this limitation, but they are typically not enabled,  and can be
>>> considered security issues.  While implementing these might require support
>>> from teh Openstack server,  they are fundamentally browser decisions.
>>> 
>> 
>> This is inaccurate. JSONP is supported by all browsers since ~Netscape 4.0.
>> 
>> CORS is supported by all modern browsers: IE > 8, Firefox > 3.5, Chrome > 3,
>> Safari > 4
>> (See http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Browser_support).
>> Additionally, CORS support is not a browser decision - the server has to
>> EXPLICITLY opt-in to support it.
>> 
>> Obviously CORS support *can* be a security issue - that is why it is
>> disabled unless the server enables it.
>> 
>> I do not believe that CORS support adds any additional security issues above
>> what the OpenStack APIs already face. Specially, the most common problem
>> (CSRF) is not an issue here because the APIs are not authorised on a session
>> basis.
>> 
>>  [snip]
>>> 
>>> 
>>> I've been working on Single Sign on Issues for another project for the
>>> past year and a half.  Here's a couple things I've learned.
>>> 
>>> 
>>> Kerberos is designed to solve this problem.  It has the benefit of being
>>> integrated into the browser.  Where Kerberos fails is that:  typically it
>>> only allows a single authentication provider (KDC in Kerberso speak) and it
>>> does not work well with Firewalls.
>>> 
>>> The only crytographically secure way to authenticate on the web that can
>>> get around the firewall issue is Client side X509 certificates.  This is the
>>> foundation for https://blueprints.launchpad.net/keystone/+spec/pki.  This
>>> could, in theory, work in with OAuth, OpenID,  or some other distributed
>>> authorization service,  or we could embed the authorization information
>>> right into the Certitificate, which is what I suggest we do.
>>> 
>>> 
>> 
>> To be clear, identity/authorisation is NOT the problem here. The OpenStack
>> APIs work well for my use cases, once I work around the cross domain POST
>> problem.
>> 
>> However, I've also worked with SSO solutions. The simple truth is that
>> client side certificates do not play well with the web - browser support
>> ranges from non-existent (on some mobile platforms -
>> see http://mobilitydojo.net/2010/12/28/client-certificate-support-across-mobile-platforms-a-summary/) to
>> abysmal (there is a reason why many websites that use certificates end up
>> using a Java applet), and their interaction with cross domain Javascript is
>> unknown.
>> 
>> Even if certificates did work for identification, CORS would still be needed
>> - many OpenStack APIs require a POST request which is impossible without
>> it.
>> 
>> 
>> Nick
>> 
>> _______________________________________________
>> 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