Tuning Liberty for secure applications

You can tune Liberty to maximize the performance for secure applications.

• Choose the connections that you want to encrypt.

  In a WebSphere Application Server environment, you 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 you 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. You can make significant performance improvements by not requiring encryption over a secured network, for instance. If your application does not require that traffic is encrypted from the client to the HTTP server and from the HTTP server to the application Server, you might be able to use SSL only from the client to the HTTP server and therefore reduce resources that are required by security.

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

  If you are using IBM® SDK Java™ Technology Edition Version 7, Service Refresh 3 or later, and you are running on an Intel processor that supports the Advanced Encryption Standard (AES) New Instructions (AES-NI) instruction set, you can achieve performance improvement by taking advantage of on-chip AES encryption. Using these features, you 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

  For more information, see Intel Advanced Encryption Standard New Instructions.

• Choose your 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 that you choose for a particular SSL connection can be predetermined. For situations where the key length is not regulated, you 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 you are making your 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 decrypted connection.

  For more information about configuring SSL settings on Liberty, 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. You 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. You can make sure that persistent connections are enabled by verifying that the keepAliveEnabled attribute in the httpOptions element is set to true in the server.xml file. 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 your clients are making more than 100 requests consecutively, consider increasing the value of the maxKeepAliveRequests attribute in the httpOptions element in the server.xml file. The default value is 100.

  For more information about the keep-alive connection attributes, see Java Servlets 3.0.

• Set the authentication cache settings.

  Because the creation of an authentication subject can increase processor usage, Liberty 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, you must make sure that it is turned on and tuned according to your users and applications.

  • Make sure that you 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 your authentication cache timeout to reflect the estimated length of client sessions. You can specify the cache timeout by setting the value of the timeout attribute to whichever time you choose in the authCache element in the server.xml file. The default value is 600 seconds.

  • Finally, if you are experiencing authentication times longer than expected, or you 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. You can change the maximum size of the authentication cache by setting the value of the maxSize attribute in the authCache element in the server.xml file. The default size is 25000.

  For more information, see Configuring the authentication cache in Liberty.

• 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 your HTTP Server or Load Balancer for instructions on setting up HTTP session affinity.

  For more information, see Configuring Liberty session persistence to a database.