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