Should I require IdP's to sign SAML2 SSO responses?

Question

Our app has SAML2 SSO integration with 3 different (Shibboleth) IdP's. We are trying to add a 4th (also Shibboleth), but running into some issues, because our app expects all SSO responses to be verifiably signed. These other 3 are signing their responses, but the 4th is not, and is hesitant to add a custom config to enforce signing for our app.

Technically I could modify our app to accept unsigned SSO responses, but I am wondering whether or not I should. What are the pitfalls of allowing unsigned SSO responses? Is there any security vulnerability?

Is there any Shibboleth (or other SAML2 SSO) documentation that recommends signing responses as a best practice?

Wack

Answer 1

The only requirement for the IdP following the SAML 2.0 spec is to digitally sign the Assertion (see http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf - section 4.1.3.5). That is enough to tell if the SSO operation from an IdP should be trusted by SP that has federated with it.

Signing the outer Response is optional. There are some security benefits to it, such as preventing Message Insertion or Modification (see sections 6.1.3/6.1.5 in http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) - but in practice it's often omitted in lieu of relying on SSL/TLS.

Scalene

So then, based on the docs, if our app is requiring authn responses to be signed, are we technically not SAML2 compliant? All of our responses are indeed forced over HTTPS. – Wack

Signing of the SAML Response or Assertion is dependent on the binding you are using. Since I'm assuming you are receiving the message via POST Binding, then either the Response and/or Assertion must be signed by the IDP to ensure message integrity. I think the confusion is stemming from what part of the Response is being signed. I would be surprised if Shibb allowed an unsigned message to be sent via POST. – Equivalency

Answer 2

The whole point of signing the response is to prove that they actually do come from the issuer. Otherwise a "man in the middle" could change the attributes e.g. to give themselves access to an application.

ADFS v2.0 using SAML by default signs all response tokens. There's no way to turn this off.

Blowsy