On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews <dolph.math...@gmail.com> wrote:
> > 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"). > The benefit of the first example is that I can easily setup DNS to redirect cloud.customer-x.com to customer-x.cloud.example.com, where example.com is my public cloud provider. The benefit of the second example is that it's completely trivial for the public cloud provider to implement. > > >> >>> 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