...
The SP faces serious challenges as a sustainable piece of software:
It contains many thousands of lines of C++ code. This code is of a complex nature, written in a complex idiom that is also dated. It has been difficult, essentially impossible, to identify new programming resources able to assume responsibility for the code as the original developer gets closer to a possible retirement.
Its key XML and security dependencies are large, complex code bases in their own right that face even more dire maintenance challenges than the SP itself, as we essentially subsidize their continued existence out of necessity. The only "stable" project among the largest dependencies is OpenSSL, and it faced its own existential crisis only a few years ago. The possibility of a significant security issue that is difficult to fix given ordinary effort is very much on the table.
Some of the features we might like to support (e.g. ECDH encryption, possibly even OIDC support) are much more difficult to add if they have to be built from scratch or at least in C++.
On the other hand, the feedback from the membership is that many organizations see significant value in what the SP does and more importantly in how it does that job:
There is concern that other options for SAML support in a native Apache or IIS footprint also lack clear sustainability (i.e, they're in the same boat, ultimately).
Concern has also been raised that mod_authn_oidc may be a suitable replacement but is itself a large code base without a bench of developers to support it.
Several members expressed the view that a lot of value and trust is attached to the "brand" we represent when it comes to supporting our code. A solution we support is seen as very desirable.
As the author, I would add that rough edges aside, the code base we have provides a number of compelling features that are probably valuable in their own right to repurpose in a new form, such as the integration between Apache configuration and a portable syntax that spans both Apache and IIS (and other integrations potentially), and a cookie-based session clustering feature.
...
We would like to get consensus quickly around these constraints:
The amount of C/C++ code should be kept to an absolute minimum, requiring that as much as possible be offloaded to "something else". For now, let's refer to "something else" as a "processing hub".
Given current project development resources and direction, the processing hub would likely be in Java but that isn't an inherent requirement as long as appropriate resources are identified to own the work long term.
The C/C++ code needs to be as self-contained as possible, in particular not relying on any libraries not present on virtually any Linux distribution. Plausibly it may be worth abstracting more of the code to leverage native Windows APIs in some areas to further limit dependencies.
Corollary: there should be no XML or XML security dependencies or processing in C/C++ to eliminate that set of dependencies.
Corollary: logging would be limited to pre-existing options, such as Apache, syslog, and/or Windows event logging and would not use an additional library.
Ideally packaging other than perhaps Windows would be farmed out to other groups of people, with funding used to incentivize that. This is more viable if we can limit the frequency of updates, akin to the way many other Apache modules tend to be much more static.
The replacement needs to support at least Apache 2.4 and IIS 7+. Supporting older versions may be in question since it increases the amount of code needed.
Some degree of configuration compatibility would be nice. Since that requires supporting XML configuration files, that may imply "outsourcing" the processing of the configuration to the processing hub. That might not be a hugely disruptive change in certain respects and the system would be inoperable without that processing hub anyway.
Deployment of the processing hub needs to be as streamlined as possible, likely including embedding a web server to allow more of a stand-alone appliance feel. If Java, this would likely filter back to the IdP eventually, providing added benefits.
Mutual TLS with some standard trust management assumptions is sufficient to secure module/processing hub exchanges, allowing that one might architect other options if they don't violate the other requirements.
A single processing hub should be expected to service multiple, discrete deployments of the module operating with their own "local" configurations.
There would be no expected communication paths between the module(s) and any systems other than the processing hub. That is, direct communication for, e.g., the purposes of SAML artifact resolution (in either direction), SAML attribute queries, potentially future OIDC callbacks,etc. would be handled solely by the processing hub.
Conversely, the processing hub is not intended to become a gateway/proxy in its own right because we already have that now. If people want to replace the SP with other agent solutions, we already have support for that using the IdP along with all the other proxies people could choose. So, the hub is not intended to ever interact with user agents directly.
Strawman Proposal
Design a publically-documented web service API for required operations such as:
obtaining a configuration for the module (e.g., this might be managed by the hub or obtained by uploading a local configuration to process it into a consumable form)
producing discovery and SSO requests
validating and processing SSO responses into session data
logout
possibly consuming session recovery cookies?
???
The API would be a key deliverable to enable theoretically independent implementations of both halves of the system, which was a deliberate non-goal of the current design.
...