StorageService
- Rod Widdowson
- Scott Cantor
Overview
The <StorageService> element configures the component used for persistent storage of information by the shibd daemon across requests, and in some cases, restart of the software.
Other components are layered on top of this service for their storage needs, and you can define multiple versions and reference them as needed, although typically only one is used.
When omitted, the software auto-configures an in-memory storage service identified by id="mem".
Using Storage Plugins
Generally using an alternative storage option involves a number of steps, first configuring the storage plugin itself, and then actually telling various other components in the SP to actually use it. This typically involves referencing the storage plugin's id attribute, which will contain a short label you give it so you can reference it elsewhere in the file. Refer to the documentation for a specific feature for information on how that feature should be told to make use of the storage service (e.g., StorageServiceSessionCache, ReplayCache, SSO relay state or POST preservation).
Storage Server Types
A few different implementations are available. As with most plugin elements, the required type XML attribute defines precisely which type to configure. Each type may have its own Attributes and Child Elements specific to itself, as well as the common attributes noted below.
Note that only the in-memory option is guaranteed to be available. The others are provided only in cases where the necessary software to build and support the plugin are actually available in the OS.