The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

NativeSPArchitecture

Owned by Scott Cantor
Last updated: Feb 17, 2011

The Shibboleth SP is native/compiled software that is divided into a pair of components: a background service or "daemon" process called "shibd", and a loadable module or filter (the term varies by web server) that is plugged into the web server behind which you want to host protected applications or content. Both halves depend on a number of libraries, some common to both, others specific to one half or the other.

These two components are independent at the OS/process level and do not share state or memory; instead they communicate using some kind of local or network-based communication mechanism called a "listener". The two halves can generally be restarted independently of each other, but "shibd" must be running for a web server that includes the Shibboleth loadable module to work properly in most cases.

Some of the SP's configuration is shared between the two "halves", because some of the communication between the two depends on this configuration being "in sync" across each part of the system. Other parts of the configuration are used only by one half or the other. In practice you don't have to care about this very much, but if you make drastic changes to your configuration, it's usually good practice to restart both halves to avoid problems.

Why a Daemon?

People are sometimes confused as to why the SP includes a daemon/service component instead of just a web server module or filter.

The primary reason for this is straightforward: the SP includes a cache of session information that is generally of arbitrary size, 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 maintain that state for a single server is to manage 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 access data originally encrypted by an IdP.
  • System stability is improved by limiting the code that needs to run inside web server processes.