...
Non-XML-based configuration support
Logging abstraction
syslog
Windows event log
Apache error log
DDF (remoted data representation and serialization)
HTTP transport between agent and Java hub
Curl-based implementation
Windows-based implementation
HTTP Request/Responose abstraction
Session cache
Session abstraction
File-backed implementation
Chunked cookie implementation
Handler framework
Session initiator handler
Token consumer handler
Logout handlers
Other handlers
Portable authorization via RequestMap
Web server bridges to interface to requests and responses
Portable authorization via RequestMap
Native modules
Apache 2.4 module
IIS module
FastCGI authorizer and requester
...
Token consumers will need to perform POST data recovery as they do now.
Logout Handler(s)
Logout hasn’t been looked at heavily in the context of the new design yet, but there will certainly be one, if not more, logout handlers needed. As with the rest, the requirement is for protocol neutrality/unawareness, so the intent is to relax a lot of the fancier requirements in these protocols and streamline the behavior down to “clear session found in client’s cookie” while punting subsequent behavior to the hub to manage. If we do back-channel logout at all, which I don’t favor, it would be in the form of some kind of storage-backed revocation process that would be enforced with some kind of poilling strategy.
Ideally, I would like to combine the current “local vs. full” logout distinction into one handler since all the protocol aspects would be shunted to the hub anyway. This is all very undercooked at this point.
Other Handlers
Some of the miscellaneous handlers in the current code probably will disappear, but a number will likely remain. These are generally just doing various things like status reporting, session debugging, etc. The DiscoFeed handler is probably something we can shunt over to Java, but security/DOS concerns might necessitate keeping a front-end to that local to the agents.
Portable Authorization
Apache has its own authorization framework (particularly in 2.4) but IIS doesn’t. We built an XML-based syntax to supplement things to support static enforcement of rules against attributes and various built-in variables. It currently hangs off the RequestMap structure but also was pluggable in theory. We would likely drop the pluggability but support the XML syntax.
One complication is that the current code supports reloadable use of external files to house rules, which will be additional code to keep/support.
Web Server Bridges
Each web server hosting an agent generally provides an API to interface to the server’s request and response handling, and the various modules today house classes that bridge from those APIs to the shared logic in the SP’s library that does most of the work in a more generic way. The bridges let that shared code read or set headers, issue responses or redirects, process request bodies, etc. That design would be expected to stay and much of that code probably will remain the same.
The most complexity there probably derives from the so-called “spoof-checking” logic that activates when populating headers is enabled.
Native Modules
The final built artifact in the new design is intended to be a single shared library module for the supported servers (or pair of executables in the case of FastCGI). The only real difference in terms of “size” would be the FastCGI case since the lack of an underlying library for shared code means both executables get big, but I’m not inclined to optimize around FastCGI for delivery. It’s a huge advantage to package a single file.
If other considerations lead to requiring additional binaries, we may revisit and continue to build a library to use the code that’s shared.
In practice the main piece that’s inside these modules today is the web server bridging logic and native configuration/startup/shutdown layers required for Apache and IIS.