! Invalid signature ! while implementing SSO in OneLogin

[4auvar]

I know that the Passport-SAML has been well tested to work with Onelogin but I am facing an issue "Invalid signature", it might be my local configuration issue or may be OneLogin setup issue.

The application throws error Invalid signature at: /node_modules/passport-saml/lib/node-saml/saml.js:584:27, When I open the file I come to know that this line belongs to function validatePostResponseAsync which calls validateSignature for assertion.

and the actual cause of error is:

const xpathSigQuery = ".//*[" +
            "local-name(.)='Signature' and " +
            "namespace-uri(.)='http://www.w3.org/2000/09/xmldsig#' and " +
            "descendant::*[local-name(.)='Reference' and @URI='#" +
            currentNode.getAttribute("ID") +
            "']" +
            "]";
        const signatures = xml_1.xpath.selectElements(currentNode, xpathSigQuery);
        // This function is expecting to validate exactly one signature, so if we find more or fewer
        //   than that, reject.
        if (signatures.length !== 1) {
            return false;
        }

for my SAML response, the signatures.length value was always 0.

I don't know the reason of this behaviour.

• here is my node.js configuration:

• And here are the OneLogin setup:

Any help will be appreciated.

[srd90]

You did not provide passport-saml version so lets just assume it is e.g. 3.2.1.

---

Background:

From SAML response integrity point of view SAML authentication response is considered safe if it has valid top level signature (Response level) or if assertion element is signed.

...As long as one of the response or assertion are signed, use of the profile is "safe" in terms of authentication integrity...

source: https://shibboleth.atlassian.net/wiki/spaces/IDP30/pages/2504884338/SAML2SSOConfiguration

passport-saml has implemented its SAML response signature validation this way:

First it tries to validate top level (aka Response) signature:

passport-saml/src/node-saml/saml.ts

Lines 761 to 765 in 6ba76ba

	// Check if this document has a valid top-level signature
	let validSignature = false;
	if (this.validateSignature(xml, doc.documentElement, certs)) {
	validSignature = true;
	}

if this validation succeeded it set validSignature = true. If top level (aka Response level) signature validation failed due some reason (invalid certificate, malformed certificate or man in the middle had modified content of response level elements but not assertion level elements or response element did not have associated xml signature) it - passport-saml - considers this as "soft failure" i.e. validSignature = false and it proceeds to check whether assertion is validly signed.

If validSignature == false it tries to validate assertion's signature:
In case of unencrypeted assertions:

passport-saml/src/node-saml/saml.ts

Lines 783 to 788 in 6ba76ba

	if (
	(this.options.wantAssertionsSigned || !validSignature) &&
	!this.validateSignature(xml, assertions[0], certs)
	) {
	throw new Error("Invalid signature");
	}

In case of encrypted assertions:

passport-saml/src/node-saml/saml.ts

Lines 812 to 817 in 6ba76ba

	if (
	(this.options.wantAssertionsSigned || !validSignature) &&
	!this.validateSignature(decryptedXml, decryptedAssertions[0], certs)
	) {
	throw new Error("Invalid signature from encrypted assertion");
	}

if assertion signature validation was successfull it proceeds to consume values from assertion.

If assertion signature validation failed it reports Invalid signature or Invalid signature from encrypted assertion.

Reasons for failure are among other things: man in the middle had modified content of assertion, certificate was malformed, certificate was invalid, assertion did not have associated xml signature

Furthermore: SP and IdP administrators can configure various way how SAML response is signed. I.e. SAML response could have

• signed response (top level) and unsigned assertion OR
• it could have unsigned response (top level) and signed assertion OR
• it could have signed response (top level) and signed assertion

---

Now lets look at your question (for full disclosure I have not used Onelogin). One of the pictures show that "SAML signature element" dropdown has "Response". I assume it means that with that choice Onelogin signs just top level element (Response) and leaves assertion unsigned.

So keeping in mind background and your configuration choises reason for the observed behaviour could be that:

1. top level signature verification failed due some reason (lets come to that a bit later)
2. you received Invalid signature and observed that validate signature function did not find any signature because at that point it had proceeded to check whether there is validly signed assertion element (and Onelogin did not sign assertion because it was configured to sign Response ... NOTE: it is better to have signature at Response level because that covers whole reponse including assertion so you should aim to keep that configuration).

If I were you I would debug why this validation failed:

passport-saml/src/node-saml/saml.ts

Lines 761 to 765 in 6ba76ba

	// Check if this document has a valid top-level signature
	let validSignature = false;
	if (this.validateSignature(xml, doc.documentElement, certs)) {
	validSignature = true;
	}

One of the pictures show that cert is not oneliner (I do not know if your editor just soft-wrapped that line) but passport-saml documentation says:

... For this, you can provide the Identity Provider's public PEM-encoded X.509 signing certificate using the cert configuration key. The "BEGIN CERTIFICATE" and "END CERTIFICATE" lines should be stripped out and the certificate should be provided on a single line. ...

source: https://github.com/node-saml/passport-saml/blob/6ba76ba3a015fea96a2dd38f661a6c1f85bc44a1/README.md#security-and-signatures

If your cert value is NOT oneliner try to remove line breaks and see whats happens. If it still does not work double check IdP certificate value and debug what happens at top level signature verification.

PS. some other SP implementations provide configuration options to "fail hard if there should be valid top level signature and validation of top level signature failed". passport-saml has never had such configuration option. For example in your case you have configured IdP to sign whole response and there should be no reason to continue message processing if that goal is not reached. It just means that someone could have modified response in some way and one should consider such SAML response poisonous:

...but there are vulnerabilities in XML Encryption that make signing responses advisable when the most common encryption algorithms are used.

source: https://shibboleth.atlassian.net/wiki/spaces/IDP30/pages/2504884338/SAML2SSOConfiguration

[cjbarth]

@srd90, I've created an issue to track the idea of failing at a bad top-level signature. I honestly can't think of any good reason that, if we find a top-level signature that is invalid, we should ever continue processing. Please feel free to offer your comments on that issue for later implementation.

node-saml/node-saml#58

[drollinger]

For those scanning through this for a solution, what worked for me is adding the option wantAuthnResponseSigned: false to the saml strategy. Further details can be found reading through the above comments and node-saml/node-saml#58 when this option was added and set as true by default causing a hard fail instead of "soft failing" when top-level signature fails.

I ran into this issue working with Azure AD. I also want to mention audience for Azure AD since it was a BTW in an above comment. If you are getting a SAML assertion audience mismatch there are a few fixes if you edit Issuer to a URI value or the quickest fix is to add the option audience: `spn:${azuread.entityID}` since Azure prefixes any non-URI Issuers with spn:.

[srd90]

It should be noted that at the time of this question was introduced (February 2022) and related comments were written passport-saml version was 3.2.1

”want response and assertion signed by default” became default policy for 4.x around 2022-10-11 ( see major changes: https://github.com/node-saml/node-saml/blob/v4.0.0/CHANGELOG.md#v400-beta5-2022-10-11 )

Here are two issues (i.e. more recent discussions) from >=4.0.0 era of passport-saml which are related to configuring want assertion/document signature parameters to reflect how IdP is configured/requested to sign node-saml/node-saml#211 (comment) and #816 (comment)

#816 contains also note how to alter azure side configuration if someone wants configure IdP (azure) to sign both (or to change which one is signed…assertion or whole response).

[dangtony98]

Running into an issue with the audience configuration for Azure AD (now Entra). Specifically:

• The SP-initiated flow works when audience is set to spn:${application_id}.
• The IdP-initiated flow (from Azure) works when audience is set to Identifier (Entity ID).

Neither of the above flows work with the other's audience, seemingly requiring conditionally setting audience depending on where the flow is initiated; something seems wrong here.

@drollinger Would you happen to remember how you got it to work?

[drollinger]

@dangtony98 This is what I've used. I haven't done extensive testing with it, but from what I've tested, it's secure.

import { Strategy as SamlStrategy } from '@node-saml/passport-saml'
new SamlStrategy(
    {
      passReqToCallback: true,
      callbackUrl,
      entryPoint,
      issuer: clientId,
      cert,
      signatureAlgorithm: 'sha256',
      wantAuthnResponseSigned: false, // Azure AD doesn't return top level signature validation
      audience: `spn:${clientId}`, // Azure AD prefixes audience with spn:
      disableRequestedAuthnContext: true, // Allow any authentication context
    },
    (req, payload, done) => { /*....*/ }
    )

[rednebmas]

For what it's worth, I am running into this issue with Google Workspace SAML. This is because by default, Google only signs the assertions, not the entire response.

Even after enabling "Sign response" it's still not working for me (and I've validated the SAML using https://www.samltool.com/validate_response.php). My current solution is to set wantAuthnResponseSigned to false if the IdP entry point starts with https://accounts.google.com.

[srd90]

@rednebmas wrote:

For what it's worth, I am running into this issue with Google Workspace SAML. This is because by default, Google only signs the assertions, not the entire response.

The link that you associated to text "Google only signs the assertions, not the entire response" requires authentication. Here is that same link modified so that it points to document so that one does not have to go through authentication form: https://support.google.com/a/answer/6087519?hl=en and here is quote from that document (referenced 10 Mar 2023):

10. (Optional) If your service provider requires the entire SAML authentication response to be signed, check the Signed Response box. If this is unchecked (the default), only the assertion within the response is signed.

@rednebmas continued:

Even after enabling "Sign response" it's still not working for me (and I've validated the SAML using https://www.samltool.com/validate_response.php). My current solution is to set wantAuthnResponseSigned to false if the IdP entry point starts with https://accounts.google.com.

There is one issue related to using Google Workspace as IdP and how it signs SAML responses (and @node-saml/passport-saml was 4.0.2):

• Assertion signature is missing in SAML Response when using Google Workspace #852

if information at aforementioned issue's description is accurate all the way to the example response then it seems that Google has implemented "Signed Response" switch so that if it is checked then Response is signed and assertion is not signed and vice versa.

So...

---

if you do not check Signed response ([ ] Signed response) do you see something like this (only one Signature element and it is referencing to Assertion element's ID)?

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 ID="_response_id"
                 ...
                 >
    ...
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     ID="_assertion_id"
                     ...
                     >
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                ...
                <ds:Reference URI="#_assertion_id">
                    ...
                </ds:Reference>
            </ds:SignedInfo>
             ...
        </ds:Signature>
        ...
    </saml2:Assertion>
</saml2p:Response>

In this case @node-saml/passport-saml configuration would be:

wantAuthnResponseSigned: false,
wantAssertionsSigned: true, 

---

if you do check Signed response ([X] Signed response) do you see something like this (only one Signature element and it referencing to Response element's ID)?

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 ID="_response_id"
                 ...
                 >
    ...
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            ...
            <ds:Reference URI="#_response_id">
                ...
            </ds:Reference>
        </ds:SignedInfo>
        ...
    </ds:Signature>
    ...
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     ID="_assertion_id"
                     ...
                     >
        ...
    </saml2:Assertion>
</saml2p:Response>

In this case @node-saml/passport-saml configuration would be:

wantAuthnResponseSigned: true,
wantAssertionsSigned: false, 

---

Do you ever see something like this when Google Workspace is used as IdP and "Signed Response" is checked or not (two Signature elements so that one is referencing to Response element's ID and another is referencing to Assertion element's ID)? (if not then assumtion that google has implemented its Google Workspace IdP so that it signs only Response or only Assertion depending on state of "Signed Response" checkbox holds water)

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 ID="_response_id"
                 ...
                 >
    ...
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            ...
            <ds:Reference URI="#_response_id">
                ...
            </ds:Reference>
        </ds:SignedInfo>
        ...
    </ds:Signature>
    ...
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     ID="_assertion_id"
                     ...
                     >
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                ...
                <ds:Reference URI="#_assertion_id">
                    ...
                </ds:Reference>
            </ds:SignedInfo>
             ...
        </ds:Signature>
        ...
    </saml2:Assertion>
</saml2p:Response>

In this case @node-saml/passport-saml configuration would be:

wantAuthnResponseSigned: true,
wantAssertionsSigned: true, 

(it could also be

wantAuthnResponseSigned: true,
wantAssertionsSigned: false, 

or

wantAuthnResponseSigned: false,
wantAssertionsSigned: true, 

but you should introduce as strict as possible confguration)

---

All situations listed above are valid (e.g. from https://www.samltool.com/validate_response.php 's point of view and from passport-saml point of view as long as those responses meet expected signature configurations)

[stavert]

Just to share my learning on this topic, I ran into this with a simple upgrade from passport-saml to @node-saml/passport-saml. I'm using OneLogin as my test IdP. After some head scratching, I read this post and went back to check the following setting in the OneLogin IdP configuration:

Be sure to check "Both". This solved my issue and I appreciate the signature checking algorithm description posted by @srd90 !!