<div dir="ltr"><span class="Apple-style-span" style="border-collapse: collapse; "><div>>> I can't find the page you're referring to</div><div>Well that's another data point on the usability of our login UI :-)</div>
<div><br></div><div>But seriously, go to <a href="http://www.google.com/a">www.google.com/a</a> (note the /a) at the end. Then in the top right, click "Returning user, sign in here." User's then enter their domain name, and pick a destination page.</div>
<div><br></div><div>>> Did you experiment with this further? Some data would be really useful.</div><div>That UI is live, and as you found yourself, it is hard to use. What we have found in practice is that user's have to start at their IDP's website, and click a link that takes them to our site with a URL parameter that indicates the domain of the IDP.</div>
<div><br></div><div>We have another live example you can look at. Try this URL:</div><div> <a href="http://sites.google.com/a/alertblue.com/testui/">http://sites.google.com/a/alertblue.com/testui/</a></div></span><div>That URL is for a webpage created by an enterprise whose email Google hosts on our AppsForYourDomain offering. But the owner of that site has allowed some people outside their enterprise to access this webpage. So when a user visits that webpage, they might be one of three types of users:</div>
<div> - An employee of that enterprise</div><div> - An employee of a different enterprise that uses AppsForYourDomain (and which might run its own IDP that authenticates users to Google via SAML)</div><div> - A consumer user with a regular Google Account that the user established manually</div>
<div>We are experimenting with different login UIs for this page, so you might see different versions.</div><br><div class="gmail_quote">On Tue, Oct 14, 2008 at 11:47 AM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
Eric,<div><div><div class="Ih2E3d"><br><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Nick, I may have missed it in this thread, but did you indicate which UI options are working better then others for your users?</span></blockquote>
<div><br></div></div><div>As I mentioned, we've found no single best UI. Drag-down lists that set long-lived cookies on selection are by far the most pervasive. You can see a basic example at the demo resource linked here:</div>
<div><br></div><div><a href="http://www.switch.ch/aai/demo/" target="_blank">http://www.switch.ch/aai/demo/</a></div><div class="Ih2E3d"><br><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
I have only talked to a few RPs with a similar situation to your own, and the most common approach was to split the login process into two steps, where the first page asks for the identity provider (which might even be the local website), and then the user is redirected to their IDP's authentication page. However a key change was removing the password field completely from the first page, otherwise many users do mistakenly type their IDP's password there.</div>
</span></blockquote><div><br></div></div><div>Yes, this has been our traditional approach. I'm glad you've encountered a few RP's that have a similar use pattern; they're quite common in our experience.</div>
<div class="Ih2E3d"><br><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
In fact, if you go to<span> </span><a href="http://www.google.com/a" target="_blank">www.google.com/a</a><span> </span>you'll see we use that approach for our GoogleAppsForYourDomain service. The first login page can then include buttons/dropdowns/selectors for IDPs, as well as a text entry box for a user to just enter the domain name of their IDP (and try to using any other hints from the browser or browser history to suggest the IDP).</div>
</span></blockquote><div><br></div></div><div>I can't find the page you're referring to, but yes, we've experimented with text entry boxes where the user is asked for their domain. It's supported in a few ways in our standard distribution. However, it's not used often because our users have no concept of domains and questions such as "What is the right half of your email address?" or "Where is your university's homepage?" are confusing. You mention that in your own summary, in fact.</div>
<div><br></div><div>Did you experiment with this further? Some data would be really useful.</div><div class="Ih2E3d"><br><blockquote type="cite"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>
In terms of Google's research (and I believe Yahoo's) we were focused on sites that had specifically chosen not to implement federated login because of usability problems. I don't expect those UI guidelines to work for every website, especially for websites who have decided to deploy federated login for other reasons (like the ones you listed), and are willing to use a more complex UI. And those UI guidelines are complete overkill for a website who is willing to just use a single IDP and completely eliminate its own legacy login system.</div>
</span></blockquote></div></div><br></div><div>For such a site leveraging Shibboleth, our guidelines suggest an immediate redirect to the associated IdP. The trust fabric and protocols under the hood are still federated. I disagree with John: I see two distinct advantages to that. You only need to support one set of protocols and software, and if you do choose to open up your site to users from other IdP's someday, your identity system doesn't need to change.</div>
<div><br></div><div>Take care,</div><div>Nate.</div></div></blockquote></div><br></div>