sign and/or encrypt SAML assetions, hack MITM

[Peter Schober]

jehan Procaccia tem <jehan.procaccia at tem-tsp.eu> [2024-02-28 21:59 CET]:
> Now changing on the fly the NamedID brakes the signature and fails
> the login process :-)

Great. You know what other things to test for next (see previous posts
or the GEANT Wiki space I linked to earlier: no signature at all,
signature from key not known/trusted out-of-bands).

> howerver, I still have a question regarding the overrides for that SP in
> /relying-party.xml/ of my IDP, now I had to force
> p:signAssertions="true" in order for the SSO flow to succeed

That probably means the SP has a bug and doesn't support signed
Responses (as discussed earlier, IIRC).

> Isn't it the default behavior for the IDP to SignAssertions ?

https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631694/SAML2SSOConfiguration
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508680/SAML2SSOConfiguration

 signAssertions, default: false
 [...]
 The default value of signResponses for this profile is "true"

I.e., it is not.

> Below is the final response with the succeed login assertion, why is
> there 2 occurences of signatures !?

Because the IDP is signing the SAML Response by default.
You could tell it to stop doing that if the SP is unable/unwilling to
support signed Responses.

> I am wondering if forcing p:signAssertions="true" in relying-party
> overrides doesn't generate that 2nd signature and hence if I finally
> correctly corrected that signature initial failure (MITM) ?

I guess the SP just never looked at the Signature on the SAML Response.
It may look at the Signature on the Assertion now that one is present.

-peter