Open Stack

Hi Jamie

see

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf

regards
David

On 13/08/2015 02:06, Jamie Lennox wrote:
> 
> 
> ----- Original Message -----
>> From: "David Chadwick" <d.w.chadwick at kent.ac.uk> To:
>> openstack-dev at lists.openstack.org Sent: Thursday, 13 August, 2015
>> 3:06:46 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> 
>> 
>> On 11/08/2015 01:46, Jamie Lennox wrote:
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Jamie Lennox" <jamielennox at redhat.com> To: "OpenStack 
>>>> Development Mailing List (not for usage questions)" 
>>>> <openstack-dev at lists.openstack.org> Sent: Tuesday, 11 August,
>>>> 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone]
>>>> [Horizon] Federated Login
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "David Chadwick" <d.w.chadwick at kent.ac.uk> To: 
>>>>> openstack-dev at lists.openstack.org Sent: Tuesday, 11 August,
>>>>> 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone]
>>>>> [Horizon] Federated Login
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/08/2015 01:53, Jamie Lennox wrote:
>>>>>> 
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "David Chadwick" <d.w.chadwick at kent.ac.uk> To: 
>>>>>>> openstack-dev at lists.openstack.org Sent: Sunday, August
>>>>>>> 9, 2015 12:29:49 AM Subject: Re: [openstack-dev]
>>>>>>> [Keystone] [Horizon] Federated Login
>>>>>>> 
>>>>>>> Hi Jamie
>>>>>>> 
>>>>>>> nice presentation, thanks for sharing it. I have
>>>>>>> forwarded it to my students working on federation aspects
>>>>>>> of Horizon.
>>>>>>> 
>>>>>>> About public federated cloud access, the way you envisage
>>>>>>> it, i.e. that every user will have his own tailored
>>>>>>> (subdomain) URL to the SP is not how it works in the real
>>>>>>> world today. SPs typically provide one URL, which
>>>>>>> everyone from every IdP uses, so that no matter which
>>>>>>> browser you are using, from wherever you are in the
>>>>>>> world, you can access the SP (via your IdP). The only
>>>>>>> thing the user needs to know, is the name of his IdP, in
>>>>>>> order to correctly choose it.
>>>>>>> 
>>>>>>> So discovery of all available IdPs is needed. You are
>>>>>>> correct in saying that Shib supports a separate discovery
>>>>>>> service (WAYF), but Horizon can also play this role, by
>>>>>>> listing the IdPs for the user. This is the mod that my
>>>>>>> student is making to Horizon, by adding type ahead
>>>>>>> searching.
>>>>>> 
>>>>>> So my point at the moment is that unless there's something
>>>>>> i'm missing in the way shib/mellon discovery works is that
>>>>>> horizon can't. Because we forward to a common websso entry
>>>>>> point there is no way (i know) for the users selection in
>>>>>> horizon to be forwarded to keystone. You would still need a
>>>>>> custom "select your idp" discovery page in front of
>>>>>> keystone. I'm not sure if this addition is part of your
>>>>>> students work, it just hasn't been mentioned yet.
>>>>>> 
>>>>>>> About your proposed discovery mod, surely this seems to
>>>>>>> be going in the wrong direction. A common entry point to 
>>>>>>> Keystone for all IdPs, as we have now with WebSSO, seems
>>>>>>> to be preferable to separate entry points per IdP. Which
>>>>>>> high street shop has separate doors for each user? Or
>>>>>>> have I misunderstood the purpose of your mod?
>>>>>> 
>>>>>> The purpose of the mod is purely to bypass the need to have
>>>>>> a shib/mellon discovery page on
>>>>>> /v3/OS-FEDERATION/websso/saml2. This page is currently
>>>>>> required to allow a user to select their idp (presumably
>>>>>> from the ones supported by keystone) and redirect to that
>>>>>> IDPs specific login page.
>>>>> 
>>>>> There are two functionalities that are required: a) Horizon 
>>>>> finding the redirection login URL of the IdP chosen by the
>>>>> user b) Keystone finding which IdP was used for login.
>>>>> 
>>>>> The second is already done by Apache telling Keystone in the 
>>>>> header field.
>>>>> 
>>>>> The first is part of the metadata of the IdP, and Keystone
>>>>> should make this available to Horizon via an API call.
>>>>> Ideally when Horizon calls Keystone for the list of trusted
>>>>> IdPs, then the user friendly name of the IdP (to be displayed
>>>>> to the user) and the login page URL should be returned. Then
>>>>> Horizon can present the user friendly list to the user, get
>>>>> the login URL that matches this, then redirect the user to
>>>>> the IdP telling the IdP the common callback URL of Keystone.
>>>> 
>>>> So my understanding was that this wasn't possible. Because we
>>>> want to have keystone be the registered service provider and
>>>> receive the returned SAML assertions the login redirect must be
>>>> issued from keystone and not horizon. Is it possible to issue a
>>>> login request from horizon that returns the response to
>>>> keystone? This seems dodgy to me but may be possible if all the
>>>> trust relationships are set up.
>>> 
>>> Note also that currently this metadata including the login URL is
>>> not known by keystone. It's controlled by apache in the metadata
>>> xml files so we would have to add this information to keystone.
>>> Obviously this is doable just extra config setup that would
>>> require double handling of this URL.
>> 
>> My idea is to use Horizon as the WAYF/Discovery service,
>> approximately as follows
>> 
>> 1. The user goes to Horizon to login locally or to discover which 
>> federated IdP to use 2. Horizon dynamically populates the list of
>> IDPs by querying Keystone 3. The user chooses the IdP and Horizon
>> redirects the user to Apache/Keystone, telling it the IdP to use 4.
>> Apache creates the SAML assertion and sends it to the IDP.
>> 
>> In order to use the standard SAML Discovery Protocol, then after
>> step 1, Horizon would go to the Apache/Keystone entry point, and
>> receive a Discovery Request. The message in step 3 would be the
>> standard Discovery Response message.
>> 
>> What do you think about this?
>> 
>> David
> 
> Interesting, I'd need to look further into how that discovery request
> works. In mellon you can establish a seperate URL [1] and same with
> shib [2], i had always considered that they would be hosted on the
> same machine but i guess there's no reason that has to be the case.
> 
> The way that would have to work then is to have horizon redirect to
> keystone, keystone throw back to horizon for the discovery service,
> horizon shows list of idps (from keystone) and returns whatever the
> correctly formatted response is to keystone's discovery. At the very
> least then this would require adding a new page to horizon that is
> capable of responding with the correct SAML discovery response?
> 
> I can see it working and i like to use the standards if they exist
> but i'm not sure it's a simpler solution.
> 
> 
> [1]
> https://github.com/UNINETT/mod_auth_mellon/blob/master/README#L444 
> [2] http://wiki.aaf.edu.au/tech-info/sp-install-guide
> 
>> 
>>> 
>>>> In a way this is exactly what my proposal was. A way for
>>>> horizon to determine a unique websso login page for each idp,
>>>> just my understanding is that this request must be bounced
>>>> through keystone.
>>>> 
>>>>>> When the response comes back from that login it returns to
>>>>>> that websso page and we look at remote_ids to determine
>>>>>> which keystone idp is handling the response from that
>>>>>> site.
>>>>> 
>>>>> This seems the more secure way of determining the IdP to me, 
>>>>> since Apache determines the IdP then tells Keystone via the 
>>>>> header field. If you rely on the IdP to contact the "right" 
>>>>> endpoint, then doesn't this allow the IdP to return to a 
>>>>> different URL and thereby trick Keystone into thinking it was
>>>>> a different IdP?
>>>> 
>>>> To me the difference is that if we all return to a common 
>>>> /OS-FEDERATION/websso/saml2 endpoint then apache has to let
>>>> all SAML responses through for all registered idps and then
>>>> keystone must determine which is the real idp. By returning to
>>>> an IDP specific websso route apache can assert that this
>>>> response may only have come from the provider configured for
>>>> that idp. This is really a secondary concern. I don't see there
>>>> being much security difference, just that in this way you
>>>> offload some additional responsibility for validating a SAML
>>>> assertion to apache and we remove some (not all) the need for
>>>> remote_ids.
>>>> 
>>>>> regards
>>>>> 
>>>>> David
>>>>> 
>>>> 
>>>> __________________________________________________________________________
>>>>
>>>>
>>
>>>> 
OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: 
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>> 
__________________________________________________________________________
>>> 
>>> 
>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>> 
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions) 
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>