...
- Spring Web Flow conversational state during profile request processing (essentially a single login, query, or other operation)
- An "IdP session" capturing authentication results (so they can be reused for SSO) and optionally tracking services for logout
- Attribute release and terms of use ("consent") store
- Message replay cache
- SAML artifact store
- CAS ticket store
The first two few are examples of per-client state that, subject to implementation constraints, can potentially be stored in the client. Consent storage can (and is) supported client-side, but is very limited in space and utility there. The last two others are examples of cross-client state that by definition have to be managed on the server node (or a data store attached to each node). In every deployment, then, there can be a mix of state with different properties.
...
While some containers do have the capability to serialize session state across restarts or replicate sessions between nodes, and Spring itself Web Flow is able to leverage that mechanism, the IdP does not support that because the objects it stores in the session are not required to be "serializable" in the formal Java sense of that term. This greatly simplifies the development of the software, but makes clustering harder.
...
All other state in the IdP falls into a second category, that of "non-conversational" data that the IdP stores and manages itself. The majority of this data is read and written using the new org.opensaml.storage.StorageService API. Any implementation of this API is able to handle storage for a wide range of purposes within the IdP.
...
- in-memory using a hashtable
- client-side using secured cookies (optionally and HTML5 Local Storage)
- relational database via Hibernate
- memcached
...
Excluding user credentials and user attribute data more generally, there is one exceptional case of data that may be managed by the IdP but is not managed by the unified StorageService API discussed above.
By default, the strategy used to generate "persistent", pair-wise identifiers for use in SAML assertions is based on salted hashing of a user attribute, and does not store any data.
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 V2older versions). 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 message replay cache and SAML artifact store use an in-memory StorageService bean.
- The IdP session manager uses a cookie- and HTML Local Storage-based StorageService bean (with session cookies) and does not track SP sessions for logout.
- The attribute release and terms of use consent features use a cookie- and and HTML Local Storage-based StorageService bean (with persistent cookies) and support a very limited history of decision tracking.
The Local Storage use and logout defaults are applicable to new installs, and not systems upgraded from V3.
The cookieclient-based side StorageServices used in the default configuration uses use a secret key to secure the cookies and storage blobs, and this key needs to be carefully protected and managed. Tools Simple tools to manage the secret key are provided.
These defaults mean that, out of the box, the IdP itself is easily clusterable with the most critical data stored in the client and the rest designed to be transient, making it simple to deploy any number of nodes without additional software. This does not address the need to make authentication and attribute sources redundant, of course, as these are outside the scope of the IdP itself. The consent features are also quite limited in utility, but are at least usable without deploying a database, though this is still highly recommendedassumed for real-world use of the feature.
Provided some form of load balancing and failover routing is available from the surrounding environment (see above), this provides a baseline degree of failover and high availability out of the box (with the caveat that high availability is limited to recovery of session state between nodes, but not mid-request), scaling to any number of nodes.
...
- Replay detection is limited, of course, to a per-node cache.Single logout, an optional feature, 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.StorageService 3.1 and idp.artifact.StorageService 3.1 properties (and others). A more complete discussion of these options can be found in the StorageConfiguration topic.