Federation User Experience

Probably the most difficult aspect of federation is producing a good user experience. With many applications, the use of SSO or externalized authentication from even one source can introduce user interface complexity. Federation adds additional considerations that can easily lead to a bad or confusing experience.

Complicating this issue, applications leverage federation in very different ways, and the lack of experience with the technology has led us down a number of dead (or at least suboptimal) ends that have left deployers with a lot of choices and confusing advice over the last decade.

Elements of the User Experience

Services share a mostly common set of user experience elements with respect to federation, even though there are specific considerations (or entire elements missing) in some cases.

• Initiating the Login Process
• Discovery of the IdP
• Login at the IdP
• User Consent (sometimes)
• Success or Failure

We elaborate on these steps below, but the overarching principle to be understood is consistency, in two senses.

First, consistency across services: studies have shown that the lack of consistency across SPs is the single biggest source of confusion for users. People can accomodate fairly ugly workflows if they're familiar ones, but even simple workflows that are "new" create barriers. This is something that can be difficult to convince application owners, who frequently think they have a special need to be different or stand-out. Experience suggests that approach will incur costs in user training and user avoidance, and federation is often a scapegoat.

Second, consistency of "story" throughout the process. Evidence suggests that users react best when the transition between steps of the process maintains a degree of consistency with respect to language and presentation. Users want the context of the overall action (logging into the SP from the IdP) to be clear at each step. If the UI changes in a jarring way, and/or lacks a visual and textual reference back to the overall goal/activity, they get confused and lost more easily. A number of new software features and federation initiatives (e.g., User Interface Elements) relate to this need, so we know improvement will be gradual.

Initiating Login

Sites have demonstrated a substantial degree of "creativity" in presenting users with the option of federated login. This is defensible because of the wide array of "starting points". Some applications are starting from scratch, but most have preexisting mechanisms, often many, that have to be supported at the same time. The trap, however, is that treating federation as a secondary (or worse) option is a self-fulfilling prophecy. Federation will always compare poorly to an integrated login experience by number of clicks, steps, etc. But users aren't counting clicks; they just want it to be obvious what to do.

The solution advocated here is a consistent experience of one discrete "Login" link, button, etc. in the upper right hand corner of a site. Login options that involve user interaction (e.g., not IP-based methods) should be accessible through that one starting point, with the user indicating what method to use through a "discovery" process (the next step). It is important, both for security and consistency reasons, that "local" login options, however prevalent, be presented on an equal footing to federated options.

Discovery

The bane of federation historically has been the need for user selection of the IdP to use, something that is largely unknown to single-domain authentication, with a few minor exceptions (e.g., selecting a login domain on a Windows desktop). In the past, progress was stunted by an overemphasis on avoiding discovery, using cookies to minimize the number of times users would encounter it, and a lack of good tools for implementing scalable approaches to the problem.

Deep Linking

First, one must note that there are scenarios in which discovery can be avoided. In particular, there are applications that, while federated, are designed as a silo in which access to the system self-determines the IdP to use. This is common in outsourced/hosted scenarios. The IdP can be implicit based on the URL (hostname or path). In other cases, access to the application requires users to start at a link that initiates the login process from the IdP side.

While superficially elegant, this is a model to avoid (or at least not use exclusively) if there is ever a possibility that the same resources will be shared by users from different organizations. The inability to directly address resources in an authentication-neutral way with a single URL is a limitation that will frustrate users deeply. So-called deep linking isn't just a good idea; it's the basis of the web. Mechanisms that bypass discovery are acceptable, but not to the exclusion of this capability.

General Guidelines

Earlier it was suggested that all login mechanisms be offered behind a single entry point. The Discovery interface is that entry point; the user should be presented with an interface to select from among all the possible login mechanisms, including federated IdPs. This interface can be presented as an "overlay" or pop-up that supplants, without replacing, the underlying application. Alternatively, a traditional "full page" interface can replace the application, allowing for more room and fewer accessibility challenges.

In either case, the UI should remain as consistent with the originating application as possible (colors, styles, etc.). If the UI replaces that of the service, the UI should reference the service via a descriptive name, icon, URL, etc. This provides the user with context for the selection of a login mechanism or IdP. When implemented separately from the service itself, SPUIElements in federation metadata can supply the UI with this information.

As an interface, discovery should be minimal, focused on the task at hand. Past selections, as well as common or predominant choices, should be offered prominently at the top for easy selection. For example, an application used mostly by users from one organization can offer that choice by default to all users to make selection easy for the widest audience. It also makes sense to directly offer options that don't lend themselves to easy identification by the user (e.g., local accounts). However, do not assume that a previous choice is the only choice; give the user the chance to select it again, or make a different one; this is essential when mistakes are made or shared machines are used.

Other choices (i.e., the "rest") should be selectable primarily through a dynamic search text box, akin to most search engines. This scales well and is simple to use provided the user can enter a variety of terms, such as geography, organization names, mascots/brands, etc. If implemented consistently, one successful "find" is sufficient to teach a user how to find their choice somewhere else. When multiple results are found and displayed, tool tip popups containing more extensive descriptive text can be used to disambiguate like-named choices. Icons can also be used in some cases. IdPUIElements provided in federation metadata can help supply the UI with this information.

While it is attractive to present "a complete list of options", bear in mind that this limits the scalability of the service. This may be appropriate for services that limit the number of IdPs they support, but is not suitable for "promiscuously" federated services that want to support the widest number of choices they can. Design for success, not failure.

It may be appropriate to leverage information about the client, such as IP address or geolocation data, as hints to aid discovery (e.g., to determine a default set of choices to favor). Hints work well, just not as a replacement for explicit user search/selection.

Finally, the UI should include a link or button to explanatory information about the purpose of the process and how to search, as well as a way for the user to signal "no choice" and return to the application. There should be no "dead ends".

The Boarding Problem

In the context of discovery, a brief word on the implications of privacy on federation. Traditionally, most IdPs take an active stance with respect to user privacy, to the point that releasing information to SPs outside of explicit agreements is rare. An exception to this approach is one of "consent" (discussed later in more detail), allowing users to opt-in to release of data. This is uncommon today, but is likely to be more common in the future.

The upshot is that today, the general case is that any given IdP is unlikely to "just work" if selected by a user accessing a service unknown to the operators of the IdP. This leads to one of two conclusions:

• Discovery should only make available IdPs that are known or reasonably expected to work.
• Discovery should make any trusted/acceptable IdP available, leaving the application to handle the case of privacy controls preventing success.

Historically, the first option was considered more attractive, because it unburdens applications from some additional error handling. In practice, the need to "board" IdPs to get them added to the Discovery list by proving successful use created much more work for deployers than error handling would. It also confused users by creating "dead ends" that failed to offer them expected choices, depending on the service being accessed. This lack of consistency, recall, has been highlighted as a problem.

Therefore, the second choice, one of asking "forgiveness" rather than permission seems the better option. The cost is that applications (or one's federation software) MUST handle the case of insufficient data to obtain access in a manner that is acceptable to users. This does not mean giving them a list of technical information and asking them to fix the problem (they can't and won't).

Rather, each IdP needs to supply a contact to which users can be directed to send a simple link to technical information to resolve the issue. One might even automate the process via an SP-generated email to the contact when failed attempts occur. In federation metadata, the "administrative" contact type is suggested for this purpose.

Mistakes were Made

Historically, discovery used to be handled by a stand-alone application, often called a "WAYF", containing lists of IdPs limited to single federations like InCommon. The big advantage to this approach is the sharing of a cookie to remember selections on behalf of multiple SPs. This is a hugely overblown feature that is undercut by structural failings. Limiting user choice by federation rarely addresses the requirements of most services. Selection of IdPs was frequently based on a drop-down list, which is not scalable.

A more subtle failing is that the choice of IdP became available only after reaching the WAYF screen via an option with no good label: federated login? InCommon? Shibboleth? None are understandable, and the extra click to get there undermines the advantage of the cookie. It's not workable.

Login at the IdP

User Consent

Outcome