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.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
