idpv3: clustering and sealer key update

[Jarno Huuskonen]

Hi,

On Sat, Feb 07, Cantor, Scott wrote:
> > Does the datasealer read new key from disk even if
> > idp.sealer.updateInterval hasn't happened yet:
> 
> I don't believe so, it's just a background thread, but there if one node sees data encrypted with a newer key, it should fetch that newer key if it's in the file. I'd have to look at the code to see what happens after that point, whether it actually starts using the new key for its own operations. It probably does, but I'm not certain.

I did some (very very quick) testing (w/3.0.0) and it looks like it reads
the new key from disk --> so it's able to decrypt the cookie but I think
it still (re)encrypts with the "current" key (until updateInterval).

> > How does idp.session.timeout correlate to how frequently you should
> > update sealer key ?
> 
> It doesn't in general unless you update the key quite often, but other uses of the sealer such as storage for consent have much longer lifetimes and in that situation you'd have to adjust the key count and change frequencey to fit how you do things and want things to persist.
> 
> It doesn't do any particular harm to keep lots of keys if it's required and we can always adjust the defaults to what ends up working well.

If you use the datasealer only for encrypted "shib_idp_session_ss" cookies
then would it make sense to limit the number of old keys to only a few and
update the sealer key often, so current/old keys cover for example
24h --> This would limit the time an attacker has for "faking" a valid
"shib_idp_session_ss" cookie to 24h ?

-Jarno

-- 
Jarno Huuskonen