Multiple SignInRequest

SAML for ASP.NET
1

I recently updated the SAML implementation to handle the Idp-Initiate SignOut. But it caused an issue on the following scenario.

1. Open SITE on TAB1, this will redirect to SignIn page, do not input anything
2. Open SITE on TAB2, this will also redirect to SignIn page
3. Go back to TAB1, input credentials then sign in

Expected: TAB1 should be able to successfully sign in to SITE
Actual: TAB1 is not signed in, and the page displays a white page

After investigation, it seems that the SAML server is keeping only one instance of the request per browser/session, thus when I opened TAB2, it overwrites the request of TAB1. Thus, causes a mismatch of the In_ResponseTo when we signed in on TAB1.

Is this a known issue?
Is there a configuration I need to do in order to fix this issue?

Thanks!

2

Hi Ronnie
Your description is correct. By default we store SAML SSO session information in the ASP.NET session.
The browser tabs are sharing the same session cookie.
The first pending SSO is being overwritten by the second SSO request as the expectation is that there’s only ever one pending request.
You could set DisableInResponseToCheck in the service provider’s SAML configuration to avoid the mismatch error.
<ParterIdentityProvider
DisableInResponseToCheck= “true”

We’ll look at whether we could better support this type of scenario in a future release.

3

[quote]DisableInResponseToCheck

The optional DisableInResponseToCheck attribute specifies whether the SAML message’s InResponseTo should be checked. This attribute should only be set to true in test environments or to work around limitations in the partner provider. The default is false.[/quote]


With the above, we would like to know what risks or limitations are involved if we disable the checking.

4

This disables the check to see whether the InResponseTo field in the SAML response is present and matches the ID field of the authn request.
Basically it’s confirming that the SAML response is in response to the authn request.
I think any associated risk in turning off this check is minimal.