On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad <lbrags...@gmail.com> wrote:
> > > On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > >> >> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox <jamielen...@redhat.com> >> 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. 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. >>> >>> 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. >>> >> >> That all makes sense, and I was admittedly only thinking of the private >> cloud use case. So, I'd like to discuss the public and private use cases >> separately: >> >> In a public cloud, is there a real use case for revealing *any* IdPs >> publicly? If not, the entire list should be made "private" using >> policy.json, which we already support today. >> > > The user would be required to know the id of the IdP in which they want to > federate with, right? > > As a federated end user in a public cloud, I'd be happy to have a custom URL / bookmark for my IdP / domain (like http://customer-x.cloud.example.com/ or http://cloud.example.com/customer-x) that I need to know to kickoff the correct federated handshake with my IdP using a single button press ("Login"). > >> In a private cloud, is there a real use case for fine-grained >> public/private attributes per IdP? (The stated use case was for a public >> cloud.) It seems the default behavior should be that horizon fetches the >> entire list from keystone. >> >> >>> >>> @David - when you add a new IdP to the university network are you having >>> to provide a new mapping each time? 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. >>> >>> 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. >>> >>> >>> 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 >> >> > > __________________________________________________________________________ > 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