Document cookie-based sticky request routing (6476922)

When Access Manager servers are deployed behind a load balancer, cookie-based sticky request routing prevents a client request from being misrouted to an incorrect Access Manager server (that is, to a server that is not hosting the session). This feature was implemented in Access Manager 7 2005Q4 patch 3.

In the previous behavior, without cookie-based sticky request routing, requests from non-browser based clients (such as policy agents and clients using the remote Access Manager client SDK) were often misrouted to an Access Manager server that was not hosting the session. Then, in order to send the request to the correct server, the Access Manager server had to validate the session using back-channel communication, which usually caused some performance degradation. Cookie-based sticky request routing prevents the need for this back-channel communication and thus improves Access Manager performance.

To implement cookie-based sticky request routing, the Access Manager deployment must be configured as a site. For information, see Configuring an Access Manager Deployment as a Site in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

To configure cookie-based sticky request routing:

1. To specify a cookie name, set the com.iplanet.am.lbcookie.name property in the AMConfig.properties file. Access Manager then generates the load balancer cookie value using the two-byte server ID (such as 01, 02, and 03). If you do not specify a cookie name, Access Manager generates the load balancer cookie value using the default name amlbcookie plus the two-byte server ID.

   If you set the cookie name on the Access Manager server, you must use the same name in the AMAgent.properties file for a Policy Agent. Also, if you are using the Access Manager client SDK, you must also use the same cookie name used by the Access Manager server.

   Note: Do not set the com.iplanet.am.lbcookie.value property, because Access Manager sets the cookie value using the two-byte server ID.

2. Configure your load balancer with the cookie name from Step 1. You can use a hardware or software load balancer with your Access Manager deployment.

3. If session failover is implemented, enable the com.sun.identity.session.resetLBCookie property for both Policy Agents and the Access Manager server.

   • For a Policy Agent, add and enable the property in the AMAgent.properties file.

   • For the Access Manager server, add and enable the property in the AMConfig.properties file.

   For example:

   com.sun.identity.session.resetLBCookie='true'

   If a failover situation occurs, the session is routed to a secondary Access Manager server, and the load balancer cookie value is set using the server ID for the secondary Access Manager server. Any subsequent requests for the session are then routed to the secondary Access Manager server.