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]
> 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
> 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