Session hijacking is a classic but still critical problem. When a user's session cookie is captured, the attacker tries to take over the session with the same token. If the system only checks whether the token exists and does not verify the IP address, device, browser or user context in which that token was generated, the session identifier becomes the only security boundary.
Forgotten cookie security flags are another common weakness. Without HttpOnly, client-side scripts can read the cookie; without Secure, the transport layer is exposed; without SameSite, cross-site requests carry more risk. Expecting every application team in a large organisation to apply these settings consistently is not realistic.
Timeout management is often incomplete. Idle timeout determines how long a session remains valid after the last activity; absolute timeout caps the maximum session lifetime from login, even when the user stays active. In finance, healthcare and enterprise portals in particular, these two limits must be managed independently.
Concurrent session control is not solved automatically by a standard cookie system. Decisions such as how many devices a user may log in from simultaneously, whether a new login should end the oldest session or be denied outright, all require a central session store and active session tracking. In multi-node deployments this becomes even more critical.
TR7 Session Protection brings these requirements together under a single policy graph: session ID generation, cookie security flags, IP / IP+UA / composite binding, idle and absolute timeout, maximum concurrent sessions and optional cookie encryption all managed in one model.
TR7 treats session protection not as a single cookie setting, but as a multi-layer policy that spans generation, validation, refresh and termination.
SAM handles session affinity, cookie name, cookie source, session format and security flags together. TR7 can generate the session ID itself or work with a cookie produced by the backend; UUID, IP+timestamp+random, IP+random and custom format options are all available.
After login, one of IP, IP+UA, composite or none binding modes is applied. When a context change is detected, the session is flagged as a mismatch and the application can request re-authentication or additional verification.
When AES-256-CBC cookie encryption is enabled, selected cookies become unreadable on the client side. The additional binding derived from the IP+UA context makes it significantly harder to replay a token from a different client.
Session refresh is executed atomically using Redis Lua functions. Idle timeout can be renewed on each activity; absolute timeout remains anchored to login time. Maximum concurrent session enforcement is also applied through the central session state.
Session Protection delivers ready-made profiles, binding options, timeout management and cookie security for a wide range of security and user experience requirements.
The default profile is designed for standard enterprise use with IP binding, an 8-hour idle timeout and a 7-day absolute timeout. The session_strict profile provides tighter security with IP+UA binding, a 30-minute idle timeout, an 8-hour absolute timeout and a single concurrent session. The session_relaxed profile suits long-running SaaS sessions with no binding and a 7-day idle and 90-day absolute timeout. The session_singleDevice profile applies IP binding and a single concurrent session policy for applications that require a licence or device restriction.
TR7 does not force session ID generation into a single fixed model. The ipTimestampRandom format combines IP, timestamp and a random value to provide a strong default. The uuid format produces an opaque value that contains no IP information. The ipRandom format uses IP and a random value. The custom format lets operators build a session key from headers, cookies or custom variables. This flexibility accommodates different application architectures.
HttpOnly can be configured as the minimum security flag at the SAM layer. Additional flags such as Secure, SameSite=Strict or SameSite=Lax can also be added at policy level. Cookie Max-Age can be tied to the absolute timeout. This removes the expectation that every application team will configure cookie security settings correctly and independently.
When samCookieSource is set to TR7, the session cookie is generated at the ADC layer. If the backend continues to produce its own cookie, a backend-sourced cookie can be used. In hybrid mode, the backend cookie is used when present; if not, TR7 generates a new session value. This approach accommodates both new applications and legacy systems.
ip binding preserves the source IP context from login and is effective in corporate office or VPN scenarios. ip+ua binding evaluates IP and User-Agent together for tighter control. composite binding can be extended with additional components such as Accept-Language, custom headers or TLS fingerprint. none mode behaves more flexibly for SaaS use cases with long sessions and frequent network changes.
Cookie encryption is not enabled by default; it is an optional protection that must be explicitly activated for the chosen cookies. When active, cookie_encrypt is applied on the response side and cookie_decrypt on the request side. Salt, padding and base64 formatting make the client-side value unreadable. When decryption fails, the value is not treated as trusted session data and the application can request re-authentication or reject the request.
sessionIdleTimeout determines how long a session remains valid after the last activity. sessionAbsoluteTimeout caps the maximum session lifetime from login and does not extend through continued activity. This distinction is especially important in banking, enterprise portals and applications that handle sensitive data. User experience and security boundaries are balanced within the same policy.
The maxConcurrentSessions value determines how many active sessions a single user can hold at the same time. When the limit is exceeded, logout_oldest drops the oldest session or deny_new rejects the new login. This can be used for single-device licensing, banking security or enterprise access control. The active session list is tracked in the central session state.
A session is created at login, idle refresh can occur on each request, a binding mismatch marks the session as suspicious and logout invalidates the session. This lifecycle ensures the session is managed not only at the start but throughout its entire active period. SIEM and audit streams can generate security signals from these events. Session history is particularly valuable in account takeover investigations.
Peer synchronisation and a Redis-backed central session store can be used together to preserve session state across multiple TR7 nodes. Failover and rolling restart scenarios are handled without session loss. Redis replication and persistence options increase session state durability and prevent session protection from being tied to a single node.
Session protection is operated together with cookie naming, attribute generation, composite binding components, audit categories, the session store and timeout fallback behaviour.
The default cookie name is TR7SID. A different name can be defined per pool using samCookieName. This is used for brand alignment, application naming conventions or integration with an existing cookie architecture.
When a cookie value is created, attributes such as HttpOnly, Secure, SameSite and Max-Age are added according to policy settings. These attributes are set only when a new session is generated. This standardises cookie security through central policy rather than individual application configuration.
Composite binding can be configured with components such as source IP and User-Agent by default. Operators can include additional components such as Accept-Language, Accept-Encoding, custom headers or TLS fingerprint. This computation must occur at a late phase, after the relevant variables have been generated.
Session and access events can be logged with categories such as whitelisted, authorized or unauthorized. This information makes it easier for SIEM teams to investigate account takeover, abuse and unauthorised access. User and session context becomes more visible for every request.
AAM session state can be maintained in Redis, with session refresh operations executed atomically through Lua functions. This model removes traditional database latency from the session check path. Redis features such as AOF and replication increase persistence and durability.
If idle timeout configuration is absent, a 1-hour fallback can be applied. If absolute timeout configuration is absent, a 24-hour fallback value is used. These values are safe defaults that prevent unlimited sessions from being created when configuration is incomplete.
A banking application may need to keep users on a single device and end the session after 30 minutes of inactivity. The session_strict profile applies IP+UA binding, a 30-minute idle timeout, an 8-hour absolute timeout and a single concurrent session policy. If a stolen session is used in a different context, a mismatch signal is generated.
B2B SaaS users may access the same account from a laptop, phone and tablet. The session_relaxed profile preserves the user experience with long idle and absolute timeouts and no binding. IP changes or device variety do not trigger unnecessary re-authentication.
Employees log in from the office or VPN network and work throughout the day without re-authenticating. The default profile can be applied with IP binding, an 8-hour idle timeout and a 7-day absolute timeout. If the IP context changes, the application can request re-authentication.
A premium application or licensed service may require that an account be used on only one device at a time. The session_singleDevice profile with a maximum of 1 concurrent session and logout_oldest behaviour drops the old session when a new login occurs. Licence sharing and uncontrolled multi-device use become significantly harder.
Session ID generation, cookie security flags, IP+UA binding, timeout policy and concurrent session limits — all under one policy graph. Let us walk through a live setup on your own services.