Session handling
This chapter describes the basics of session handling within nevisProxy.
Reverse proxy
nevisProxy as a mere reverse proxy is stateless and does not enforce or require any sessions. This is due to the fact that the transport protocols of the Internet (HTTP, HTTPS) are stateless as well. Statefulness and the need for sessions arise when stateful applications are accessed through the reverse proxy, and nevisProxy therefore needs to route any subsequent calls of the user to the same application server.
Authenticating reverse proxy
The same requirements arise, inside nevisProxy itself, when it is acting as an authenticating reverse proxy. It then needs to associate the user through some client-side information (e.g. a cookie) with a local session. This mechanism also allows Single Sign-On (SSO) support. The figure below shows a scenario where cookies are used for the external session representation. Whenever the client resends the session cookie, nevisProxy is able to look up the database key to access the user's internal session where all user session data, like cookies or authentication tickets and credentials, are stored.
Session lifecycle
Creation
Sessions are created inside nevisProxy as soon as one of the conditions that trigger the need for local sessions is detected. These triggering conditions are:
- Authentication: One of the security filters is configured to enforce authentication on protected resources.
- Cookie management: One of the connector servlets has been explicitly configured to create a session for managing the cookies sent by a content provider.
- Backend stickiness: Once an HTTP request has been directed to a specific application server (within a load balancing or fail-over setup), subsequent requests must be redirected to the same server.
- Special use cases: A custom configuration, for example a LuaFilter script, can also create a new session.
The following sections concentrate on the most important first case.
Establishment
A session is considered to be established when the initial authentication has completed, and a client is considered to be a trusted user of resources behind the reverse proxy (e.g., session timeouts are raised from their initial values in this case).
Locking
A session can get locked. The following events lead to a session lock:
- A re-authentication timeout because of user inactivity ).
- A request that includes the lock query.
- If the LuaFilter attribute ch.nevis.isiweb4.auth.ExternalHint is set to "lock". See the [Known variables and reserved words] chapter for more information.
A locked session remains valid, but needs specific user input to get unlocked, such as a password or another user credential. Which input is needed exactly depends on the implementation of the unlock authentication event by nevisAuth. For more information, check the unlock authentication event in the nevisAuth reference guide.
Termination
Sessions are terminated through explicit user logout, asynchronous timeouts or external notifications.
See the sequence diagram below of the nevisProxy synchronous session life cycle (without redirect). It shows the minimal session life cycle of the reverse proxy session in conjunction with the global Nevis session (nevisAuth) and a local content provider session.
nevisProxy is considered to be the session master as all user requests are handled by the reverse proxy, and therefore, reliable session activity tracking can only be done here. This fact is visible in the diagram as the reverse proxy's session is the one that is created first and is terminated last. There are two exceptions:
- If no authentication interception is required, i.e., the client's request does not need to be saved during authentication, the reverse proxy session is created after the global Nevis session inside nevisAuth. This has the advantage that an unauthenticated user does not bind a session resource on the reverse proxy. This can only be done with X509 user certificate authentication, basic authentication using browser popups or other client authentication types where login credentials are sent along with the first (or every) request.
- Local content provider sessions may be terminated after the reverse proxy session with the help of a local session reaper if a user does not explicitly log out and the session is not synchronized with nevisProxy or nevisAuth.
A global session coordinator (see nevisAuth documentation) as well as any content provider may only influence the premature session termination of the reverse proxy session through notifications. Session lifetime may be extended by content providers by inducing periodic session activity from the client.
Client channel association
Clients accessing the reverse proxy are associated with previous requests, using channel-specific characteristics.
Cookies
As an alternative, nevisProxy uses an HTTP cookie to elongate the channel associations with clients. These cookies contain information that allows to perform security checks in the reverse proxy. The following table lists the details of client identification aspects.
| Client Information | Reverse Proxy Check |
|---|---|
| TLS Session ID | This check is security relevant, when using TLS-based client identification. The check is only performance relevant in all other cases (as TLS session renegotiations are computational expensive). |
| Cookie | The nevisProxy secure cookie contains the following attributes: Secure randomness; Optional signature to prevent brute force attacks (simple construction of cookies with a valid structure). They should only be held in the client's memory by using the cookies secure attribute. |
| TLS Client Certificate | When using X509 client certificates, a renegotiation of the TLS channel is denied, when the certificate was used to authenticate a user and the fingerprint of the new certificate differs. |
Session correlation in content providers
To associate a user with the local session on the content provider, the following setups are possible:
| Session Identification through | Remarks |
|---|---|
| Cookie | A content provider's cookie is propagated to the client, without the reverse proxy interfering with it. This leads to a security problem: User 'A' may steal this cookie from user 'B' (or fake it, if it is not secure), log in as user 'A' and pretend to be user 'B', when accessing the content provider. This problem may be solved in any of the following ways: Use the reverse proxy's cookie manager to remove session cookies from content provider responses and re-add them to subsequent requests; Correlate the local session cookie with the global Nevis session (using the user's security token); Provide a secure local session cookie factory, which reduces the risk to fake another user. |
| URL Part | The same problems as with cookies arise, but the Nevis reverse proxy does not provide URL rewriting. |
| Nevis SecToken | Use the user's global session information from the Nevis SecToken to identify the local content provider session. |
Timeouts
Session timeouts
Sessions inside nevisProxy are not only terminated by an explicit user logout, but also through asynchronous session timeouts (by the reverse proxy's session reaper) and session termination notifications from other (Nevis) components. These events are treated in exactly the same way as if the client had logged out.
nevisProxy as participating node in the Nevis environment supports termination of the reverse proxy session triggered by the following event sources:
- Logout by the user
- Expired SecToken
- Local timeout (inactivity, lifetime)
- Timeout or explicit termination by nevisAuth, in case the nevisAuth feature "polling for terminated sessions" is enabled.
The following table provides an overview of all session timeouts that influence the reverse proxy's session life cycle.
| Timeout Event | Influence | Configuration |
|---|---|---|
| Reauthentication timeout | nevisProxy locks sessions after an inactivity timeout. A user needs to provide some authentication credentials to unlock the session. | With the attribute ReauthInterval of the IdentityCreationFilter. See chapter IdentityCreationFilter. |
| Inactivity timeout | nevisProxy terminates sessions that have not been accessed by the user for the specified inactivity period. | With the attribute MaxInactiveInterval in the configured session store or session management filter. Can be overwritten by the attribute InactiveInterval of the IdentityCreationFilter. See chapter IdentityCreationFilter. |
| Lifetime timeout | nevisProxy terminates sessions that have exceeded their maximum lifetime. | With the attribute MaxLifetime in the configured session store or session management filter. Can be overwritten by attributes set in the IdentityCreationFilter. See chapter IdentityCreationFilter. |
| SecToken timeout | nevisProxy terminates established sessions once the lifetime of the SecToken has expired. | See the chapter Nevis SecToken in the nevisAuth Reference Guide. |
| Session termination by nevisAuth | nevisProxy terminates an established session, if nevisAuth terminated a session and the nevisAuth feature "polling for terminated sessions" is enabled in the EsAuth4ConnectorServlet (with the attribute EnablePollTerminatedCalls). | With the attribute EnablePollTerminatedCalls of the EsAuth4ConnectorServlet. See chapter EsAuth4ConnectorServlet. |
For further information on the Nevis distributed session management, see the nevisAuth Reference Guide.
Advanced session timeout policies
nevisProxy provides session timeout policies that allow you to control session lifetime depending on the user's usage pattern. For example, after accessing a company's portal application, the application allows the user to stay inactive for half an hour without losing the authentication context. However, as soon as the user accesses a sensitive area, the session timeout is reduced to, for example, 10 minutes.
The following sample provides an overview of all components and configuration settings that can influence the nevisProxy's session timeout, by demonstrating the minimum session timeout policy.
