Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

Using Nova APIs from Javascript: possible?

 

 

First page Previous page 1 2 Next page Last page  View All OpenStack dev RSS feed   Index | Next | Previous | View Threaded


john.postlethwait at nebula

Apr 25, 2012, 11:50 AM

Post #26 of 39 (430 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

TL;DR for the below: +1 to what Nick said.


I think both sides here are valid...

Yes, security issues are opened up with these technologies, and they are indeed rather new, but the use-case for wanting to access the files in this manner also definitely exists.

Whatever solution is decided on, we should do it in a manner that allows someone installing OpenStack to entirely shut to off/not use it, OR to open it up to JSONP/CORS/whatever and have Tres' use-cases supported.

The risk is up to the installer depending on their needs/use-cases. We should support them AND do a good job of educating them of the risks and rewards of using such technologies. It shouldn't be up to us to determine if it is theoretically a good idea or not, or if it is necessary, or if it could be done in a different way, or if their desire is off-base, but we should support the functionality in an intelligent manner and let the installer decide on what/how/why they want to use and install OpenStack…


John Postlethwait
Nebula, Inc.
206-999-4492


On Wednesday, April 25, 2012 at 10:01 AM, Jan Drake wrote:

> A little of both. Serving JS, et al from a CDN for a set of domain services is easy peasey stuff and we do it all the time... but we tend to do so with a common edge (at the very least in DNS space) that precludes the need for JSONP/CORS. I'm not sure if the use case here is:
>
> 1) JS client talking to multiple service providers hosting openstack, (seems low priority to me but potentially valid)
> 2) JS client talking to multiple openstack services within a single hosting provider (seems high priority to me)
>
> #2 is easy we do it all the time. #1 gets messy but I probably wouldn't just use a JS only mashup client to get the job done.
>
> Anyway, just thoughts... re maturity: our enterprise security folks have issues with using jsonp/cors and consider it contraindicated at the moment.
>
>
>
> Jan
>
>
> Subject: Re: [Openstack] Using Nova APIs from Javascript: possible?
> From: tres [at] treshenry (mailto:tres [at] treshenry)
> Date: Wed, 25 Apr 2012 09:49:15 -0700
> CC: openstack [at] lists (mailto:openstack [at] lists)
> To: jan_drake [at] hotmail (mailto:jan_drake [at] hotmail)
>
> Jan: is the concern that you don't see the value in the use case or that you don't believe the proposed technologies are sufficiently mature?
>
> In order to keep the thread somewhat linear I'm basically going to +1 what Nick said and add that as an application developer I should be able to serve the JS, HTML and CSS for my application from a CDN and have my application talk directly to an OpenStack endpoint. This is an important scenario now but will become critical with the wave of PAAS offerings coming for OpenStack (i.e. my application should be able to talk directly to FathomDB running on OS).
>
>
> On Apr 25, 2012, at 3:46 AM, Nick Lothian wrote:
> > JSONP has been used for years - for example Solr has supported it since 2008 (and possibly earlier). CORS matches the Openstack APIs better though.
> > Redirects are unrelated to the problem as far as I can see.
> > I think that toolmakers trying to build Javascript tools that connect to multiple service providers is a completely valid use case. It is supported for pretty much any other language, why not Javascript?
> > On Apr 25, 2012 12:33 PM, "Jan Drake" <jan_drake [at] hotmail (mailto:jan_drake [at] hotmail)> wrote:
> > > So, why such a focus on this? IMO both JSONP and CORS are way too early stage to adopt and the security risks outweigh the rewards. Usually, I see people doing this to enable mashups across separate providers.
> > >
> > > Just curious why the focus/need is perceived in the community? If this is really because of redirects then we probably have a broken model and/or improper distribution of responsibilities.
> > >
> > > Love to know if I'm missing a real use case. Can help fix model if it is broken. Have much experience in this area.
> > >
> > > IMO no solution should trick the browser.
> > >
> > >
> > > Jan
> > >
> > >
> > >
> > > On Apr 24, 2012, at 7:05 PM, Luis Gervaso <luis [at] woorea (mailto:luis [at] woorea)> wrote:
> > >
> > > > The solution until the webservice deliver that headers is:
> > > >
> > > > Solution 1:
> > > >
> > > > 1. Put the webservice behind a remote or local proxy
> > > > 2. Apply some a filter (decorator) for each response with the CORS headers (in the proxy) in order to trick the browser
> > > >
> > > > Solution 2:
> > > >
> > > > Some time ago I tested it with Chrome (disabling security) and it worked for me
> > > >
> > > > Solution 3 (really dirty, but works):
> > > >
> > > > Embedded Flash Proxy
> > > >
> > > >
> > > > On Wed, Apr 25, 2012 at 3:09 AM, Nick Lothian <nick.lothian [at] gmail (mailto:nick.lothian [at] gmail)> wrote:
> > > > > Yes, this will work if I know in advance what server I will be connecting too.
> > > > > However, it does remove the ability to support any cloud without intervention on the serverside.
> > > > > On Apr 25, 2012 2:46 AM, "Joel Semar" <semarjt [at] gmail (mailto:semarjt [at] gmail)> wrote:
> > > > > > Nick,
> > > > > >
> > > > > > I know you said 'serverless clients' but you have to be serving the js from somewhere right?
> > > > > >
> > > > > > If you are using nginx it can be as simple as:
> > > > > >
> > > > > > location /nova/ {
> > > > > > proxy_pass: http://nova-api.trystack.org (http://nova-api.trystack.org/);
> > > > > > }
> > > > > >
> > > > > > then you can POST to yourserver/nova/v.02/. from the browser
> > > > > >
> > > > > > etc.
> > > > > > (it's just about as simple on apache but you'd have to look it up)
> > > > > >
> > > > > >
> > > > > > But then i guess this won't work for you if you are writing some distributable component/plugin/library.
> > > > > >
> > > > > > (sorry if you've already dismissed this option but i thought it worth a shot since it has worked flawlessly for me in the past)
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh <sandy.walsh [at] rackspace (mailto:sandy.walsh [at] rackspace)> wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 04/24/2012 11:19 AM, Nick Lothian wrote:
> > > > > > > > JSONP is great, but won't work with POST requests.
> > > > > > >
> > > > > > > Hmm, good point.
> > > > > > >
> > > > > > > > I don't quite understand what "Due to the redirect nature of the auth
> > > > > > > > system" means, though.
> > > > > > > >
> > > > > > > > If I use a custom Webkit browser & allow cross domain XMLHttpRequests it
> > > > > > > > works fine - I do a POST to /v2.0/tokens, get the token and then use
> > > > > > > > that. What am I missing?
> > > > > > >
> > > > > > > The Auth system will give you a token and then a new "management" url
> > > > > > > where the actual commands are issued (the real Nova API endpoint). These
> > > > > > > are often two different systems (domains), so cross-site requests are
> > > > > > > mandatory.
> > > > > > >
> > > > > > > -S
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Nick
> > > > > > > >
> > > > > > > > On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh <sandy.walsh [at] rackspace (mailto:sandy.walsh [at] rackspace)
> > > > > > > > <mailto:sandy.walsh [at] rackspace>> wrote:
> > > > > > > >
> > > > > > > > Due to the redirect nature of the auth system we may need JSONP support
> > > > > > > > for this to work.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > > > > > <mailto:openstack [at] lists>
> > > > > > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > > More help : https://help.launchpad.net/ListHelp
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > > > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > > More help : https://help.launchpad.net/ListHelp
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > > More help : https://help.launchpad.net/ListHelp
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > >
> > > > > > Joel
> > > > > >
> > > > > > _______________________________________________
> > > > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > > More help : https://help.launchpad.net/ListHelp
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > > More help : https://help.launchpad.net/ListHelp
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -------------------------------------------
> > > > Luis Alberto Gervaso Martin
> > > > Woorea Solutions, S.L
> > > > CEO & CTO
> > > > mobile: (+34) 627983344
> > > > luis@ (mailto:luis.gervaso [at] gmail)woorea.es (http://woorea.es/)
> > > > _______________________________________________
> > > > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > > > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > > > More help : https://help.launchpad.net/ListHelp
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > Post to : openstack [at] lists (mailto:openstack [at] lists)
> > Unsubscribe : https://launchpad.net/~openstack (https://launchpad.net/%7Eopenstack)
> > More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists (mailto:openstack [at] lists)
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


ayoung at redhat

Apr 25, 2012, 1:19 PM

Post #27 of 39 (423 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

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.

3. If you are doing this from a command line or non-webbrowser UI, you
are not limited by the same origin policy.

4. You can always proxy through the the origin to the remote services,
but this may prove to be a scalability limitation.

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.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


kevin.mitchell at rackspace

Apr 25, 2012, 3:55 PM

Post #28 of 39 (416 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

On Wed, 2012-04-25 at 16:19 -0400, Adam Young wrote:
> 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.

Well, Kerberos uses UDP for its network communication, so that's the
place it fails with firewalls. (Krb4 also embedded the IP in the
ticket, but I don't believe this is required in Krb5; that said, it's
been a long time since I looked at Kerberos.) Once you have the service
credential (as opposed to the TGT, which you would use to get the
service credential), firewalls are irrelevant to Kerberos.

As for authentication provider…this obviously is not the place to
discuss cross-realm authentication in Kerberos, but rest assured it
works fine. It requires the realm administrators to set up a trust
relationship, however, which is the disadvantage relative to
certificates.

As far as KDC availability goes—it is incredibly stable; the master KDC
at MIT used to run on an old Ultrix machine, and it ran for so long that
the Ultrix operating system uptime counter rolled over and crashed the
machine. The KDC is also surprisingly low traffic—it uses UDP, so you
avoid the overhead of TCP (at the expense of having to implement
exponential backoff), and the KDC is only contacted when you need to get
your initial TGT and later the first time you need to contact a
particular service, thanks to the credentials cache. Finally, it is
very easy to set up redundant slave KDCs.
--
Kevin L. Mitchell <kevin.mitchell [at] rackspace>


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


nick.lothian at gmail

Apr 25, 2012, 9:28 PM

Post #29 of 39 (419 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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<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


jcervino at dit

Apr 26, 2012, 12:50 AM

Post #30 of 39 (418 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

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

On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>
>
> On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
> (Seehttp://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 fromnon-existent(on some mobile platforms -
> seehttp://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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


nick.lothian at gmail

Apr 26, 2012, 3:30 AM

Post #31 of 39 (418 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

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 cervio" <jcervino [at] dit> 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 Cervio.
>
> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
> >
> >
> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>


tres at treshenry

Apr 26, 2012, 12:56 PM

Post #32 of 39 (415 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

Interesting! Nice job on jstack!

On Apr 26, 2012, at 12:50 AM, javier cervio 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 Cervio.
>
> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>
>>
>> On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


diego.parrilla.santamaria at gmail

Apr 27, 2012, 12:20 AM

Post #33 of 39 (405 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

Awesome Javier!!!!

Anxiously waiting for a meeting with you guys to see your progress!

Cheers
Diego
--
Diego Parrilla
<http://www.stackops.com/>*CEO*
*www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29 |
skype:diegoparrilla*
* <http://www.stackops.com/>
*

*




On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit> 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 Cervio.
>
> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
> >
> >
> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>


adrian_f_smith at dell

Apr 27, 2012, 4:37 AM

Post #34 of 39 (406 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

I'd be really interested to hear how you go on with the CORS middleware Javier.
Did it work as-is or did you have to modify it? Was there much effort
involved in using it with Nova?

>From your experience it sounds like there's decent CORS support in browsers
now so it's probably time to submit this change to gerrit.

Adrian


2012/4/27 Diego Parrilla Santamara <diego.parrilla.santamaria [at] gmail>

> Awesome Javier!!!!
>
> Anxiously waiting for a meeting with you guys to see your progress!
>
> Cheers
> Diego
> --
> Diego Parrilla
> <http://www.stackops.com/>*CEO*
> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29 |
> skype:diegoparrilla*
> * <http://www.stackops.com/>
> *
>
> *
>
>
>
>
> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>
>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>> >
>> >
>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


jcervino at dit

Apr 27, 2012, 6:13 AM

Post #35 of 39 (404 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

Hi!

We have just published the code of the portal in Github. You can find it in
https://github.com/ging/horizon-js. It will only work with Keystone and
Nova if they have CORS implemented.

Adrian, we didn't make big changes in your code, only logger classes and a
little problem we found with PUT requests in some cases (I have to take a
deeper look into this problem, anyway). We've made tests from iPhone,
iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
week I will test it with Android and Opera browsers.

Sure! It will be very interesting to submit your code to gerrit!!

Diego, I will talk with Joaquin to check if we can show you a demo in two
weeks!!

Cheers,
Javier.

2012/4/27 Adrian Smith <adrian_f_smith [at] dell>

> I'd be really interested to hear how you go on with the CORS middleware Javier.
> Did it work as-is or did you have to modify it? Was there much effort
> involved in using it with Nova?
>
> From your experience it sounds like there's decent CORS support in
> browsers now so it's probably time to submit this change to gerrit.
>
> Adrian
>
>
> 2012/4/27 Diego Parrilla Santamara <diego.parrilla.santamaria [at] gmail>
>
>> Awesome Javier!!!!
>>
>> Anxiously waiting for a meeting with you guys to see your progress!
>>
>> Cheers
>> Diego
>> --
>> Diego Parrilla
>> <http://www.stackops.com/>*CEO*
>> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29 |
>> skype:diegoparrilla*
>> * <http://www.stackops.com/>
>> *
>>
>> *
>>
>>
>>
>>
>> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>>
>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>> >
>>> >
>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat> 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
>>> > Unsubscribe : https://launchpad.net/~openstack
>>> > More help : https://help.launchpad.net/ListHelp
>>> >
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>


jcervino at dit

Apr 30, 2012, 2:53 AM

Post #36 of 39 (398 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

Hi Adrian,

I've just seen you submitted your Swift-based CORS implementation to
Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
the other hand, it could be better to wait for its approval because we
could apply changes proposed by the reviewers to the rest of components.

We've just started to implement Glance API support in jStack, and then I
will started with Swift. Is anybody out there who wants to join this
challenge? You're welcome to propose changes, write code, and so on. The
idea is to develop full OpenStack API in JavaScript, so that community
could start working with it.

Cheers,
Javier.

2012/4/27 javier cervio <jcervino [at] dit>

> Hi!
>
> We have just published the code of the portal in Github. You can find it
> in https://github.com/ging/horizon-js. It will only work with Keystone
> and Nova if they have CORS implemented.
>
> Adrian, we didn't make big changes in your code, only logger classes and a
> little problem we found with PUT requests in some cases (I have to take a
> deeper look into this problem, anyway). We've made tests from iPhone,
> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
> week I will test it with Android and Opera browsers.
>
> Sure! It will be very interesting to submit your code to gerrit!!
>
> Diego, I will talk with Joaquin to check if we can show you a demo in two
> weeks!!
>
> Cheers,
> Javier.
>
> 2012/4/27 Adrian Smith <adrian_f_smith [at] dell>
>
>> I'd be really interested to hear how you go on with the CORS middleware Javier.
>> Did it work as-is or did you have to modify it? Was there much effort
>> involved in using it with Nova?
>>
>> From your experience it sounds like there's decent CORS support in
>> browsers now so it's probably time to submit this change to gerrit.
>>
>> Adrian
>>
>>
>> 2012/4/27 Diego Parrilla Santamara <diego.parrilla.santamaria [at] gmail>
>>
>>> Awesome Javier!!!!
>>>
>>> Anxiously waiting for a meeting with you guys to see your progress!
>>>
>>> Cheers
>>> Diego
>>> --
>>> Diego Parrilla
>>> <http://www.stackops.com/>*CEO*
>>> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29|
>>> skype:diegoparrilla*
>>> * <http://www.stackops.com/>
>>> *
>>>
>>> *
>>>
>>>
>>>
>>>
>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>>>
>>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>>> >
>>>> >
>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat>
>>>> 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
>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>> > More help : https://help.launchpad.net/ListHelp
>>>> >
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>


adrian at 17od

Apr 30, 2012, 4:50 AM

Post #37 of 39 (394 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

I have no issue with you submitting your code Javier. As you say though, it
might be worth waiting until it's accepted into Swift so you can take
advantage of suggestions.

Adrian

2012/4/30 javier cervio <jcervino [at] dit>

> Hi Adrian,
>
> I've just seen you submitted your Swift-based CORS implementation to
> Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
> the other hand, it could be better to wait for its approval because we
> could apply changes proposed by the reviewers to the rest of components.
>
> We've just started to implement Glance API support in jStack, and then I
> will started with Swift. Is anybody out there who wants to join this
> challenge? You're welcome to propose changes, write code, and so on. The
> idea is to develop full OpenStack API in JavaScript, so that community
> could start working with it.
>
> Cheers,
> Javier.
>
> 2012/4/27 javier cervio <jcervino [at] dit>
>
>> Hi!
>>
>> We have just published the code of the portal in Github. You can find it
>> in https://github.com/ging/horizon-js. It will only work with Keystone
>> and Nova if they have CORS implemented.
>>
>> Adrian, we didn't make big changes in your code, only logger classes and
>> a little problem we found with PUT requests in some cases (I have to take a
>> deeper look into this problem, anyway). We've made tests from iPhone,
>> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
>> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
>> week I will test it with Android and Opera browsers.
>>
>> Sure! It will be very interesting to submit your code to gerrit!!
>>
>> Diego, I will talk with Joaquin to check if we can show you a demo in two
>> weeks!!
>>
>> Cheers,
>> Javier.
>>
>> 2012/4/27 Adrian Smith <adrian_f_smith [at] dell>
>>
>>> I'd be really interested to hear how you go on with the CORS middleware Javier.
>>> Did it work as-is or did you have to modify it? Was there much effort
>>> involved in using it with Nova?
>>>
>>> From your experience it sounds like there's decent CORS support in
>>> browsers now so it's probably time to submit this change to gerrit.
>>>
>>> Adrian
>>>
>>>
>>> 2012/4/27 Diego Parrilla Santamara <diego.parrilla.santamaria [at] gmail
>>> >
>>>
>>>> Awesome Javier!!!!
>>>>
>>>> Anxiously waiting for a meeting with you guys to see your progress!
>>>>
>>>> Cheers
>>>> Diego
>>>> --
>>>> Diego Parrilla
>>>> <http://www.stackops.com/>*CEO*
>>>> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29|
>>>> skype:diegoparrilla*
>>>> * <http://www.stackops.com/>
>>>> *
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>>>>
>>>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat>
>>>>> 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
>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>> > More help : https://help.launchpad.net/ListHelp
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack [at] lists
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


nick.lothian at gmail

Apr 30, 2012, 4:56 AM

Post #38 of 39 (397 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

I'm testing out the existing JStack code at the moment.

It's been enjoyable process so far.
On Apr 30, 2012 7:30 PM, "javier cervio" <jcervino [at] dit> wrote:

> Hi Adrian,
>
> I've just seen you submitted your Swift-based CORS implementation to
> Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
> the other hand, it could be better to wait for its approval because we
> could apply changes proposed by the reviewers to the rest of components.
>
> We've just started to implement Glance API support in jStack, and then I
> will started with Swift. Is anybody out there who wants to join this
> challenge? You're welcome to propose changes, write code, and so on. The
> idea is to develop full OpenStack API in JavaScript, so that community
> could start working with it.
>
> Cheers,
> Javier.
>
> 2012/4/27 javier cervio <jcervino [at] dit>
>
>> Hi!
>>
>> We have just published the code of the portal in Github. You can find it
>> in https://github.com/ging/horizon-js. It will only work with Keystone
>> and Nova if they have CORS implemented.
>>
>> Adrian, we didn't make big changes in your code, only logger classes and
>> a little problem we found with PUT requests in some cases (I have to take a
>> deeper look into this problem, anyway). We've made tests from iPhone,
>> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
>> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
>> week I will test it with Android and Opera browsers.
>>
>> Sure! It will be very interesting to submit your code to gerrit!!
>>
>> Diego, I will talk with Joaquin to check if we can show you a demo in two
>> weeks!!
>>
>> Cheers,
>> Javier.
>>
>> 2012/4/27 Adrian Smith <adrian_f_smith [at] dell>
>>
>>> I'd be really interested to hear how you go on with the CORS middleware Javier.
>>> Did it work as-is or did you have to modify it? Was there much effort
>>> involved in using it with Nova?
>>>
>>> From your experience it sounds like there's decent CORS support in
>>> browsers now so it's probably time to submit this change to gerrit.
>>>
>>> Adrian
>>>
>>>
>>> 2012/4/27 Diego Parrilla Santamara <diego.parrilla.santamaria [at] gmail
>>> >
>>>
>>>> Awesome Javier!!!!
>>>>
>>>> Anxiously waiting for a meeting with you guys to see your progress!
>>>>
>>>> Cheers
>>>> Diego
>>>> --
>>>> Diego Parrilla
>>>> <http://www.stackops.com/>*CEO*
>>>> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29|
>>>> skype:diegoparrilla*
>>>> * <http://www.stackops.com/>
>>>> *
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>>>>
>>>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat>
>>>>> 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
>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>> > More help : https://help.launchpad.net/ListHelp
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack [at] lists
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


jcervino at dit

May 18, 2012, 10:42 AM

Post #39 of 39 (346 views)
Permalink
Re: Using Nova APIs from Javascript: possible? [In reply to]

Due to problems people are facing with CORS we've already included further
description and a video of how the JavaScript portal can be used. We'll
work with the fantastic people from StackOps on the implementation of a
basic HTTP proxy which could be used until we find a solution to implement
CORS in OpenStack components.

In the meantime you can see video, description and code in here:
http://ging.github.com/horizon-js/

On 30 April 2012 13:56, Nick Lothian <nick.lothian [at] gmail> wrote:

> I'm testing out the existing JStack code at the moment.
>
> It's been enjoyable process so far.
> On Apr 30, 2012 7:30 PM, "javier cervio" <jcervino [at] dit> wrote:
>
>> Hi Adrian,
>>
>> I've just seen you submitted your Swift-based CORS implementation to
>> Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
>> the other hand, it could be better to wait for its approval because we
>> could apply changes proposed by the reviewers to the rest of components.
>>
>> We've just started to implement Glance API support in jStack, and then I
>> will started with Swift. Is anybody out there who wants to join this
>> challenge? You're welcome to propose changes, write code, and so on. The
>> idea is to develop full OpenStack API in JavaScript, so that community
>> could start working with it.
>>
>> Cheers,
>> Javier.
>>
>> 2012/4/27 javier cervio <jcervino [at] dit>
>>
>>> Hi!
>>>
>>> We have just published the code of the portal in Github. You can find it
>>> in https://github.com/ging/horizon-js. It will only work with Keystone
>>> and Nova if they have CORS implemented.
>>>
>>> Adrian, we didn't make big changes in your code, only logger classes and
>>> a little problem we found with PUT requests in some cases (I have to take a
>>> deeper look into this problem, anyway). We've made tests from iPhone,
>>> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
>>> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
>>> week I will test it with Android and Opera browsers.
>>>
>>> Sure! It will be very interesting to submit your code to gerrit!!
>>>
>>> Diego, I will talk with Joaquin to check if we can show you a demo in
>>> two weeks!!
>>>
>>> Cheers,
>>> Javier.
>>>
>>> 2012/4/27 Adrian Smith <adrian_f_smith [at] dell>
>>>
>>>> I'd be really interested to hear how you go on with the CORS middleware Javier.
>>>> Did it work as-is or did you have to modify it? Was there much effort
>>>> involved in using it with Nova?
>>>>
>>>> From your experience it sounds like there's decent CORS support in
>>>> browsers now so it's probably time to submit this change to gerrit.
>>>>
>>>> Adrian
>>>>
>>>>
>>>> 2012/4/27 Diego Parrilla Santamara <
>>>> diego.parrilla.santamaria [at] gmail>
>>>>
>>>>> Awesome Javier!!!!
>>>>>
>>>>> Anxiously waiting for a meeting with you guys to see your progress!
>>>>>
>>>>> Cheers
>>>>> Diego
>>>>> --
>>>>> Diego Parrilla
>>>>> <http://www.stackops.com/>*CEO*
>>>>> *www.stackops.com | * diego.parrilla [at] stackops** | +34 649 94 43 29|
>>>>> skype:diegoparrilla*
>>>>> * <http://www.stackops.com/>
>>>>> *
>>>>>
>>>>> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cervio <jcervino [at] dit>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 Cervio.
>>>>>>
>>>>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian [at] gmail> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung [at] redhat>
>>>>>> 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
>>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>>> > More help : https://help.launchpad.net/ListHelp
>>>>>> >
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack [at] lists
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack [at] lists
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

First page Previous page 1 2 Next page Last page  View All OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.