++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense.

- Steve

David Chadwick <d.w.chadw...@kent.ac.uk> wrote on 09/17/2014 09:37:21 AM:

> From: David Chadwick <d.w.chadw...@kent.ac.uk>

> To: openstack-dev@lists.openstack.org, Kristy Siu <k.w.s....@kent.ac.uk>,
> Date: 09/17/2014 09:42 AM
> 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@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
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to