Open Stack

Hi Tim

I don't believe she has pushed this through the official channel yet as
we were very pushed for time to get something working for our GIANT
CLASSe project. We only did the work in the latter half of August.  I
also don't know if we are too late for Juno or not.

regards

David

On 17/09/2014 15:14, Tim Bell wrote:
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>