openstack team mailing list archive

[Nick Lothian <nick.lothian@xxxxxxxxx>]

On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung@xxxxxxxxxx> wrote:

> 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.
>
>
This is inaccurate. JSONP is supported by all browsers since ~Netscape 4.0.

CORS is supported by all modern browsers: IE > 8, Firefox > 3.5, Chrome >
3, Safari > 4 (See
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Browser_support).
Additionally, CORS support is not a browser decision - the server has to
EXPLICITLY opt-in to support it.

Obviously CORS support *can* be a security issue - that is why it is
disabled unless the server enables it.

I do not believe that CORS support adds any additional security issues
above what the OpenStack APIs already face. Specially, the most common
problem (CSRF) is not an issue here because the APIs are not authorised on
a session basis.

 [snip]

>
> 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<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.
>
>
>
To be clear, identity/authorisation is NOT the problem here. The OpenStack
APIs work well for my use cases, once I work around the cross domain POST
problem.

However, I've also worked with SSO solutions. The simple truth is that
client side certificates do not play well with the web - browser support
ranges from non-existent (on some mobile platforms - see
http://mobilitydojo.net/2010/12/28/client-certificate-support-across-mobile-platforms-a-summary/)
to
abysmal (there is a reason why many websites that use certificates end up
using a Java applet), and their interaction with cross domain Javascript is
unknown.

Even if certificates did work for identification, CORS would still be
needed - many OpenStack APIs require a POST request which is impossible
without it.


Nick