On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick <d.w.chadw...@kent.ac.uk> wrote:
> > > On 11/08/2015 01:46, Jamie Lennox wrote: > > > > > > ----- Original Message ----- > >> From: "Jamie Lennox" <jamielen...@redhat.com> To: "OpenStack > >> Development Mailing List (not for usage questions)" > >> <openstack-dev@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.chadw...@kent.ac.uk> To: > >>> openstack-dev@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.chadw...@kent.ac.uk> To: > >>>>> openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev