Different inactivityTimeout in a MFA environment

[Cantor, Scott]

> The next step I would like to understand is the "enforce a
> custom timeout programmatically". First of all: wouldn't be
> enough just returning true of false as the reuseCondition is a
> predicate (where false means: do not reuse the SSO)?

That is correct. The condition returns whether to reuse the flow's result for SSO or execute it from scratch, MFA in this case. Timeouts are just one automated/static form of such a condition that the IdP executes itself based on what it knows about the last time the result was used.

As for the structure, all I can say in the scope of non-member support is that the active AuthenticationResults are attached to the AuthenticationContext, and in the case of MFA, the individual results from the subflows are inside a special Principal type [1] inside the Subject in the MFA result, one instance of that for each subflow's result.

Those results carry the type of flow used and when they were created. Only the top level MFA result tracks last time used, which is why the timeouts can't get enforced at a lower layer. To do so would mean constantly having to reserialize the changed object back into the session and I didn't feel it was warranted. I don't believe in timeouts in general, so that was the other reason.

-- Scott

[1] https://shibboleth.net/api/java-identity-provider/5.1.3/net/shibboleth/idp/authn/principal/AuthenticationResultPrincipal.html