Open Stack

On 09/16/2014 08:56 PM, Richard Jones wrote:
> CORS for all of OpenStack is possible once the oslo middleware lands*, 
> but as you note it's only one of many elements to be considered when 
> exposing the APIs to browsers. There is no current support for CSRF 
> protection in the OpenStack APIs, for example. I believe that sort of 
> functionality belongs in an intermediary between the APIs and the browser.

Typically, CSRF is done by writing a customer header.  Why wouldn't the 
-X-Auth-Token header qualify?  Its not a cookie, automatically added.  
So, CORS support would be necesary for horizon to send the token on a 
request to Nova, but no other site would be able to do that.  No?

>
>
>     Richard
>
> * https://review.openstack.org/#/c/120964/
>
> On 17 September 2014 08:59, Gabriel Hurley <Gabriel.Hurley at nebula.com 
> <mailto:Gabriel.Hurley at nebula.com>> wrote:
>
>     This is generally the right plan. The hard parts are in getting
>     people to deploy it correctly and securely, and handling fallback
>     cases for lack of browser support, etc.
>
>     What we really don't want to do is to encourage people to set
>     "Access-Control-Allow-Origin: *" type headers or other such
>     nonsense simply because it's too much work to do things correctly.
>     This becomes especially challenging for federated clouds.
>
>     I would encourage looking at the problem of adding all the
>     necessary headers for CORS as an OpenStack-wide issue. Once you
>     figure it out for Keystone, the next logical step is to want to
>     make calls from the browser directly to all the other service
>     endpoints, and each service is going to have to respond with the
>     correct CORS headers ("Access-Control-Allow-Methods" and
>     "Access-Control-Allow-Headers" are particularly fun ones for
>     projects like Glance or Swift). A common middleware and means of
>     configuring it will go a long way to easing user pain and spurring
>     adoption of the new mechanisms. It will help the Horizon team
>     substantially in the long run to do it consistently and
>     predictably across the stack.
>
>     As a side-note, once we're in the realm of handling all this
>     sensitive data with the browser as a middleman, encouraging people
>     to configure things like CSP is probably also a good idea to make
>     sure we're not loading malicious scripts or other resources.
>
>     Securing a browser-centric world is a tricky realm... let's make
>     sure we get it right. :-)
>
>          - Gabriel
>
>     > -----Original Message-----
>     > From: Adam Young [mailto:ayoung at redhat.com
>     <mailto:ayoung at redhat.com>]
>     > Sent: Tuesday, September 16, 2014 3:40 PM
>     > To: OpenStack Development Mailing List
>     > Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation
>     >
>     > Phase one for dealing with Federation can be done with CORS
>     support solely
>     > for Keystone/Horizon  integration:
>     >
>     > 1.  Horizon Login page creates Javascript to do AJAX call to
>     Keystone 2.
>     > Keystone generates a token 3.  Javascript reads token out of
>     response and
>     > sends it to Horizon.
>     >
>     > This should support Kerberos, X509, and Password auth;  the
>     Keystone team
>     > is discussing how to advertise mechanisms, lets leave the onus
>     on us to solve
>     > that one and get back in a timely manner.
>     >
>     > For Federation, the handshake is a little more complex, and
>     there might be a
>     > need for some sort of popup window for the user to log in to
>     their home
>     > SAML provider.  Its several more AJAX calls, but the end effect
>     should be the
>     > same:  get a standard Keystone token and hand it to Horizon.
>     >
>     > This would mean that Horizon would have to validate tokens the
>     same way
>     > as any other endpoint.  That should not be too hard, but there
>     is a little bit of
>     > "create a user, get a token, make a call" logic that currently
>     lives only in
>     > keystonemiddleware/auth_token;  Its a solvable problem.
>     >
>     > This approach will support the straight Javascript approach that
>     Richard Jones
>     > discussed;  Keystone behind a proxy will work this way without CORS
>     > support.  If CORS  can be sorted out for the other services, we
>     can do straight
>     > Javascript without the Proxy.  I see it as phased approach with
>     this being the
>     > first phase.
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140917/9091570b/attachment.html>