We maintain SAML state in support of the SAML protocol. For example, as part of SP-initiated SSO the SAML response returned by the IdP has an InResponseTo field which should match the ID field of the SAML authn request sent by the SP. We save this ID in the SAML state so we can perform this check when the SAML response is received.
In v2.8.8 the SAML state is saved in the ASP.NET session. In a later release we removed the reliance on the ASP.NET session and introduced a custom SAML_SessionId cookie which, by default, is backed by an in-memory SAML session store.
The scenario you describe is problematic and we don't recommend users do this if at all possible. The underlying problem is that the same SAML_SessionId is used for both browser tabs. Therefore, the same SAML state applies to both tabs. The sequence is as follows:
1. In tab #1, a SAML authn request with ID 1 is sent to Okta. We save ID 1 in the SAML state.
2. In tab #2, a SAML authn request with ID 2 is sent to Okta. We save ID 2, replacing ID 1, in the SAML state.
3. In tab #1, a SAML response in response to SAML authn request 1 is received.
4. An exception is thrown as we're expecting a SAML response in response to SAML authn request 2.
The only way we could handle this is to save multiple IDs in the SAML state. However, this adds complexity for a scenario which we typically don't see. If this is a significant issue, please contact
[email protected] to discuss possible options.
If you're using a web farm, the default in-memory SAML state session store may be used if you employ sticky sessions. If that's not the case, you need to implement a session store in a central repository such as a database. Please refer to the WebFarm Guide and the Developer Guide for more information.
https://www.componentspace.com/Forums/9356/Web-Farm-Guidehttps://www.componentspace.com/Forums/8231/Developer-Guide
Regards
ComponentSpace Development