Scriptable DataSealerKeyStrategy Question

[Cantor, Scott]

On 11/4/19, 4:31 PM, "dev on behalf of Snyder, Bill" <dev-bounces at shibboleth.net on behalf of bpsnyder at amazon.com> wrote:

> If I let the page sit for longer than the 15 second timeout, the browser gets redirected back to the IdP which appears to
> successfully redirect the user back to the SP without requiring them to login again.  What is confusing me is that, in this
> situation, I would expect there to be a call to my class's implementation of the getKey() method, passing in the version
> id of the sealer key previously used, but the calls that are made are to the getDefaultKey() method.   Is this the expected
> behavior?

Yes. The data is cached in the container session and is tagged with a simple version number (not the key version, it's a record version) that enables the code to detect that the data in the session cache is the same as the data in the client and doesn't need to be reloaded, so the read step is skipped. The data is generally updated each time and written back to the client under the default key with the updated record number, thus the calls to getDefaultKey() each time.

> If I let things sit for a while (maybe hours), I will see calls to the getKey() method be made but, in this scenario, the user
> seems to always get redirected back to the login screen.  My goal is to be able to definitively test that I can keep X
> number of sealer key versions and have those sessions still work and also verify that once a sealer key version is
> "rotated out", that any sessions using that sealer key will be terminated.

Clear the JSESSIONID cookie in between or restart the container and the read step will be forced back through the client and have to upload and decrypt the data again with whatever key was used.

Rotating out a key will not end any sessions, it simply makes them unsable by fiat, but as long as the sessions would have been expired anyway then the impact is the same.

Writes always happen under the default key, reads under whatever key was used.

Turn up logging to TRACE for some of the calling classes and you'll see more low level operations.

-- Scott