Session Timeout - IsSSO

SAML for ASP.NET
1

When we log out from the SP we also want to log out from the IDP but I don’t seem to be able to do this if the SP session has timed out.

So after the SP times out

  • The user clicks logout
  • As IsSSO comes back false, we just log out locally and get redirected to the home page
  • Home page requires authentication so we get sent to IDP which we are already logged into and we get bounced back to the SP.
So from the users point of view, the user clicks logout, the page refreshes and they are still on the same page and still logged in. Obviously if they click logout again, they will be logged out of the IDP and SP as IsSSO will return true and the user is sent to the login page on the IDP.

Is there something I can do differently in the logout method (or anywhere else) do deal with this problem?

My logout method on the SP:


public ActionResult Logout()
{
string partnerIDP = WebConfigurationManager.AppSettings[“PartnerIDP”];

var hasSession = SAMLServiceProvider.IsSSO(partnerIDP);
if (hasSession)
{
SAMLServiceProvider.InitiateSLO(Response, null, partnerIDP);
return new EmptyResult();
}

LogoutLocally();

return RedirectToAction(“Index”, “Home”, new { Area = string.Empty });
}


Thanks

2

The SAML session information is stored in the ASP.NET user session. If the user session times out at the SP then the SAML session information for that user disappears. That’s why the IsSSO is returning false.
Unfortunately the SAML specification doesn’t provide any solution for synchronizing user sessions. The user session at the IdP is totally independent from the user session at the SP. As you’ve seen, the SP session can timeout but the IdP session remain active. In this case, the user will not have to log back into the IdP. This can be a good thing in some scenarios but could lead to possible confusion for the user if their SP session times out.
The simplest solution is to arrange for the SP session time out to be greater than or equal to the IdP session time out.
We do support storing SAML session information in a custom database rather than in the ASP.NET session. This means that the SAML session information can persist beyond the life of the user session. However, this adds complexity and I’m not sure it’s worth it just to try to cover this scenario.