Open Stack

Hi all,

The code for my proof of concept software is at https://github.com/kwss/horizon/tree/federated (templates)

And

https://github.com/kwss/django_openstack_auth/tree/federated (federation handling). 

Please note that the horizon branch also contains some additional panels for managing IdPs and mappings. 

Regards,
Kristy

> On 17 Sep 2014, at 16:34, "David Chadwick" <d.w.chadwick at kent.ac.uk> wrote:
> 
> 
> 
>> On 17/09/2014 15:38, Adam Young wrote:
>>> 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.
> 
> That is correct
> 
>> 
>> How do you propose going from Horizon to Keystone using  SAML creds?
> 
> The flow is something like this
> 
> Browser          Horizon         Keystone/Apache       IDP
> -get login->
>                  --retrieve IDPs-->
>                  <-list of IdPs  --
> <-display login page-
> -Choose fed login->
> <-redirect to Keystone-
> |
> -----------------fed login request ->
>                      remember address of Horizon
> <--- SAML Authn request  (redirect)---
> |
> ------------------------------------------------>
> 
> <---------------User logs in -------------------->
> <--------SAML Authn Response (redirect)----------
> |
> ---------------------------------->
> <-----redirect back to Horizon---------
> |      using remembered address
> ------------------>
> 
> The modification that Kristy had to make to Keystone was the last
> redirection request to Horizon had to be remembered when the initial
> request was received
> 
> We would like to make our proof of concept code available to the Horizon
> experts for them to re-engineer/toughen to industry standards so that it
> can be released asap to the public.
> 
> We have documentation that describes our release which you can download
> from here
> 
> https://classe.sec.cs.kent.ac.uk/juno-server.pdf
> 
> Note that a newer version will be uploaded very shortly as the above
> version contains partial VO documentation which will be stripped out
> until we can complete it later this month or next.
> 
> regards
> 
> David
> 
> 
>> 
>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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