Transientid and session timeout

[Cantor, Scott]

> Our current thinking is that this
> is the route of our problem. In our environment the IdP won't be able to
> lookup a session based on a persistent id as they are dynamically
> created/non-reversible and we don't use a backend data store for
> sessions. So perhaps we need to change our config so that we use the
> trasient-id as a NameID for this particular SP.

That is not how it works, logout does not depend on reversibility.

> After testing this further yesterday (with logging set to trace) we now
> realise that we get the SLO error much sooner than 60min. In fact we
> think it is happening after 30min (of inactivity).

I can tell you that any claims that timeouts aren't happening as directed have never turned out to be legitimate, not on either end. There's always another explanation, so I don't even bother to check into that sort of thing anymore.

> So that seems to imply that the persistent-id is used as the secondary
> lookup and that for a period of time that succeeds (we think 30min) and
> thereafter it fails. So it looks like some of the session data is server
> side and not all client side as we were assuming.

It's wherever you configure the session cache's storage service to live. There is nothing split, all the session data is either recovered from the client or on the server somewhere/somehow.

-- Scott