[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Destination vs. Recipient and signing of Assertion vs. Response
Hello, We are using the HTTP POST Binding with Web SSO Profile. The IDP will be sending an (unsolicited) samlp:Response to us, the SP. We are finding the spec to be a little confusing on certain items: 1) For us to verify that the SAML message was really intended for us, does the IDP need to provide the Destination attribute of <Response>, or Recipient attribute of <SubjectConfirmationData>? Or both? SubjectConfirmation and SubjectConfirmationData are described in the SAML core spec (2.4.1.1 and 2.4.1.2) as elements which are used by a "relying party" to verify the relationship between the Subject and the "asserting party". SubjectConfirmation doesn't seem to have anything to do with who should act on the entire Assertion (its scope seems smaller than the Assertion). Yet, the Response processing rules under Web SSO Profile (SAML Profiles 4.1.4.2) do imply that SubjectConfirmationData's Recipient should be used as an overall check by the "relying party" that it was really intended for them. 2) The answer to the above affects what portion of the SAML message should be signed -- i.e. if we are relying on the Destination attribute then the entire <Response> should be signed, correct? 3) Also the Security Consideration doc section 6.4.2 (HTTP POST Binding - Man in the Middle Attack) says: Countermeasures: The Service Provider site MUST check the Recipient attribute of the SAML response to ensure that its value matches the https://<assertion consumer host name and path>. As the response is digitally signed, the Recipient value cannot be altered by the malicious site. This is unclear because <Response> doesn't have a Recipient attribute, it has Destination. Is this what was intended instead? And is the entire <Response> element supposed to be signed (or otherwise integrity-protected) when using HTTP POST Binding, or is just signing <Assertion> okay? I can't find anything that says "when using HTTP POST binding the *entire* SAML message must be integrity-protected". Thanks for any help, Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]