v3.3 change in configuration values breaks ACSF

While I was typing up a response, I realized the acsf_sso module needs an update for this. Did I just break the compatibility contract by ceasing to use a certain configuration value? :( Then I have to keep that in mind for the future.

I'll whip up a draft patch (untested because no access to ACSF).

Patch posted in #3218895: Compatibility with samlauth >= 8.3 for your review.

I'm not sure that this is officially a breach of an implicit compatibility contract... the error happens because acsf_sso overwrites config values at runtime, which is an edge case.*

Still, it's dumb of me not to consider/check ACSF before releasing a new version.

* I think this happens only on non-live environments. Live environments are OK because they don't get config values injected at runtime. On non-live environments, the login process now sees the (saved) 'live' IdP certificate - which is why you get a "Signature validation failed" error, not a "Certificate not found".

+1 for freezing samlauth to 3.2 (for anyone who doesn't somehow need any of the features added in 3.3). ACSF historically isn't quick with its module updates.

I'll keep this issue open so the title stays in the queue... without doing work on it.

This just happened to me as well, is the recommendation to pin to version 3.2? We are using Site Factory and just can't have the SSO logins be broken for non production sites.

My recommendation would be to pin to version 3.2 unless you need new features from 3.3 (Key module support). In that case, patch acsf module with the patch in the related issue.

Hi,

I have a site on Drupal 9.5.3, with php 8.3.2. I installed samlauth 8.x-3.8 via composer. I wanted the ACS url to return as https instead of http.

I enabled various reverse_proxy values in settings.php and now I see the ACS url with https, but I get the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected" .

I went back to samlauth 8.x-3.2, and I am still getting the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected".

I reverted to samlauth 8.x-3.8 and was able to get this to work once I used the correct certificate.

This is what I had to enable in /var/www/devportal/web/sites/default/settings.php :

$settings['reverse_proxy'] = TRUE;

$settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];

Does this work with Acquia Connector 4?

@kevinquillen - I believe the answer is "yes; this issue only applies to the ACSF module specifically". (The Acquia Connector module has nothing to do with this error.)

Please check my reasoning:

• I do not know of Acquia Connector itself doing anything with SAML SSO. (Then again, I have only seen it briefly, years ago.)
• I'm assuming you are using the samlauth module + Acquia Connector on 'regular' Acquia hosting (not ACSF), and that you're using it to log in through an Identity Provider that is not part of Acquia's hosting infrastructure.

Then there's no issue. Specifics: ACSF has a custom (not equal to the 'regular') Acquia dashboard for managing its cookie-cutter sites, and people can log into their individual sites from the dashboard. That is -- this custom ACSF dashboard acts like a SAML IdP, and the bug is specifically in the auto-configuration of that Acquia IdP.

---

@minkahb - for completeness (to the other issue readers)

• from your description, I believe the site you have an issue with, is not on Acquia Cloud Site Factory (ACSF) -- so this issue is unrelated
• I'm happy you got it to work - your error indeed sounded like a local certificate issue.
• The reverse proxy settings should be documented in this module's readme; #3272609: Force HTTPS for ACS and SLS is open to remind me of this. (Though the value of $_SERVER['REMOTE_ADDR'] smells like something strange is going on in your case. I can't fully judge the situation, though.)

#3218895: Compatibility with samlauth >= 8.3 was fixed 8 months ago.