File(s): conf/global.xml, conf/idp.properties
Format: Native Spring
Overview
The IdP provides a number of general-purpose storage facilities that can be used by core subsystems like session management and consent. Broadly speaking, there are two kinds of storage plugins: client-side and server-side. Client-side plugins have the advantage of requiring no additional software or configuration and make clustering very robust and simple, but they only support a subset of use cases. Server-side plugins (aside from the simple case of storing data in memory) support all use cases, but require additional software and configuration, and usually create additional points of failure in a clustered deployment.
The IdP ships with 3 preconfigured org.opensaml.storage.StorageService beans:
- shibboleth.ClientSessionStorageService (of type ClientStorageService)
- Stores data in a browser session cookie or HTML local storage
- shibboleth.ClientPersistentStorageService (of type ClientStorageService)
- Stores data in a long-lived browser cookie or HTML local storage
- shibboleth.StorageService (of type MemoryStorageService)
- Stores data in server memory, does not survive restarts and is not replicated across a cluster
There are additional storage service plugins included in the software (JPA, memcached) but they are not predefined. Using them requires defining beans yourself and setting various properties to point to them.
By default, the shibboleth.ClientSessionStorageService bean, which stores data in the client, is used to store IdP session data, but that can be modified via the idp.properties file:
idp.session.StorageService = shibboleth.StorageService
There are additional properties that can be used to change how other data is stored on a per-use case basis, but note that some components can't rely on client-side storage options, and more specific documentation should address that.
Reference
Storage Implementations
There are three functionally-complete implementations of the storage interface supplied with the software.