Problem/Motivation
samlauth >= 8.x-3.3 changed its configuration structure. I forgot to check how that would influence ACSF. Sorry about that.
samlauth still reads configuration values from the old locations for now, but
- only if the new locations are not populated. (So below effect 1 likely only manifests after running update.php on a newer samlauth module.)
- this 'backward compatibility' behavior is not going to be around in the samlauth module forever.
This has two separate kinds of effects after samlauth >= 8.x-3.3 is installed:
1)
What happens: On non-live environments, on every request, acsf's SamlauthRequestSubscriber overrides (in-memory) configuration values at an 'old' location/key.
Effect: people get errors on login*: "Signature validation failed. SAML Response rejected". Reason: the live IDP certificate value is seen (because it is read from the new config location / isn't overwritten with the non-live certificate). Reported in
🐛
v3.3 change in configuration values breaks ACSF
Active
Fix: apply included patch / update to fixed acsf module; errors will go away.
2)
What happens: On all environments, acsf.install saves the IDP certificate configuration value for newly provisioned sites into the 'old' location.
(Note the non-zero possibility that some people do a test upgrade to the new ACSF module, forget to check if login works on test, do not see the failure from effect 1, and then upgrade their live env.)
Immediate effect: nothing for now, on the live environment.
Longer term effect: you now have sites with the IDP certificate written into two locations:
- older sites that were provisioned before 8.x-3.3 was installed, will have IdP cert config moved to the new location by samlauth_update_8305()
- newer sites that were provisioned after 8.x-3.3 was installed / without the included patch, will still write IdP cert config to the old location.
This can cause breakage for login to those newer sites, when the 'compatibility layer' in 8.x-3.x, which reads values from the old location, is removed. I plan to do this in samlauth 4.0.0 (and will likely release alpha versions that still have it). At the same time, I'll include an update hook that re-checks/re-moves the IdP cert value again.
This means that if any sites upgrade to samlauth v4.0.0+ without having the included acsf patch applied, then 1) the sites provisioned after previously upgrading to samlauth 8.x-3.3+ will break login on the live environment; 2) you are on your own in making an upgrade script that fixes the configuration.
So I urge you to apply this patch in a new release that drops compatibility with samlauth <8.x-3.3, before samlauth 4.0.0 is released - for your own sake.
Steps to reproduce point 1
- install samlauth >= 8.x-3.3 on test
- run code update (I think it doesn't happen if the code is replaced without running update hooks)
- see login failures.
Remaining tasks
- Apply patch. Test it; I didn't.
- Recommended: figure out your composer dependencies for acsf_sso. (The patch only has the updated dependency in the info.yml so far.)
If you don't add the composer dependency, there's a chance the customer will not update to samlauth >= 8.x-3.3 while installing the new acsf_sso.
- I think this won't have any immediate effect and the config will likely be rectified on a samlauth 4.0.0 upgrade (see point 2 above)... but still, IMHO this is a good time to figure things out.
- ...but that any new sites created with the updated acsf module that do not upgrade to samlauth >= 8.x-3.3 at the same time (which is the inverse of above bolded statement), will have immediately-breaking login on all environments
- Note I still haven't figured out what is the recommended drupal policy: all dependencies in root composer.json or a separate acsf_sso/composer.json (does a standard Drupal composer install pick these up)?)
- Then release this fix in an acsf version where acsf_sso has a dependency on samlauth >= 8.x-3.3, in both the composer.json and the info.yml file.
If you see any holes in this reasoning / where your customer sites can still end up with wrong config and samlauth should assist with that... let me know.