idpv3: clustering and sealer key update

[Cantor, Scott]

> Is idp.sealer.updateInterval property how often idp checks if the
> datasealer keys have changed on disk ?

Yes.

> 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.

> -> if client (for example load balancer idletimout=5M) moves from server1 to
> server2 between steps 2-3 does server2 read new key v101 from disk or is
> the client forced to reauthenticate ?

It should read the new key as long as it's actually present. 

> 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.

> One more question: How do these(idp.session.timeout,
> idp.authn.defaultLifetime and idp.authn.defaultTimeout) values control
> how often client has to reauthenticate ?
> (Are the the authn.default* values: maximum lifetime and inactivity
> timeout describe in:
> https://wiki.shibboleth.net/confluence/display/IDP30/Authentication
> )

They should map to the discussion there, yes. It's not hugely different from V2.

As a way to track the issue, you could create a placeholder somewhere in the actual configuration docs on Authentication and note a TBD for describing how the timeouts work together.

> So for example:
> idp.session.timeout=PT1H and idp.authn.defaultLifetime=PT2H
> user needs to reauthenticate every 1 hour ?

Well, that depends if the user interacts within the timeout or not, so there's no way to answer that apart from the upper bound being 2H.

> And idp.session.timeout=PT4H, idp.authn.defaultLifetime=PT3H and
> idp.authn.defaultTimeout=PT30M then if user is active(<30M) they
> don't need to reauth. in 3H ?

Yes, if the login flows are actually using those default values. They can be anything you want on a per-flow basis, which then means it depends which methods are used and by which SPs.

-- Scott