Open Stack

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?


>
> 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 > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150806/9f2daedb/attachment.html>