Apex Code Development You need to sign in to do that
Don't have an account?
Scott T. Salesforce.com SAML IdP Problem
Hi there,
In testing out Salesforce.com as an IdP, I'm running into what looks like a violation of the SAML 2.0 spec.
IdP initiated (unsolicited) login to my SP works fine.
SP initiated login is where I'm having issues. In this case, the SubjectConfirmation returned by Salesforce.com looks as follows:
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2010-11-22T05:42:09.711Z" Recipient="http://<mysp>/Saml/SP/SSO/Post"/></saml:SubjectConfirmation>
Unfortunately, this is lacking an "InResponseTo" attribute. The SAML 2.0 Web Browser SSO Profile (629-635) states the following:
At lease one bearer <SubjectConfirmation> element MUST contain a
<SubjectConfirmationData> element that itself MUST contain a Recipient attribute containing
the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the
window during which the assertion can be [E52]confirmed by the relying party. It MAY also contain an
Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT
contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>,
then the InResponseTo attribute MUST match the request's ID.
Bug?
Thanks,
Scott
Hi Scott - thanks for pointing that out.
I read the section several times, and it's pretty tough to determine if we're conforming or not. I agree it says it must match, but haven't found any area that says it must be present. Regardless, we want it to work for you, so are digging deeper.
With that in mind I'm going to check with some of our partners on how they interpret this section and what they've implemented. At the moment we've been supporting inResponseTo on the samlp:Response element. If it appears we're against the norm here, we'll get that fixed.
Also, please reply to the thread if this is breaking you, not working with the software you're using, and more detail.
thanks again
Hi Chuck,
Thanks for the reply!
Indeed this is breaking us for a project. I work for a WAM product vendor, and unfortunately we've interpreted the spec as requiring this attribute - and at present there's no way to bypass that check.
This is the first time it's been an issue for us during an interop test. Other vendors seem to interpret it the same way we do...
Cheers
Scott
Hi Scott
I checked with a number of ISVs and TC members. I wouldn't say there was consensus on anything but the spec being ambiguous. 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.
Given the holidays and that fact that we're wrapping up on Spring 11 will cause it to take a little bit. Contact me directly from my profile if you have a serious timing issue you need to discuss.
Thanks for your help.
Thanks Chuck!
I will send you a PM to discuss timing then. :-)
Cheers
Scott
Greetings....
This should be fixed now.
thanks for finding this and sorry about the issue
-cmort
Thanks Chuck - we've confirmed the issue is now resolved - the inResponseTo attribute is now populated.
Really appreciate the promptaction by your team on this before the holidays!
Cheers
Scott
Great news! Thanks for confirming on your side