Open Stack

On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

>
> 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").
>

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