InResponseTo doesn't match

SAML for ASP.NET
1

Hi,
After a user resets their password at our IdP they get sent to our home page. When clicking to go to a page that is login protected we get this error. Then, if I change the URL to another page, they seem to be logged in. Also, it doesn't look like there is a new flow because I don't see anything in SAML-tracer (app). Is there a way to suppress the error so I can log it but allow the user to continue?

The SAML message InResponseTo _6331583f-435a-4440-8cd0-5064bd0804af doesn't match the expected InResponseTo _cc53630b-fe97-4d9b-972e-6888e14f3de7.

2
[quote]
paulkeefe - 10/12/2021

Hi,
After a user resets their password at our IdP they get sent to our home page. When clicking to go to a page that is login protected we get this error. Then, if I change the URL to another page, they seem to be logged in. Also, it doesn't look like there is a new flow because I don't see anything in SAML-tracer (app). Is there a way to suppress the error so I can log it but allow the user to continue?

The SAML message InResponseTo _6331583f-435a-4440-8cd0-5064bd0804af doesn't match the expected InResponseTo _cc53630b-fe97-4d9b-972e-6888e14f3de7.

[/quote]

I was able to put a try/catch in that suppresses the issue. Afterward, the user has to click the button twice to start a new SAML flow, but at least it works without crashing.
3

The mismatching InResponseTo usually results from two SAML authn requests being sent to the IdP.

For example:

1. Call SAMLServiceProvider.InitiateSSO creates and sends SAML authn request #1 to the IdP.
2. Call SAMLServiceProvider.InitiateSSO again creates and sends SAML authn request #2 to the IdP.
3. At this stage we’re expecting a SAML response for SAML authn request #2.
4. IdP sends a SAML response for SAML authn request #1.
5. We throw an exception as the InResponseTo doesn’t match.

It’s best to avoid sending a second SAML authn request if a SAML response is pending.

We also recommend wrapping calls to the SAML API in a try/catch in case any such errors occur.

4
[quote]
ComponentSpace - 10/12/2021
The mismatching InResponseTo usually results from two SAML authn requests being sent to the IdP.

For example:

1. Call SAMLServiceProvider.InitiateSSO creates and sends SAML authn request #1 to the IdP.
2. Call SAMLServiceProvider.InitiateSSO again creates and sends SAML authn request #2 to the IdP.
3. At this stage we're expecting a SAML response for SAML authn request #2.
4. IdP sends a SAML response for SAML authn request #1.
5. We throw an exception as the InResponseTo doesn't match.

It's best to avoid sending a second SAML authn request if a SAML response is pending.

We also recommend wrapping calls to the SAML API in a try/catch in case any such errors occur.
[/quote]

Hi, I did end up putting it in a try/catch to fix the issue. But I'm not sure how I would stop from sending a second authn. Is there a method or property I can look at to tell me if there is one waiting for a return?
5

You could remember this state in your application.

For example, if the user clicks a button to initiate SSO, disable the button once it’s clicked and only re-enable after SSO completes.

Alternatively, call SAMLServiceProvider.IsSSOCompletionPending(). This returns true if an SAML response is pending.

6
[quote]
ComponentSpace - 10/13/2021
You could remember this state in your application.

For example, if the user clicks a button to initiate SSO, disable the button once it's clicked and only re-enable after SSO completes.

Alternatively, call SAMLServiceProvider.IsSSOCompletionPending(). This returns true if an SAML response is pending.
[/quote]

The first example wouldn't work because the person is returning to the site after an email password reset. So we don't know if and when that SSO will complete.

I'll try to see if I use the second one if I skip sending a new SSO what might happen.

Thanks for the info!
7

You’re welcome.