Open Stack

Hi Jamie

On 05/08/2015 00:46, Jamie Lennox wrote:
> 
> 
> ----- Original Message -----
>> From: "Steve Martinelli" <stevemar at ca.ibm.com> To: "OpenStack
>> Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org> 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 <drfish at us.ibm.com> wrote: > Hi David,
>> 
>> From: Lance Bragstad <lbragstad at gmail.com> To: "OpenStack
>> Development Mailing List (not for usage questions)" 
>> <openstack-dev at lists.openstack.org> Date: 2015/08/04 01:49 PM 
>> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish < drfish at us.ibm.com >
>> wrote:
>> 
>> Hi David, This is a cool looking UI. I've made a minor comment on
>> it in InVision. I'm curious if this is an implementable idea - does
>> keystone support large numbers of 3rd party idps? is there an API
>> to retreive the list of idps or does this require carefully
>> coordinated configuration between Horizon and Keystone so they both
>> recognize the same list of idps? There is an API call for getting a
>> list of Identity Providers from Keystone
>> 
>> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers
>>
>>
>>
>>
>> 
Doug Fish David Chadwick < d.w.chadwick at kent.ac.uk > wrote on 08/01/2015
>> 06:01:48 AM: > From: David Chadwick < d.w.chadwick at kent.ac.uk > >
>> To: OpenStack Development Mailing List <
>> openstack-dev at lists.openstack.org > > Date: 08/01/2015 06:05 AM >
>> Subject: [openstack-dev] [Keystone] [Horizon] Federated Login > >
>> Hi Everyone > > I have a student building a GUI for federated login
>> with Horizon. The > interface supports both a drop down list of
>> configured IDPs, and also > Type Ahead for massive federations
>> with hundreds of IdPs. Screenshots > are visible in InVision here >
>> > https://invis.io/HQ3QN2123 > > All comments on the design are
>> appreciated. You can make them directly > to the screens via
>> InVision > > Regards > > David > > > > 
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions) >
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > 
>> __________________________________________________________________________
>>
>> 
OpenStack Development Mailing List (not for usage questions) Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> __________________________________________________________________________
>>
>> 
OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> __________________________________________________________________________
>>
>> 
OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>