Has Kristy's patch made it into Juno ?
Tim > -----Original Message----- > From: David Chadwick [mailto:[email protected]] > Sent: 17 September 2014 15:37 > To: [email protected]; Kristy Siu > Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
