function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Rose Sage BaroneRose Sage Barone 

Shibboleth as IDP issue

We're having an issue with using Shibboleth as our IDP.    Salesforce is rejectig the Shibboleth SAML assertion because of the presence of the inResponseTo attribute.   Our ITS group won't modify Shibboleth to not send the attribute because that will break other implmentations.  Any Shibboleth users out there with some insight?


Issue: Salesforce rejects the SAML assertion from Shibboleth because of the presence of an attribute called InResponseTo

Taken from Shibboleth users forum, posting by Brent Putman on 01/25/2011

Many people, including our school, have gotten the Shib IdP to work via
SAML 2 with  The only real substantive issue is that the
issued Response and Assertion must have the InResponseTo attribute
removed, else they are rejected by Salesforce.  That requires some mods
to the IdP, either code changes or additions.  See the list archive for
some solutions people have come up with.

Taken from Shibboleth users forum, posting by Scott Cantor on 01/26/2011

That [commenting out the code in  the IdP that sends out a inResponseTo attribute in the SAML response] will simply break other SPs ... that enforce the check. In other words, this is a bad idea.

Previous Salesforce response to Salesforce not sending out the inResponseTo, taken from Developer Force forum postings at, posting from Chuck Mortimore at 11/23/2010

 That being said there seem to be enough implementations that favor duplication of the inResponseTo that we need to fix it.   Code wins as they say.


Is it possible for Salesforce to look at adding the inResponseTo attribute?

Scott T.Scott T.

Is your setup just not working for IdP(Shibboleth) initiated SSO ?

Does it work for SP initiated SSO (i.e.: user starting at ?


I can't imagine not sending an inResponseTo in IdP initiated SSO breaking anything.  For sure it is required for SP initiated SSO (as you want to be sure that you match up the authentication request & response), but with the IdP initiated use case you don't have a request, so there's nothing to refer to in the inResponseTo attribute.  The Response is "unsolicited" as they say.  In fact, the SAML 2.0 profiles spec states it must not be included:


4.1.5  Unsolicited Responses

An identity provider MAY initiate this profile by delivering an unsolicited <Response> message to a service provider.
An unsolicited <Response> MUST NOT contain an InResponseTo attribute, nor should any bearer
<SubjectConfirmationData> elements contain one.

Are you sure this is the cause of your problems?