Open Stack

On 13/08/2015 02:22, Jamie Lennox wrote:
> 
> 
> ----- Original Message -----
>> From: "David Chadwick" <d.w.chadwick at kent.ac.uk> To:
>> openstack-dev at lists.openstack.org Sent: Thursday, 13 August, 2015
>> 7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> Hi Jamie
>> 
>> I have been thinking some more about your Coke and Pepsi use case 
>> example, and I think it is a somewhat spurious example, for the 
>> following reasons:
>> 
>> 1. If Coke and Pepsi are members of the SAME federation, then they
>> trust each other (by definition). Therefore they would not and
>> could not object to being listed as alternative IdPs in this
>> federation.
>> 
>> 2. If Coke and Pepsi are in different federations because they
>> dont trust each other, but they have the same service provider,
>> then their service provider would be a member of both federations.
>> In this case, the SP would provide different access points to the
>> different federations, and neither Coke nor Pepsi would be aware of
>> each other.
>> 
>> regards
>> 
>> David
> 
> So yes, my point here is to number 2 and providing multitenancy in a
> way that you can't see who else is available, and in talking with
> some of the keystone people this is essentially what we've come to
> (and i think i mentioned earlier?) that you would need to provide a
> different access point to different companies

not to the different companies, but to the different federations. This
is fundamentally different.
However, an SP within a federation may have a private contract with one
organisation and provide a separate access point to it (which may have
several IdPs associated with it).
So I think that Keystone needs a way of indicating which groups of IdPs
have similar relationships to the SP and need to be grouped together for
display purposes.
This brings me back to another related email I sent out. OpenStack needs
a general way of applying access controls to list (tables) of entities.
This would solve the current and other similar problems in a common way.

 to keep this
> information private. It has the side advantage for the public cloud
> folks of providing whitelabelling for horizon.
> 
> The question then once you have multiple access points per customer
> (not user) is how to list IDPs that are associated with that
> customer. The example i had earlier was tagging so you could tag a
> horizon instance (probably doesn't need to be a whole instance, just
> a login page) with like a value like COKE and when you list IDPs from
> keystone you say list with tag=COKE to find out what should show in
> horizon. This would allow common idps like google to be reused.

I think it is an authorisation issue, and tagging is no different to
applying roles (except its less secure). If you have the right role, you
get access to the list entry, otherwise you do not. This is secure.
Tagging is not. It effectively allows anyone to claim any role they wish
by saying I want tag Z.

> 
> This is why i was saying that public/private may not be fine grained
> enough.

Agreed. I is effectively a single role based system.

> It may also be not be a realistic concern. If we are talking
> a portal per customer does the cost of rebooting horizon to staticly
> add a new idp to the local_config matter? This is assumedly a rare
> operation.
> 
> I think the answer has been for a while that idp listing is going to
> need to be configurable from horizon because we already have a case
> for list nothing, list everything, and use this static list, so if in
> future we find we need to add something more complex like tagging
> it's another option we can consider then.

I dont think this is the correct approach. It is allowing the user (in
this case Horizon) to apply his own access controls.

regards

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