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:
Example changing IdP session storage
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
Property | Type | Default | Description |
---|---|---|---|
idp.storage.cleanupInterval | Duration | PT10M | Interval of background thread sweeping server-side storage for expired records |
idp.storage.htmlLocalStorage | Boolean | false | Whether to use HTML Local Storage (if available) instead of cookies |
idp.storage.clientSessionStorageName | String | shib_idp_session_ss | Name of cookie or HTML storage key used by the default per-session instance of the client storage service |
idp.storage.clientPersistentStorageName | String | shib_idp_persistent_ss | Name of cookie or HTML storage key used by the default persistent instance of the client storage service |
idp.session.StorageService | Bean ID of a StorageService | shibboleth.ClientSessionStorageService | Storage back-end to use for IdP sessions, authentication results, and optionally tracking of SP usage for logout |
idp.consent.StorageService | Bean ID of a StorageService | shibboleth.ClientPersistentStorageService | Storage back-end to use for consent and terms-of-use records |
idp.replayCache.StorageService | Bean ID of a StorageService | shibboleth.StorageService | Storage back-end to use for message replay checking (must be server-side) |
idp.replayCache.strict | Boolean | true | Whether storage errors during replay checks should be treated as a replay |
idp.artifact.StorageService | Bean ID of a StorageService | shibboleth.StorageService | Storage back-end to use for short-lived SAML Artifact mappings (must be server-side) |
idp.cas.StorageService | Bean ID of a StorageService | shibboleth.StorageService | Storage back-end to use for CAS ticket mappings (must be server-side) |
Storage Implementations
There are three functionally-complete implementations of the storage interface supplied with the software.