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.chadw...@kent.ac.uk> To: >> openstack-dev@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" <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. >> >> 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-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 > __________________________________________________________________________ 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