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

David Chadwick d.w.chadwick at kent.ac.uk
Thu Aug 6 08:56:59 UTC 2015



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 <lbragstad at gmail.com>
>     To: "OpenStack Development Mailing List (not for usage questions)"
>     <openstack-dev at lists.openstack.org>
>     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
>     <stevemar at ca.ibm.com <mailto:stevemar at 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
>         <d.w.chadwicDolph Mathews ---2015/08/05 01:38:09 PM---On Wed,
>         Aug 5, 2015 at 5:39 AM, David Chadwick <d.w.chadwick at kent.ac.uk
>         <mailto:d.w.chadwick at kent.ac.uk>> wrote:
> 
>         From: Dolph Mathews <dolph.mathews at gmail.com
>         <mailto:dolph.mathews at gmail.com>>
>         To: "OpenStack Development Mailing List (not for usage
>         questions)" <openstack-dev at lists.openstack.org
>         <mailto:openstack-dev at lists.openstack.org>>
>         Date: 2015/08/05 01:38 PM
>         Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
> 
>         ------------------------------------------------------------------------
> 
> 
> 
> 
>         On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick
>         <_d.w.chadwick at kent.ac.uk_ <mailto:d.w.chadwick at kent.ac.uk>> wrote:
> 
> 
> 
> 
>           *   On 04/08/2015 18:59, Steve Martinelli wrote:
>             > Right, but that API is/should be protected. If we want to
>             list IdPs
>             > *before* authenticating a user, we either need: 1) a new
>             API for listing
>             > public IdPs or 2) a new policy that doesn't protect that API.
> 
>             Hi Steve
> 
>             yes this was my understanding of the discussion that took
>             place many
>             months ago. I had assumed (wrongly) that something had been
>             done about
>             it, but I guess from your message that we are no further
>             forward on this
>             Actually 2) above might be better reworded as - a new
>             policy/engine that
>             allows public access to be a bona fide policy rule
> 
> 
>         The existing policy simply seems wrong. Why protect the list of
>         IdPs?
>          
> 
> 
>           * regards
> 
>             David
> 
>             >
>             > Thanks,
>             >
>             > Steve Martinelli
>             > OpenStack Keystone Core
>             >
>             > Inactive hide details for Lance Bragstad ---2015/08/04
>             01:49:29 PM---On
>             > Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish
>             <drfish at us.iLance Bragstad
>             > ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52
>             AM, Douglas
>             > Fish <_drfish at us.ibm.com_ <mailto:drfish at us.ibm.com>>
>             wrote: > Hi David,
>             >
>             > From: Lance Bragstad <_lbragstad at gmail.com_
>             <mailto:lbragstad at gmail.com>>
>             > To: "OpenStack Development Mailing List (not for usage
>             questions)"
>             > <_openstack-dev at lists.openstack.org_
>             <mailto:openstack-dev at lists.openstack.org>>
>             > Date: 2015/08/04 01:49 PM
>             > Subject: Re: [openstack-dev] [Keystone] [Horizon]
>             Federated Login
>             >
>             >
>             ------------------------------------------------------------------------
>             >
>             >
>             >
>             >
>             >
>             > On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish
>             <_drfish at us.ibm.com_
>             > <mailto:_drfish at us.ibm.com_ <mailto:drfish at us.ibm.com>>>
>             wrote:
>             >
>             >     Hi David,
>             >
>             >     This is a cool looking UI. I've made a minor comment
>             on it in InVision.
>             >
>             >     I'm curious if this is an implementable idea - does
>             keystone support
>             >     large
>             >     numbers of 3rd party idps? is there an API to retreive
>             the list of
>             >     idps or
>             >     does this require carefully coordinated configuration
>             between
>             >     Horizon and
>             >     Keystone so they both recognize the same list of idps?
>             >
>             >
>             > There is an API call for getting a list of Identity
>             Providers from Keystone
>             >
>             >
>             __http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers__
>             >
>             >
>             >
>             >     Doug Fish
>             >
>             >
>             >     David Chadwick <_d.w.chadwick at kent.ac.uk_
>             >     <mailto:_d.w.chadwick at kent.ac.uk_
>             <mailto:d.w.chadwick at kent.ac.uk>>> wrote on 08/01/2015
>             06:01:48 AM:
>             >
>             >     > From: David Chadwick <_d.w.chadwick at kent.ac.uk_
>             >     <mailto:_d.w.chadwick at kent.ac.uk_
>             <mailto:d.w.chadwick at kent.ac.uk>>>
>             >     > To: OpenStack Development Mailing List
>             >     <_openstack-dev at lists.openstack.org_
>             >     <mailto:_openstack-dev at lists.openstack.org_
>             <mailto:openstack-dev at lists.openstack.org>>>
>             >     > Date: 08/01/2015 06:05 AM
>             >     > Subject: [openstack-dev]  [Keystone] [Horizon]
>             Federated Login
>             >     >
>             >     > Hi Everyone
>             >     >
>             >     > I have a student building a GUI for federated login
>             with Horizon. The
>             >     > interface supports both a drop down list of
>             configured IDPs, and also
>             >     > Type Ahead for massive federations with hundreds of
>             IdPs. Screenshots
>             >     > are visible in InVision here
>             >     >
>             >     > __https://invis.io/HQ3QN2123__
>             >     >
>             >     > All comments on the design are appreciated. You can
>             make them directly
>             >     > to the screens via InVision
>             >     >
>             >     > Regards
>             >     >
>             >     > David
>             >     >
>             >     >
>             >     >
>             >     >
>             >   
>              __________________________________________________________________________
>             >     > OpenStack Development Mailing List (not for usage
>             questions)
>             >     > Unsubscribe:_
>             >   
>              ___OpenStack-dev-request at lists.openstack.org?subject:unsubscribe__
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>
>             >   
>              <_http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>
>             >     >
>             __http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
>             >     >
>             >
>             >
>             >   
>              __________________________________________________________________________
>             >     OpenStack Development Mailing List (not for usage
>             questions)
>             >     Unsubscribe:
>             >   
>              __OpenStack-dev-request at lists.openstack.org?subject:unsubscribe__
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>
>             >   
>              <_http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_>_
>             >   
>              ___http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
>             >
>             >
>             __________________________________________________________________________
>             > OpenStack Development Mailing List (not for usage questions)
>             > Unsubscribe:
>             _OpenStack-dev-request at lists.openstack.org?subject:unsubscribe_
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             >
>             _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
>             >
>             >
>             >
>             >
>             >
>             __________________________________________________________________________
>             > OpenStack Development Mailing List (not for usage questions)
>             > Unsubscribe:
>             _OpenStack-dev-request at lists.openstack.org?subject:unsubscribe_
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             >
>             _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
>             >
> 
>             __________________________________________________________________________
>             OpenStack Development Mailing List (not for usage questions)
>             Unsubscribe:
>             _OpenStack-dev-request at lists.openstack.org?subject:unsubscribe_
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             _http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_
> 
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>          
> 
>          
> 
> 
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>          
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>  
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list