[openstack-dev] [horizon][keystone]

Adam Young ayoung at redhat.com
Mon Feb 23 19:00:34 UTC 2015


On 02/23/2015 11:19 AM, David Chadwick wrote:
> Hi Adam
>
> there is some work being done on this by HP, Intel and IBM, and they
> have some designs at
>
> http://invis.io
>
> pieter.c.kruithof-jr at hp.com  can send you the details as he invited me
> to comment on the designs, which I have done.
>
> As you know, we already have our own federated Horizon login screen, and
> this summer I am hoping to have another student integrate this into the
> current release, as well as make some enhancements to it (like
> type-ahead searching for IdPs)
>
> regards
>
> David
>
> On 23/02/2015 15:54, Adam Young wrote:
>> On 02/18/2015 12:02 PM, David Chadwick wrote:
>>> I think this GUI is not intuitive to users and therefore should not be
>>> encouraged or supported.
>> It is a fist hack.  I think you don't mean "any gui"  just that there
>> are some warning flags raised by this design?
>>
>>> If you ask a user "what does authenticate via a Discovery Service mean?"
>>> I think you will get some very strange answers. The same goes for
>>> "Authenticate using Default Protocol". Users will have no idea what that
>>> means.
>> He's not a native English speaker.  We'll need to craft the text here,
>> and also carefully review the nuances.  Then there are the international
>> translations....
>>
>>> There has been a lot of research into how to support federated
>>> authentication and there is a lot of practical experience across the
>>> academic world from dozens of countries for many years. Most
>>> universities now use federated login on a daily basis. We should use
>>> this experience and follow best practise (which sadly does not involve
>>> the screens that are being proposed here).
>>>
>>> If you want to read more you can read a Good Practice Guide here
>>>
>>> https://discovery.refeds.org/
>>>
>>> It should help you to redesign the login page
>> THanks for the links.  Very helpful.  Some of that might require some
>> changes from Horizon, but Jamie has seen those issues also come up in
>> the context of the Kerberos login, and we can work to make this a
>> smoother experience.
>>
>> David, we certainly could use some UX  feedback here. Unfortunately, my
>> GO-TO team member has decided to GO-TO a trip around the world...who can
>> we pull in to make this flow in with the rest of Horizon?

Thanks.  I tripped over the fact that both David Chadwick and David Lyle 
are very involved in the discussion, but the response shows that the 
unplanned is often the most valuable response.  Thanks

>>
>>
>>
>>> regards
>>>
>>> David
>>>
>>> On 18/02/2015 16:06, Dolph Mathews wrote:
>>>> On Fri, Feb 6, 2015 at 12:47 PM, Adam Young <ayoung at redhat.com
>>>> <mailto:ayoung at redhat.com>> wrote:
>>>>
>>>>       On 02/04/2015 03:54 PM, Thai Q Tran wrote:
>>>>>       Hi all,
>>>>>
>>>>>       I have been helping with the websso effort and wanted to get some
>>>>>       feedback.
>>>>>       Basically, users are presented with a login screen where they can
>>>>>       select: credentials, default protocol, or discovery service.
>>>>>       If user selects credentials, it works exactly the same way it
>>>>>       works today.
>>>>>       If user selects default protocol or discovery service, they can
>>>>>       choose to be redirected to those pages.
>>>>>
>>>>>       Keep in mind that this is a prototype, early feedback will be
>>>>> good.
>>>>>       Here are the relevant patches:
>>>>>       https://review.openstack.org/#/c/136177/
>>>>>       https://review.openstack.org/#/c/136178/
>>>>>       https://review.openstack.org/#/c/151842/
>>>>>
>>>>>       I have attached the files and present them below:
>>>>
>>>>       Replace the dropdown with a specific link for each protocol type:
>>>>
>>>>       SAML and OpenID  are the only real contenders at the moment, but we
>>>>       will not likely have so many that it will clutter up the page.
>>>>
>>>>
>>>> Agree, but the likelihood that a single IdP will support multiple
>>>> protocols is probably low. Keystone certainly supports that from an API
>>>> perspective, but I don't think it should be the default UX. Choose a
>>>> remote IdP first, and then if *that* IdP supports multiple federation
>>>> protocols, present them.
>>>>   
>>>>
>>>>       Thanks for doing this.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>> __________________________________________________________________________
>>>>>
>>>>>       OpenStack Development Mailing List (not for usage questions)
>>>>>       Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> <mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> __________________________________________________________________________
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list