On 09/16/2014 06:59 PM, Gabriel Hurley 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.
Do we really care about Browser support? I mean, are we really going to
have to support non-Javascript capable browsers for Horizon? Are there
any Browsers with sufficient quality of Javascript support that don't
also have CORS support?
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 was thinking we would have two common approaches:
1. User the service catalog. It implies adding Horizon to the Service
catalog, but then we know each endpoint, and we can limit CORS to other
official endpoints. This is my preferred approach.
2. Have a DNS Zone for the openstack deployment. So, the
Access-Control-Allow-Origin: *.openstack.example.com
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.
Yes. I think this is an obvious cross-project track session for the
Summit.
Securing a browser-centric world is a tricky realm... let's make sure we get it
right. :-)
Agreed. I think this is one topic that will benefit from serious
upfront effort.
- 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
