SLO problems related to multiple SAML sessions in the session store

We are running into new logout problems related to my previous posts: post1 post2 . The problems described in these posts were fixed - the first one in the latest released version (6.1), and the second one in a 6.2 beta version. But once they were resolved, two new problems have appeared which we could not see before due to the original problems.

Problem 1:
In our application you can select multiple databases, and each database has to authenticate with the identity provider. So we can have a case where two consecutive SAML authentication requests could be sent to the identity provider (Azure). We have a problem as follows:
1. database 1 sends authentication request to our Azure identity provider and authentication response is received
2. database 2 sends authentication request to our Azure identity provider and authentication response is received
3. database 1 sends logout request to our Azure identity provider and logout response is received
4. after receiving the logout response from the identity provider, we call SAMLServiceProvider.IsSSO(partnerIdP) as a way to verify whether the logout succeeded. IsSSO returns true (i.e. we are still single signed-on with the identity provider) so we show a message to the user that they are still logged in. But in fact, they have been successfully logged out of the Azure identity provider, so the message we display is incorrect and confusing to the user.

Looking at the SAML Trace log file, IsSSO is returning true because there is still a SAML session for the identity provider in the SSO session store (one SAML session was added for each database login, and the logout removed only one of these sessions). But with Azure, since it only remembers the last SAML session, once we have received the response to our logout request we are effectively no longer single signed-on to the identity provider. So IsSSO returning true is giving us the wrong information.

Problem 2:
A related problem that we are running into is that, after following steps 1 to 4 above and having logged out of database 1, if the user selects Logout in our application to log out of database 2, a SAML logout request is sent to Azure even though we are already logged out. This results in Azure showing a “You signed out of your account” page, without redirecting back to our Single Logout Service page. We always call CanSLO to check whether we can send a SAML logout request or not, and if the check returns false we do not send the logout request. But in the case described above CanSLO returns true, even though we have already logged out of the identity provider, so we send the second logout request and then get stuck on the Azure “You signed out of your account” page with no way to get back to our application.

We need for IsSSO and CanSLO to return the correct information for identity providers such as Azure that do not remember multiple SAML sessions. Once a logout request has been sent to the identity provider and we received the SLO response back, we need these functions to return false for that identity provider, regardless of how many authentication requests we had sent to the identity provider prior to the logout request.

I realize that these problems are all due to the version 6.0 change of storing multiple SAML sessions for the same identity provider in the session store. Is there a way to turn this off? Maybe make it configurable so we can decide whether we want multiple sessions to be stored or only a single session per identity provider?

I am attaching two SAML Trace log files which illustrate the two problems. They were generated by our application using the 6.2 beta version of the ComponentSpace dll.

Thank you for the detail description and the log files.

The problem boils down to Azure AD not supporting multiple SSO sessions within the one browser session. This functionality was added in v6.0 but it also depends on the partner identity provider having the same support for it to function properly.

We’ll look at either adding a configuration parameter or a method your application would call to clear the SSO session state after a logout.

Please contact