Multiple signature problem by OKTA SAMLResponse

[H-D-Choi]

There is an option to sign double the assertion in OKTA. But xml-crypto has a rule which SAMLResponse has to has only one signature. Therefore it can't be validated due to that reason. How and Could I contribute here to solve this problem?

[cjbarth]

Thank you for identifying this condition @H-D-Choi . Please create a PR with a test suite and we'll check the code over and get it landed.

[srd90]

@H-D-Choi your issue report speaks about "sign double the assertion" and it also speaks about xml-crypto not being able to validate SAMLResponse which has more than one signature.

I.e. you are mixing multiple assertion signature and SAML Response signature into same report. One possibility is that you are seeing SAML response which has top level (Response) signature and signed assertion.

It is business as usual that SAML authentication response can have two signatures (if IdP is configured to sign Response and Assertion). In business as usual case one signature would cover Response (and also assertion due to assertion being child of Response) and second one would cover only Assertion.

OKTA's documentation https://help.okta.com/en-us/content/topics/apps/aiw-saml-reference.htm (link referenced 02 Nov 2023) provides only these possibilities at Advanced Settings section:

Response | Choose whether the IdP digitally signs the SAML authentication response message. Assertion Signature | Choose whether the SAML assertion is digitally signed.

i.e. there doesn't seem to be any option to "sign assertion twice" but there seems to be possibility to configure signing of Response and signing of Assertion.

Have you perhaps enabled Response and Assertion signing (i.e. both) and are you perhaps using some (catch all signatures from any nesting level) xpath statement which loads all Signature elements to be used for validation or something like that.

Here are two different SAML libraries approach to validate signatures with xml-crypto (both support aforementioned scenario):

• samlify uses absolute xpaths to find signature nodes for signature validation:
  • https://github.com/tngan/samlify/blob/v2.8.10/src/libsaml.ts#L357-L500
• @node-saml/node-saml
  • https://github.com/node-saml/node-saml/blob/v4.0.5/src/saml.ts#L691
  • https://github.com/node-saml/node-saml/blob/v4.0.5/src/saml.ts#L717
  • https://github.com/node-saml/node-saml/blob/v4.0.5/src/xml.ts#L77-L115
  • fwiw, @node-saml/node-saml used to fail also in case of signed Response & signed Assertion case but it was fixed with
    • passport-samlPR #455 (at the time core node saml and passport-saml lived at the same codebase)
    • https://github.com/node-saml/passport-saml/pull/455/files#diff-864bd7929a1a1603afbae244cec33bac640a5bd41114620d085251f08f1ed352 <-- note: it seems that this is based on finding signature for current node...i.e. to node which was feeded to validation