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?
Per the Automic Automation documentation, the SAML Response must be signed. => To ensure message integrity, it is recommended signing both, the SAML Response and the Assertion.
In SAML the most important thing for an SP is to being able to validate that the assertion is indeed from the IDP and not from some fake source. That can only be done through signing with the IDP's key. That's why signing is mandatory in the SAML standard.
509 Certificate - A certificate provided by the IdP, used to verify the public key as passed by the IdP in the metadata of the SAML assertion. It allows the SP to verify the SAML assertion is actually coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed.
SAML uses a claims-based authentication workflow. First, when a user tries to access a site, the service provider asks the identity provider to authenticate the user. Then, the service provider uses the SAML assertion issued by the identity provider to grant the user access.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With