...
Finally, be aware that fail over and load balancing are completely really outside the control of the IdP. These require some mechanism (some described below) for routing traffic before it even reaches a node.
...
Spring Web Flow conversational state during profile request processing (essentially a single login, query, or other operation). This refers to the start and finish of a particular “logical” operation being performed; the most common tend to be SAML, CAS, or (with the OP plugin) OpenID Connect authentication request and response sequences. In some cases this results in several HTTP request/response pairs and may even involve redirects to external sites in the middle.
An "IdP session" capturing authentication results (so they can be reused for SSO) and optionally tracking services for logout. This is state that is created by specific authentication requests but extends beyond their lifetime.
Attribute release and terms of use ("consent") storage
Message replay cache
SAML artifact store
CAS ticket store
The first 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 or utility there. The others are examples of crossmultiple-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 is a mix of state with different properties.
...
So, out of the box, the IdP software requires that flows involving views must start and finish on the same node, the most common example being a login that requires a form prompt or redirect.
While some Java containers do have the capability to serialize session state across restarts or replicate sessions between nodes, and Spring 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. We do not have plans at present to fix this restriction.
At present, there is no solution provided to replicate the per-request conversational state. This means that 100% high availability is not supported; a failed node will disrupt any requests that are in the midst of being processed by the node. It also means that some degree of session "stickiness" is required. Clients must have some degree of node affinity so that requests will continue to go to a single node for the life of a request. This was always strongly encouraged for performance reasons, but is now formally required.
The most common techniques for implementing this “stickiness” in load balancers are affinity based on client/source IP address, and affinity based on cookies. Using cookies of course requires that the load balancer implement HTTP(S) itself and proxy traffic to the actual IdP servers. Using the IP address is more flexible and less invasive to the client and allows a wider range of load balancing scenarios but is also dependent on clients using somewhat unique, and stable, addresses, at least for the life of a series of related requests.
Non-Conversational State
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 org.opensaml.storage.StorageService API. Any implementation of this API is able to handle storage for a wide range of purposes within the IdP.
...
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 pairwise identifiers for use in SAML assertions (or OIDC tokens) is based on salted hashing of a user attribute, and does not store any rely on stored 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 dating to older 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 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), but we naturally expect people will deploy a more persistent storage option for this use case.
The CAS support relies on a ticket service that produces encrypted and self-recoverable ticket strings to avoid the need for clustered storage, though this can sometimes break older CAS clients due to string length.
The Local Storage use and logout defaults are applicable to new installs, and not systems originally upgraded from V3.
The client-side StorageServices used in the default configuration use a secret key to secure the cookies and storage blobs, and this key needs to be carefully protected and managed. Simple tools to manage the secret key are provided.
...
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.
Feature Limitations of these Defaults
Replay detection is limited, of course, to a per-node cache.
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)by prefixing the artifacts and then implementing advanced routing within a load balancer. This is rarely done.
To combine these missing features with clustering requires the use of alternative StorageService implementations (e.g., memcache, JDBC, or something else). This can in part be overridden via the idp.replayCache.StorageService and idp.artifact.StorageService properties (and others). A more complete discussion of these options can be found in the StorageConfiguration topic.