This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list.
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.
Categorizing Services
Consider what kind of service you are deploying before making decisions about the UI.
Broadly speaking, we can divide up the application space into a few categories with regard to the use of federation:
Outsourced silos.
These are applications that are hosted by a third party, but essentially targeted at a single organization that would have otherwise hosted it internally. Generally a formal contract exists, and each instance of the application is tied to a single IdP. Non-public resources within the silo are not available to users from other organizations (at least by direct means) The release of information to the SP is an explicit policy set up in advance by the IdP.
iTunesU, while not really an outsourced application in the usual sense, is architected as a silo of this sort.
Services with broad, organizational access restrictions.
Typically there is a single application which users from multiple organizations access directly (thus differing from the silo case above). Because access is restricted on an organizational level, based on organizational affiliation or similar attributes, the release of information by the IdP is usually contractual as in the silo case, and can be set up explicitly.
Library resources are an example of this kind of service. Note that anonymity is not an assumption here, though we tend to think in those terms for many library use cases. For our purposes, it's the general model that matters, not anonymity.
Relatively open, widely federated systems.
These are sometimes called "contract-less" because there is generally no formal agreement between the SP and its IdPs. Rather it's the users of the service who may have a relationship with it. These applications want to present a common access path for all users, regardless of their "home" organization, want to allow for a large and dynamic set of IdPs, and provide access to the same resources to users from different organizations.
This is the "extreme" of federation, and is essentially the use case that OpenID and its successors try to fill, in part because SAML implementations were geared toward the other types of applications.
Elements of the User Experience
All of the categories of services one could develop 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. Studies show 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
Best Practice
- Use a "Login" link or button in the upper right corner of a site.
- Avoid cluttering the main application screen with choices of different login mechanisms.
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 we advocate 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.