I think this GUI is not intuitive to users and therefore should not be
encouraged or supported.

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.

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

regards

David

On 18/02/2015 16:06, Dolph Mathews wrote:
> 
> On Fri, Feb 6, 2015 at 12:47 PM, Adam Young <ayo...@redhat.com
> <mailto:ayo...@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-requ...@lists.openstack.org?subject:unsubscribe 
>> <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>     <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to