[openstack-dev] [Keystone] [Horizon] Federated Login
Adam Young
ayoung at redhat.com
Fri Aug 7 13:00:57 UTC 2015
On 08/06/2015 07:09 PM, Dolph Mathews wrote:
>
> On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad <lbragstad at gmail.com
> <mailto:lbragstad at gmail.com>> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
> <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>> wrote:
>
>
> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
> <jamielennox at redhat.com <mailto:jamielennox at redhat.com>> wrote:
>
>
>
> ----- Original Message -----
> > From: "David Lyle" <dklyle0 at gmail.com
> <mailto:dklyle0 at gmail.com>>
> > To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org
> <mailto: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 <mailto:dolph.mathews at gmail.com> >
> > wrote:
> >
> >
> >
> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
> stevemar at ca.ibm.com <mailto: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 <http://COKE.COM>
> domain and i can see for example that PEPSI.COM
> <http://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 <http://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 <http://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").
Are we going about this backwards? Wouldn't it make more sense to tell
a new customer:
you get https://coke.cloudprovider.net
And have that hard coded to a UI.
For larger organizations, I suspect it would make more sense that the UI
should be owned by Coke, and run on a server managed by Coke, and talk
to multiple OpenStack instances.
The UI should not be Provider specific, but consumer specific.
>
> 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.chadwick at kent.ac.uk
> <mailto:d.w.chadwick at kent.ac.uk> > wrote:
> >
> > From: Dolph Mathews < dolph.mathews at gmail.com
> <mailto:dolph.mathews at gmail.com> >
> > To: "OpenStack Development Mailing List (not for usage
> questions)" <
> > openstack-dev at lists.openstack.org
> <mailto: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 <mailto: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 <mailto:drfish at us.ibm.com> > wrote:
> > Hi David, > > From: Lance Bragstad <
> > lbragstad at gmail.com <mailto:lbragstad at gmail.com> > > To:
> "OpenStack Development Mailing List (not for
> > usage questions)" > < openstack-dev at lists.openstack.org
> <mailto: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
> <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 <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 <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
> <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://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://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://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://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://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://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://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150807/a96c1b2e/attachment.html>
More information about the OpenStack-dev
mailing list