Open Stack

Hi Lance

On 12/08/2015 18:55, Lance Bragstad wrote:
> 
> 
> On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick
> <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
> 
> 
> 
>     On 11/08/2015 01:46, Jamie Lennox wrote:
>     >
>     >
>     > ----- Original Message -----
>     >> From: "Jamie Lennox" <jamielennox at redhat.com
>     <mailto:jamielennox at redhat.com>> To: "OpenStack
>     >> Development Mailing List (not for usage questions)"
>     >> <openstack-dev at lists.openstack.org
>     <mailto: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
>     <mailto:d.w.chadwick at kent.ac.uk>> To:
>     >>> openstack-dev at lists.openstack.org
>     <mailto: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
>     <mailto:d.w.chadwick at kent.ac.uk>> To:
>     >>>>> openstack-dev at lists.openstack.org
>     <mailto: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.
> 
> 
> 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)? 

The user has two choices
a) click on the entire (public) list and then pick his IdP from there
b) start to type characters from his IdP's name and the list is
progressively filtered to only those containing the string typed by the user

As I have just said in a recent posting, I think the Coke/Pepsi use case
is somewhat spurious (see that message for the rationale). All IdPs that
are part of the same federation as the SP and have an agreement with
this SP will have their names in the published list. The SP will require
this if it has a common entry point, otherwise how could some of its
users log in? (Note this might not be all the IdPs in the federation,
since the SP may not have business relationships with some of the IdPs
and therefore will not publish these names - there is no point as their
users are not authorised. And it might not be all the IdPs that have a
relationship with the SP, if the SP has some private relationship with
some IdPs, then they would be missing from the list).

regards

David

>  
> 
> 
>     What do you think about this?
> 
>     David
> 
>     >
>     >> 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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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
>