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