Open Stack

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.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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev