Plan for SAML Authentication 4.x

Because the module evolved so slowly, this issue has evolved with it over major releases.

My current plan for a 4.x rewrite follows. This is just my personal plan, it has no timeline, and I have no idea if the bigger things will happen. There is no sponsor.

Theme: keeping the same functionality while adding automated tests, becoming more logically structured (and therefore easier to work on), and helping other external authentication modules achieve success faster.

1) things that will happen

📌 Get rid of deprecated code (breaking D8 compatibility) Fixed are relatively small changes that must happen before Drupal 10 - so will trigger a 4.x release before D10 is stable. (Outdated / untrue: the 8.x-3.x now supports Drupal >=9.2 and D10 since 8.x-3.6. This -raising the minimum supported Drupal version in a minor release- is fine, and module major version changes actually should not be tied to Drupal major version changes.)

2) things that will likely happen before 4.x is released

📌 Refactor SamlService::getAttributes() to a value object. Active (issue is a bit windy, may be split up)

#3211531: Remove Forwarded-For-*/proxy config settings → (easy)

#3211530: Move login/logout error handling to event subscriber →

📌 Reimplement response caching on login/logout routes Active (not super urgent)

3) things that I'm interested in but take more work than I can commit to

Work on externalauth.

• I've made a start at a plan in ✨ Redo authmap_alter / register events. Needs review . Basic summary: basically 'noone' is using externalauth's events. I want to change them so they become more usable. Some aspects of the current patch may change still - but the important part is getting the change to the events in. If that doesn't happen, I'm going to build this module on a forked ExternalAuth class.
• I'd also love to move parts of samlauth into externalauth so they can be made useful for more modules. (This would make the v4 code smaller even though no functionality gets lost.) I have my eye on:
  • linking an existing user by name/e-mail
  • the logic around locking the current e-mail/password elements on the user edit screen
  • our UI for attribute synchronization and role assignment. (Part of it will need to be split into general base classes, and our own module can build on those to implement the SAML-attribute specific parts.)
  • bits and pieces, e.g. flood control. (There isn't much general we can do there, but moving it into externalauth as example code means the other modules don't forget about it.)

In 2023 I wrote up a plan for doing the whole second point, in 🌱 Datahandler plugins, (optionally) mappable from login providers Active . This likely makes #3179148 obsolete. (I don't have buy-in from others yet though, so until I work on it / someone comments on it, both issues are open.) This means one of two things will likely happen, if anything:

• Instead of ✨ Redo authmap_alter / register events. Needs review , fork the ExternalAuth service (which implies not caring too much about future compatibility with externalauth module). When that is done, I can apply #2925171-14: Use externalauth::register event vs hook_user_presave → , which un-spaghettifies this module's code considerably, and makes it easier to write tests.
• Rewrite externalauth per 🌱 Datahandler plugins, (optionally) mappable from login providers Active . This decreases this module's code considerably, and moves all the icky parts (fixed and tested) into externalauth.

Doing the first point is not ideal, but might happen if anyone 1) cares enough about un-spaghettifying this module's code / stopping to use hook_user_presave, 2) does not care that much about theoretical future externalauth compatibility; 3) agrees that the second point is just way too much work (even if it's better for other externalauth-using modules).

After this, we can pick up part 2 of 📌 Write tests Active - or whatever part of that is still needed.

NOTE: Extensions of functionality can still be done in 3.x branch:

🌱 NameID support Fixed

#3208564: Option to only sync fields on account creation/linking vs every login →

Part 1 + 3 of 📌 Write tests Active

---
Original issue text:
Release roadmap?

Hi,

Are there specific features or bugs that need to be completed before this module can be released (vs. an alpha release)?

Thanks!