Tuning security configurations


Before you begin

Performance issues typically involve trade-offs between function and speed. Usually, the more function and the more processing involved, the slower the performance. Consider what type of security is necessary and what you can disable in your environment. For example, if your application servers are running in a VPN, consider whether disable SSL. If you have a lot of users, can they be mapped to groups and then associated to your J2EE roles? These questions are things to consider when designing your security infrastructure.



Complete the following steps for general security tuning:



  1. Consider disabling Java 2 Security Manager if you know exactly what code is put onto your server and you do not need to protect process resources. Remember that in doing so, you put your local resources at some risk.

  2. Disable security for the specific application server that does not require resource protection because some application servers do not have protected resources. If the application server needs to go downstream with credentials, however, this action might not be feasible. There are two ways to disable security. Use either of the following two procedures and then restart the application server:

    Using the administrative console

    1. Click Security > Global security .

    2. Disable the Enable global security option.

    Using the command line

    1. Type wsadmin.sh -conntype NONE.

    2. When the system command prompt redisplays, type securityoff.

  3. Consider propagating new security settings to all nodes before restarting the deployment manager and node agents to change the new security policy.

    If your security configurations are not consistent across all servers, you get access denied errors. Therefore, propagate new security settings when enabling or disabling global security in a Network Deployment environment.

    Configuration changes are generally propagated using configuration synchronization. If auto-synchronization is enabled, one can wait for the automatic synchronization interval to pass, or one can force synchronization before the synchronization interval expires. If you are using manual synchronization, synchronize all nodes.

    If the cell is in a configuration state (the security policy is mixed with nodes that have security enabled and disabled) use the syncNode utility to synchronize the nodes where the new settings are not propagated.

    Refer to the article, Enabling global security in the WAS Network Deployment package for more detailed information about enabling security in a distributed environment.

  4. Consider increasing the cache and token time-out if you feel your environment is secure enough. By doing so, you have to re-authenticate less often. This action supports subsequent requests to reuse the credentials that already are created. The downside of increasing the token time-out is the exposure of having a token hacked and providing the hacker more time to hack into the system before the token expires. Use security cache properties to determine the initial size of the primary and secondary hashtable caches, which affect the frequency of rehashing and the distribution of the hash algorithms.

    See the article Security cache properties for a list of these properties.

  5. Consider changing your administrative connector from Simple Object Access Protocol (SOAP) to RMI because RMI uses stateful connections while SOAP is completely stateless. Run a benchmark to determine if the performance is improved in your environment.

  6. Use the wsadmin script to complete the access IDs for all the users and groups to speed up the application startup. Complete this action if applications contain many users, or groups, or if applications are stopped and started frequently.

  7. Consider tuning the Object Request Broker (ORB) because it is a factor in enterprise bean performance with or without security enabled. Refer to the article, ORB tuning guidelines.

  8. If using SSL, then enable the SSL session tracking mechanism option as described in the article, Session management settings.

  9. In some cases, using the unrestricted Java Cryptography Extension (JCE) policy file can improve performance. Refer to the article, Tuning Web services security.


See also

Security cache properties
Secure Sockets Layer performance tips
Tuning security

Tuning CSIv2



  1. Consider using SSL client certificates instead of a user ID and password to authenticate Java clients. Since you are already making the SSL connection, using mutual authentication adds little overhead while removing the service context containing the user ID and password completely.

  2. If you send a large amount of data that is not very security sensitive, reduce the strength of your ciphers. The more data you have to bulk encrypt and the stronger the cipher, the longer this action takes. If the data is not sensitive, do not waste your processing with 128-bit ciphers.

  3. Consider putting just an asterisk (*) in the trusted server ID list (meaning trust all servers) when you use Identity Assertion for downstream delegation. Use SSL mutual authentication between servers to provide this trust. Adding this extra step in the SSL handshake performs better than having to fully authenticate the upstream server and check the trusted list. When an asterisk is used, we simply trust the identity token. The SSL connection trusts the server by way of client certificate authentication.

  4. Ensure that stateful sessions are enabled for Common Secure Interoperability V2 (CSIv2). This is the default, but only requires authentication on the first request and any subsequent token expirations.

  5. If you are only communicating with WebSphere Application Server V6 servers, make the Active Authentication Protocol CSI, instead of CSI and SAS. This action removes an interceptor invocation for every request on both the client and server sides.

  6. For a pure Java client, one can disable the creation of server sockets used for Object Request Broker (ORB) callbacks.

    1. In the sas.client.props file, add com.ibm.CSI.claimTransportAssocSSLTLSRequired=false and com.ibm.CSI.claimTransportAssocSSLTLSSupported=false.

    2. Set the active protocol to csiv2 instead of both in the sas.client.props file. The protocol property changes to com.ibm.CSI.protocol=csiv2.

Tuning LDAP authentication



  1. Select the Ignore case for authorization option in the WebSphere Application Server Lightweight Directory Access Protocol (LDAP) User Registry configuration, when case-sensitivity is not important.

  2. Select the Reuse connections option in the WebSphere Application Server LDAP User Registry configuration.

  3. Check to see which caches your LDAP server has and take advantage of them. This action is best with LDAP servers that do not change frequently.

  4. Choose the directory type of either IBM Tivoli Directory Server or SecureWay, if you are using an IBM Tivoli Directory Server. The IBM Tivoli Directory Server yields improved performance because it is programmed to use the new group membership attributes to improve group membership searches. However, it is required that authorization is case insensitive to use IBM Tivoli Directory Server.

  5. Choose either iPlanet Directory Server (also known as Sun ONE) or Netscape as the directory if you are an iPlanet Directory user. Using the iPlanet Directory Server directory increases performance in group membership lookup. However, only use Role for group mechanisms.

Tuning Web authentication



  1. Consider increasing the cache and token time-out if you feel your environment is secure enough. The Web authentication information is stored in these caches and as long as the authentication information is in the cache, the login module is not invoked to authenticate the user. This supports subsequent requests to reuse the credentials already created. The downside of increasing the token time-out is the exposure of having a token stolen and providing the thief more time to hack into the system before the token expires.

    See the article Security cache properties for a list of these properties.

  2. Consider enabling single signon (SSO). SSO is only available when you select LTPA as the authentication mechanism in the Global security panel. When you select SSO, a single authentication to one application server is enough to make requests to multiple application servers in the same SSO domain. There are some situations where SSO is not desirable and should not be used in those situations.

  3. Consider disabling or enabling the Web Inbound Security Attribute Propagation option on the SSO panel if the function is not required. In some cases, having the function enabled improves performance. This improvement is most likely for higher volume cases where a considerable number of user registry calls reduces performance. In other cases, having the feature disabled improves performance. This improvement is most likely when the user registry calls do not take considerable resources.

Tuning authorization



  1. Consider mapping your users to groups in the user registry. Then associate the groups with your J2EE roles. This association greatly improves performance as the number of users increases.

  2. Judiciously assign method-permissions for enterprise beans. For example, use an asterisk (*) to indicate all methods in the method-name element. When all the methods in enterprise beans require the same permission, use an asterisk (*) for the method-name to indicate all methods. This indication reduces the size of deployment descriptors and reduces the memory required to load the deployment descriptor. It also reduces the search time during method-permission match for the enterprise beans method.

  3. Judiciously assign security-constraints for servlets. For example, use the URL pattern *.jsp to apply the same authentication data constraints to indicate all JSP files. For a given URL, the exact match in the deployment descriptor takes precedence over the longest path match. Use the extension match (*.jsp, *.do, *.html) if there is no exact match and longest path match for a given URL in the security constraints.



There is always a trade off between performance, feature and security. Security typically adds more processing time to your requests, but for a good reason. Not all security features are required in your environment. When you decide to tune security, you should create a benchmark before making any change to ensure the change is improving performance.


What to do next

In a large scale deployment, performance is very important. Running benchmark measurements with different combinations of features can help you to determine the best performance versus the benefit configuration for your environment. Continue to run benchmarks if anything changes in your environment, to help determine the impact of these changes.




WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.