[openstack-dev] [Keystone] [Horizon] Federated Login
Jamie Lennox
jamielennox at redhat.com
Fri Aug 7 00:29:59 UTC 2015
----- Original Message -----
> From: "Dolph Mathews" <dolph.mathews at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Sent: Friday, August 7, 2015 9:09:25 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad < lbragstad at gmail.com >
> wrote:
> > On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews < dolph.mathews at gmail.com >
> > wrote:
>
> > > On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox < jamielennox at redhat.com >
> > > 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. 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").
I always envisioned the subdomain method. I would say no to listing IdPs, but it's not simply making the list private because you will still need to provide at least one IdP option manually in that horizon's local_settings and at which point you should just turn off listing because you know it's always going to get a 403. I'm not sure how this would be managed today because we have a single WebSSO entry point so you can't really specify the IdP you want from the login page, it's expected to have your own discovery page - hence the spec https://review.openstack.org/#/c/199339/
> > > 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.
> >
>
I don't think so. I think privately you would list everything.
I feel at this point I'm missing something obvious, so let me explain my understanding of the current flow.
* From horizon you select federated provider, the key of this is a protocol name, eg saml.
* On login you get redirected to: https://keystone.example.com:5000/v3/OS-FEDERATION/websso/saml (where saml is the protocol from above)
* On this page if you are cern/kent and have hundreds of IdPs you show a discovery page to pick the one you want, and get redirected to the actual login page.
* On returning to keystone from login you have the remote_url of the page you logged in with. Keystone consults the remote_id parameter of each idp and FROM THAT URL DETERMINES WHICH KEYSTONE IDP WE USE.
* Keystone uses that idp, the protocol mentioned earlier, determines the mapping, and maps variables.
* Keystone then redirects a new token back to horizon.
For an example of this see the talk i did last weekend: https://youtu.be/YYzJdxI_g6g
So as you might have seen from the CAPS there is currently no mechanism for django_openstack_auth to indicate to keystone which IdP the user selected from a drop down list, only a protocol. I find this absurd and so wrote a spec: https://review.openstack.org/#/c/199339/
I agree otherwise on the basics of this thread. I'm just haven't seen a plan yet on how anyone expects to implement this horizon based selection with the current implementation.
> > > > @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 > 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
> >
>
> > __________________________________________________________________________
>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150806/236bceaa/attachment.html>
More information about the OpenStack-dev
mailing list