...
- 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 money available 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 a in question since it increases the amount of extra 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.
The web service format will need to be such that producing and parsing it doesn't violate the design constraints. JSON might be is of course an option but even that may pull in more code than would be preferred, depending on what Apache's APR library supports these days.
Done correctly, it may be possible to fully abstract this API away from SAML and allow for other protocols to be supported as long as they generally fit the same message exchange pattern.
...
The processing hub would presumably be built in Java using OpenSAML, other existing libraries, and possibly some portions of the IdP code (probably moved to a new shared library). It would probably be based on Spring and Spring Web Flow as the IdP is now. Much of the logic for this exists already in the IdP's proxying support.
Obviously the SAML keys used would be held at the hub, and would out of necessity (because of bugs in ADFS) have to allow for potentially many sets of keys.
Naming is interesting. The entityID(s) should really be a problem for the hub, but there will have to be some kind of identification of the modules connecting to it to tie to the proper SSO configuration, and the ApplicationOverride concept will have to be captured in some way.