Tune security configurations

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 appservers are running in a Virtual Private Network (VPN), consider whether disable Single Sockets Layer (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 appserver that does not require resource protection because some appservers do not have protected resources. If the appserver needs to go downstream with credentials, however, this action might not be feasible.

3. Consider propagating new security settings to all nodes before cycling 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, you can wait for the automatic synchronization interval to pass, or you 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) you can use the syncNode utility to synchronize the nodes where the new settings are not propagated.

   Refer to the article, Enabling and disabling 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 types and sizes 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 or 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.

 

Tuning CSIv2

1. Consider using 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 Version 2 (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 WAS Version 5 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, you can disable the creation of server sockets used for Object Request Broker (ORB) callbacks.Do this only if you are communicating with servers running WAS, Version 5 or later.

   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 check box in the WebSphere Application Server LDAP User Registry configuration, when case-sensitivity is not important.

2. Select Reuse Connections in the WAS 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_Directory_Server or SecureWay, if you are using an IBM Directory Server. The IBM 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 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 types and sizes for a list of these properties.

2. Consider enabling single singon (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 appserver is enough to make requests to multiple appservers in the same SSO domain. There are some situations where SSO is not desirable and should not be used in those situations.

 

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, you can 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, you can 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, create a benchmark before making any change to ensure the change is improving performance.

 

Usage Scenario

Continue to run benchmarks if anything changes in your environment, to help determine the impact of these changes.

 

See Also

Security cache properties
SSL performance tips

 

---