Session Termination Polling and Actor Identification
Upon receiving an AUTH_DONE response state together with a SecToken, nevisProxy identifies the user session as an authenticated session. Further requests may only cross nevisProxy. Therefore, nevisProxy holds the master session. This means, if a logout is detected, either instructed by the user or a back-end application. nevisProxy is then responsible for sending a logout or kill request to nevisAuth.
However, it is also possible that nevisAuth decides to terminate the session. This might happen, for example, if the nevisAuth session reaper detects a timed-out session. In this case, the session coordination between nevisProxy and nevisAuth can be achieved using the poll_terminated_sessions method.
An external server (usually nevisProxy) can use this method to collect notifications of terminated sessions. The method handler will postpone sending a response until at least a minimal duration has passed (since this notification mechanism is understood to be near-real-time only) and, if no sessions have been terminated since the last call, it will wait up to a maximal duration for the termination of new events. Both minimal and maximal durations can be specified with the request.
To keep track of termination notifications and administer which notifications have been consumed by which actor, each external server must be identified with a unique actorId. This is done via the HTTP header actorId (in SOAP deployment) or, as a fallback, via the SubjectDN in the transport layer client certificate used by the actor.
By default, all nevisProxy nodes behind the same load balancer share the same actorId (configured via the application-id context parameter in web.xml). Consequently, nevisAuth treats them as a single actor: once one node has consumed a termination notification, it is not redelivered to the other nodes. If nevisProxy resolves sessions through a shared database, this is harmless, because any node can look up the current session state there. However, if nevisProxy nodes rely on a local session cache (for example the MultiLevelSessionStoreServlet), the notification may be consumed by a node other than the one holding the session, and that session is never invalidated. Assigning a unique application-id per node changes which node receives which notification, but it does not fix the underlying issue for a node that is temporarily unavailable, and it is not a supported workaround for this limitation. See Terminated session polling for the recommended session store choice in clustered deployments.