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

David Lyle dklyle0 at gmail.com
Wed Aug 5 19:52:40 UTC 2015


Forcing Horizon to duplicate Keystone settings just makes everything much
harder to configure and much more fragile. Exposing whitelisted, or all,
IdPs makes much more sense.

On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

> On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli <stevemar at ca.ibm.com>
> wrote:
>
>> Some folks said that they'd prefer not to list all associated idps, which
>> i can understand.
>>
> Why?
>
>>
>>
>> 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 <d.w.chadwic]Dolph
>> Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David
>> Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>
>> From: Dolph Mathews <dolph.mathews at gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> Date: 2015/08/05 01:38 PM
>> Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
>> ------------------------------
>>
>>
>>
>>
>> On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick <*d.w.chadwick at kent.ac.uk*
>> <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* <drfish at us.ibm.com>> wrote: > Hi David,
>>    >
>>    > From: Lance Bragstad <*lbragstad at gmail.com* <lbragstad at gmail.com>>
>>    > To: "OpenStack Development Mailing List (not for usage questions)"
>>    > <*openstack-dev at lists.openstack.org*
>>    <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* <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_*
>>    <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* <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* <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*
>>    <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_* <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>    >
>>    >     > _
>>    *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_*
>>    <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>    >_
>>    >     __
>>    *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_*
>>    <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*
>>    <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*
>>    <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*
>>    <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150805/98a146b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150805/98a146b7/attachment.gif>


More information about the OpenStack-dev mailing list