Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Jamie

see

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf

regards
David

On 13/08/2015 02:06, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "David Chadwick"  To:
>> openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015
>> 3:06:46 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> 
>> 
>> On 11/08/2015 01:46, Jamie Lennox wrote:
>>> 
>>> 
>>> - Original Message -
>>>> From: "Jamie Lennox"  To: "OpenStack 
>>>> Development Mailing List (not for usage questions)" 
>>>>  Sent: Tuesday, 11 August,
>>>> 2015 10:09:33 AM Subject: Re: [openstack-dev] [Keystone]
>>>> [Horizon] Federated Login
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -
>>>>> From: "David Chadwick"  To: 
>>>>> openstack-dev@lists.openstack.org Sent: Tuesday, 11 August,
>>>>> 2015 12:50:21 AM Subject: Re: [openstack-dev] [Keystone]
>>>>> [Horizon] Federated Login
>>>>> 
>>>>> 
>>>>> 
>>>>> On 10/08/2015 01:53, Jamie Lennox wrote:
>>>>>> 
>>>>>> 
>>>>>> - Original Message -
>>>>>>> From: "David Chadwick"  To: 
>>>>>>> openstack-dev@lists.openstack.org Sent: Sunday, August
>>>>>>> 9, 2015 12:29:49 AM Subject: Re: [openstack-dev]
>>>>>>> [Keystone] [Horizon] Federated Login
>>>>>>> 
>>>>>>> Hi Jamie
>>>>>>> 
>>>>>>> nice presentation, thanks for sharing it. I have
>>>>>>> forwarded it to my students working on federation aspects
>>>>>>> of Horizon.
>>>>>>> 
>>>>>>> About public federated cloud access, the way you envisage
>>>>>>> it, i.e. that every user will have his own tailored
>>>>>>> (subdomain) URL to the SP is not how it works in the real
>>>>>>> world today. SPs typically provide one URL, which
>>>>>>> everyone from every IdP uses, so that no matter which
>>>>>>> browser you are using, from wherever you are in the
>>>>>>> world, you can access the SP (via your IdP). The only
>>>>>>> thing the user needs to know, is the name of his IdP, in
>>>>>>> order to correctly choose it.
>>>>>>> 
>>>>>>> So discovery of all available IdPs is needed. You are
>>>>>>> correct in saying that Shib supports a separate discovery
>>>>>>> service (WAYF), but Horizon can also play this role, by
>>>>>>> listing the IdPs for the user. This is the mod that my
>>>>>>> student is making to Horizon, by adding type ahead
>>>>>>> searching.
>>>>>> 
>>>>>> So my point at the moment is that unless there's something
>>>>>> i'm missing in the way shib/mellon discovery works is that
>>>>>> horizon can't. Because we forward to a common websso entry
>>>>>> point there is no way (i know) for the users selection in
>>>>>> horizon to be forwarded to keystone. You would still need a
>>>>>> custom "select your idp" discovery page in front of
>>>>>> keystone. I'm not sure if this addition is part of your
>>>>>> students work, it just hasn't been mentioned yet.
>>>>>> 
>>>>>>> About your proposed discovery mod, surely this seems to
>>>>>>> be going in the wrong direction. A common entry point to 
>>>>>>> Keystone for all IdPs, as we have now with WebSSO, seems
>>>>>>> to be preferable to separate entry points per IdP. Which
>>>>>>> high street shop has separate doors for each user? Or
>>>>>>> have I misunderstood the purpose of your mod?
>>>>>> 
>>>>>> The purpose of the mod is purely to bypass the need to have
>>>>>> a shib/mellon discovery page on
>>>>>> /v3/OS-FEDERATION/websso/saml2. This page is currently
>>>>>> required to allow a user to select their idp (presumably
>>>>>> from the ones supported by keystone) and redirect to that
>>>>>> IDPs

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 13/08/2015 02:22, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "David Chadwick"  To:
>> openstack-dev@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"  To: "OpenStack
>>>> Development Mailing List (not for usage questions)" 
>>>>  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.math...@gmail.com > wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Aug 5, 2015 at 1:02 P

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Chadwick" 
> To: openstack-dev@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 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. 

This is why i was saying that public/private may not be fine grained enough. 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.

> 
> On 06/08/2015 00:54, Jamie Lennox wrote:
> > 
> > 
> > - Original Message -
> >> From: "David Lyle" 
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> 
> >> 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.math...@gmail.com >
> >> wrote:
> >>
> >>
> >>
> >> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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 goin

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Chadwick" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, 13 August, 2015 3:06:46 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> On 11/08/2015 01:46, Jamie Lennox wrote:
> > 
> > 
> > - Original Message -
> >> From: "Jamie Lennox"  To: "OpenStack
> >> Development Mailing List (not for usage questions)"
> >>  Sent: Tuesday, 11 August, 2015
> >> 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >> Federated Login
> >> 
> >> 
> >> 
> >> - Original Message -----
> >>> From: "David Chadwick"  To:
> >>> openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015
> >>> 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >>> Federated Login
> >>> 
> >>> 
> >>> 
> >>> On 10/08/2015 01:53, Jamie Lennox wrote:
> >>>> 
> >>>> 
> >>>> - Original Message -
> >>>>> From: "David Chadwick"  To:
> >>>>> openstack-dev@lists.openstack.org Sent: Sunday, August 9,
> >>>>> 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone]
> >>>>> [Horizon] Federated Login
> >>>>> 
> >>>>> Hi Jamie
> >>>>> 
> >>>>> nice presentation, thanks for sharing it. I have forwarded it
> >>>>> to my students working on federation aspects of Horizon.
> >>>>> 
> >>>>> About public federated cloud access, the way you envisage it,
> >>>>> i.e. that every user will have his own tailored (subdomain)
> >>>>> URL to the SP is not how it works in the real world today.
> >>>>> SPs typically provide one URL, which everyone from every IdP
> >>>>> uses, so that no matter which browser you are using, from
> >>>>> wherever you are in the world, you can access the SP (via
> >>>>> your IdP). The only thing the user needs to know, is the name
> >>>>> of his IdP, in order to correctly choose it.
> >>>>> 
> >>>>> So discovery of all available IdPs is needed. You are correct
> >>>>> in saying that Shib supports a separate discovery service
> >>>>> (WAYF), but Horizon can also play this role, by listing the
> >>>>> IdPs for the user. This is the mod that my student is making
> >>>>> to Horizon, by adding type ahead searching.
> >>>> 
> >>>> So my point at the moment is that unless there's something i'm
> >>>> missing in the way shib/mellon discovery works is that horizon
> >>>> can't. Because we forward to a common websso entry point there
> >>>> is no way (i know) for the users selection in horizon to be
> >>>> forwarded to keystone. You would still need a custom "select
> >>>> your idp" discovery page in front of keystone. I'm not sure if
> >>>> this addition is part of your students work, it just hasn't
> >>>> been mentioned yet.
> >>>> 
> >>>>> About your proposed discovery mod, surely this seems to be
> >>>>> going in the wrong direction. A common entry point to
> >>>>> Keystone for all IdPs, as we have now with WebSSO, seems to
> >>>>> be preferable to separate entry points per IdP. Which high
> >>>>> street shop has separate doors for each user? Or have I
> >>>>> misunderstood the purpose of your mod?
> >>>> 
> >>>> The purpose of the mod is purely to bypass the need to have a
> >>>> shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2.
> >>>> This page is currently required to allow a user to select their
> >>>> idp (presumably from the ones supported by keystone) and
> >>>> redirect to that IDPs specific login page.
> >>> 
> >>> There are two functionalities that are required: a) Horizon
> >>> finding the redirection login URL of the IdP chosen by the user
> >>> b) Keystone finding which IdP was used for login.
> >>> 
> >>> The second is already done by Apache telling Keystone in the
> >>> header field.
> >>> 
> >>> The first is part of the metadata of the IdP, and Keystone should
> >>> m

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Lance

On 12/08/2015 18:55, Lance Bragstad wrote:
> 
> 
> On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick
> mailto:d.w.chadw...@kent.ac.uk>> wrote:
> 
> 
> 
> On 11/08/2015 01:46, Jamie Lennox wrote:
> >
> >
> > - Original Message -
> >> From: "Jamie Lennox"  <mailto:jamielen...@redhat.com>> To: "OpenStack
> >> Development Mailing List (not for usage questions)"
> >>  <mailto:openstack-dev@lists.openstack.org>> Sent: Tuesday, 11
> August, 2015
> >> 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >> Federated Login
> >>
> >>
> >>
> >> - Original Message -
> >>> From: "David Chadwick"  <mailto:d.w.chadw...@kent.ac.uk>> To:
> >>> openstack-dev@lists.openstack.org
> <mailto:openstack-dev@lists.openstack.org> Sent: Tuesday, 11 August,
> 2015
> >>> 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >>> Federated Login
> >>>
> >>>
> >>>
> >>> On 10/08/2015 01:53, Jamie Lennox wrote:
> >>>>
> >>>>
> >>>> - Original Message -
> >>>>> From: "David Chadwick"  <mailto:d.w.chadw...@kent.ac.uk>> To:
> >>>>> openstack-dev@lists.openstack.org
> <mailto:openstack-dev@lists.openstack.org> Sent: Sunday, August 9,
> >>>>> 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone]
> >>>>> [Horizon] Federated Login
> >>>>>
> >>>>> Hi Jamie
> >>>>>
> >>>>> nice presentation, thanks for sharing it. I have forwarded it
> >>>>> to my students working on federation aspects of Horizon.
> >>>>>
> >>>>> About public federated cloud access, the way you envisage it,
> >>>>> i.e. that every user will have his own tailored (subdomain)
> >>>>> URL to the SP is not how it works in the real world today.
> >>>>> SPs typically provide one URL, which everyone from every IdP
> >>>>> uses, so that no matter which browser you are using, from
> >>>>> wherever you are in the world, you can access the SP (via
> >>>>> your IdP). The only thing the user needs to know, is the name
> >>>>> of his IdP, in order to correctly choose it.
> >>>>>
> >>>>> So discovery of all available IdPs is needed. You are correct
> >>>>> in saying that Shib supports a separate discovery service
> >>>>> (WAYF), but Horizon can also play this role, by listing the
> >>>>> IdPs for the user. This is the mod that my student is making
> >>>>> to Horizon, by adding type ahead searching.
> >>>>
> >>>> So my point at the moment is that unless there's something i'm
> >>>> missing in the way shib/mellon discovery works is that horizon
> >>>> can't. Because we forward to a common websso entry point there
> >>>> is no way (i know) for the users selection in horizon to be
> >>>> forwarded to keystone. You would still need a custom "select
> >>>> your idp" discovery page in front of keystone. I'm not sure if
> >>>> this addition is part of your students work, it just hasn't
> >>>> been mentioned yet.
> >>>>
> >>>>> About your proposed discovery mod, surely this seems to be
> >>>>> going in the wrong direction. A common entry point to
> >>>>> Keystone for all IdPs, as we have now with WebSSO, seems to
> >>>>> be preferable to separate entry points per IdP. Which high
> >>>>> street shop has separate doors for each user? Or have I
> >>>>> misunderstood the purpose of your mod?
> >>>>
> >>>> The purpose of the mod is purely to bypass the need to have a
> >>>> shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2.
> >>>> This page is currently required to allow a user to select their
> >>>> idp (presumably from the ones supported by keystone) and
> >>>> redi

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

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

On 06/08/2015 00:54, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "David Lyle" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> 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.math...@gmail.com >
>> wrote:
>>
>>
>>
>> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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.chadw...@kent.ac.uk > wrote:
>>
>> From: Dolph Mathews < dolph.math...@gmail.com >
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@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.chadw...@kent.ac.uk >
>> wrote:
>>
>> On 04/08/2015 18:59, Steve Martinelli wrote: > Right, but that API is/sh

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Lance Bragstad]

On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick 
wrote:

>
>
> On 11/08/2015 01:46, Jamie Lennox wrote:
> >
> >
> > - Original Message -
> >> From: "Jamie Lennox"  To: "OpenStack
> >> Development Mailing List (not for usage questions)"
> >>  Sent: Tuesday, 11 August, 2015
> >> 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >> Federated Login
> >>
> >>
> >>
> >> - Original Message -
> >>> From: "David Chadwick"  To:
> >>> openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015
> >>> 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >>> Federated Login
> >>>
> >>>
> >>>
> >>> On 10/08/2015 01:53, Jamie Lennox wrote:
> >>>>
> >>>>
> >>>> - Original Message -
> >>>>> From: "David Chadwick"  To:
> >>>>> openstack-dev@lists.openstack.org Sent: Sunday, August 9,
> >>>>> 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone]
> >>>>> [Horizon] Federated Login
> >>>>>
> >>>>> Hi Jamie
> >>>>>
> >>>>> nice presentation, thanks for sharing it. I have forwarded it
> >>>>> to my students working on federation aspects of Horizon.
> >>>>>
> >>>>> About public federated cloud access, the way you envisage it,
> >>>>> i.e. that every user will have his own tailored (subdomain)
> >>>>> URL to the SP is not how it works in the real world today.
> >>>>> SPs typically provide one URL, which everyone from every IdP
> >>>>> uses, so that no matter which browser you are using, from
> >>>>> wherever you are in the world, you can access the SP (via
> >>>>> your IdP). The only thing the user needs to know, is the name
> >>>>> of his IdP, in order to correctly choose it.
> >>>>>
> >>>>> So discovery of all available IdPs is needed. You are correct
> >>>>> in saying that Shib supports a separate discovery service
> >>>>> (WAYF), but Horizon can also play this role, by listing the
> >>>>> IdPs for the user. This is the mod that my student is making
> >>>>> to Horizon, by adding type ahead searching.
> >>>>
> >>>> So my point at the moment is that unless there's something i'm
> >>>> missing in the way shib/mellon discovery works is that horizon
> >>>> can't. Because we forward to a common websso entry point there
> >>>> is no way (i know) for the users selection in horizon to be
> >>>> forwarded to keystone. You would still need a custom "select
> >>>> your idp" discovery page in front of keystone. I'm not sure if
> >>>> this addition is part of your students work, it just hasn't
> >>>> been mentioned yet.
> >>>>
> >>>>> About your proposed discovery mod, surely this seems to be
> >>>>> going in the wrong direction. A common entry point to
> >>>>> Keystone for all IdPs, as we have now with WebSSO, seems to
> >>>>> be preferable to separate entry points per IdP. Which high
> >>>>> street shop has separate doors for each user? Or have I
> >>>>> misunderstood the purpose of your mod?
> >>>>
> >>>> The purpose of the mod is purely to bypass the need to have a
> >>>> shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2.
> >>>> This page is currently required to allow a user to select their
> >>>> idp (presumably from the ones supported by keystone) and
> >>>> redirect to that IDPs specific login page.
> >>>
> >>> There are two functionalities that are required: a) Horizon
> >>> finding the redirection login URL of the IdP chosen by the user
> >>> b) Keystone finding which IdP was used for login.
> >>>
> >>> The second is already done by Apache telling Keystone in the
> >>> header field.
> >>>
> >>> The first is part of the metadata of the IdP, and Keystone should
> >>> make this available to Horizon via an API call. Ideally when
> >>> Horizon calls Keystone for the list of trusted IdPs, then the
> >>> user friendly name of the IdP (to be displ

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 11/08/2015 01:46, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "Jamie Lennox"  To: "OpenStack
>> Development Mailing List (not for usage questions)"
>>  Sent: Tuesday, 11 August, 2015
>> 10:09:33 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> 
>> 
>> - Original Message -
>>> From: "David Chadwick"  To:
>>> openstack-dev@lists.openstack.org Sent: Tuesday, 11 August, 2015
>>> 12:50:21 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>>> Federated Login
>>> 
>>> 
>>> 
>>> On 10/08/2015 01:53, Jamie Lennox wrote:
>>>> 
>>>> 
>>>> - Original Message -
>>>>> From: "David Chadwick"  To: 
>>>>> openstack-dev@lists.openstack.org Sent: Sunday, August 9,
>>>>> 2015 12:29:49 AM Subject: Re: [openstack-dev] [Keystone]
>>>>> [Horizon] Federated Login
>>>>> 
>>>>> Hi Jamie
>>>>> 
>>>>> nice presentation, thanks for sharing it. I have forwarded it
>>>>> to my students working on federation aspects of Horizon.
>>>>> 
>>>>> About public federated cloud access, the way you envisage it,
>>>>> i.e. that every user will have his own tailored (subdomain)
>>>>> URL to the SP is not how it works in the real world today.
>>>>> SPs typically provide one URL, which everyone from every IdP
>>>>> uses, so that no matter which browser you are using, from
>>>>> wherever you are in the world, you can access the SP (via
>>>>> your IdP). The only thing the user needs to know, is the name
>>>>> of his IdP, in order to correctly choose it.
>>>>> 
>>>>> So discovery of all available IdPs is needed. You are correct
>>>>> in saying that Shib supports a separate discovery service
>>>>> (WAYF), but Horizon can also play this role, by listing the
>>>>> IdPs for the user. This is the mod that my student is making
>>>>> to Horizon, by adding type ahead searching.
>>>> 
>>>> So my point at the moment is that unless there's something i'm 
>>>> missing in the way shib/mellon discovery works is that horizon
>>>> can't. Because we forward to a common websso entry point there
>>>> is no way (i know) for the users selection in horizon to be
>>>> forwarded to keystone. You would still need a custom "select
>>>> your idp" discovery page in front of keystone. I'm not sure if
>>>> this addition is part of your students work, it just hasn't
>>>> been mentioned yet.
>>>> 
>>>>> About your proposed discovery mod, surely this seems to be
>>>>> going in the wrong direction. A common entry point to
>>>>> Keystone for all IdPs, as we have now with WebSSO, seems to
>>>>> be preferable to separate entry points per IdP. Which high
>>>>> street shop has separate doors for each user? Or have I
>>>>> misunderstood the purpose of your mod?
>>>> 
>>>> The purpose of the mod is purely to bypass the need to have a 
>>>> shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2.
>>>> This page is currently required to allow a user to select their
>>>> idp (presumably from the ones supported by keystone) and
>>>> redirect to that IDPs specific login page.
>>> 
>>> There are two functionalities that are required: a) Horizon
>>> finding the redirection login URL of the IdP chosen by the user 
>>> b) Keystone finding which IdP was used for login.
>>> 
>>> The second is already done by Apache telling Keystone in the
>>> header field.
>>> 
>>> The first is part of the metadata of the IdP, and Keystone should
>>> make this available to Horizon via an API call. Ideally when
>>> Horizon calls Keystone for the list of trusted IdPs, then the
>>> user friendly name of the IdP (to be displayed to the user) and
>>> the login page URL should be returned. Then Horizon can present
>>> the user friendly list to the user, get the login URL that
>>> matches this, then redirect the user to the IdP telling the IdP
>>> the common callback URL of Keystone.
>> 
>> So my understanding was that this wasn't possible. Because we want
>> to have keystone be the registered service provider an

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

This is essentially an access control issue. Ideally the existing access
control mechanism should be sufficient to provide the functionality we
want. If it is not, then it is better to change the underlying access
control system rather than to add a patch to provide this specific bit
of extra functionality for one use case.

The general functionality that is needed is to be able to access control
a list of entities and make entries in the list accessible to different
principals. We have come across this is two different scenarios and
there are probably others that you can think of:
i) the list of IdPs available for federated login
ii) the list of conditions in a policy available to policy writers (some
condition values might contain sensitive information)

Swift already has this functionality for listing files in a directory.
Can a project be started to make this functionality more general for all
sorts of lists of entities?

regards

David

On 11/08/2015 10:55, Jesse Pretorius wrote:
> On 6 August 2015 at 10:02, David Chadwick  > wrote:
> 
> 
> this is a value judgement that admins take. I think we should allow this
> to be configurable, by either improving the policy engine to allow a
> public access rule (coarse grained), or adding a public/private flag to
> each configured IdP (fine grained)
> 
> 
> Perhaps an idea which could evolve this and keep the settings in
> keystone instead of splitting them between two projects:
> 
> 1. Have the list of trusted dashboards be set per IDP - this would allow
> that dashboard to list that IDP.
> 2. If an IDP does not have any trusted dashboards listed, then assume
> that it's public and fall back to the defaults set in keystone.conf
> 3. Also enable the policies suggested by David above in order to cover
> API security needs. Perhaps there needs to be some other sort of way of
> doing fine-grained protection of information here?
> 
> This would mean that Coke's dashboard would not be able to list Pepsi's
> IDP at all.
> 
> The trouble with allowing just a public flag on the IDP list is that
> someone in Coke could still type other letters and see the list of other
> providers, including Pepsi. Just a public/private flag is not good enough.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jesse Pretorius]

On 6 August 2015 at 10:02, David Chadwick  wrote:

>
> this is a value judgement that admins take. I think we should allow this
> to be configurable, by either improving the policy engine to allow a
> public access rule (coarse grained), or adding a public/private flag to
> each configured IdP (fine grained)
>

Perhaps an idea which could evolve this and keep the settings in keystone
instead of splitting them between two projects:

1. Have the list of trusted dashboards be set per IDP - this would allow
that dashboard to list that IDP.
2. If an IDP does not have any trusted dashboards listed, then assume that
it's public and fall back to the defaults set in keystone.conf
3. Also enable the policies suggested by David above in order to cover API
security needs. Perhaps there needs to be some other sort of way of doing
fine-grained protection of information here?

This would mean that Coke's dashboard would not be able to list Pepsi's IDP
at all.

The trouble with allowing just a public flag on the IDP list is that
someone in Coke could still type other letters and see the list of other
providers, including Pepsi. Just a public/private flag is not good enough.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Marek Denis]

Hi

On 05.08.2015 19:36, Dolph Mathews wrote:



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?


Would Rackspace be happy to expose list of their customers to everybody?

--
cheers
Marek

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "Jamie Lennox" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, 11 August, 2015 10:09:33 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> - Original Message -
> > From: "David Chadwick" 
> > To: openstack-dev@lists.openstack.org
> > Sent: Tuesday, 11 August, 2015 12:50:21 AM
> > Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> > 
> > 
> > 
> > On 10/08/2015 01:53, Jamie Lennox wrote:
> > > 
> > > 
> > > - Original Message -
> > >> From: "David Chadwick"  To:
> > >> openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
> > >> 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> > >> Federated Login
> > >> 
> > >> Hi Jamie
> > >> 
> > >> nice presentation, thanks for sharing it. I have forwarded it to
> > >> my students working on federation aspects of Horizon.
> > >> 
> > >> About public federated cloud access, the way you envisage it, i.e.
> > >> that every user will have his own tailored (subdomain) URL to the
> > >> SP is not how it works in the real world today. SPs typically
> > >> provide one URL, which everyone from every IdP uses, so that no
> > >> matter which browser you are using, from wherever you are in the
> > >> world, you can access the SP (via your IdP). The only thing the
> > >> user needs to know, is the name of his IdP, in order to correctly
> > >> choose it.
> > >> 
> > >> So discovery of all available IdPs is needed. You are correct in
> > >> saying that Shib supports a separate discovery service (WAYF), but
> > >> Horizon can also play this role, by listing the IdPs for the user.
> > >> This is the mod that my student is making to Horizon, by adding
> > >> type ahead searching.
> > > 
> > > So my point at the moment is that unless there's something i'm
> > > missing in the way shib/mellon discovery works is that horizon can't.
> > > Because we forward to a common websso entry point there is no way (i
> > > know) for the users selection in horizon to be forwarded to keystone.
> > > You would still need a custom "select your idp" discovery page in
> > > front of keystone. I'm not sure if this addition is part of your
> > > students work, it just hasn't been mentioned yet.
> > > 
> > >> About your proposed discovery mod, surely this seems to be going in
> > >> the wrong direction. A common entry point to Keystone for all IdPs,
> > >> as we have now with WebSSO, seems to be preferable to separate
> > >> entry points per IdP. Which high street shop has separate doors for
> > >> each user? Or have I misunderstood the purpose of your mod?
> > > 
> > > The purpose of the mod is purely to bypass the need to have a
> > > shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
> > > page is currently required to allow a user to select their idp
> > > (presumably from the ones supported by keystone) and redirect to that
> > > IDPs specific login page.
> > 
> > There are two functionalities that are required:
> > a) Horizon finding the redirection login URL of the IdP chosen by the user
> > b) Keystone finding which IdP was used for login.
> > 
> > The second is already done by Apache telling Keystone in the header field.
> > 
> > The first is part of the metadata of the IdP, and Keystone should make
> > this available to Horizon via an API call. Ideally when Horizon calls
> > Keystone for the list of trusted IdPs, then the user friendly name of
> > the IdP (to be displayed to the user) and the login page URL should be
> > returned. Then Horizon can present the user friendly list to the user,
> > get the login URL that matches this, then redirect the user to the IdP
> > telling the IdP the common callback URL of Keystone.
> 
> So my understanding was that this wasn't possible. Because we want to have
> keystone be the registered service provider and receive the returned SAML
> assertions the login redirect must be issued from keystone and not horizon.
> Is it possible to issue a login request from horizon that returns the
> response to keystone? This seems dodgy to me but may be possible if all the
> trust relationships are set up.

Note also that currently this m

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Chadwick" 
> To: openstack-dev@lists.openstack.org
> Sent: Tuesday, 11 August, 2015 12:50:21 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> On 10/08/2015 01:53, Jamie Lennox wrote:
> > 
> > 
> > - Original Message -
> >> From: "David Chadwick"  To:
> >> openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
> >> 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
> >> Federated Login
> >> 
> >> Hi Jamie
> >> 
> >> nice presentation, thanks for sharing it. I have forwarded it to
> >> my students working on federation aspects of Horizon.
> >> 
> >> About public federated cloud access, the way you envisage it, i.e.
> >> that every user will have his own tailored (subdomain) URL to the
> >> SP is not how it works in the real world today. SPs typically
> >> provide one URL, which everyone from every IdP uses, so that no
> >> matter which browser you are using, from wherever you are in the
> >> world, you can access the SP (via your IdP). The only thing the
> >> user needs to know, is the name of his IdP, in order to correctly
> >> choose it.
> >> 
> >> So discovery of all available IdPs is needed. You are correct in
> >> saying that Shib supports a separate discovery service (WAYF), but
> >> Horizon can also play this role, by listing the IdPs for the user.
> >> This is the mod that my student is making to Horizon, by adding
> >> type ahead searching.
> > 
> > So my point at the moment is that unless there's something i'm
> > missing in the way shib/mellon discovery works is that horizon can't.
> > Because we forward to a common websso entry point there is no way (i
> > know) for the users selection in horizon to be forwarded to keystone.
> > You would still need a custom "select your idp" discovery page in
> > front of keystone. I'm not sure if this addition is part of your
> > students work, it just hasn't been mentioned yet.
> > 
> >> About your proposed discovery mod, surely this seems to be going in
> >> the wrong direction. A common entry point to Keystone for all IdPs,
> >> as we have now with WebSSO, seems to be preferable to separate
> >> entry points per IdP. Which high street shop has separate doors for
> >> each user? Or have I misunderstood the purpose of your mod?
> > 
> > The purpose of the mod is purely to bypass the need to have a
> > shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
> > page is currently required to allow a user to select their idp
> > (presumably from the ones supported by keystone) and redirect to that
> > IDPs specific login page.
> 
> There are two functionalities that are required:
> a) Horizon finding the redirection login URL of the IdP chosen by the user
> b) Keystone finding which IdP was used for login.
> 
> The second is already done by Apache telling Keystone in the header field.
> 
> The first is part of the metadata of the IdP, and Keystone should make
> this available to Horizon via an API call. Ideally when Horizon calls
> Keystone for the list of trusted IdPs, then the user friendly name of
> the IdP (to be displayed to the user) and the login page URL should be
> returned. Then Horizon can present the user friendly list to the user,
> get the login URL that matches this, then redirect the user to the IdP
> telling the IdP the common callback URL of Keystone.

So my understanding was that this wasn't possible. Because we want to have 
keystone be the registered service provider and receive the returned SAML 
assertions the login redirect must be issued from keystone and not horizon. Is 
it possible to issue a login request from horizon that returns the response to 
keystone? This seems dodgy to me but may be possible if all the trust 
relationships are set up.

In a way this is exactly what my proposal was. A way for horizon to determine a 
unique websso login page for each idp, just my understanding is that this 
request must be bounced through keystone.

> > When the response comes back from that
> > login it returns to that websso page and we look at remote_ids to
> > determine which keystone idp is handling the response from that
> > site.
> 
> This seems the more secure way of determining the IdP to me, since
> Apache determines the IdP then tells Keystone via the header field. If
> you rely on the IdP to contact the "right" endpoint, then doesn't this
> allow the IdP to return to a different U

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 10/08/2015 01:53, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "David Chadwick"  To:
>> openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
>> 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> Hi Jamie
>> 
>> nice presentation, thanks for sharing it. I have forwarded it to
>> my students working on federation aspects of Horizon.
>> 
>> About public federated cloud access, the way you envisage it, i.e.
>> that every user will have his own tailored (subdomain) URL to the
>> SP is not how it works in the real world today. SPs typically
>> provide one URL, which everyone from every IdP uses, so that no
>> matter which browser you are using, from wherever you are in the
>> world, you can access the SP (via your IdP). The only thing the
>> user needs to know, is the name of his IdP, in order to correctly
>> choose it.
>> 
>> So discovery of all available IdPs is needed. You are correct in
>> saying that Shib supports a separate discovery service (WAYF), but
>> Horizon can also play this role, by listing the IdPs for the user.
>> This is the mod that my student is making to Horizon, by adding
>> type ahead searching.
> 
> So my point at the moment is that unless there's something i'm
> missing in the way shib/mellon discovery works is that horizon can't.
> Because we forward to a common websso entry point there is no way (i
> know) for the users selection in horizon to be forwarded to keystone.
> You would still need a custom "select your idp" discovery page in
> front of keystone. I'm not sure if this addition is part of your
> students work, it just hasn't been mentioned yet.
> 
>> About your proposed discovery mod, surely this seems to be going in
>> the wrong direction. A common entry point to Keystone for all IdPs,
>> as we have now with WebSSO, seems to be preferable to separate
>> entry points per IdP. Which high street shop has separate doors for
>> each user? Or have I misunderstood the purpose of your mod?
> 
> The purpose of the mod is purely to bypass the need to have a
> shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
> page is currently required to allow a user to select their idp
> (presumably from the ones supported by keystone) and redirect to that
> IDPs specific login page.

There are two functionalities that are required:
a) Horizon finding the redirection login URL of the IdP chosen by the user
b) Keystone finding which IdP was used for login.

The second is already done by Apache telling Keystone in the header field.

The first is part of the metadata of the IdP, and Keystone should make
this available to Horizon via an API call. Ideally when Horizon calls
Keystone for the list of trusted IdPs, then the user friendly name of
the IdP (to be displayed to the user) and the login page URL should be
returned. Then Horizon can present the user friendly list to the user,
get the login URL that matches this, then redirect the user to the IdP
telling the IdP the common callback URL of Keystone.

> When the response comes back from that
> login it returns to that websso page and we look at remote_ids to
> determine which keystone idp is handling the response from that
> site.

This seems the more secure way of determining the IdP to me, since
Apache determines the IdP then tells Keystone via the header field. If
you rely on the IdP to contact the "right" endpoint, then doesn't this
allow the IdP to return to a different URL and thereby trick Keystone
into thinking it was a different IdP?

regards

David

> 
> If we were to move that to
> /v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/saml2/websso
> then we can more easily support selection from horizon, or otherwise
> do discovery without relying on shib/mellons discovery mechanism. A
> selection from horizon would forward us to the idp specific websso on
> keystone, which would forward to the idp's login page (without
> needing discovery because we already know the idp) and the response
> from login would go to the idp specific page negating the need for
> dealing with remote_ids.
> 
> So i'm not looking for a seperate door so much as a way to indicate
> that the user picked an IDP in horizon and i don't want to do
> discovery again.
> 
>> regards
>> 
>> David
>> 
>> On 07/08/2015 01:29, Jamie Lennox wrote:
>>> 
>>> 
>>> 
>>>
>>>
>>> 
*From: *"Dolph Mathews" 
>>> *To: *"OpenStack Development Mailing List 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Chadwick" 
> To: openstack-dev@lists.openstack.org
> Sent: Sunday, August 9, 2015 12:29:49 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> Hi Jamie
> 
> nice presentation, thanks for sharing it. I have forwarded it to my
> students working on federation aspects of Horizon.
> 
> About public federated cloud access, the way you envisage it, i.e. that
> every user will have his own tailored (subdomain) URL to the SP is not
> how it works in the real world today. SPs typically provide one URL,
> which everyone from every IdP uses, so that no matter which browser you
> are using, from wherever you are in the world, you can access the SP
> (via your IdP). The only thing the user needs to know, is the name of
> his IdP, in order to correctly choose it.
> 
> So discovery of all available IdPs is needed. You are correct in saying
> that Shib supports a separate discovery service (WAYF), but Horizon can
> also play this role, by listing the IdPs for the user. This is the mod
> that my student is making to Horizon, by adding type ahead searching.

So my point at the moment is that unless there's something i'm missing in the 
way shib/mellon discovery works is that horizon can't. Because we forward to a 
common websso entry point there is no way (i know) for the users selection in 
horizon to be forwarded to keystone. You would still need a custom "select your 
idp" discovery page in front of keystone. I'm not sure if this addition is part 
of your students work, it just hasn't been mentioned yet.

> About your proposed discovery mod, surely this seems to be going in the
> wrong direction. A common entry point to Keystone for all IdPs, as we
> have now with WebSSO, seems to be preferable to separate entry points
> per IdP. Which high street shop has separate doors for each user? Or
> have I misunderstood the purpose of your mod?

The purpose of the mod is purely to bypass the need to have a shib/mellon 
discovery page on /v3/OS-FEDERATION/websso/saml2. This page is currently 
required to allow a user to select their idp (presumably from the ones 
supported by keystone) and redirect to that IDPs specific login page. When the 
response comes back from that login it returns to that websso page and we look 
at remote_ids to determine which keystone idp is handling the response from 
that site.

If we were to move that to 
/v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/saml2/websso then we 
can more easily support selection from horizon, or otherwise do discovery 
without relying on shib/mellons discovery mechanism. A selection from horizon 
would forward us to the idp specific websso on keystone, which would forward to 
the idp's login page (without needing discovery because we already know the 
idp) and the response from login would go to the idp specific page negating the 
need for dealing with remote_ids.

So i'm not looking for a seperate door so much as a way to indicate that the 
user picked an IDP in horizon and i don't want to do discovery again.
 
> regards
> 
> David
> 
> On 07/08/2015 01:29, Jamie Lennox wrote:
> > 
> > 
> > 
> > 
> >     *From: *"Dolph Mathews" 
> > *To: *"OpenStack Development Mailing List (not for usage questions)"
> > 
> > *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  > <mailto:lbrags...@gmail.com>> wrote:
> > 
> > 
> > 
> > On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
> > mailto:dolph.math...@gmail.com>> wrote:
> > 
> > 
> > On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
> > mailto:jamielen...@redhat.com>> wrote:
> > 
> > 
> > 
> > - Original Message -
> >         > From: "David Lyle"  >     > <mailto:dkly...@gmail.com>>
> > > To: "OpenStack Development Mailing List (not for usage
> > > questions)"  > <mailto:openstack-dev@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
> > > 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 07/08/2015 00:11, Dolph Mathews wrote:
> 
> 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.
>  

How do you expect this to work when the public service is listed in some
public directory or search engine like google?

How will any user from any organisation know how to contact this
service, http://service.com?

Should it be
http://service.com/myOrg
http://service.com/Organisation
http://service.com/Org.com
the potential values for the name of each IdP are endless. Users will
never know what to use, remembering also that the URL is case sensitive.

regards

David

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Jamie

nice presentation, thanks for sharing it. I have forwarded it to my
students working on federation aspects of Horizon.

About public federated cloud access, the way you envisage it, i.e. that
every user will have his own tailored (subdomain) URL to the SP is not
how it works in the real world today. SPs typically provide one URL,
which everyone from every IdP uses, so that no matter which browser you
are using, from wherever you are in the world, you can access the SP
(via your IdP). The only thing the user needs to know, is the name of
his IdP, in order to correctly choose it.

So discovery of all available IdPs is needed. You are correct in saying
that Shib supports a separate discovery service (WAYF), but Horizon can
also play this role, by listing the IdPs for the user. This is the mod
that my student is making to Horizon, by adding type ahead searching.

About your proposed discovery mod, surely this seems to be going in the
wrong direction. A common entry point to Keystone for all IdPs, as we
have now with WebSSO, seems to be preferable to separate entry points
per IdP. Which high street shop has separate doors for each user? Or
have I misunderstood the purpose of your mod?

regards

David

On 07/08/2015 01:29, Jamie Lennox wrote:
> 
> 
> 
> 
> *From: *"Dolph Mathews" 
> *To: *"OpenStack Development Mailing List (not for usage questions)"
> 
> *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  <mailto:lbrags...@gmail.com>> wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
> mailto:dolph.math...@gmail.com>> wrote:
> 
> 
> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
> mailto:jamielen...@redhat.com>> wrote:
> 
> 
> 
> - Original Message -
> > From: "David Lyle"  <mailto:dkly...@gmail.com>>
> > To: "OpenStack Development Mailing List (not for usage 
> questions)"          <mailto:openstack-dev@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.math...@gmail.com <mailto:dolph.math...@gmail.com> >
> > wrote:
> >
> >
> >
> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < 
> steve...@ca.ibm.com <mailto:steve...@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 <http://COKE.COM>
> domain and i can see for example that PEPSI.COM
> <http://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 <http://COKE.COM> domain (because the UX
> for inputting a domain at login is not great so per
>  

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Adam Young]

On 08/06/2015 07:09 PM, Dolph Mathews wrote:


On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad <mailto:lbrags...@gmail.com>> wrote:




On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews
mailto:dolph.math...@gmail.com>> wrote:


On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox
mailto:jamielen...@redhat.com>> wrote:



- Original Message -
> From: "David Lyle" mailto:dkly...@gmail.com>>
> To: "OpenStack Development Mailing List (not for usage
questions)" mailto:openstack-dev@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.math...@gmail.com <mailto:dolph.math...@gmail.com> >
> wrote:
>
>
>
> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
steve...@ca.ibm.com <mailto:steve...@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 <http://COKE.COM>
domain and i can see for example that PEPSI.COM
<http://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 <http://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 <http://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").



Are we going about this backwards?  Wouldn't it make more sense to tell 
a new customer:


you get https://coke.cloudprovider.net

And have that hard coded to a UI.

For larger organizations, I suspect it would make more sense that the UI 
should be owned by Coke, and run on a server managed by Coke, and talk 
to multiple OpenStack instances.


The UI should not be Provider specific, but consumer specific.






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 h

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Adam Young]

On 08/06/2015 04:56 AM, David Chadwick wrote:


On 05/08/2015 19:28, Thai Q Tran wrote:

I agree with Lance. Quite honestly, the list of Idps does not belong
in horizon's settings. Just throwing out some ideas, why not white-list
the Idps you want public it in keystone's settings, and have an API call
for that?

that was the conclusion reached many months ago the last time this was
discussed.

regards

David


Posted a spec for review here.  It needs a corresponding API change.

https://review.openstack.org/#/c/209941/




  
  


 - Original message -
 From: Lance Bragstad 
 To: "OpenStack Development Mailing List (not for usage questions)"
 
     Cc:
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
 Date: Wed, Aug 5, 2015 11:19 AM
  
  
  
 On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli

 mailto:steve...@ca.ibm.com>> wrote:

 Some folks said that they'd prefer not to list all associated
 idps, which i can understand.

 Actually, I like jamie's suggestion of just making horizon a bit
 smarter, and expecting the values in the horizon settings
 (idp+protocol)

  
 This *might* lead to a more complicated user experience, unless we

 deduce the protocol for the IdP selected (but that would defeat the
 point?). Also, wouldn't we have to make changes to Horizon every
 time we add an IdP? This might be case by case, but if you're
 consistently adding Identity Providers, then your ops team might not
 be too happy reconfiguring Horizon all the time.
  




 Thanks,

 Steve Martinelli
 OpenStack Keystone Core

 Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick
 mailto:d.w.chadw...@kent.ac.uk>> wrote:

 From: Dolph Mathews mailto:dolph.math...@gmail.com>>
 To: "OpenStack Development Mailing List (not for usage
 questions)" mailto:openstack-dev@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.chadw...@kent.ac.uk_ <mailto:d.w.chadw...@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
  ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52
 AM, Douglas
 > Fish <_drf...@us.ibm.com_ <mailto:drf...@us.ibm.com>>
 wrote: > Hi David,
 >
 > From: Lance Bragstad <_lbragstad@gmail.com_
 <mailto:lbrags...@gmail.com>>
 > To: "OpenStack Development Mailing List (not for usage
 questions)"
         > <_openstack-dev@lists.openstack.org_
     <mailto:openstack-dev@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
 <_drf...@us.ibm.com_
 > <mailto:_drf...@us.ibm.com_ <mailto:drf...@us.ibm.com>>>
 wrote:
 >
 > Hi David,
 &

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -

> From: "Dolph Mathews" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> 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 < lbrags...@gmail.com >
> wrote:

> > On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews < dolph.math...@gmail.com >
> > wrote:
> 

> > > On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox < jamielen...@redhat.com >
> > > wrote:
> > 
> 

> > > > - Original Message -
> > > 
> > 
> 
> > > > > From: "David Lyle" < dkly...@gmail.com >
> > > 
> > 
> 
> > > > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > > > openstack-dev@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.math...@gmail.com
> > > > > >
> > > 
> > 
> 
> > > > > wrote:
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
> > > > > steve...@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
> > 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Dolph Mathews]

On Thu, Aug 6, 2015 at 6:09 PM, Dolph Mathews 
wrote:

>
> On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad 
> wrote:
>
>>
>>
>> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews 
>> wrote:
>>
>>>
>>> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox 
>>> wrote:
>>>
>>>>
>>>>
>>>> - Original Message -
>>>> > From: "David Lyle" 
>>>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>>>> openstack-dev@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.math...@gmail.com >
>>>> > wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
>>>> steve...@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 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Dolph Mathews]

On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad  wrote:

>
>
> On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews 
> wrote:
>
>>
>> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox 
>> wrote:
>>
>>>
>>>
>>> - Original Message -
>>> > From: "David Lyle" 
>>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@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.math...@gmail.com >
>>> > wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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").


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

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Lance Bragstad]

On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews 
wrote:

>
> On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox 
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "David Lyle" 
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@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.math...@gmail.com
>> >
>> > wrote:
>> >
>> >
>> >
>> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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 Ch

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Dolph Mathews]

On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox  wrote:

>
>
> - Original Message -
> > From: "David Lyle" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@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.math...@gmail.com
> >
> > wrote:
> >
> >
> >
> > On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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.

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.chadw...@kent.ac.uk > wrote:
> >
> > From: Dolph Mathews < dolph.math...@gmail.com >
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@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.chadw...@kent.ac.uk
> >
> > wrote:
> >
> > On 04/08/2015 18:59, Steve Martinelli wrote: > Right, but that API
> is/should
>

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Chadwick" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, August 6, 2015 6:25:29 PM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> On 06/08/2015 00:54, Jamie Lennox wrote:
> > 
> > 
> > - Original Message -
> >> From: "David Lyle"  To: "OpenStack Development
> >> Mailing List (not for usage questions)"
> >>  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.math...@gmail.com > wrote:
> >> 
> >> 
> >> 
> >> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
> >> steve...@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

So my point here was that in many situations you strictly don't want to allow 
people to see this entire list. 

> 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 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 05/08/2015 18:36, Dolph Mathews wrote:
> 
> On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick  <mailto:d.w.chadw...@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?

this is a value judgement that admins take. I think we should allow this
to be configurable, by either improving the policy engine to allow a
public access rule (coarse grained), or adding a public/private flag to
each configured IdP (fine grained)

regards

David

>  
> 
> 
> 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  > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
> > Fish mailto:drf...@us.ibm.com>> wrote: > Hi David,
> >
> > From: Lance Bragstad mailto:lbrags...@gmail.com>>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >  <mailto:openstack-dev@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 <_drf...@us.ibm.com_
> > <mailto:drf...@us.ibm.com <mailto:drf...@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.chadw...@kent.ac.uk_
> > <mailto:d.w.chadw...@kent.ac.uk
> <mailto:d.w.chadw...@kent.ac.uk>>> wrote on 08/01/2015 06:01:48 AM:
> >
> > > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
> > <mailto:d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk>>>
> > > To: OpenStack Development Mailing List
> > <_openstack-dev@lists.openstack.org_
> > <mailto:openstack-dev@lists.openstack.org
> <mailto:openstack-dev@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
>

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 05/08/2015 19:28, Thai Q Tran wrote:
> I agree with Lance. Quite honestly, the list of Idps does not belong
> in horizon's settings. Just throwing out some ideas, why not white-list
> the Idps you want public it in keystone's settings, and have an API call
> for that?

that was the conclusion reached many months ago the last time this was
discussed.

regards

David

>  
>  
> 
> - Original message -
> From: Lance Bragstad 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc:
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> Date: Wed, Aug 5, 2015 11:19 AM
>  
>  
>  
> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli
> mailto:steve...@ca.ibm.com>> wrote:
> 
> Some folks said that they'd prefer not to list all associated
> idps, which i can understand.
> 
> Actually, I like jamie's suggestion of just making horizon a bit
> smarter, and expecting the values in the horizon settings
> (idp+protocol)
> 
>  
> This *might* lead to a more complicated user experience, unless we
> deduce the protocol for the IdP selected (but that would defeat the
> point?). Also, wouldn't we have to make changes to Horizon every
> time we add an IdP? This might be case by case, but if you're
> consistently adding Identity Providers, then your ops team might not
> be too happy reconfiguring Horizon all the time. 
>  
> 
> 
> 
> Thanks,
> 
> Steve Martinelli
> OpenStack Keystone Core
> 
> Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
> PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick
>  Aug 5, 2015 at 5:39 AM, David Chadwick  <mailto:d.w.chadw...@kent.ac.uk>> wrote:
> 
> From: Dolph Mathews  <mailto:dolph.math...@gmail.com>>
>     To: "OpenStack Development Mailing List (not for usage
> questions)"  <mailto:openstack-dev@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.chadw...@kent.ac.uk_ <mailto:d.w.chadw...@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
>  > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52
> AM, Douglas
> > Fish <_drf...@us.ibm.com_ <mailto:drf...@us.ibm.com>>
>     wrote: > Hi David,
> >
> > From: Lance Bragstad <_lbragstad@gmail.com_
> <mailto:lbrags...@gmail.com>>
> > To: "OpenStack Development Mailing List (not for usage
> questions)"
> > <_openstack-dev@lists.openstack.org_
> <mailto:openstack-dev@lists.openstack.org>>
> > Date: 2015/08/04 01:49 PM
> > Subject: Re: [openstack-dev] [Keystone] [Horizon]
> Federated Login
> >
> >
>  

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 06/08/2015 00:54, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "David Lyle"  To: "OpenStack Development
>> Mailing List (not for usage questions)"
>>  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.math...@gmail.com > wrote:
>> 
>> 
>> 
>> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <
>> steve...@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

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "David Lyle" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 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.math...@gmail.com >
> wrote:
> 
> 
> 
> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli < steve...@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.chadw...@kent.ac.uk > wrote:
> 
> From: Dolph Mathews < dolph.math...@gmail.com >
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@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.chadw...@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 
> ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas > Fish
> < drf...@us.ibm.com > wrote: > Hi David, > > From: Lance Bragstad <
> lbrags...@gmail.com > > To: "OpenStack Development Mailing List (not for
> usage questi

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Lyle]

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

> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli 
> wrote:
>
>> Some folks said that they'd prefer not to list all associated idps, which
>> i can understand.
>>
> Why?
>
>>
>>
>> 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
>>
>> [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
>> PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick > Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David
>> Chadwick  wrote:
>>
>> From: Dolph Mathews 
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@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.chadw...@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 >Bragstad
>>> ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
>>> Fish <*drf...@us.ibm.com* > wrote: > Hi David,
>>>
>>> From: Lance Bragstad <*lbrags...@gmail.com* >
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <*openstack-dev@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 <_drf...@us.ibm.com_
>>> <mailto:*drf...@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_*
>>
>> <http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_>
>>>
>>>
>>>
>>> Doug Fish
>>>
>>>
>>  

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Dolph Mathews]

On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli 
wrote:

> Some folks said that they'd prefer not to list all associated idps, which
> i can understand.
>
Why?

>
>
> 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
>
> [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
> PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick  Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David
> Chadwick  wrote:
>
> From: Dolph Mathews 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@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.chadw...@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 > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
>    > Fish <*drf...@us.ibm.com* > wrote: > Hi David,
>>
>> From: Lance Bragstad <*lbrags...@gmail.com* >
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <*openstack-dev@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 <_drf...@us.ibm.com_
>> <mailto:*drf...@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_*
>
> <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.chadw...@kent.ac.uk_
>> <mailto:*d.w.chadw...@kent.ac.uk* >>
>wrote on 08/01/2015 06:01:48 AM:
>>
>> > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
>> <mailto:*d.w.chadw...@kent.ac.uk* >>
>> > To: OpenStack Development Mailing List
>> <_openstack-dev@lists.openstack.org_
>> <mailto:*openstack-dev@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 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Thai Q Tran]

<<< text/html; charset=UTF-8: Unrecognized >>>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Lance Bragstad]

On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli 
wrote:

> Some folks said that they'd prefer not to list all associated idps, which
> i can understand.
>
> Actually, I like jamie's suggestion of just making horizon a bit smarter,
> and expecting the values in the horizon settings (idp+protocol)
>

This *might* lead to a more complicated user experience, unless we deduce
the protocol for the IdP selected (but that would defeat the point?). Also,
wouldn't we have to make changes to Horizon every time we add an IdP? This
might be case by case, but if you're consistently adding Identity
Providers, then your ops team might not be too happy reconfiguring Horizon
all the time.


>
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
> PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick  Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David
> Chadwick  wrote:
>
> From: Dolph Mathews 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@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.chadw...@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 > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
>    > Fish <*drf...@us.ibm.com* > wrote: > Hi David,
>>
>> From: Lance Bragstad <*lbrags...@gmail.com* >
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <*openstack-dev@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 <_drf...@us.ibm.com_
>> <mailto:*drf...@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_*
>
> <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.chadw...@kent.ac.uk_
>> <mailto:*d.w.chadw...@kent.ac.uk* >>
>wrote on 08/01/2015 06:01:48 AM:
>>
>> > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
>> <mailto:*d.w.chadw...@kent.ac.uk* >>
>> > To: OpenStack Development Mailing List
>> <_openstack-dev@lists.openstack.org_
>> <m

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Steve Martinelli]

Some folks said that they'd prefer not to list all associated idps, which i
can understand.

Actually, I like jamie's suggestion of just making horizon a bit smarter,
and expecting the values in the horizon settings (idp+protocol)

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Dolph Mathews 
To: "OpenStack Development Mailing List (not for usage questions)"

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 
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  ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
  > Fish  wrote: > Hi David,
  >
  > From: Lance Bragstad 
  > To: "OpenStack Development Mailing List (not for usage questions)"
  > 
  > 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 <_drf...@us.ibm.com_
  > <mailto:drf...@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.chadw...@kent.ac.uk_
  >     <mailto:d.w.chadw...@kent.ac.uk>> wrote on 08/01/2015 06:01:48 AM:
  >
  >     > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
  >     <mailto:d.w.chadw...@kent.ac.uk>>
  >     > To: OpenStack Development Mailing List
  >     <_openstack-dev@lists.openstack.org_
  >     <mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe_
  >     <
  http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Dolph Mathews]

On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick 
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  > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
> > Fish  wrote: > Hi David,
> >
> > From: Lance Bragstad 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > 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 <_drf...@us.ibm.com_
> > <mailto:drf...@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.chadw...@kent.ac.uk_
> > <mailto:d.w.chadw...@kent.ac.uk>> wrote on 08/01/2015 06:01:48 AM:
> >
> > > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
> > <mailto:d.w.chadw...@kent.ac.uk>>
> > > To: OpenStack Development Mailing List
> > <_openstack-dev@lists.openstack.org_
> > <mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe_
> > <
> http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>_
> > __http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
> >
> >
> 

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

On 04/08/2015 17:51, Lin Hua Cheng wrote:
> Hi David,
> 
> There was a similar effort in Kilo to design the flow in the login page
> for federated login[1].   WebSSO feature[2] was implemented in Kilo, it
> allows the user to perform federated login by selecting an IdP
> protocol.  This have tested with kerberos and saml2.  

This is not a very user friendly thing to do. Users typically have no
idea what a federation protocol is, and wont know which one to select.
They will however know which organisation (IdP) they are associated with
and can use for federated login. We have been following the best
practice guide available here

https://discovery.refeds.org/guide/

> 
> There is a proposal to extend that feature to show listing per
> Idp/Protocol instead [3], because just listing only by protocol is
> fairly limited . 

Our intention is to list by organisation/IdP only and not to mention the
protocol to the user, since it is meaningless to him. Horizon can work
the protocol out itself and use the correct one, without burdening the
user with extra mental effort that will only confuse, frustrate and distress


> 
> I think the Type Ahead can fit it nicely when we implement the support
> for WebSSO by IdP/Protocol.

Agreed, type ahead was introduced after many years of simple listing,
since once federation grew to any appreciable size, the listing became
unusable.

regards

David

> 
> thanks,
> Lin
> 
> [1] https://openstack.invisionapp.com/d/main#/projects/2784587
> [2] http://docs.openstack.org/developer/keystone/extensions/websso.html
> [3] https://review.openstack.org/#/c/199339/
> 
> 
> https://review.openstack.org/#/c/199339/
> 
> On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick  > wrote:
> 
> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

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

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  ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
> Fish  wrote: > Hi David,
> 
> From: Lance Bragstad 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> 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 <_drf...@us.ibm.com_
> <mailto:drf...@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.chadw...@kent.ac.uk_
> <mailto:d.w.chadw...@kent.ac.uk>> wrote on 08/01/2015 06:01:48 AM:
> 
> > From: David Chadwick <_d.w.chadw...@kent.ac.uk_
> <mailto:d.w.chadw...@kent.ac.uk>>
> > To: OpenStack Development Mailing List
> <_openstack-dev@lists.openstack.org_
> <mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe_
> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_
> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Jamie

On 05/08/2015 00:46, Jamie Lennox wrote:
> 
> 
> - Original Message -
>> From: "Steve Martinelli"  To: "OpenStack
>> Development Mailing List (not for usage questions)"
>>  Sent: Wednesday, August 5, 2015
>> 3:59:34 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
>> Federated Login
>> 
>> 
>> 
>> 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.
>> 
>> Thanks,
> 
> Is there a real requirement here for this to be a dynamic listing

Yes. As the size of federations increase, then dynamic listing is the
only sensible approach otherwise you will be reconfiguring Horizon every
day. In the worldwide academic community (EduGain) we already have
hundreds of IdPs.

 as
> opposed to something that can be edited from the horizon
> local_settings? There are obvious use cases for both situations where
> you want this to be dynamic or you very carefully want to protect
> which IdPs are available to log in with and from that perspective it
> would be a very unusual API for keystone to have.

We discussed this many months back and two approaches were proposed then

a) alter the policy that currently controls the API that lists IdPs to
allow 'public access' to be a policy option. The current policy engine
does not support 'public access', but only 'anyone who has been
authenticated', and this is too restrictive for federated login where
the user has not yet been authenticated. In this way different sites can
configure their policy to give public access to IdPs or not.
b) edit the list of IdPs to say whether they are publicly accessible or
not, and create a new publicly accessible API that lists only the public
IdPs. Horizon can then be configured to call either the public list of
IdPs or all IdPs, since Horizon is an authenticated user.

I thought that option b) had been chosen as the preferred approach, but
I don't know whether it was implemented or not. If it has been, then I
don't see what extra functionality is needed

regards

David
> 
> My understanding of the current websso design where we always logged
> in via /v3/OS-FEDERATION/auth/websso/{protocol} was so that you would
> run a discovery page on that address that allowed you to customize
> which IdPs you exposed outside of keystone. Personally i don't like
> this which is what i wrote this spec[1] was for. However my intention
> there would have been to manually specify in the local_settings what
> IdPs were available and reuse the current horizon WebSSO drop down
> box.
> 
> Jamie
> 
> 
> [1] https://review.openstack.org/#/c/199339/
> 
> 
>> Steve Martinelli OpenStack Keystone Core
>> 
>> Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at
>> 10:52 AM, Douglas Fish  wrote: > Hi David,
>> 
>> From: Lance Bragstad  To: "OpenStack
>> Development Mailing List (not for usage questions)" 
>>  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 < drf...@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.chadw...@kent.ac.uk > wrote on 08/01/2015
>> 06:01:48 AM: > From: David Chadwick < d.w.chadw...@kent.ac.uk > >
>> To: OpenStack Development Mailing List <
>> openstack-dev@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 > > Al

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Jamie Lennox]

- Original Message -
> From: "Steve Martinelli" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Wednesday, August 5, 2015 3:59:34 AM
> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
> 
> 
> 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.
> 
> Thanks,

Is there a real requirement here for this to be a dynamic listing as opposed to 
something that can be edited from the horizon local_settings? There are obvious 
use cases for both situations where you want this to be dynamic or you very 
carefully want to protect which IdPs are available to log in with and from that 
perspective it would be a very unusual API for keystone to have. 

My understanding of the current websso design where we always logged in via 
/v3/OS-FEDERATION/auth/websso/{protocol} was so that you would run a discovery 
page on that address that allowed you to customize which IdPs you exposed 
outside of keystone. Personally i don't like this which is what i wrote this 
spec[1] was for. However my intention there would have been to manually specify 
in the local_settings what IdPs were available and reuse the current horizon 
WebSSO drop down box.

Jamie 


[1] https://review.openstack.org/#/c/199339/  


> Steve Martinelli
> OpenStack Keystone Core
> 
> Lance Bragstad ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM,
> Douglas Fish  wrote: > Hi David,
> 
> From: Lance Bragstad 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> 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 < drf...@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.chadw...@kent.ac.uk > wrote on 08/01/2015
> 06:01:48 AM: > From: David Chadwick < d.w.chadw...@kent.ac.uk > > To:
> OpenStack Development Mailing List < openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Steve Martinelli]

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.

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Lance Bragstad 
To: "OpenStack Development Mailing List (not for usage questions)"

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  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  wrote on 08/01/2015 06:01:48 AM:

  > From: David Chadwick 
  > To: OpenStack Development Mailing List
  
  > 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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Lance Bragstad]

On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish  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  wrote on 08/01/2015 06:01:48 AM:
>
> > From: David Chadwick 
> > To: OpenStack Development Mailing List
> 
> > 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Lin Hua Cheng]

Hi David,

There was a similar effort in Kilo to design the flow in the login page for
federated login[1].   WebSSO feature[2] was implemented in Kilo, it allows
the user to perform federated login by selecting an IdP protocol.  This
have tested with kerberos and saml2.

There is a proposal to extend that feature to show listing per Idp/Protocol
instead [3], because just listing only by protocol is fairly limited .

I think the Type Ahead can fit it nicely when we implement the support for
WebSSO by IdP/Protocol.

thanks,
Lin

[1] https://openstack.invisionapp.com/d/main#/projects/2784587
[2] http://docs.openstack.org/developer/keystone/extensions/websso.html
[3] https://review.openstack.org/#/c/199339/


https://review.openstack.org/#/c/199339/

On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick 
wrote:

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Doug

On 04/08/2015 16:52, Douglas Fish wrote:
> Hi David,
> 
> This is a cool looking UI. I've made a minor comment on it in InVision.

thanks

> 
> I'm curious if this is an implementable idea 

It has to be, since there are many existing federations with 100s of
IDPs. Simply displaying a list is not usable in this environment.
There are many SPs that implement this sort of interface today. Eg. the
UK Access Management federation has hundreds of members, see

http://www.ukfederation.org.uk/content/Documents/MemberList


- does keystone support large
> numbers of 3rd party idps?

It should. I dont know of anyone who has done scalability testing, but I
dont think the design has any inbuilt constraints

 is there an API to retreive the list of idps

yes

or
> does this require carefully coordinated configuration between Horizon and
> Keystone so they both recognize the same list of idps?

No, Horizon uses the Keystone API

regards
David

> 
> Doug Fish
> 
> 
> David Chadwick  wrote on 08/01/2015 06:01:48 AM:
> 
>> From: David Chadwick 
>> To: OpenStack Development Mailing List
> 
>> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Douglas Fish]

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?

Doug Fish


David Chadwick  wrote on 08/01/2015 06:01:48 AM:

> From: David Chadwick 
> To: OpenStack Development Mailing List

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev