SP v4 alpha2 sessions ?

[Scott Cantor]

> First, thank you for the new
> CredentialResolverService(https://shibboleth.atlassian.net/wiki/spaces/sphub1/pages/5539168277/CredentialResolverService
> ). Helps a lot in using different saml cert/keys in agents.

Glad it's helping, it was a "challenge" to pull that off.

> Once a session is available in an agent’s memory/filesystem cache, does
> the agent still query the hub for session data or validation on
> subsequent requests?

The Hub never tracks sessions in any way. It can function optionally as a passthrough to handle the storage steps but it doesn't retain any information about them apart from that, and the Agent only contacts the Hub for sessions if that cache "type" is used, which is not the default at the moment. Using the filesystem is an alternative (the only one at the moment).

> Or does it use the locally cached session until an
> expiration, timeout, version change, or other invalidation condition
> requires hub interaction?

If the filesystem is used, there is *no* access to the Hub again for that session unless logout happens. The filesystem is checked and updated based on the storageAccessInterval setting or if a new process has to check for the session. With the storage type, it does have to contact the Hub at time-based intervals you control.

> (If hub is loadbalanced (using agents basic auth username as sticky
> session), but if this hub server is down during reboot, then agent
> traffic goes to second server during this time. Will agent send session
> traffic to after initial login ? (Would need to use hub/storage for
> sessions).

The Hub is completely stateless unless some feature is using the in-memory StorageService for something (the shibboleth.StorageService bean). The only "typical" use of that would be for the replay cache where it's just tolerated making the replay check less exact.

> Also deleting session file from cache does seem to result in 500
> internal server error:

It would depend on the code path using the session. Some cases would likely request a new session but with many it's probably much too late in the request lifecycle for that to happen.

However it's possible that the different stages of the request handling are more decoupled now from the session cache and so it's possible that the initial session checking is not hitting the filesystem but the later processing does, simply because of timing, and that might be more awkward. I can probably look at that a bit and maybe force it to stick with the in-memory copy once it reaches certain points in the lifecycle.

> Is this expected, I kind of expected this to behave like no session ->
> make client login again (quick and dirty logout). (I think url had
> require shibsession rule).

I don't think even the old SP did that at some points (it couldn't during authorization for example because Apache is invoking that directly). But I also had some API support back then to bypass some of the checks where it would have noticed that shibd was missing for example, and I might have removed those and need to restore some of that.

-- Scott