How to configure/ control SSL session timeout / SSL caching lifetime in API Gateway 9.4

Products

• CA API Gateway
• API SECURITY
• CA API Gateway Precision API Monitoring Module for API Gateway (Layer 7)
• CA API Gateway Enterprise Service Manager (Layer 7)
• STARTER PACK-7
• CA Microgateway

Issue/Introduction

The user has customized OTK Oauth endpoints to use Mutual Authentication for user identification / authentication.  We could not find any details about how to control the lifetime of the SSL cache or how to configure SSL session timeout in the gateway.

FYI - We are not using gateway clusters as provided by the product, rather a single instance of gateway is used.

By the ability to control SSL session timeout  or lifetime, we will be able to ensure that the same SSL session is not reused by the client using our endpoints beyond the configured timeout value.

 

Environment

Release : 9.4

Component : API GATEWAY

Resolution

The requirement is to set session timeout for SSL cache for inbound connection, there is a property used by the Gateway SSL connector. i.e sessionCacheTimeout (default value for this is 24 hours).   

Try setting this property value in SSL port through Manage Listen Ports --> Advanced properties.
The actual units would be in seconds.
The actual property is called "sessionCacheTimeout"

It seems both sessionTimeout (tomcat property) and sessionCacheTimeout (ssg connector property) works in this case. 

My recommendation would be to use sessionCacheTimeout connector property name to configure SSL session timeout while preparing the listen port ssg connector.  And the units are seconds (not milliseconds). As it is connector level property, it cannot be bind to a specific service unless you hardwired the listen port to a service. 

Note that client software often sets shorter limits and many common servers are customized with other limits as well. Our default of 24 hours is right in the middle of the pack. Facebook, for example, uses 48 hours. Google uses 28 hours. That's for user tracking for ads, mostly. If the customer would like strong security, I'd suggest 1 hour.

Note that many load balancer configurations inadvertently cause sessions to be destroyed far sooner than the session hint, due to "round robin" configuration. When a session originally defined on gateway A is sent to gateway B, gateway B will send a session renegotiation because we don't share session information between gateways, so gateway B cannot resume the session, because it doesn't have a session cache entry for the original session negotiated with gateway A.