On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews <[email protected]> wrote:
> > On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox <[email protected]> > wrote: > >> >> >> ----- Original Message ----- >> > From: "David Lyle" <[email protected]> >> > To: "OpenStack Development Mailing List (not for usage questions)" < >> [email protected]> >> > 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 < [email protected] >> > >> > wrote: >> > >> > >> > >> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < [email protected] >> > >> > 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? > > 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 < [email protected] > wrote: >> > >> > From: Dolph Mathews < [email protected] > >> > To: "OpenStack Development Mailing List (not for usage questions)" < >> > [email protected] > >> > 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 < >> [email protected] > >> > 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 <[email protected] Bragstad > >> > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas > >> Fish >> > < [email protected] > wrote: > Hi David, > > From: Lance Bragstad < >> > [email protected] > > To: "OpenStack Development Mailing List (not >> for >> > usage questions)" > < [email protected] > > 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 >> > <[email protected]_ > <mailto: [email protected] >> 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 <[email protected]_ > >> <mailto: >> > [email protected] >> wrote on 08/01/2015 06:01:48 AM: > > > From: >> > David Chadwick <[email protected]_ > <mailto: >> [email protected] >> > >> > > To: OpenStack Development Mailing List > >> > <[email protected]_ > <mailto: >> > [email protected] >> > > 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:_ > __ >> > [email protected]?subject:unsubscribe_ > < >> > http://[email protected]?subject:unsubscribe > >> > > _ >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ > > >> > > > >> > >> __________________________________________________________________________ > >> > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: >> > > _ [email protected]?subject:unsubscribe_ > < >> > http://[email protected]?subject:unsubscribe >> >_ > __ >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_ > > >> > >> __________________________________________________________________________ > >> > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: >> > [email protected]?subject:unsubscribe > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >> > > > >> > >> __________________________________________________________________________ > >> > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: >> > [email protected]?subject:unsubscribe > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> > [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
