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) or the communication channel (e.g. TLS session) with a local session. This mechanism also allows Single Sign-on (SSO) support. The 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:

• Requirement of authentication: One of the security filters is configured to enforce authentication on protected resources.
• Requirement of cookie management: One of the connector servlets has been explicitly configured to create a session for managing the cookies sent by a content provider.
• Requirement of backend stickiness:Once a HTTP request has been directed to a specific application server (within a load balancing or failover setup), subsequent requests shall be redirected to the very same server.
• Requirement of session join: If nevisProxy does not act as entry point, it may be configured to join the global Nevis session.

In the following we 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 Sessions are locked when user inactivity results in a so-called reauthentication timeout. This means that the session stays valid, but needs to be unlocked by some user credential (e.g. a password).

Termination Sessions are terminated through explicit user logout, asynchronous timeouts or external notifications (see the chapter Time-outs.

The sequence diagram nevisProxy synchronous session life cycle (redirect is not shown) 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 auth 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.

TLS Session ID The most secure possible channel association is currently the TLS session identification. The TLS protocol makes sure that attacks with a guessed or well-known TLS session ID are averted. This channel association only works properly if the client is caching the TLS session context for an acceptable period and always sends the TLS session resume along with each request. This is not always the case (e.g. older MSIE browsers have a client-side TLS session cache timeout of 2 minutes).

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
IP	The IP of the client (peer address) is compared against the peer address that was stored during the authentication. This allows to prevent cookie spoofing attacks from another client host (without doing IP spoofing as well). This check may lead to problems with client-side proxies that change IP addresses (e.g. ISDN dial-up routers). The check is only performed when using cookies for client identification and it may be disabled (on the cookie cache component)
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 (56 bytes per default). optional signature (SHA1withRSA) 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. The cookie may expire on the client (by using the cookie's 'maxage' attribute in certain cases). A validity timeout on the cookie is not enforced by the reverse proxy.
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 (e.g. J2EE Servletcontainer)	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 as follows: Correlate the local session cookie with the global Nevis session (using the user's security token). Use the reverse proxy's cookie manager to remove session cookies from content provider responses and re-add them to subsequent requests ). * Provide a secure local session cookie factory, which reduces the risk to fake another user.
URL Part (e.g. J2EE Servletcontainer)	The same problems as with cookies arise, but the Nevis reverse proxy does not provide URL rewriting.
Nevis SecToken (see Authentication concepts)	Use the user's global session information from the Nevis SecToken to identify the local content provider session.

Time-outs

Session time-outs Sessions inside nevisProxy are not only terminated by an explicit user logout, but also through asynchronous session time-outs (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:

• Synchronous logout by the user
• Expired SecToken
• Asynchronous local timeout (inactivity, absolute)
• Asynchronous timeout or explicit termination by nevisAuth (Note: nevisAuth 4.x also supports an inactivity and absolute timeout on the global session as well as session termination through agreement of all joined session members).

The following provides an overview of all session timeouts that influence the reverse proxy's session life cycle.

Timeout Event	Influence	Configuration
nevisProxy reauthentication timeout	". can be overwritten by nevisAuth
nevisProxy inactivity timeout	".
nevisProxy absolute timeout (given by the maximum lifetime of the SecToken returned by nevisAuth)	nevisProxy terminates established sessions once the lifetime of the SecToken has expired. => session is terminated, notifications are sent to all participating session members (via nevisAuth or directly)	See the chapter Nevis SecToken in the nevisAuth Reference Guide.
nevisAuth inactivity timeout	". For a general overview, see the chapter Session Termination Polling and Actor Identification in the nevisAuth Reference Guide.
nevisAuth absolute timeout	". For a general overview, see the chapter Session Termination Polling and Actor Identification in the nevisAuth Reference Guide.
local session timeout of session member	Session members reaching an asynchronous local session timeout, may contact nevisAuth and vote for session termination. If all session members agree (by a 100% positive vote of all members) that a session has no activity whatsoever, the global session is terminated.

For further information on the Nevis distributed session management, see the nevisAuth documentation Reference Guide nevisAuth 4.6.x.x, AdNovum.

A note at the end: Failsafeness and session association mechanisms delegated to the client (e.g. using cookies) result in a lower level of protection.

Advanced session time-out policies

nevisProxy provides session timeout policies that allow to control session lifetime, depending on the user's usage pattern. E.g. accessing a company's portal application allows the user to stay inactive for half an hour without losing the authentication context, but as soon as a sensitive area is accessed, the session timeout is reduced to e.g. 10 minutes. The following sample provides an overview over all components and configuration settings, which may influence the nevisProxy's session timeout. The above example is shown by demonstrating the minimum session timeout policy.

Refer to the nevisProxy security filters ") for configuration details.