Page Comparison

...

1. 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".
2. 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.
3. 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.
   1. Corollary: there should be no XML or XML security dependencies or processing in C/C++ to eliminate that set of dependencies.
   2. 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.
4. Ideally packaging other than perhaps Windows would be farmed out to other groups of people, with money available 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.
5. The replacement needs to support at least Apache 2.4 and IIS 7+. Supporting older versions may be a question since it increases the amount of extra code needed.
6. 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.
7. 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.
8. 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.
9. A single processing hub should be expected to service multiple, discrete deployments of the module operating with their own "local" configurations.
10. 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.

Strawman Proposal

Design a publically-documented web service API for required operations such as:

...