openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

Let me try to summarize:

1.  If you are running from a web browser,  post requests to hosts or 
ports other than the origin are allowed,  but the headers cannot be 
modified.  This prevents the addition of the token from Keystone to 
provide single sign on.

2.  There are various browser side technologies (JSONP, CORS) that get 
around this limitation, but they are typically not enabled,  and can be 
considered security issues.  While implementing these might require 
support from teh Openstack server,  they are fundamentally browser 
decisions.

3.  If you are doing this from a command line or non-webbrowser UI,  you 
are not limited by the same origin policy.

4.  You can always proxy through the the origin to the remote services,  
but this may prove to be a scalability limitation.

I've been working on Single Sign on Issues for another project for the 
past year and a half.  Here's a couple things I've learned.

Kerberos is designed to solve this problem.  It has the benefit of being 
integrated into the browser.  Where Kerberos fails is that:  typically 
it only allows a single authentication provider (KDC in Kerberso speak) 
and it does not work well with Firewalls.

The only crytographically secure way to authenticate on the web that can 
get around the firewall issue is Client side X509 certificates.  This is 
the foundation for https://blueprints.launchpad.net/keystone/+spec/pki.  
This could, in theory, work in with OAuth, OpenID,  or some other 
distributed authorization service,  or we could embed the authorization 
information right into the Certitificate, which is what I suggest we do.