<div dir="ltr">You're quite probably correct - going through the OWASP threat list in more detail is on my TODO. That was just off the top of my head as something that has me concerned but I've not investigated it thoroughly.</div><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2014 14:15, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 09/16/2014 08:56 PM, Richard Jones
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.</div>
</blockquote>
<br></span>
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?<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div> Richard</div>
<div><br>
</div>
<div>* <a href="https://review.openstack.org/#/c/120964/" style="font-size:13px;font-family:arial,sans-serif" target="_blank">https://review.openstack.org/#/c/120964/</a></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 17 September 2014 08:59, Gabriel
Hurley <span dir="ltr"><<a href="mailto:Gabriel.Hurley@nebula.com" target="_blank">Gabriel.Hurley@nebula.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Securing a browser-centric world is a tricky realm... let's
make sure we get it right. :-)<br>
<span><font color="#888888"><br>
- Gabriel<br>
</font></span>
<div>
<div><br>
> -----Original Message-----<br>
> From: Adam Young [mailto:<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>]<br>
> Sent: Tuesday, September 16, 2014 3:40 PM<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] [Keystone][Horizon] CORS
and Federation<br>
><br>
> Phase one for dealing with Federation can be done
with CORS support solely<br>
> for Keystone/Horizon integration:<br>
><br>
> 1. Horizon Login page creates Javascript to do
AJAX call to Keystone 2.<br>
> Keystone generates a token 3. Javascript reads
token out of response and<br>
> sends it to Horizon.<br>
><br>
> This should support Kerberos, X509, and Password
auth; the Keystone team<br>
> is discussing how to advertise mechanisms, lets
leave the onus on us to solve<br>
> that one and get back in a timely manner.<br>
><br>
> For Federation, the handshake is a little more
complex, and there might be a<br>
> need for some sort of popup window for the user to
log in to their home<br>
> SAML provider. Its several more AJAX calls, but
the end effect should be the<br>
> same: get a standard Keystone token and hand it to
Horizon.<br>
><br>
> This would mean that Horizon would have to validate
tokens the same way<br>
> as any other endpoint. That should not be too
hard, but there is a little bit of<br>
> "create a user, get a token, make a call" logic
that currently lives only in<br>
> keystonemiddleware/auth_token; Its a solvable
problem.<br>
><br>
> This approach will support the straight Javascript
approach that Richard Jones<br>
> discussed; Keystone behind a proxy will work this
way without CORS<br>
> support. If CORS can be sorted out for the other
services, we can do straight<br>
> Javascript without the Proxy. I see it as phased
approach with this being the<br>
> first phase.<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>