ComponentSpace

Forums



Getting InResponseTo does not match error on subsequent request after logout


Getting InResponseTo does not match error on subsequent request after...

Author
Message
nikunj.patel
nikunj.patel
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 12
In our application, we are using SP initiated SSO, by redirecting with the SAMLRequest parameter to the IDP SSO page.
After a successful login user is redirected back to our application. Now when the user logs out we redirect page to SLO page by SP initiated SLO method and after logout from IDP ADFS, they redirect back the user to our application's login page. To this point, SSO works as expected. But when a user tried to login immediately, when the user redirects to the ADFS's SSO login page but on the successful login ADFS calls AssertionConsumerServiceUrl and then we call SAMLServiceProvider.ReceiveSSO method. We are getting an error at this point. 
Exception: ComponentSpace.SAML2.Exceptions.SAMLProtocolException: The SAML message InResponseTo _bb137ad2-69dc-47c0-8ce0-6506fe0dc330 doesn't match the expected InResponseTo _1147aa2f-59d3-4227-b317-b4edf4835c28.

When I try to use DisableInResponseToCheck=true in SAML.config gives me an error about the invalid configuration and stops the SSO itself.
Can you please help me with this? I am not able to enable the logs. 
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9.4K
This normally occurs if SAMLServiceProvider.InitiateSSO is called twice.
On the first call to SAMLServiceProvider.InitiateSSO, a SAML authn request is sent to the IdP (ie _bb137ad2-69dc-47c0-8ce0-6506fe0dc330).
However, before a SAML response is returned, SAMLServiceProvider.InitiateSSO is called again and a second authn request is sent to the IdP (_1147aa2f-59d3-4227-b317-b4edf4835c28).
The IdP returns a SAML response with an InResponseTo field set to _bb137ad2-69dc-47c0-8ce0-6506fe0dc330 as it's responding to the first authn request.
However, the second call to SAMLServiceProvider.InitiateSSO overrode the first call so we expect the InResponseTo to be _1147aa2f-59d3-4227-b317-b4edf4835c28.
It isn't so we throw the exception you see.

You should avoid making multiple calls to SAMLServiceProvider.InitiateSSO. Make sure the SSO has completed and SAMLServiceProvider.ReceiveSSO has been called.

DisableInResponseToCheck may be used to disable this check but we recommend not doing so unless absolutely necessary.

<PartnerIdentityProvider DisableInResponseToCheck="true"/>

If you get a SAML configuration error, you may be using an older release that doesn't include this support.

Regards
ComponentSpace Development
nikunj.patel
nikunj.patel
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 12
ComponentSpace - 12/24/2019
This normally occurs if SAMLServiceProvider.InitiateSSO is called twice.
On the first call to SAMLServiceProvider.InitiateSSO, a SAML authn request is sent to the IdP (ie _bb137ad2-69dc-47c0-8ce0-6506fe0dc330).
However, before a SAML response is returned, SAMLServiceProvider.InitiateSSO is called again and a second authn request is sent to the IdP (_1147aa2f-59d3-4227-b317-b4edf4835c28).
The IdP returns a SAML response with an InResponseTo field set to _bb137ad2-69dc-47c0-8ce0-6506fe0dc330 as it's responding to the first authn request.
However, the second call to SAMLServiceProvider.InitiateSSO overrode the first call so we expect the InResponseTo to be _1147aa2f-59d3-4227-b317-b4edf4835c28.
It isn't so we throw the exception you see.

You should avoid making multiple calls to SAMLServiceProvider.InitiateSSO. Make sure the SSO has completed and SAMLServiceProvider.ReceiveSSO has been called.

DisableInResponseToCheck may be used to disable this check but we recommend not doing so unless absolutely necessary.

<PartnerIdentityProvider DisableInResponseToCheck="true"/>

If you get a SAML configuration error, you may be using an older release that doesn't include this support.

We are not using the InitiateSSO method, we are using ServiceProvider.SendAuthnRequestByHTTPRedirect method to send the authn request. And we saw there is only one call in the fiddler to the SSO. I think login is working as expected but on logout when we call InitiateSLO, ADFS is not completely removing the request with the provided ID. So on the next immediate authn request in AssertionConsumerService > ReceiveSSO, it is giving an error.
In a second approach, If we directly redirect to the SSO page, it is not sending the SAML Request (like authn request) or Relay message. This approach is working with other customer (IDP).
Please help and advise whether I am missing anything. 
 
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9.4K
You can't mix the SAML high-level API (eg InitiateSLO) and low-level API (eg SendAuthnRequestByHTTPRedirect) calls.
SAMLServiceProvider.InitiateSLO depends on previous SAML state information that's saved when calling SAMLServiceProvider.InitiateSSO and SAMLServiceProvider.ReceiveSSO.
If you haven't called the SAML high-level API for SSO, InitiateSLO won't have this state information to support SLO.
You should either use the high-level API or low-level API exclusively and not mix the two. Our recommendation is use the high-level API for both SSO and SLO.
If there's still an issue, please enable SAML trace and send the generated log file as an email attachment to [email protected] mentioning your forum post.
You should capture both SSO and SLO.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace


Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search