On 09/17/2014 10:14 AM, Tim Bell wrote:
Has Kristy's patch made it into Juno ?
I don't see any patches from Kristy in either the merged or pending review state for non-keystone projects;

https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n,z

So I'm guessing it is proof-of-concept code that has not been yet submitted.

How do you propose going from Horizon to Keystone using  SAML creds?



Tim

-----Original Message-----
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@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@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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to