How to fix browser back button issue after SAML SSO from Shibboleth - asp.net-mvc-3

Question

Have a SAML2 Service Provider web application build on .NET MVC (3). We are using ComponentSpace's SAML2 library to do the authentication, not the Shibboleth SP. Here is the relevant controller logic:
public class SignOnController : Controller
{
// constructor-inject _services
[HttpPost]
public ActionResult SendAuthnRequest(string userName, string returnUrl)
{
// this users ComponentSpace internally to push user to IdP
_services.SamlServiceProvider.SendAuthnRequest(args);
return new EmptyResult();
}
[HttpPost]
public ActionResult ReceiveAuthnResponse()
{
var samlResponse = _services.SamleServiceProvider
.ReceiveSamlResponse(args);
// ...
return Redirect(samlResponse.RelayResourceUrl ?? defaultUrl);
}
}
Ultimately the user lands on either the relay url or the default login page. However when they click a link, then click the back button, the browser goes back to an error page on the Shibboleth IdP server. After that, the browser forward and back buttons ultimately become useless.
Am I doing something wrong in either of the above methods? Should I be returning a View() instead of an EmptyResult() when sending? Is there some way to reset the browser history to prevent repeated postbacks back to the IdP? Is this something that I can configure in ComponentSpace's implementation?

Answer 1

So I understand that you hit back button during authentication in IdP i WBSSO SAML2 profile? I don't know components which you enumerated but in Shibboleth case it always ends with error page. I may be wrong but if you consider the nature of SP->IdP communication I believe there is no other option, unless you reimplement something.

Answer 2

The SAML protocols messages used in SAML SSO as sent via the browser. Clicking the browser forward and backward navigation buttons can be problematic when using SAML SSO, as you have seen.
There is no simple solution to this problem. You could look at incorporating Javascript to disable the navigation buttons but that most likely will cause other issues.
I think the best and simplest solution is to display a generic error message if this occurs. This is something you need to do in your application.
Our MvcExampleIdentityProvider and MvcExampleServiceProvider applications that we ship don't have issues in most cases. They use the SAML high-level API as opposed to the SAML low-level API used in the question but this shouldn't make a difference. In our examples we return an EmptyResult as well.

Answer 3

We faced the same problem and worked around it with JavaScript history API:
https://www.thecssninja.com/javascript/stealing-history-api
It's not nice though since essentially the browsing history is manipulated. But it works efficiently and prevents the error page from showing up. Back/forward buttons inside your web app continue to work correctly but there's no way for the user to get back to any previous page which is not your web app. That was a compromise we could live with.

Answer 4

We use this script. It checks if the main url is called from an SSO redirect. If so, it skips the SSO page when the user clicks the back button. If not, the script does nothing because the back button is working as expected.
(function(window, location) {
var previous = document.referrer.toLowerCase();
var issso = previous.indexOf('account/sso');
if(issso >= 0){
history.replaceState(null, document.title, location.pathname+"#!/skipsso");
history.pushState(null, document.title, location.pathname);
window.addEventListener("popstate", function() {
if(location.hash === "#!/skipsso") {
setTimeout(function(){
history.go(-2);
},0);
}
}, false);
}
}(window, location));