Open Stack

Has Kristy's patch made it into Juno ? 


Tim

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: 17 September 2014 15:37
> To: openstack-dev at lists.openstack.org; 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
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev