SLO request results in Azure error: "session index does not match the existing sessions"

We have implemented an SSO service provider using the latest version of the ComponentSpace dll (6.0.0). 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 get an error from Azure with the following steps:
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
4. Azure throws the following error:
AADSTS50070: Signout failed. The request specified session indexes ‘_89e7f9bc-aac7-4997-ad30-596494a46900’ which did not match the existing session(s).

I enabled SAML Trace and looked through the log file, and it shows that the SAML logout request that is sent to Azure contains the wrong session index value. In the SSO session store there are 2 session state entries that are identical except for the session index value, and ComponentSpace seems to just be reading the first entry and putting its session index value in the SAML logout request. But that is the session index returned in the SAML response to our first authentication request, which Azure discards when it receives our second authentication request. So Azure throws the error that it can’t find the session index.

Is there a way to make sure that the logout request is generated using the session index returned in response to the latest authentication request? Or another way that we can prevent this logout error?

I am attaching the SAML Trace log file.

In version 6.0.0, we added support for multiple pending SSO connections to the same IdP within the one browser session. This means we remember the state for each of these SAML sessions. Azure doesn’t have this type of support and only remembers the most recent SAML session.

When the SP initiates logout, we logout the earliest SAML session. This causes the error you’re seeing in Azure.

To accommodate partner providers that only remember the most recent SAML session, we’ll make a change to logout the most recent SAML session instead.

This should support both scenarios.

Please contact mentioning your forum post to receive a beta.

Thank you for your help. The problem is fixed in the new version 6.1.

Thanks for the confirmation.