...
- in-memory using a hashtable
- client-side using secured cookies (optionally HTML5 Local Storage)
- relational database via Hibernate
- memcached
...
An alternative strategy available relies on a JDBC connection to a relational database with a specialized table layout (one that is compatible with the StoredID connector plugin provided in V2). The requirements of this use case make it impractical to leverage the more generic StorageService API, but the IdP is extensible to other approaches to handling this data.
The NameIDGenerationConfiguration PersistentNameIDGenerationConfiguration topic describes this feature in more detail.
...
- Replay detection is limited, of course, to a per-node cache.
- Single logout, planned as an optional feature in a future release, is not supported due to the lack of space in cookies for tracking the sessions, but you can support this if you enable use of Local Storage.
- SAML 1.1 artifact use is not supported if more than one node is deployed, because that requires a global store accessible to all nodes.
- SAML 2.0 artfact use is not supported by default if more than one node is deployed, but it is possible to make that feature work with additional configuration (discussion TBD).
- CAS support is not available if more than one node is deployed, because that requires a global store accessible to all nodes.
To combine these missing features with clustering requires the use of alternative StorageService implementations (e.g., memcache, JPA/Hibernate, or something else). This can in part be overridden via the idp.replayCache.StorageService3.1 and idp.artifact.StorageService3.1 properties (and others). A more complete discussion of these options can be found in the StorageConfiguration topic.