Date: Fri, 29 Mar 2024 06:48:04 +0000 (UTC) Message-ID: <980590470.7567.1711694884468@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7566_1549902780.1711694884465" ------=_Part_7566_1549902780.1711694884465 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Recommended Practice
Federation software in most cases comes equipped with a default error ha= ndling experience that is limited in scope:
In short, out of the box error handling is functional and helpful for de= bugging, but is typically lacking in providing a professional and appropria= te experience for users of an IdP or SP.
Before moving to a production state, deployers should take steps to addr= ess these deficiencies. Obvious steps include:
A less obvious, but important, step is to explore different error condit= ions in your federating software and/or application; consider what problems= are likely to recur in production and how users ought to be advised to pro= ceed. For example, consider how bookmarks of various kinds, or the use of t= he back button, influences the user experience. Turn those otherwise useles= s messages into a straightforward warning about these features.
The hand-off between SPs and IdPs within a federation can result in user= confusion when errors occur. See Federated Error Handling for ways to address this.= p>
Finally, translate overly technical messages into customized responses i= n plain language that lead users to solutions; most software will provide t= he capability to do this. Even if error message testing breaks after upgrad= es, a deployment is no worse off for having improved the experience in the = meantime.