Occasionally people seem confused as to why the Shibboleth SP includes a daemon/service component, called shibd, instead of just a web server module or filter.
The primary reason for this is straightforward: the SP includes a cache of session information and can provide cookie-based session semantics to applications independently of the application's own language or framework. Most web servers today run as a pool of processes, even if this pool is small, and the simplest way to provide such state for a single server is to store it in a separate process.
It turns out, however, that there are several other advantages to this design even if state were not a requirement:
- Many significant libraries need not be linked into the web server, minimizing conflicts and speeding up process creation.
- Access to private keys can be restricted to the daemon process and not granted to the web server, while still allowing applications on the server to receive encrypted data.
- System stability is improved by limiting the code that needs to run inside web server processes.