Can anyone point me in the direction of finding out/reading more about this error? “Receiving an SSO response from a partner identity provider has failed.” We have an SP initiated SSO. Apparently on the IDP side there are two different “types” of users that attempting to login. One group can login successfully with no issues and the second group cannot. Trying to narrow down the differences and what they are doing on the idp to throw this error. I’ve been unsuccessful in hunting down what this means, or any documentation related to it.
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Hi, I am getting the exact same error. I turned on NLog and this is what I have:
It would help to see the entire log file.
Please send the log file as an email attachment to support@componentspace.com.
Hi ComponentSpace Developer,
Have you looked into this issue yet? We too are seeing it regularly in our logs.
I am attaching a JSON from our logs.
We would be grateful if you could help us solve this.
Regards,
BKBK
Thanks for the log. The error in the log is:
“The SAML message InResponseTo _7787eaf8-66ea-44e1-9211-5f1e6af2a31d doesn’t match the expected InResponseTo _73a93cfc-02d4-4ded-80ae-ca57c0487f19.”
When a SAML response is received from the IdP, we check the InResponseTo field against the ID field of the SAML authn request that had been sent to the IdP. This ties the SAML response to the authn request. If the two don’t match, we throw the exception you’re seeing.
One scenario that can lead to this is if SAMLServiceProvider.InitiateSSO is called again before the call to SAMLServiceProvider.ReceiveSSO. The flow is as follows:
1. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #1 to the IdP. Expecting a response to #1.
2. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #2 to the IdP. Now expecting a response to #2.
3. IdP sends a SAML response to request #1.
4. Call SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
5. The InResponseTo is #1 but expecting a response to #2 so throw an exception.
One way to avoid this is to call SAMLServiceProvider.IsSSOCompletionPending() to check if an SSO completion is already pending. If this method returns true, don’t call SAMLServiceProvider.InitiateSSO again.
Alternatively, the application could keep track of the state of the button or link that’s clicked to initiate SSO and disable it if it’s already been clicked.
[quote][/quote]
Thanks for the log. The error in the log is:
"The SAML message InResponseTo _7787eaf8-66ea-44e1-9211-5f1e6af2a31d doesn't match the expected InResponseTo _73a93cfc-02d4-4ded-80ae-ca57c0487f19."
When a SAML response is received from the IdP, we check the InResponseTo field against the ID field of the SAML authn request that had been sent to the IdP. This ties the SAML response to the authn request. If the two don't match, we throw the exception you're seeing.
One scenario that can lead to this is if SAMLServiceProvider.InitiateSSO is called again before the call to SAMLServiceProvider.ReceiveSSO. The flow is as follows:
1. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #1 to the IdP. Expecting a response to #1.
2. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #2 to the IdP. Now expecting a response to #2.
3. IdP sends a SAML response to request #1.
4. Call SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
5. The InResponseTo is #1 but expecting a response to #2 so throw an exception.
One way to avoid this is to call SAMLServiceProvider.IsSSOCompletionPending() to check if an SSO completion is already pending. If this method returns true, don't call SAMLServiceProvider.InitiateSSO again.
Alternatively, the application could keep track of the state of the button or link that's clicked to initiate SSO and disable it if it's already been clicked.
"The SAML message InResponseTo _7787eaf8-66ea-44e1-9211-5f1e6af2a31d doesn't match the expected InResponseTo _73a93cfc-02d4-4ded-80ae-ca57c0487f19."
When a SAML response is received from the IdP, we check the InResponseTo field against the ID field of the SAML authn request that had been sent to the IdP. This ties the SAML response to the authn request. If the two don't match, we throw the exception you're seeing.
One scenario that can lead to this is if SAMLServiceProvider.InitiateSSO is called again before the call to SAMLServiceProvider.ReceiveSSO. The flow is as follows:
1. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #1 to the IdP. Expecting a response to #1.
2. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #2 to the IdP. Now expecting a response to #2.
3. IdP sends a SAML response to request #1.
4. Call SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
5. The InResponseTo is #1 but expecting a response to #2 so throw an exception.
One way to avoid this is to call SAMLServiceProvider.IsSSOCompletionPending() to check if an SSO completion is already pending. If this method returns true, don't call SAMLServiceProvider.InitiateSSO again.
Alternatively, the application could keep track of the state of the button or link that's clicked to initiate SSO and disable it if it's already been clicked.
Thank you for your reply.
Your explanation is helpful. Not only have you made us aware of the cause of the error, you've also provided a possible solution. Thanks.
[quote][/quote]
Thanks for the log. The error in the log is:
"The SAML message InResponseTo _7787eaf8-66ea-44e1-9211-5f1e6af2a31d doesn't match the expected InResponseTo _73a93cfc-02d4-4ded-80ae-ca57c0487f19."
When a SAML response is received from the IdP, we check the InResponseTo field against the ID field of the SAML authn request that had been sent to the IdP. This ties the SAML response to the authn request. If the two don't match, we throw the exception you're seeing.
One scenario that can lead to this is if SAMLServiceProvider.InitiateSSO is called again before the call to SAMLServiceProvider.ReceiveSSO. The flow is as follows:
1. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #1 to the IdP. Expecting a response to #1.
2. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #2 to the IdP. Now expecting a response to #2.
3. IdP sends a SAML response to request #1.
4. Call SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
5. The InResponseTo is #1 but expecting a response to #2 so throw an exception.
One way to avoid this is to call SAMLServiceProvider.IsSSOCompletionPending() to check if an SSO completion is already pending. If this method returns true, don't call SAMLServiceProvider.InitiateSSO again.
Alternatively, the application could keep track of the state of the button or link that's clicked to initiate SSO and disable it if it's already been clicked.
"The SAML message InResponseTo _7787eaf8-66ea-44e1-9211-5f1e6af2a31d doesn't match the expected InResponseTo _73a93cfc-02d4-4ded-80ae-ca57c0487f19."
When a SAML response is received from the IdP, we check the InResponseTo field against the ID field of the SAML authn request that had been sent to the IdP. This ties the SAML response to the authn request. If the two don't match, we throw the exception you're seeing.
One scenario that can lead to this is if SAMLServiceProvider.InitiateSSO is called again before the call to SAMLServiceProvider.ReceiveSSO. The flow is as follows:
1. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #1 to the IdP. Expecting a response to #1.
2. Call SAMLServiceProvider.InitiateSSO to create and send SAML authn request #2 to the IdP. Now expecting a response to #2.
3. IdP sends a SAML response to request #1.
4. Call SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
5. The InResponseTo is #1 but expecting a response to #2 so throw an exception.
One way to avoid this is to call SAMLServiceProvider.IsSSOCompletionPending() to check if an SSO completion is already pending. If this method returns true, don't call SAMLServiceProvider.InitiateSSO again.
Alternatively, the application could keep track of the state of the button or link that's clicked to initiate SSO and disable it if it's already been clicked.
We resolved this by updating to version 3.0.1 - we were using 3.0.0
Thanks for the update.