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@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