Open Stack

On 06/08/2015 00:54, Jamie Lennox 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. 

This is the whole purpose of the mod we are currently making to Horizon.
If you look at our screenshots on InVision, you will see the user has
the choice to either list all (potentially hundreds of) IdPs, or start
to type in the name of his organisation. With type ahead, we then filter
the IdPs to match the characters the user enters. This is also shown in
our screenshots. So using your coke/pepsi example above, the Coke user
would type C and the list of IdPs would be immediately culled to only
contain those with C in their name (and pepsi would be removed from the
list). When he enters O then the list is further culled to only IdPs
containing co in their name. Consequently with only minor effort from
the user (both mental load and physical load) the user's IdP is very
quickly revealed to him, allowing him to login. See

https://openstack.invisionapp.com/d/#/console/4277424/92772663/preview


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.

Actually gmail (at least for me) works in a different way. It takes your
email address and ASSUMES that your idp is the same as your domain name.
So no list of IdPs is presented. Instead the IdP name is computed
automatically from your email address. This approach wont work for everyone.


> 
> 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.
> 
> @David - when you add a new IdP to the university network are you

the list of IdPs is centrally (i.e. nationally) managed, and every UK
university/federation member is sent a new list periodically. So we do
not add new IdPs, we simply use the list that is provided to us.


> having to provide a new mapping each time?

Since all federation members use the EduPerson schema, then one set of
mapping rules are applicable to all IdPs. They dont need to be updated.

So to conclude
a) we dont need to do anything when the federation membership changes
(except use the new list)
b) we dont need to change mapping rules
c) we dont need to tailor user interfaces

We would like to move OpenStack in this direction, where there is
minimal effort to managing federation membership. We believe our
proposed change to Horizon is one step in the right direction.


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

Not a good solution from a trust perspective since you dont know who the
actual IdP is. You are told it is always the proxy IdP.

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

It cant be outside the scope of Keystone, since the list of trusted IdPs
should be in Keystone

regards

David

> 
> 
> 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
>