...
Collectively, these records all expire at somewhat varying times, but they are all bounded and are eventually cleaned up by the StorageService without any intervention.
An example layout:
Context | Key | Value | Expiration |
|---|---|---|---|
<session ID> | _session | <serialized form of IdPSession and subrecord keys> | session last activity + timeout + offset |
<session ID> | authn/JAAS | <serialized AuthenticationResult> | result last activity + timeout + offset |
<session ID> | authn/SPNEGO | <serialized AuthenticationResult> | result last activity + timeout + offset |
<session ID> | https://sp.example.org/shibboleth | net.shibboleth.idp.saml.session.SAML2Session:<serialized SPSession> | SP session expiration + offset |
<session ID> | https://sp2.example.org/shibboleth | net.shibboleth.idp.saml.session.SAML2Session:<serialized SPSession> | SP session expiration + offset |
A word about versioning: a big reason for manipulating the various record expirations is to be able to update and recover the last activity time without actually touching the record. This is safe because the versioning policy for such a field would be last-update-wins anyway, and it avoids needing to modify the serialized form of a record to perform the most common update.
...
Following along with the example above, the secondary records created might be:
Context | Key | Value | Expiration |
|---|---|---|---|
https://sp.example.org/shibboleth | <NameID value> | <session ID> | SP session expiration + offset |
https://sp2.example.org/shibboleth | <NameID value> | <session ID> | SP session expiration + offset |