Upgrading from v3 -> v5 gives "Invalid Signature" for one Google IDP customer

[zaiddabaeen]

I've recently upgraded from passport-saml 3.2.4 to 5.0.1. I have a MultiSamlStrategy and there are customers who are using different IDPs log in to my SP using the MultiSamlStrategy.

As I upgraded and was testing locally with Google and Okta IDPs, I realised I needed to add wantAuthnResponseSigned: false to get a successful login. Of course, I needed to change the SAML options to conform to the new signature:

   export function cleanCertificate(cert) {
     cert = cert.replace(/ /g, '');
     return cert.split(/[\n|\r]/).join('');
   } 

   return {
      idpCert: provider.cert.split('\n\n').map(cleanCertificate),
      issuer: provider.entityId,
      callbackUrl: config.passport.callbackUrl + '/' + key,
      entryPoint: provider.entryPoint,
      wantAuthnResponseSigned: false,
    };

I tested again with different SAML applications for staging and production environments both on Google and Okta IDPs, and everything was working well.

Today, only one of many customers who are using Google IDP started getting "Invalid Signature" error originating from validatePostResponseAsync function. I double checked the certificates and I can confirm that they're unchanged and still valid for years.

I tested with more SAML options:

      acceptedClockSkewMs: 300000,
      validateInResponseTo: 'never',
      disableRequestedAuthnContext: true,

but still they get the same error message. I can confirm that in their metadata XML WantAuthnRequestsSigned="false".

I sense the issue has to do with cleanCertificate function.

provider.cert looks like the following:

MIIDdDCCAlygAwIBAgIGAXfoxrlqMA0GCSqGSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
...
MIIBCgKCAQEAhvpmQbMoGRBomDy5Nw6TyPLmdapV+jsbFumnqXqfjuwvPCpt/x7zQwJ45Soc+RNg nWAxrRgKISXMOcT5qI4N3khWoBAzJXU8TxQms3CEFTpba7HKMh4SoPEKkaQ5NYphVICFCYgpBSW7 Lde61xzPfZsAvHJX0pJhwgGqDheRKekQSh0U4qoL2wYoTMh9Raf0fMRhIheyar4sBmtVMAFNJVv4
...
VSeoPbC1MMok9AL2c0wN/uaCWEt4KQeFvYHt0I9Ip6+9KOwQkQIDAQABMA0GCSqGSIb3DQEBCwUA
...
x8N818KDaekOGZe1vKGlEmUCb0vMtDjAW/xfpa9oyo5oq4EArcvway/6103wMhagxKEDEGeDgUFsYt69aHMQsNPDkb2LedMu96Mm6MwMuHYyTnKRV2Mi3Gqc9NBbQnJ+/+gGn8SGrE9LhF4GmFl/gctU
...
d2QEyg8RliOiW/fhzFQ2VPO4P1jj7p7L3g85pHpo2REq

How can I begin debugging this?

[srd90]

First of all this:

I can confirm that in their metadata XML WantAuthnRequestsSigned="false".

is not related to auth responses.

---

Here are few links to similar cases:

1. [BUG] When validating the SAML Response, it is assumed that the SAML Response ID attribute is the same as the SAML Assertion ID attribute node-saml#211
2. [BUG] Invalid document signature after upgrading from 2.2.0 to 4.0.1 #816
3. [BUG] After an upgrade from passport-saml to @node-saml/passport-saml, assertion validation stopped working with HTTP-POST binding with an error: SAML.validatePostResponseAsync, Invalid document signature #839
4. Assertion signature is missing in SAML Response when using Google Workspace #852
5. [BUG] Invalid document signature #859
6. Reference id not matching with documentElement id #863
7. Can't find the signature - Invalid document signature #870
8. https://stackoverflow.com/q/76537574
9. https://stackoverflow.com/a/79091591
10. [BUG] When the ID of the response is different from the ID of the assertion, no signature node is found node-saml#378

And especially check https://github.com/node-saml/passport-saml/wiki/Common-Issues/542624c1ed01a1948c9c4dfd43c9d252d65e0e34

See comment from #671 (reply in thread) to see how to spot from authnresponse what sort of signatures it has and possibilities to configure @node-saml/passport-saml / @node-saml/node-saml if IdP configuration management is not an option for you or if you rather modify SP configuration.

[srd90]

Furthermore you might want to check @node-saml/passport-saml (and @node-saml/node-saml) implementation to see conditions of throwing "Invalid signature" (compare control flow also to your configuration, passport defaults and auth response payload). Here is short cut to comment which contains references to places where invalid signature is reported (message content varys per place where it is reported): node-saml/node-saml#378 (comment)

So given the possibilities to configure your IdP side (see #671 (reply in thread)) and your error message and based on control flow (see node-saml/node-saml#378 (comment)) your problem is most likely that IdP side is configured to sign only response but your configuration has wantAssertionsSigned=true (which is default setting as communicated by documentation and changelog).

[zaiddabaeen]

Many thanks @srd90.

Turns out Signed Responses was toggled on for their Google SAML application, which means that I needed to set: wantAuthnResponseSigned: true and wantAssertionsSigned: false.

For anyone who is not super fluent with SAML responses, if the ds:Signature exists as a direct child under saml2p:Response, that means that the response should be signed. If it exists under saml2:Assertion, that means that the assertions should be signed. Note that this is not shown in the IdP metadata.

[srd90]

Note that this is not shown in the IdP metadata.

From metadata pov want assertion / response signed is not at IdPs metadata because those "wants" are SP's. If SP metadata is used to provision SP to IdP then SP may communicate with SP metadata that it wants assertions signed. Want response signed does not have similar setting.

Another possibility to provision SP to IdP is without metadata in which case someone clicks / setups IdP to sign one or both entities via IdP specific admin console (for newly provisioned SP) and this information is then shared between SP and IdP administrators via some side/back channel (like email / phone cinversation). If admins of IdP and SP are unable to communicate then SP admin may use content of auth responses to "debug" / deduct IdP side auth response signing configuration (by observing signature element positions/whats being signed by IdP) and setup node-saml / passport-saml's configuration options ("wants") accordingly.

Quote which try to explain from another angle ( quote copied from node-saml/node-saml#326 (comment) ) :

fwiw, if you have studied security related protocol (in this case SAML 2.0) prior to using it production in order to know whats going on you might have noticed that wantAssertionsSigned reflects whats being said at SAML metadata spec.
wantAuthnResponseSigned does not have similar "presence" at e.g. SAML metadata spec but it was introduced to node-saml so that node-saml client SW can configure responses without response level signature invalid. I.e. if client SW developer knows that his/her IdP is always signing at response level there should not be any reason to accept response without valid response level signature (it is a sign that someone has deliberately removed that signature from message and maybe trying some false play stuff). Before these parameters were added default behaviour was the same that you get now when you turn both "wants" off. I.e. missing response level signature or response level signature which didn't match with content was treated as soft error and stack proceeded to check whether there is at least validly signed assertion.

fwiw2, change log has these entries (related to these two parameters): node-saml/node-saml#83 and node-saml/node-saml#177 (in case you want to take a look around stuff done / discussed).

And here is reference to metadata spec:

Metadata for the OASIS Security Assertion Markup Language (SAML) 2.0

OASIS Standard, 15 March 2005

https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

[zaiddabaeen]

@srd90 I seriously appreciate the time you're taking to provide a full answer and explanation. This makes things much clearer. Thank you!