General requirements for load balancer configuration
The requirements and recommendations in this section apply to any load balancer used with Bravura Security Fabric. They describe the session persistence behavior required by the product, the recommended persistence strategy, and how to configure health monitoring.
Note
If a CDN or reverse proxy terminates SSL in front of the load balancer, security headers such as HSTS may not reach end users. See HSTS configuration for CDN and reverse proxy deployments for configuration guidance.
Session persistence requirements
Bravura Security Fabric uses stateful sessions that are stored locally on the specific application node handling each request. Any load balancer configuration that directs web traffic to the application nodes must ensure that once a session is established on a node, all subsequent requests from that client are sent to the same node.
If session persistence is not configured properly, core product features will fail because stateful network traffic is redirected to a node that has no knowledge of the active session. The following features are affected by session persistence:
Normal use of the web interface by end users.
Bravura Privilege access disclosure and session monitoring.
SAML and single sign-on authentication.
Bravura Pass Login Assistant and secure kiosk account (SKA).
SOAP API integrations.
The Bravura Privilege Local Workstation Service and
pamutilremote integrations.Bravura One configurations using
mobproxy.
Note
When administering the product, connect directly to each application node rather than through the load balancer. Make product configuration changes only on the primary application node.
Note
For Bravura One, the external connection from the mobile app to mobproxy can use round-robin DNS or a round-robin load balancer. However, the connection from mobworker to mobproxy cannot, because each mobile app HTTP request is separated into two mobworker HTTP posts, and round-robin distribution cannot guarantee that both posts reach the same mobproxy instance.
Recommended persistence strategy
Bravura Security recommends configuring the load balancer with cookie-based session persistence as the primary method and source-address (IP-based) persistence as a fallback. Additionally, a traffic management rule should handle API traffic separately.
Use cookie-based persistence as the primary method
Configure the load balancer to use cookies as the primary method of establishing session persistence. The recommended approach is to have the load balancer insert its own cookies into HTTP responses (the "HTTP cookie insert" method). Load-balancer-inserted cookies are more reliable for persistence tracking than the application's own session cookies, which are more volatile.
When the load balancer inserts a cookie, it includes information that identifies the backend node handling the session. On subsequent requests, the load balancer reads this cookie and routes the request to the same node.
Use source-address persistence as a fallback
Some product features, particularly privileged access workflows, create new network sessions with Bravura Security Fabric services that cannot use cookie-based session persistence. Using source IP address-based persistence as a fallback ensures that new network connections that lack cookies are directed to the same node that is already handling that client's existing browser session.
Fallback persistence profiles do not create new IP-based sessions when no pre-existing session is found. They only improve the coverage of the primary cookie-based persistence profile by catching traffic that the primary method cannot match.
Configure traffic rules for API traffic
API traffic (SOAP) cannot register a cookie-based session with the load balancer. Without a specific rule, the load balancer will continually attempt to assign new cookies to API traffic it considers new, which can cause session interruptions.
Configure a traffic management rule that inspects the HTTP header for the SOAPAction value and enforces IP-based session persistence when this header is present. This ensures that API sessions are reliably handled by the correct node, regardless of whether a cookie-based session exists for that client.
Alternative: manual node partitioning
If sticky sessions cannot be achieved with your load balancer, the alternative is to assign specific nodes to specific purposes and implement failover through a different method. For example, configure the load balancer to prefer a specific node for a given IP range and fail over to another node only when the preferred node is unresponsive. This approach sacrifices the benefits of active load distribution but preserves session stability.
Health monitoring
Bravura Security Fabric provides a dedicated health check endpoint for use by load balancers. Configure your load balancer's health monitor to use an HTTPS content check against the nodestatus endpoint rather than pinging individual service ports directly.
The nodestatus endpoint performs a series of application-level health checks — including service availability, database connectivity, replication queue status, and IIS performance — and returns standard HTTP status codes:
200 OK— all checks passed; the node is healthy.503 Unavailable— one or more checks failed; the node should be removed from the pool.500 Internal Server Error— a problem with the IIS configuration on the node.
Using the nodestatus endpoint is preferred over port-level health checks because it validates that the application is actually functioning, not merely that a port is accepting connections. It also avoids generating unnecessary load and log noise from repeated port probes.
How load balancers implement session persistence
This section provides background on how session persistence works at the load balancer level. Understanding this behavior is helpful when configuring or troubleshooting persistence for Bravura Security Fabric.
Most load balancers encapsulate session persistence options into profiles that centralize the relevant configuration. A load balancer maintains a table of active sessions, which typically contains:
The session identifier.
The application node handling the session.
The client and destination IP addresses.
The persistence method used.
The primary persistence profile is the first method used to check incoming traffic against the session table. It determines whether the traffic belongs to an existing session and which persistence method to use when creating a new session.
A fallback persistence profile checks incoming traffic against the session table when the primary method finds no match. Fallback persistence is typically restricted to IP-based methods. Fallback profiles do not create new sessions; they only improve coverage of the primary profile.
The following table summarizes the expected behavior:
Scenario | Session data exists in load balancer | Load balancer has no knowledge of the session |
|---|---|---|
Request includes session cookie | Primary persistence succeeds. Request is forwarded to the node identified by the session data. | Primary persistence fails. Fallback persistence checks active sessions and finds no match. A new session is created. |
Request has no session cookie | Primary persistence fails. Fallback persistence checks active sessions and finds a match by IP address. Request is forwarded to the matching node. | Primary persistence fails. Fallback persistence checks active sessions and finds no match. A new session is created. |