SAML 2.0 - Failed to verify signature

@techtuga

i have completed my setup of CMK on RockyLinux 9.1 with the shipped mod_auth_mellon and i am facing the exact same issue as you have:

(process:8911): Lasso-CRITICAL **: 00:55:25.427: 2023-02-05 00:55:25 (tools.c/:1512) Error: failed to limit allowed signature transforms

[Sun Feb 05 00:55:25.427386 2023] [auth_mellon:error] [pid 8911:tid 8911] [client 127.0.0.1:39914] Error processing authn response. Lasso error: [-111] Failed to verify signature., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)", referer: https://login.myIDP.tld/

After that i have installed (from repo) both mod_auth_mellon and lasso, changed the reference in auth.conf.
With no difference in result unfortunately.

So it seems Lasso 2.7.0 is both broken in the shipped version, as well as when using the version supplied in the repository.

  • Glowsome

Hi Glowsome,

That’s very kind from your part to test it on your end, so it’s confirmed SW issue.
I have opened a support ticket with Lasso, till now no response. Let’s see

Will post here any update i might get.

Have a nice rest of weekend,
Fred

I did some more testing, and pulled a 2.8.0 lasso rpm from https://lemonldap-ng.org/redhat/extras/9/x86_64/lasso-2.8.0-1.el9.x86_64.rpm

But unfortunately this also has not change behaviour.

Been digging a bit further into this, and the distinct difference i see between Lasso 2.6.1 code and 2.7.0 (and up) is the code on tools.c.

2.6.1 ( https://repos.entrouvert.org/lasso.git/tree/lasso/xml/tools.c?id=92d12b995459c01ccba48d8b99bd69b09f00f5b1#n1488 ) Starting Line 1488

lasso_saml_constrain_dsigctxt(xmlSecDSigCtxPtr dsigCtx) {
	/* Limit allowed transforms for signature and reference processing */
	if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NWithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NWithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11WithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformDsaSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha1Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha256Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha256Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha256Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha384Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha384Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha384Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha512Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha512Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha512Id) < 0)
			) {

		message(G_LOG_LEVEL_CRITICAL, "Error: failed to limit allowed signature transforms");
		return FALSE;
	}

2.7.0 ( https://repos.entrouvert.org/lasso.git/tree/lasso/xml/tools.c?id=0d34c97be1c761a9eb12692e4cc4eac58feb7d19#n1500 ) starting line 1500.

lasso_saml_constrain_dsigctxt(xmlSecDSigCtxPtr dsigCtx) {
	/* Limit allowed transforms for signature and reference processing */
	if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NWithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NWithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11WithCommentsId) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha512Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha512Id) < 0) ||
			(xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha512Id) < 0)
			) {

		message(G_LOG_LEVEL_CRITICAL, "Error: failed to limit allowed signature transforms");
		return FALSE;
	}

As from that point on they seem to have taken out the SHA1, SHA256 and SHA384- checks.

So even setting the suggested option

update-crypto-policies --set LEGACY

will not do anything, as the whole routine to allow/evaluate SHA1/SHA256/SHA384 has been taken out.
In other words, the coder(s) of the Lasso-package have taken matters into their own hands, no longer adhering to backwards-compatibillity of a/the system.

  • Glowsome

@techtuga

Question, you said you compiled the 2.8.0 version of Lasso and tested it.

if you were to re-compile with a change in the tools.c file:

Change the routine (starting at Line 1500):

lasso_saml_constrain_dsigctxt(xmlSecDSigCtxPtr dsigCtx) {
        /* Limit allowed transforms for signature and reference processing */
        if((xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NId) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NId) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14NWithCommentsId) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformExclC14NWithCommentsId) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformInclC14N11WithCommentsId) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha256Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha256Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha256Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha384Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha384Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha384Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformSha512Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformHmacSha512Id) < 0) ||
                        (xmlSecDSigCtxEnableSignatureTransform(dsigCtx, xmlSecTransformRsaSha512Id) < 0)
                        ) {

And then re-test with this version ?

I have re-added the evaluations for SHA256/SHA384.

Tried to compile on my Rocky-box, but somewhere its failing dependancies 
 even tho i meet all requirements.

  • Glowsome

Hi Glowsome,

Sorry for my late reply, was occupied with some other matters.
Actually i am using a Centos 7 testbox to compile the package.
After compiling, exported liblasso.so.3.15.0 to the Alma 9.1 box.

> ls -ltra /usr/lib64/liblass*
-rwxr-xr-x 1 root root  556056 Feb  9  2022 /usr/lib64/liblasso.so.3.13.1
-rwxr-xr-x 1 root root 2078696 Feb  2 15:56 /usr/lib64/liblasso.so.3.15.0
**lrwxrwxrwx 1 root root      24 Feb 10 14:28 /usr/lib64/liblasso.so.3 -> /root/liblasso.so.3.15.0**

The error/result is the same as before :frowning:

I am slowly running into a dead end here as to where the developers of Lasso went completely haywire ( my opinion)
I mean with enough effort i can probably fix it, but that will not guarantee any changes if i were to put in a pull-request with the proposed changes.

In this, for now the combination of CMK and RHEL 9.x - based distro’s seem to be a dead end for supporting the current implementation with SAML on the level of using a module in the httpd/Apache server itself.

At current i am putting effort in a similar setup, but then by using OIDC, which has a less restrictive relation with a/the IDP.

Current status on this implementation:
Authentication has been set up, but at the first redirect i seem to end up on port 5000 ?
→ needs investigation, as when reloading/re-entering/stripping the url of its port, then i am logged in correctly.

  • Glowsome
1 Like

Same problem here. I’m trying to set up SSO between checkmk and AAD.
Different Linux distribution (centos7)

[Fri Feb 24 14:17:13.739622 2023] [auth_mellon:error] [pid 9516] [client 127.0.0.1:47596] Error processing authn response. Lasso error: [-201] The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer()., SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Success", StatusCode2="(null)", StatusMessage="(null)", referer: https://login.microsoftonline.com/

Hi there,

This error means that your metadata does not contain the same entityID that the one given in the SAML request/responce.
Better said it is a ‘trust-issue’.
Did you correctly exchange metadata ?

  • Glowsome

Hi Glowsome,

Did you by any chance advanced with the OpenID implementation?

Br,
Fred

@techtuga

i’ve been a bit busy, on-and off with some testing.

Still have not figured out why after authentication at IDP i get a redirect to port 5000.
was testing to implement the OIDC statements in a different file/level but have not yet gotten further.

So Work-in-progress, to be continued :slight_smile:

  • Glowsome

afaik OMD is running at port 5000 and the apache on 443 is redirecting

think so. Used the xml from the checkmk to create the enterprise app and used the xml from AAD as idp-metadata.xml on the checkmk server


I deleted the whole AAD setup and created it again. Now it’s working

User still can’t log in. I need to create the user in checkmk with the UID of checkmk = UPN of AAD

If the attribute contains (aka UPN username@something or AD-style DOMAIN\Username) you will have to modify the part of setting the Header, and then edit the header.

See documentation Authentication with SAML

Also CheckMK expects the identical casing of the username so Glowsome != glowsome

  • Glowsome

This is correct, i just need to find the setting where i pass the identity after login without getting stuck on port 5000 (which is defined as proxypass in the Apache config)

  • Glowsome

@techtuga, @fdutenho

Well i think i solved it for a/the most simple setup, i needed to add the directive:

  • OIDCXForwardedHeaders X-Forwarded-Host

please see https://forum.checkmk.com/t/howto-cmk-with-oidc-authentication/37168

be aware: the UPN is case sensitive. Even though ist in most cases the email address


Hi Glowsome,

Following the OIDC wiki still don’t get there.
It presents the normal checkMK login and turning on the developer tools there is no request or whatsoever to the remote IDP.
This is my monitoring site auth.conf:

Define SITE monitoring
ServerName https://example.com
<IfModule !mod_auth_openidc.c>
        LoadModule auth_openidc_module /usr/lib64/httpd/modules/mod_auth_openidc.so
</IfModule>
OIDCProviderMetadataURL https://example.com/428f5-f266c725c32c/v2.0/.well-known/openid-configuration
OIDCClientID a10333441-86d9-414e-a8f7-6734fdkdsl65da347
OIDCClientSecret IR933Q~9P~_u7Bll444ZLxdTfWOXfgwwVLW-cg1
OIDCRedirectURI https://example.com/${SITE}/check_mk/redirect_uri
OIDCCryptoPassphrase 2wm00kQwh2uTrLscwfLqJRnZSbWHEC4p
OIDCScope "openid email profile"
OIDCRemoteUserClaim upn
OIDCXForwardedHeaders X-Forwarded-Host
<Location /monitoring>
  AuthType openid-connect
  Require valid-user
</Location>

Anything im missing here?

Thanks,
Fred

Hi @techtuga

First of all:

  • Do NOT share your ClientID / Secret in code

And you should have adapted the original auth.conf, and only adapt/add the configuration for the module to it.
ONly thing that should be added in the Location directive ( as you have done) the authtype openid-connect and require valid-user

<Location /${SITE}>

        # Use OpenID-Connect auth only in case there is no Checkmk authentication
        # Cookie provided by the user and whitelist also some other required URLs.

    <If "! %{HTTP_COOKIE} =~ /^auth_${SITE}/ && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
        ! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
        ! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
                ! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">

                Order allow,deny
                Allow from all

                AuthType openid-connect
                require valid-user

But i would suggest if you want to discuss OIDC more then switch to that Howto-thread, so we keep this one clean for SAML :slight_smile:

  • Glowsie