About load balancer configuration and session persistence
Bravura Security Fabric uses state-ful sessions which are locally stored on the specific application node handling each request. Any load balancer configuration in place to direct web traffic to the product application nodes for any purpose must ensure that once a session is open on an application node, all subsequent requests are sent to the same node.
Bravura Security recommends to use the nodestatus endpoint that Bravura Security Fabric provides, instead of having the load balancer add noise and load on the various application ports by pinging them to check that "something" is listening on those ports.
If session persistence is not configured properly, then core features of the product will begin to fail as stateful network traffic is redirected to a node with no knowledge of the active session. The list of product features affected by session persistence includes:
Normal use of the web interface by end-users
When administrating the product, you should connect directly to each application node that's being administered or troubleshot, instead of connecting through the load balancer. Product configuration should be done only on the Primary application node.
Bravura Privilege access disclosure, and session monitoring
SAML/Single Sign-On authentication
Bravura Pass Login Assistant/SKA
Any use of the SOAP API integration with the product
The Bravura Privilege Local Workstation Service or
pamutil.exe remote integrationsBravura One configurations using
mobproxy.The external connection from Bravura One App to
mobproxycan have round-robin DNS or round-robin load-balancer in between, but not the connection frommobworkertomobproxy. Because every mobile App's HTTP request is being separated by two mobworker's HTTP posts, round-robin DNS or round-robin load-balancer cannot ensure the samemobproxyfor both requests.
How Load Balancers Implement Session Persistence
Most load balancers encapsulate their session persistence options into "profiles", centralizing the configurations involved. Bravura Security Fabric was most prominently tested against the F5 "BIG-IP" load balancer, and the advice in this article originates from that environment.
To implement session persistence, the load balancer keeps a table of active sessions which typically contains:
The session ID
The product application node(s) involved
The client and destination IP involved
The persistence method
The "Primary" persistence profile is the first method used to check all incoming network traffic against the session table to determine if the traffic belongs to an existing session. It also determines which persistence method to use when creating a new session.
A "Fallback" persistence configuration checks incoming traffic against sessions tracked by the load balancer, if no match was found for the primary persistence method. Fallback persistence is often restricted to IP-based options.
Fallback persistence profiles do not create new IP-based sessions if a preexisting session is not found; instead, they only improve the coverage of the primary persistence profile.
For this discussion and demonstration, the behavior is as follows:
Session data exists in load balancer | Load balancer has no knowledge of the session | |
|---|---|---|
Request has session cookie | Primary persistence method succeeds. Request is forwarded to the node defined by the session data. | Primary persistence fails. Fallback persistence checks the list of active sessions and fails. A new session is created. |
Request has no session cookie | Primary persistence fails. Fallback persistence checks the list of active sessions, and a match is found. Request is forwarded to the node defined by the session data. | Primary persistence fails. Fallback persistence checks the list of active sessions and fails. A new session is created. |
Prefer Cookie-Based Persistence
The load balancer should be configured to use cookies as the primary method of establishing session persistence.
The best approach is to have the load balancer insert its own cookies into incoming HTTP requests (that is, the "HTTP cookie insert" option), as cookies used by Bravura Security Fabric are more volatile than those inserted by a load balancer.
Use "Source Address"-Based Persistence as a fallback
Product features such as privileged access use the web GUI to create new network sessions with Bravura Security Fabric services, which cannot make use of cookie-based session persistence.
Using IP address-based persistence as a fallback option ensures that new network connections that lack cookies will be directed to the same node that is already handling that user's existing browser session.
Configure Traffic Rules for API Traffic
Because API traffic is never able to register a cookie-based session with the load balancer, API traffic can experience interruptions as the load balancer continually tries to assign new cookies to HTTP traffic it considers "New."
The best practice here is to ensure that a traffic management rule is in place which checks the HTTP header for the value `SOAPAction`, and enforces IP-based session persistence when this attribute is found. This ensures that API sessions are reliably handled by the correct node, regardless of whether a cookie-based session exists for that client.
Manually partition node responsibilities if sticky sessions cannot be achieved
The alternative, if sticky sessions are not possible on the LB, is to target specific nodes for specific purposes, and build the failover with a different method (for example, remove round-robin; have the LB prefer a node for a specific IP range, and fail over to another node only when that node is unresponsive)