Open Stack

Hi Adam

Kristy has already added support to Horizon for federated login to
Keystone. She will send you details of how she did this.

One issue that arose was this:
in order to give the user the list of IDPs/protocols that are trusted,
the call to Keystone needs to be authenticated. But the user is not yet
authenticated. So Horizon has to have its own credentials for logging
into Keystone so that it can retrieve the list of IdPs for the user.
This works, but it is not ideal.

The situation is far worse for the Keystone command line client. The
user is not logged in and the Keystone client does not have its own
account on Keystone, so it cannot retrieve the list of IdPs for the
user. The only way that Kristy could solve this, was to remove the
requirement for authentication to the API that retrieves the list of
IdPs. But this is not a standard solution as it requires modifying the
core Keystone code.

We need a fix to address this issue. My suggestion would be to make the
API for retrieving the list of trusted IDPs publicly accessible, so that
no credentials are needed for this.

regards

David


On 16/09/2014 23:39, Adam Young wrote:
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>