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.hur...@nebula.com <mailto:gabriel.hur...@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:ayo...@redhat.com
    <mailto:ayo...@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@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to