Open Stack

----- Original Message -----
> From: "David Chadwick" <d.w.chadwick at kent.ac.uk>
> To: openstack-dev at lists.openstack.org
> Sent: Thursday, August 6, 2015 6:25:29 PM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> On 06/08/2015 00:54, Jamie Lennox wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "David Lyle" <dklyle0 at gmail.com> To: "OpenStack Development
> >> Mailing List (not for usage questions)"
> >> <openstack-dev at 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.mathews at gmail.com > wrote:
> >> 
> >> 
> >> 
> >> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
> >> stevemar at 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

So my point here was that in many situations you strictly don't want to allow people to see this entire list. 

> 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

So i completely agree the existing solution isn't a good solution. That's why i wrote that spec and it almost seems like a prerequisite for what you are trying todo. How are you passing the IdP id from django_openstack_auth to keystone websso url? The only WebSSO url exposed by keystone is /v3/OS-FEDERATION/websso/{protocol} so there is still the need for a discovery system (externally managed) to figure out which IdP you selected from horizon.

The situation CERN optimized for - that you would have many, changing, real IdPs that would all be configured with the same protocol and mapping, is exactly what you are trying to do. Because of the way WebSSO works via a single URI (per protocol) you are still going to have to manage remote_ids= per idp that each map back to the same copied keystone idp/protocol combination linking to the same mapping. 

It can be done but 

 - it's harder to create these IdP/protocol objects than simply synchronize the remote_ids list to what the latest list is 
 - it pushes the burden of dealing with selecting an IdP onto horizon where we have to deal with these new constraints in a way that works for everyone. Something you can easily do externally.

Again, not saying i like the way it's done, just that we can handle this requirement currently and we have multiple unanswered questions regarding what horizon should expose.


> 
> 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.chadwick at kent.ac.uk > wrote:
> >> 
> >> From: Dolph Mathews < dolph.mathews at gmail.com > To: "OpenStack
> >> Development Mailing List (not for usage questions)" <
> >> openstack-dev at 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.chadwick at 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 at us.iLance Bragstad > ---2015/08/04 01:49:29 PM---On Tue,
> >> Aug 4, 2015 at 10:52 AM, Douglas > Fish < drfish at us.ibm.com >
> >> wrote: > Hi David, > > From: Lance Bragstad < lbragstad at gmail.com >
> >> > To: "OpenStack Development Mailing List (not for usage
> >> questions)" > < openstack-dev at 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
> >> <_drfish at us.ibm.com_ > <mailto: drfish at 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.chadwick at kent.ac.uk_ > <mailto:
> >> d.w.chadwick at kent.ac.uk >> wrote on 08/01/2015 06:01:48 AM: > > >
> >> From: David Chadwick <_d.w.chadwick at kent.ac.uk_ > <mailto:
> >> d.w.chadwick at kent.ac.uk
> >>>>>> To: OpenStack Development Mailing List >
> >> <_openstack-dev at lists.openstack.org_ > <mailto:
> >> openstack-dev at 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-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 >
> >> > > > > 
> >> __________________________________________________________________________
> >> > 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
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> __________________________________________________________________________
> >>
> >> 
> 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
> >> 
> > 
> > __________________________________________________________________________
> >
> > 
> 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
>