Tune the Liberty profile for secure applications

We can tune the Liberty profile to maximize the performance for secure applications.

When we are securing the WebSphere application environment, it is important to understand the impact security can have on performance. Within an application server environment, running applications with security settings can often decrease performance because of increased processor usage from security tasks such as encryption, authentication, and authorization. These services can often increase the path length of application server requests, requiring more resources for each request and slowing down application throughput.

In most cases, we can reduce or eliminate some of this security-related performance loss through performance tuning. We can adjust the resources that are used by security services and choose to use only the security services required by a particular application or environment. Achieving the best possible performance, without sacrificing any necessary security, requires an understanding of the network topology and the security needs of the applications.

• Choose the connections to encrypt.

  In a WebSphere Application Server environment, we can encrypt the following transports:

  • HTTP traffic that is to the web server

  • HTTP traffic that is from the web server to the application server

  • SOAP/JMX traffic

  • File transfer service

  • Web services over HTTP

  When we are determining which traffic to transport over encrypted connections, consider whether the network that is connecting the communicating machines is private or public. There is a significant amount of resources that are associated with setting up a secured connection and encrypting and decrypting the traffic over that connection. We can make significant performance improvements by not requiring encryption over a secured network, for instance. If the application does not require that traffic is encrypted from the client to the HTTP server and from the HTTP server to the application Server, we might be able to use SSL only from the client to the HTTP server and therefore reduce resources required by security.

• Enable on-chip Advanced Encryption Standard (AES) Encryption.

  If we are using IBM SDK Java Technology Edition v7, Service Refresh 3 or later, and we are running on an Intel processor that supports the Advanced Encryption Standard (AES) New Instructions (AES-NI) instruction set, we can achieve performance improvement by taking advantage of on-chip AES encryption. Using these features, we can run AES encryption and decryption using hardware instructions without extra software.

  To enable AES-NI usage, add the following property to the JVM command line or jvm.options file:

  com.ibm.crypto.provider.doAESInHardware=true

  Add the following property to the JVM command line or the jvm.options file to verify that the processor supports AES-NI instruction set:

  com.ibm.crypto.provider.AESNITrace=true

  See Intel Advanced Encryption Standard New Instructions.

• Choose the cipher key length.

  In some cases, the bit length of a cipher key is governed by regulations that are put on the transfer of certain types of data. In these cases, the cipher and key length we choose for a particular SSL connection can be predetermined. For situations where the key length is not regulated, we must choose the appropriate resources to allocate to security so that performance is not decreased more than is necessary. For example, a 256-bit cipher offers stronger encryption than a corresponding 128-bit cipher. However, decrypting messages with a stronger cipher requires more processing time.

  When we are making the decision about the encryption strength to choose, consider the type of data that is traveling across a network. For example, sensitive information, such as financial or medical records, needs the maximum amount of security. Also, consider who has access to the network. If the network is protected by a firewall, consider decreasing the strength of the cipher, or possibly transmitting the data over an unencrypted connection.

  For more information about configuring SSL settings on the Liberty profile, see SSL configuration attributes

• Set connection keep-alive requests.

  In the Secure Socket Layer (SSL) protocol, the initial handshake uses a public-key cipher to exchange a private key for a faster private-key cipher. This faster cipher is used to encrypt and decrypt communication beyond the initial handshake. Because the cipher used for subsequent communication is faster than the one used for the initial handshake, it is important from a performance perspective to limit the number of SSL handshakes that are performed within the application server. We can achieve this result by increasing the length of an SSL connection by increasing session affinity.

  One way to increase the duration of a single SSL connection is to enable persistent HTTP keep-alive connections. Increasing the duration prevents SSL handshakes from taking place on consecutive requests. We can make sure that persistent connections are enabled by verifying that the keepAliveEnabled attribute in the httpOptions element is set to true in server.xml. The default value is true.

  Another way to tune persistent connections is by setting the maximum number of consecutive requests on a single HTTP connection. If the clients are making more than 100 requests consecutively, consider increasing the value of the maxKeepAliveRequests attribute in the httpOptions element in server.xml. The default value is 100.

  See Configuration elements in server.xml.

• Set the authentication cache settings.

  Because the creation of an authentication subject can increase processor usage, the Liberty profile provides an authentication cache to store a subject after the authentication of a user is successful. To fully take advantage of this service to increase performance, we must make sure that it is turned on and tuned according to the users and applications.

  • Make sure that we do not disable the authentication cache. By default, the authentication cache is enabled to help improve performance.

  • Consider changing the authentication cache timeout value. Increasing the timeout value enables subjects to remain in the authentication cache longer and reduces the number of reauthentications needed. However, increasing the timeout value increases the risk of user permissions becoming stale compared to a modified external repository, such as LDAP. Set the authentication cache timeout to reflect the estimated length of client sessions. We can specify the cache timeout by setting the value of the timeout attribute to whichever time you choose in the authCache element in server.xml. The default value is 600 seconds.

  • Finally, if we are experiencing authentication times longer than expected, or we are noticing more traffic to an external authentication repository than expected, the authentication cache might be full. When the authentication cache is full, subjects are evicted. There is not a one-to-one mapping of authenticated users to authentication cache entries. The number of entries in the cache per user depends on other security configurations. It is a best practice for the maximum size of the authentication cache to be larger than the number of distinct authenticated users that are accessing the server at one time. Setting the maximum size of the authentication cache this way helps prevent subjects from being evicted from the cache before timing out. We can change the maximum size of the authentication cache by setting the value of the maxSize attribute in the authCache element in server.xml. The default size is 25000.

  See Configure the authentication cache .

• Configure the HTTP session affinity settings.

  One of the operations in a secure application environment that drains performance the most is the initial setup, including the SSL handshake and authentication. In clustered environments, performance decreases might occur when a web client accesses different application servers. To prevent the increased processor usage of the SSL handshake and reauthentication, it is important to make sure that HTTP session affinity is configured.

  HTTP session affinity ensures that consecutive client requests are routed to the same application server. HTTP session affinity aids performance in various ways, but specifically, it prevents the increased processor usage of reauthentication and SSL handshaking. Consult the documentation of the HTTP Server or Load Balancer for instructions on setting up HTTP session affinity.

  See Configure session persistence .

Parent topic: Tune the Liberty profile

Tasks:

Tune federated LDAP repositories

Related information:

Intel Advanced Encryption Standard New Instructions