Date: Fri, 29 Mar 2024 00:40:52 +0000 (UTC) Message-ID: <2114648607.7285.1711672852924@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7284_298124658.1711672852923" ------=_Part_7284_298124658.1711672852923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Probably the most difficult aspect of federation is producing a good use= r experience. With many applications, the use of SSO or externalized authen= tication from even one source can introduce user interface complexity. Fede= ration adds additional considerations that can easily lead to a bad or conf= using user experience.
Complicating this issue, applications leverage federation in very differ= ent ways, and the lack of experience with the technology has led us down a = number of dead ends (or at least suboptimal paths) that have left deployers= with a lot of choices and confusing advice over the last decade.
Note that the bulk of this material represents a "snapshot in time" base= d on the currently prevalent user interface metaphors and capabilities in w= ide use. Adjustments for mobile devices, lacking screen size or pointing de= vices, as well as for touch screen devices are inevitable. Some of the mate= rial reflects the limitations of such interfaces already.
Services share a mostly common set of user experience elements with resp= ect to federation, even though there are specific considerations (or entire= elements missing) in some cases.
We elaborate on these steps below, but the overarching principle to be u= nderstood is consistency, in two senses.
First, consistency across services: studies have shown that the lack of = consistency across SPs is the single largest 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 tha= t can be difficult to convince application owners, who frequently think the= y have a special need to be different or to stand out. Experience suggests = that such an approach incurs 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 mai= ntains a degree of consistency with respect to language and presentation. U= sers want the context of the overall action (logging into the SP from the I= dP) to be clear at each step. If the UI changes in a jarring way, and/or la= cks a visual and/or textual reference back to the overall goal/activity, th= ey 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.
Sites have demonstrated a substantial degree of "creativity" in presenti= ng users with the option of federated login. This is defensible because of = the wide array of "starting points". Some applications are starting from sc= ratch, but most have preexisting mechanisms, often numerous such mechanisms= , that have to be supported at the same time. The trap, however, is that tr= eating federation as a secondary (or worse) option is a self-fulfilling pro= phecy. Federation will always compare poorly to an integrated login experie= nce by number of clicks, steps, etc., but users aren't counting clicks, the= y just want it to be obvious what to do.
The solution advocated here is a consistent experience of one discrete "= Login" link in the upper right hand corner of a site. Login options that in= volve user interaction (e.g., not IP-based methods) should be accessible th= rough that one starting point, with the user indicating what method to use = through a "discovery" process (the next step). It is important, both for se= curity and consistency reasons, that "local" login options, however prevale= nt, be presented on an equal footing to federated options.
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 auth= entication, 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 implementin= g scalable approaches to the problem.
First, 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/domain or path). In other cases, access to the applicatio= n requires users to start at a link that initiates the login process from t= he IdP and "pushes" the client into the site.
While superficially elegant, this is a model to avoid (or at least not t= o use exclusively) if there is ever a possibility that the same resources w= ill be shared by users from different organizations. The inability to direc= tly 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 disco= very are acceptable, but not to the exclusion of this capability.
Earlier it was suggested that all login mechanisms be offered behind a s= ingle entry point. The discovery interface is that entry point; the user sh= ould be presented with an interface to select from among all the possible l= ogin 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 replac= e the application, allowing for more room and fewer accessibility challenge= s.
The discovery component may be part of the application or SP, or a separ= ate service. The former enables a more consistent UI experience (color, sty= le, etc.), while the latter enables work to be offloaded and shared by mult= iple services with identical or at least compatible discovery needs. In eit= her case, the UI should remain as consistent with the originating applicati= on as possible. If the UI replaces that of the service, the UI should refer= ence the service with some combination of 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, SP user interface elements= in federation metadata can supply the UI with this information.
As an interface, discovery should be minimal, focused on the task at han= d. Past selections, as well as common or predominant choices, should be off= ered prominently at the top for easy selection. For example, an application= used mostly by users from one organization can offer that choice by defaul= t to all users to make selection easy for the widest audience. It also make= s sense to directly offer options that don't lend themselves to easy identi= fication 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 a= gain, or make a different one; this is essential when mistakes are made or = shared machines are used, or when users have multiple accounts.
Other choices (i.e., the "rest") should be selectable primarily through = a dynamic search text box, akin to most search engines. This scales well an= d is simple to use provided the user can enter a variety of terms, such as = geography, organization names, mascots/brands, etc. If implemented consiste= ntly, one successful "find" is sufficient to teach a user how to find their= choice somewhere else. When multiple results are found and displayed, tool= tips containing more extensive descriptive text might be used to disambigu= ate like-named choices (but beware of mobile devices that don't support mou= seover events). Icons may also be used in some cases. IdP user interface elements i= n 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 appropria= te for services that limit the number of IdPs they support, but is not suit= able for "promiscuously" federated services that want to support the widest= number of choices possible. 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 determi= ne a default set of choices to favor). Hints work well, just not as a repla= cement for explicit user search/selection.
Finally, the UI should include a link to explanatory information about t= he 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 "de= ad ends."
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 "cons= ent" (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 fut= ure.
The upshot is that today, the general case is that any given IdP is unli= kely to "just work" if selected by a user accessing a service unknown to th= e operators of the IdP. This leads to one of two conclusions:
Historically, the first option was considered more attractive, because i= t 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 wo= uld. It also confused users by creating "dead ends" that failed to offer th= em 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 pe= rmission seems the better option. The cost is that applications (or one's f= ederation software) MUST handle the case of insufficient d= ata to obtain access in a manner that is acceptable to users. This is discu= ssed in more detail in the Outcome section below.
In parallel, it is critical for IdPs to address the problem of defining = an effective and accessible Attribute Release Process.
Historically, discovery used to be handled by a stand-alone application,= often called a "WAYF", containing lists of IdPs limited to single federati= ons like InCommon. The big advantage to this approach is simplicity for SPs= , and the sharing of a cookie to remember selections on behalf of multiple = SPs. The latter is a hugely overblown feature that is undercut by structura= l failings. Limiting the choice of IdP to one federation rarely addresses t= he requirements of most services; often the limitation was a consequence of= this approach to discovery rather than any inherent decision to do so by t= he service.
A more subtle failing is that the choice of IdP became available only af= ter reaching the WAYF screen via an option with no good label: federated lo= gin? InCommon? Shibboleth? None are understandable by the poor end user.
The user interface of the IdP is not for the most part within the reach = of standardization, but one can apply lessons learned to achieve a better, = more consistent approach that will feel more natural to users. The most ess= ential point is that the "story" of the login be maintained by identifying = the service involved using a name, descriptive text, an icon, etc. SP user interface el= ements in federation metadata can supply the UI with this information.<= /p>
Another consideration is that reducing phishing is best achieved by ensu= ring the IdP page is visible within a complete browser window so that SSL-p= rotected location information can be verified by the user (no laughter plea= se, it's still the right thing to do).
For an IdP to be broadly useful, the decision whether to allow authentic= ation to proceed and particular attributes be released must be automated in= some fashion, rather than in the hands of university staff. One popular me= chanism is to add an interface to collect the user's consent to the transac= tion before allowing it. There is likely to be substantial variability in c= onsent UI in the near term, but there are some obvious general principles t= hat are likely to emerge.
In keeping with earlier recommendations, a consent UI must identify the = service receiving the information. SP user interface elements in federation metadata= can supply the UI with this information, including links to privacy polici= es that are obviously relevant to the act of consent.
Common sense also dictates that users need to clearly understand what th= ey're consenting to. Keeping the text to a minimum, and avoiding overly tec= hnical descriptions of attributes that won't make sense to most users is im= portant.
For some IdPs, it may be sufficient for some users to merely offer a gen= eric "terms of use" agreement asking for permission to release a typical se= t of information to SPs that guarantee appropriate protection and use of th= e information. This is much less technically complex to deploy.
Obviously the outcome of the whole process is either success or failure.= Success is easy: simply give the user what they asked for. Failure is more= complex, since there can be many causes and degrees of failure to handle.<= /p>
The case of outright technical failure is discussed in the Error Handling topic. The Federated Error Handli= ng topic discusses failure due to access control issues and the hand-of= f between IdPs and SPs.