Open Stack

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