Apex Code Development You need to sign in to do that
Don't have an account?
Rose 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 http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-td5741045.html, posting by Brent Putman on 01/25/2011
Many people, including our school, have gotten the Shib IdP to work via
SAML 2 with salesforce.com. 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 http://shibboleth.1660669.n2.nabble.com/IdP-Initiated-SSO-td5741045.html, 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 http://boards.developerforce.com/t5/Security/Salesforce-com-SAML-IdP-Problem/td-p/218531, 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?
Is your setup just not working for IdP(Shibboleth) initiated SSO ?
Does it work for SP initiated SSO (i.e.: user starting at Salesforce.com) ?
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