On 06/08/2015 00:54, Jamie Lennox wrote: > > > ----- Original Message ----- >> From: "David Lyle" <dkly...@gmail.com> To: "OpenStack Development >> Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> Sent: Thursday, August 6, 2015 >> 5:52:40 AM Subject: Re: [openstack-dev] [Keystone] [Horizon] >> Federated Login >> >> Forcing Horizon to duplicate Keystone settings just makes >> everything much harder to configure and much more fragile. Exposing >> whitelisted, or all, IdPs makes much more sense. >> >> On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews < >> dolph.math...@gmail.com > wrote: >> >> >> >> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < >> steve...@ca.ibm.com > wrote: >> >> >> >> >> >> Some folks said that they'd prefer not to list all associated idps, >> which i can understand. Why? > > So the case i heard and i think is fairly reasonable is providing > corporate logins to a public cloud. Taking the canonical coke/pepsi > example if i'm coke, i get asked to login to this public cloud i then > have to scroll though all the providers to find the COKE.COM domain > and i can see for example that PEPSI.COM is also providing logins to > this cloud. Ignoring the corporate privacy implications this list has > the potential to get long.
This is the whole purpose of the mod we are currently making to Horizon. If you look at our screenshots on InVision, you will see the user has the choice to either list all (potentially hundreds of) IdPs, or start to type in the name of his organisation. With type ahead, we then filter the IdPs to match the characters the user enters. This is also shown in our screenshots. So using your coke/pepsi example above, the Coke user would type C and the list of IdPs would be immediately culled to only contain those with C in their name (and pepsi would be removed from the list). When he enters O then the list is further culled to only IdPs containing co in their name. Consequently with only minor effort from the user (both mental load and physical load) the user's IdP is very quickly revealed to him, allowing him to login. See https://openstack.invisionapp.com/d/#/console/4277424/92772663/preview Think about for example how you can do a > corporate login to gmail, you certainly don't pick from a list of > auth providers for gmail - there would be thousands. Actually gmail (at least for me) works in a different way. It takes your email address and ASSUMES that your idp is the same as your domain name. So no list of IdPs is presented. Instead the IdP name is computed automatically from your email address. This approach wont work for everyone. > > My understanding of the usage then would be that coke would have been > provided a (possibly branded) dedicated horizon that backed onto a > public cloud and that i could then from horizon say that it's only > allowed access to the COKE.COM domain (because the UX for inputting a > domain at login is not great so per customer dashboards i think make > sense) and that for this instance of horizon i want to show the 3 or > 4 login providers that COKE.COM is going to allow. > > Anyway you want to list or whitelist that in keystone is going to > involve some form of IdP tagging system where we have to say which > set of idps we want in this case and i don't think we should. > > @David - when you add a new IdP to the university network are you the list of IdPs is centrally (i.e. nationally) managed, and every UK university/federation member is sent a new list periodically. So we do not add new IdPs, we simply use the list that is provided to us. > having to provide a new mapping each time? Since all federation members use the EduPerson schema, then one set of mapping rules are applicable to all IdPs. They dont need to be updated. So to conclude a) we dont need to do anything when the federation membership changes (except use the new list) b) we dont need to change mapping rules c) we dont need to tailor user interfaces We would like to move OpenStack in this direction, where there is minimal effort to managing federation membership. We believe our proposed change to Horizon is one step in the right direction. > I know the CERN answer to > this with websso was to essentially group many IdPs behind the same > keystone idp because they will all produce the same assertion values > and consume the same mapping. Not a good solution from a trust perspective since you dont know who the actual IdP is. You are told it is always the proxy IdP. > > Maybe the answer here is to provide the option in > django_openstack_auth, a plugin (again) of fetch from keystone, fixed > list in settings or let it point at a custom text file/url that is > maintained by the deployer. Honestly if you're adding and removing > idps this frequently i don't mind making the deployer maintain some > of this information out of scope of keystone. It cant be outside the scope of Keystone, since the list of trusted IdPs should be in Keystone regards David > > > Jamie > >> >> >> >> >> >> Actually, I like jamie's suggestion of just making horizon a bit >> smarter, and expecting the values in the horizon settings >> (idp+protocol) But, it's already in keystone. >> >> >> >> >> >> >> >> Thanks, >> >> Steve Martinelli OpenStack Keystone Core >> >> Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at >> 5:39 AM, David Chadwick < d.w.chadw...@kent.ac.uk > wrote: >> >> From: Dolph Mathews < dolph.math...@gmail.com > To: "OpenStack >> Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org > Date: 2015/08/05 01:38 PM >> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login >> >> >> >> >> >> On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick < >> d.w.chadw...@kent.ac.uk > wrote: >> >> On 04/08/2015 18:59, Steve Martinelli wrote: > Right, but that API >> is/should be protected. If we want to list IdPs > *before* >> authenticating a user, we either need: 1) a new API for listing > >> public IdPs or 2) a new policy that doesn't protect that API. Hi >> Steve yes this was my understanding of the discussion that took >> place many months ago. I had assumed (wrongly) that something had >> been done about it, but I guess from your message that we are no >> further forward on this Actually 2) above might be better reworded >> as - a new policy/engine that allows public access to be a bona >> fide policy rule The existing policy simply seems wrong. Why >> protect the list of IdPs? >> >> >> regards David > > Thanks, > > Steve Martinelli > OpenStack Keystone >> Core > > Inactive hide details for Lance Bragstad ---2015/08/04 >> 01:49:29 PM---On > Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish >> <drfish@us.iLance Bragstad > ---2015/08/04 01:49:29 PM---On Tue, >> Aug 4, 2015 at 10:52 AM, Douglas > Fish < drf...@us.ibm.com > >> wrote: > Hi David, > > From: Lance Bragstad < lbrags...@gmail.com > >> > To: "OpenStack Development Mailing List (not for usage >> questions)" > < openstack-dev@lists.openstack.org > > Date: >> 2015/08/04 01:49 PM > Subject: Re: [openstack-dev] [Keystone] >> [Horizon] Federated Login >>>> ------------------------------------------------------------------------ >>>>>>>> >>>> On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish >> <_drf...@us.ibm.com_ > <mailto: drf...@us.ibm.com >> wrote: > > Hi >> David, > >>> This is a cool looking UI. I've made a minor comment on it in >>> InVision. > I'm curious if this is an implementable idea - does >>> keystone support > >> large > numbers of 3rd party idps? is there an API to retreive the >> list of > idps or > does this require carefully coordinated >> configuration between > Horizon and > Keystone so they both >> recognize the same list of idps? > > > There is an API call for >> getting a list of Identity Providers from Keystone >>>> _ >> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_ >>>>>> >> Doug Fish > > > David Chadwick <_d.w.chadw...@kent.ac.uk_ > <mailto: >> d.w.chadw...@kent.ac.uk >> wrote on 08/01/2015 06:01:48 AM: > > > >> From: David Chadwick <_d.w.chadw...@kent.ac.uk_ > <mailto: >> d.w.chadw...@kent.ac.uk >>>>>> To: OpenStack Development Mailing List > >> <_openstack-dev@lists.openstack.org_ > <mailto: >> openstack-dev@lists.openstack.org >> > > Date: 08/01/2015 06:05 AM >> > > Subject: [openstack-dev] [Keystone] [Horizon] Federated Login > >> > > > Hi Everyone > > > > I have a student building a GUI for >> federated login with Horizon. The > > interface supports both a >> drop down list of configured IDPs, and also > > Type Ahead for >> massive federations with hundreds of IdPs. Screenshots > > are >> visible in InVision here > > > > _ https://invis.io/HQ3QN2123_ > > >> > > All comments on the design are appreciated. You can make them >> directly > > to the screens via InVision > > >>>> Regards > > > > David > > > > > > > > > >> __________________________________________________________________________ >> > >>> OpenStack Development Mailing List (not for usage questions) > > >> Unsubscribe:_ > __ >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe_ > < >> http://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://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 >> >> >> >> >> >> >> __________________________________________________________________________ >> >> 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