Skip to main content

Enable session persistence for API calls

While cookie persistence is a robust solution for most web application use cases, it is not functional for applications that cannot handle cookie traffic, but require a persistent session regardless. In Bravura Security Fabric a prominent example of this scenario is requests made to the Bravura Security Fabric API. API calls can originate from a wide variety of client-scripted plugins and applications, and each of these would need to support HTTP cookie retransmission for cookie persistence to support these connections.

As API operations require a persistent connection to their server in order to function properly, a traffic management rule is required to handle API traffic for Bravura Security Fabric; in the F5 LTM, these rules are known as "iRules." iRules are simple scripted solutions that evaluate packet data in order to make various routing decisions and data modifications. To support the Bravura Security Fabric API, an iRule that performs the following operations for HTTP requests is required:

  • Confirm the incoming traffic is an API request.

  • Enable persistence for the request.

  • Assign the pool for the request.

  • Change the "Host" header for the request, setting it to the address of the Bravura Security Fabric server that will receive this request.

The exact functionality of this script may vary depending on the needs of your business, but enabling an iRule to selectively handle API traffic is a minimally-disruptive solution for supporting calls to the Bravura Security Fabric API.

To enable session persistence for API calls through iRules:

  1. Log into the BIG-IP administration UI as an administrator.

  2. Navigate to Main > Local Traffic > iRules.

  3. Click Create...

  4. Assign a unique name for this iRule.

  5. Configure the iRule to modify API traffic, by updating the following packet information:

    • The HTTP "Host" header must be set to the IP address of the server handling the request.

    • The packet must be assigned to a pool, if one was not already assigned.

    • A non-cookie persistence profile must be applied to the packet.

    The following iRule example is capable of updating SOAP API traffic in order to enable session persistence through Destination Address, or "sticky" persistence:

    when HTTP_REQUEST {
if {[HTTP::header exists "SOAPAction"]}{ e-session-persistence
    # Set custom persistence profile, as API requests may not support cookies.
    persist sticky 255.255.0.0 3600
       # Confirm that members of "Pool1" are available, and set the pool. 
       if { [active_members Pool1] > 1 } {
             pool Pool1
    }
    # Replace the Host header, as this needs to match the destination node. 
    HTTP::header replace Host [LB::server addr]

    # log local0. "SOAP request: [HTTP::header value SOAPAction], sending to: [LB::server
            addr]."
}
}
when LB_FAILED {
log local0. "Failed pool selection"
}

  6. Click Finished when your iRule is complete.

In this section: