[Openstack] Using Nova APIs from Javascript: possible?

javier cerviño jcervino at dit.upm.es
Thu Apr 26 07:50:14 UTC 2012


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 at gmail.com> wrote:
>
>
> On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung at redhat.com> 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>




More information about the Openstack mailing list