[openstack-dev] [Keystone] [Horizon] Federated Login

Lance Bragstad lbragstad at gmail.com
Wed Aug 12 17:55:04 UTC 2015


On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick <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> 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.
>

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)?


>
> 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://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150812/c9dee05a/attachment.html>


More information about the OpenStack-dev mailing list