These financial institutions are
super concerned about their image and brand, as any large organization is. One thing that they all worry about is what happens when an error occurs while a user is SSOing from them to their service provider (SP). It's not good enough that the SP brands their service with custom URLs to make it look like they are in the bank's domain. That's a given. If an error page is shown,
it must be branded w/ their graphics, logos, colors, and text. Regardless of the minuscule chance of such an error occurring, the image of the bank must not be tarnished if it actually does.
To be specific, these are the cases I'm talking about:
- The XML of the SAML message is malformed or invalid.
- The digital signature on the SAML message or assertion is invalid.
- The digital signature is missing.
- The assertion or SAML message is expired.
- The assertion has been submitted before.
- The assertion can't be decrypted.
- The audience restriction of the assertion is missing or incorrect.
- The assertion is a holder-of-key (HoK) rather than bearer type.
To complicate things, some banks want to know exactly what went wrong. They want a different error code for each of these conditions printed on the page together with
their toll-free support number. Others just want a generic SSO error code. Even more challenging, some banks want the user redirected back to their Web site while others are OK with the user being left on the SP's server (as long as the page is branded). The requirements are all over the map, and it's very difficult for an SP to accommodate all of these needs. Coming up w/ a solutions for this that works for all partners is really, really hard. Here's the best I've been able to do using PingFederate for
just the SAML IdP-initiated SSO scenario.
PingFederate uses the
Apache Velocity templating framework to render HTML pages, including those displayed when SSO errors occur. It also allows you to provide information that should be displayed when errors happen during SSO (both IdP- and SP-initiated though I'm only talking about the former). This info can be configured on a per federation connection basis. As shown in the following screenshot, it is usually just text.
The trick though is to use text
and HTML, and to alter the Velocity template to output it as such.
Courtesy:http://travisspencer.com/blog/2010/09/per-partner-sso-error-pages-in.html