Hi,
I have a IdP and SP sites setup. IdP as a virtual application (localhost:xxx/identity) SP as localhost:xxx. SP-initiated SSO is working perfectly. But when I try to do a IdP-initiated SSO it throws me The SAML message doesn’t contain an InResponseTo attribute. exception from the SP’s Assertion consumer service. What I’m doing wrong? Also if I do a back and if click again to initiate SSO with SP it works.
I use same code as MVC high level api example.
Thanks
This error message only applies to SP-initiated SAML SSO. An authn request has been sent to the IdP by the SP. The IdP replies with a SAML response. The SAML response should include an InResponseTo field specifying the ID of the original authn request.
Could you please enable SAML trace at the IdP and the SP and sends the two log files as email attachments to support@componentspace.com mentioning this forum topic?
Hi,
Seems like its an issue with browser caching. When I tried to reproduce this in a incognito session it worked without any problems. I will post in this thread if I get any more details on this.
Thank you.
Regards,
Tharidu
Thanks for the update.
I too am running into this. I can almost get it reproduce every time. The flow is as described, IdP initiated. I’ve sent an email with the logs and stacktraces.
Thanks. We’ll take a look.
Any update on this issue?
I’m still experiencing the same issue and can reproduce it as well.
dmarlow was manipulating a URL causing the application not to redirect back to the correct page after local login completed. The application was changed to correctly handle this.
If you're still seeing an issue, please email the SAML log file and any other relevant information to support@componentspace.com.
The steps to reproduce this, provided by tharidu, are as follows.
1. User browses SP
2. SP-initiated SSO
3. User gets redirected to IdP where he will choose reset password
4. User gets an email including a link in IdP site
5. When user visits the site and resets password IdP will initiate a IdP-initiated SSO
6. Exception is thrown in SP’s assertion consumer method
What’s happening here is that the SP is still expecting a SAML response as part of SP-initiated SSO. When you switch to IdP-initiated SSO at the IdP, the SP has no knowledge of this and is still expecting a SAML response as part of the original SP-initiated SSO flow.
We include an OverridePendingAuthnRequest attribute that you can set to let this flow work (ie any pending authn request is overridden which will occur if an SP-initiated SSO flow is overridden by an IdP-initiated SSO flow).
For example:
<PartnerIdentityProvider
Name=” urn:componentspace:ExampleIdentityProvider”
OverridePendingAuthnRequest=”true”
Thanks a lot. Adding that attribute fixed the issue I had. 
[quote][/quote]
The steps to reproduce this, provided by tharidu, are as follows.
1. User browses SP
2. SP-initiated SSO
3. User gets redirected to IdP where he will choose reset password
4. User gets an email including a link in IdP site
5. When user visits the site and resets password IdP will initiate a IdP-initiated SSO
6. Exception is thrown in SP’s assertion consumer method
What's happening here is that the SP is still expecting a SAML response as part of SP-initiated SSO. When you switch to IdP-initiated SSO at the IdP, the SP has no knowledge of this and is still expecting a SAML response as part of the original SP-initiated SSO flow.
We include an OverridePendingAuthnRequest attribute that you can set to let this flow work (ie any pending authn request is overridden which will occur if an SP-initiated SSO flow is overridden by an IdP-initiated SSO flow).
For example:
<PartnerIdentityProvider
Name=” urn:componentspace:ExampleIdentityProvider”
OverridePendingAuthnRequest=”true”
1. User browses SP
2. SP-initiated SSO
3. User gets redirected to IdP where he will choose reset password
4. User gets an email including a link in IdP site
5. When user visits the site and resets password IdP will initiate a IdP-initiated SSO
6. Exception is thrown in SP’s assertion consumer method
What's happening here is that the SP is still expecting a SAML response as part of SP-initiated SSO. When you switch to IdP-initiated SSO at the IdP, the SP has no knowledge of this and is still expecting a SAML response as part of the original SP-initiated SSO flow.
We include an OverridePendingAuthnRequest attribute that you can set to let this flow work (ie any pending authn request is overridden which will occur if an SP-initiated SSO flow is overridden by an IdP-initiated SSO flow).
For example:
<PartnerIdentityProvider
Name=” urn:componentspace:ExampleIdentityProvider”
OverridePendingAuthnRequest=”true”
Hello,
where exactly I need to add the attribute "OverridePendingAuthnRequest" as I am also facing the same issue?
on IDP side or on SP side and where?
OverridePendingAuthnRequest is part of the configuration of your service provider’s SAML configuration.
For example:
<PartnerIdentityProvider
OverridePendingAuthnRequest=“true”
Setting this flag to true means that even if an authn request has been sent and therefore a SAML response is pending, if a SAML response is received with no InResponseTo field, this won’t be treated as a SAML protocol error.
The assumption is that an IdP-initiated SSO is overriding a pending SP-initiated SSO.