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