openstack team mailing list archive

[Nick Lothian <nick.lothian@xxxxxxxxx>]

Excellent, thanks for that information Javier.

It's good to know I'm not the only person doing this.
On Apr 26, 2012 5:20 PM, "javier cerviño" <jcervino@xxxxxxxxxx> 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
> >
>