SAML doesn't work anymore after Update to 7.0

[koelle25]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

The SAML login does no longer work. Only a general error message "There was a problem while trying to log you in, please try again." is shown, even in debug mode. Besides the Snipe-IT upgrade there were no other changes.

In the laravel.log file the underlying issue is shown:

The response was received at http://assets.example.com/saml/acs instead of https://assets.example.com/saml/acs

Reproduction steps

1. Have a working SAML authentication in v6.x
2. Upgrade to v7
3. SAML authentication does not work anymore

Expected behavior

SAML authentication keeps working

Screenshots

Snipe-IT Version

7.0.3

Operating System

Official Docker Image (Ubuntu 22.04.4)

Web Server

Apache/2.4.52

PHP Version

PHP 8.1.2-1ubuntu2.17

Operating System

Windows 11

Browser

Firefox

Version

115.12.0esr

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

storage/logs/laravel.log

[2024-06-18 13:49:00] production.WARNING: APP_LOCALE in .env is set to en and should be updated to be en-US
[2024-06-18 13:49:38] production.ERROR: There was an error with SAML ACS: invalid_response
[2024-06-18 13:49:38] production.ERROR: Reason: The response was received at http://assets.example.com/saml/acs instead of https://assets.example.com/saml/acs

Container logs

Considering dependency socache_shmcb for ssl:

Module socache_shmcb already enabled

Module ssl already enabled

   INFO  Nothing to migrate.  

   INFO  Configuration cache cleared successfully.  

   INFO  Configuration cached successfully.  

2024-06-18 13:33:40,118 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.

2024-06-18 13:33:40,120 INFO supervisord started with pid 1

2024-06-18 13:33:41,123 INFO spawned: 'exit_on_any_fatal' with pid 36

2024-06-18 13:33:41,126 INFO spawned: 'apache' with pid 37

2024-06-18 13:33:41,128 INFO spawned: 'run_schedule' with pid 38

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.255.3.12. Set the 'ServerName' directive globally to suppress this message

   INFO  No scheduled commands are ready to run.  

2024-06-18 13:33:42,344 INFO success: exit_on_any_fatal entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2024-06-18 13:33:42,345 INFO success: apache entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2024-06-18 13:33:42,345 INFO success: run_schedule entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

   INFO  No scheduled commands are ready to run.

==> /var/log/apache2/access.log <==

10.255.1.3 - - [18/Jun/2024:13:35:30 +0200] "GET / HTTP/1.1" 302 1659 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:30 +0200] "GET /login HTTP/1.1" 302 1684 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:30 +0200] "GET /login/saml HTTP/1.1" 302 910 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "POST /saml/acs HTTP/1.1" 302 1229 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /login HTTP/1.1" 200 3959 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /vendor/livewire/livewire.js?id=90730a3b0e7144480175 HTTP/1.1" 200 45324 "https://assets.example.com/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /css/dist/all.css?id=a9f493a1d66b45420401f3ae8ee4aab1 HTTP/1.1" 200 75012 "https://assets.example.com/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /js/dist/all.js?id=99df559d106d7c1da6beff663646d76f HTTP/1.1" 200 299493 "https://assets.example.com/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /css/webfonts/fa-solid-900.woff2 HTTP/1.1" 200 156635 "https://assets.example.com/css/dist/all.css?id=a9f493a1d66b45420401f3ae8ee4aab1" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
10.255.1.3 - - [18/Jun/2024:13:35:34 +0200] "GET /favicon.ico HTTP/1.1" 200 18157 "https://assets.example.com/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"

Additional context

It's an upgraded instance (v6.4.2 --> v7.0.3). Additionally we had to use APP_FORCE_TLS=true, because without it the SAML login failed with "invalid redirect uri" (I guess because the redirect URI then started with http:// instead of https://) and the no-SAML login (/login?nosaml=1) had CSS issues. We use Traefik as a reverse proxy.

[koelle25]

It seems APP_FORCE_TLS=true is not respected when generating the redirect URI for the IdP.

[uberbrady]

It looks like there might be an option we can set called destinationStrictlyMatches which maybe we can flip over to false which might help here? I think, in the context of how we use the SAML library, that might be in the 'advanced settings' and be referred to as security.destinationStrictlyMatches ? Could be worth a shot to play with.

[chadfrownfelter]

I ran into this exact issue when using the docker container behind an application load balancer (AWS). To resolve this, I rolled back to the previous version, added the baseurl=https://assets.example.com/saml option to the SAML config (Admin Settings -> SAML -> SAML Custom Settings), and then pulled the latest v7 container. The documentation does mention this but I missed it originally since it was working fine prior to the upgrade.

[koelle25]

Oh, nice catch! Will definitely try that tomorrow. Am 18. Juni 2024 14:21:27 UTC schrieb Chad Frownfelter ***@***.***>:

…

I ran into this exact issue when using the docker container behind an application load balancer (AWS). To resolve this, I rolled back to the previous version, added the `baseurl=https://assets.example.com/saml` option to the SAML config (Admin Settings -> SAML -> SAML Custom Settings), and then pulled the latest v7 container. The [documentation](https://snipe-it.readme.io/docs/saml#:~:text=When%20you%20run%20Snipe%2DIT%20behind%20a%20reverse%20proxy%20the%20following%20property%20might%20be%20necessary%3A%20baseurl%3Dhttps%3A//assets.example.com/saml) does mention this but I missed it originally since it was working fine prior to the upgrade. -- Reply to this email directly or view it on GitHub: #14895 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[MarijnMB]

We're experiencing the same issue.

Message: AADSTS50011: The reply URL 'http://inventory.oursite.com/saml/acs' specified in the request does not match the reply URLs configured for the application 'https://inventory.oursite.com/'. Make sure the reply URL sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/urlMismatchError to learn more about how to fix this.

Specifying baseurl=https://inventory.oursite.com/saml in the customSAML settings does not resolve this when upgrading from v6.4.3 to v7.0.3

[koelle25]

✅ I just tried it, and in my case the addition of baseurl=https://assets.example.com/saml did work! Thanks for pointing out @chadfrownfelter .
Note: I don't know if it was really necessary, but after adding the setting I restarted the container.

[koelle25]

@MarijnMB :
Maybe looking at the SAML Response can help? See Debug SAML Settings. After applying the baseurl setting, my SAML Response looks like this:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://assets.idial.institute/saml/acs" ...

Maybe also doublecheck again your IdP client setings. My client settings in Keycloak look like this:

[koelle25]

Oh, I just noticed while checking the SAMLResponse that the RelayState still has the wrong URL:

Interesting that it works nevertheless (in my environment). But that may be your issue @MarijnMB.

Does someone have any idea how to fix this?

[snipe]

@koelle25 we pushed out a few changes yesterday (and this morning) to try to help folks behind a proxy. Can you give latest from master a shot, and/or add APP_FORCE_TLS=true in your .env?

[koelle25]

I'm on 7.0.4 now. SAML auth (still) works (at least for me), but I still have both APP_FORCE_TLS=true and baseurl=https://assets.example.com enabled/configured.

But upon inspection of the SAML Response, the RelayState is still starting with http:// (see screenshot from my post above).

[Joly0]

I am having the same issue on 7.0.4 and i cant fix it using the APP_FORCE_TLS=true and baseurl=https://assets.example.com environment variables

[koelle25]

I am having the same issue on 7.0.4 and i cant fix it using the APP_FORCE_TLS=true and baseurl=https://assets.example.com environment variables

Try again with baseurl=https://assets.example.com/saml/ (/saml/ seems to be important)

[Joly0]

I am having the same issue on 7.0.4 and i cant fix it using the APP_FORCE_TLS=true and baseurl=https://assets.example.com environment variables

Try again with baseurl=https://assets.example.com/saml/ (/saml/ seems to be important)

Nope, still does not work

[Joly0]

Ok, now it seems to work. Adding baseurl=https://assets.example.com/saml/ as an enviroment variable like APP_FORCE_TLS=true does not help, but adding it to the SAML Custom Settings in the webui works

[madhancock]

Ok, now it seems to work. Adding baseurl=https://assets.example.com/saml/ as an enviroment variable like APP_FORCE_TLS=true does not help, but adding it to the SAML Custom Settings in the webui works

This is working for me. We're using Azure Front Door + Azure Container Apps.

v6 was working fine but v7 requires these adjustments. As others have mentioned, the relaystate in the acs call is wrong (in our case it reports the hostname of the ACA instance instead of the configured app URL).

[uberbrady]

I'm really happy to hear that it sounds like we have a workaround! That's great news.

But we're working on an actual code-fix for that as well; the discussion for that is happening in #14919 - as well as the code-workaround. If any of y'all want to take a swing at that test I mentioned there, it would really be appreciated. Thanks!

[thesorskod]

SAML was working great with Azure for us.
not sure which update, but SSO is no longer working for us also seen in the logs

[2024-06-24 13:27:50] production.ERROR: There was an error with SAML ACS: invalid_response [2024-06-24 13:27:50] production.ERROR: Reason: The response was received at http://assets.mydomain.com/saml/acs instead of https://assets.mydomain.com/saml/acs

local access works fine for me using /login?nosaml without any custom or force variables added.

what is needed to get SSO working again after the update? 😒

UPDATE:

Ok, adding baseurl=https://assets.example.com/saml/ as an environment variable like APP_FORCE_TLS=true does not help, but adding it to the SAML Custom Settings in the webui works.

[uberbrady]

v7.0.6 just dropped and should include a fix for this issue.

[Joly0]

v7.0.6 just dropped and should include a fix for this issue.

Cool, just to be sure, i dont need the baseurl parameter anymore? Do i still need the app_force_tls env variable?

[uberbrady]

You should no longer need the baseurl Custom Saml Configuration parameter any more, no.

For the force TLS thing, you shouldn't need that env var any more? But you should give it a try and see if it works without, just to be sure.

[chadfrownfelter]

I can confirm I no longer need the APP_FORCE_TLS=true environment variable to load CSS assets correctly in v7.0.6 (running in docker behind a reverse proxy).

[snipe]

Excellent! Thanks for reporting back!

[uberbrady]

I can confirm I no longer need the APP_FORCE_TLS=true environment variable to load CSS assets correctly in v7.0.6 (running in docker behind a reverse proxy).

Thank you!!!!

[koelle25]

I can also report that neither the environment variable APP_FORCE_TLS=true nor the Custom SAML Configuration parameter baseurl are needed anymore!
CSS and other assets are loading without problems, and SAML authentication works as before again.