Error Handling, Info and Transition Pages

[matthew.hayes]

We've had a few issues regarding the handling of certain situations within the IDP.  And while I had some quick work-arounds I wanted to get a feel for any more permanent solutions you might have in mind. 

First one is probably the most major - currently when processing a SAML Request on the IDP if any unexpected Exception is thrown it swallows it, and attempts to throw an Error Response back to the SP.  We've found in many cases the SAML Response never has the destination populated so the user just ends up on a blank page.   From what I can see the catch (Exception) in  IDPWebBrowserSSOValue.processSAMLRequestMessage is catching everything and the Finally clause after it reprocessed the request until it couldn't go any further.  My fix was setting up block for unexpected exception (currently just non-IssuerNotTrusted), setting a flag saying the process was in error, pushing the error to a session variable and forwarding to an error page.  In the finally block if the flag is set it skips the SAML processing allowing the user to get to the error page.  We found that handling the error on the IDP side (when its unexpected) seemed to make more sense than trying to pass back what would probably be partial or erroneous data to the SP.

Second item is more for user-friendlyness.  On the PostBindingUtil.sendPost we needed to change some of the titles, content and meta-data that was being displayed.   For the Titles it was just a case confusing to the users exactly what was happening.  For the META tags we needed to add robots tags because the google search was indexing the SAML page (with the obscure title), for the content again we want a please wait page that made it a little more obvious that something was happening.  In some cases the app that the user was being directed to the load time could be a few seconds.  In this case I just updated the necessary text but I would think the best way to do it would be either a configuration setting or a HTML/XML file that could be used as a template for the page displayed. 

Last one is just we wanted to have some informational pages (help, diagnostic info, etc) reside on the IDP.  Some available pre-login, some post, some both.  I would when I required no roles for a page in web.xml it worked fine when I wasn't logged in but when I was logged in the SAML processing would kick in and I would get redirected to the host page.  There is a trace line of SAML 1.1::Proceeding to IDP index page right before the redirect in the invoke method of IDPWebBrowserSSOValue.  My thought was to be able to configure a parameter which could match and ignore paths based on regex. 

Also I noticed a bug on BaseWriter.writeAttributeTypeWithoutRootTag on the last loop (around line 193 on 2.0.1.final)attributeValue isn't checked for null.  I just set it on our end to only run the loop code when attributeValue != null, I guess it also could be written to write out a zero length string or throw a more descriptive exception.  Not sure which would fit best for the overall design.

Thanks,

Matt

[anil.saldhana]

Matthew Hayes wrote:

We've had a few issues regarding the handling of certain situations within the IDP.  And while I had some quick work-arounds I wanted to get a feel for any more permanent solutions you might have in mind. 

First one is probably the most major - currently when processing a SAML Request on the IDP if any unexpected Exception is thrown it swallows it, and attempts to throw an Error Response back to the SP.  We've found in many cases the SAML Response never has the destination populated so the user just ends up on a blank page.   From what I can see the catch (Exception) in  IDPWebBrowserSSOValue.processSAMLRequestMessage is catching everything and the Finally clause after it reprocessed the request until it couldn't go any further.  My fix was setting up block for unexpected exception (currently just non-IssuerNotTrusted), setting a flag saying the process was in error, pushing the error to a session variable and forwarding to an error page.  In the finally block if the flag is set it skips the SAML processing allowing the user to get to the error page.  We found that handling the error on the IDP side (when its unexpected) seemed to make more sense than trying to pass back what would probably be partial or erroneous data to the SP.

This is tricky because the SAML2 spec says that errors have to be returned to the Service Provider.

Second item is more for user-friendlyness.  On the PostBindingUtil.sendPost we needed to change some of the titles, content and meta-data that was being displayed.   For the Titles it was just a case confusing to the users exactly what was happening.  For the META tags we needed to add robots tags because the google search was indexing the SAML page (with the obscure title), for the content again we want a please wait page that made it a little more obvious that something was happening.  In some cases the app that the user was being directed to the load time could be a few seconds.  In this case I just updated the necessary text but I would think the best way to do it would be either a configuration setting or a HTML/XML file that could be used as a template for the page displayed. 

One of the goals of the project is to keep things simple with less configuration.  I am thinking what is the best way to achieve this. Would you mind creating a feature request at https://issues.jboss.org/browse/PLFED for me to see what we can do here?

Last one is just we wanted to have some informational pages (help, diagnostic info, etc) reside on the IDP.  Some available pre-login, some post, some both.  I would when I required no roles for a page in web.xml it worked fine when I wasn't logged in but when I was logged in the SAML processing would kick in and I would get redirected to the host page.  There is a trace line of SAML 1.1::Proceeding to IDP index page right before the redirect in the invoke method of IDPWebBrowserSSOValue.  My thought was to be able to configure a parameter which could match and ignore paths based on regex. 

You are free to craft your own IDP web application. But overloading the default IDP war archive is going to become difficult to manage.

Also I noticed a bug on BaseWriter.writeAttributeTypeWithoutRootTag on the last loop (around line 193 on 2.0.1.final)attributeValue isn't checked for null.  I just set it on our end to only run the loop code when attributeValue != null, I guess it also could be written to write out a zero length string or throw a more descriptive exception.  Not sure which would fit best for the overall design.

Please create a bug report. You can add a test case or update if we already have one and fix it. You have full commit rights.   As long as the test suite works, we are fine.

[matthew.hayes]

I wasn't aware of that aspect of the spec.  Ok I will submit a bug report at least for the destination is null error that prevents the browser from returning to the SP.  Maybe a feature to encapsulate the functionality of returning to the SP on error into something that could possibly be overridden would be acceptable.

Understandable, configuration is so complex in some projects it makes them almost unmanagable, I will submit the request.

That's fine, just wasn't sure if you had a preference on how you wanted it handled.  I will update it to skip variables that are null (that seemed to work best on our end).  I'll verify it won't break anything on the test suite

[anil.saldhana]

https://issues.jboss.org/browse/PLFED-240

[matthew.hayes]

Thanks, feature request is https://issues.jboss.org/browse/PLFED-242