General security tuning tips

The following are some general tuning tips for WebSphere security configurations:

1. Consider disabling the 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 are putting your local resources at some risk.

2. Disable security for the specific application server that does not require resource protection, because some application servers may not contain any protected resources. If the application server needs to access a downstream application server with credentials, however, this action may not be feasible. Note that for the base WebSphere Application Server product, security cannot be disabled for a specific application server without leaving the administrative application unsecured. However, for the Network Deployment product, global security can be overridden at the server level. Thus, security is provided for the administrative application and not for applications that are deployed into the server where security has been disabled. For more information, see Configure server security (Network Deployment only).

3. (Network Deployment only) 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 you enable or disable global security in a Network Deployment environment.

   Configuration changes are generally propagated with 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 were not propagated. For more information, see The syncNode script in the Administration topic.

   See Configure server security (Network Deployment only) for more detailed information about enabling security in a distributed environment.

4. If you feel your environment is secure enough, consider increasing the cache and token time-out settings. (These settings are available as general properties on the Global Security panel in the WebSphere administrative console.) By doing so, re-authentication is less frequently required. This action allows subsequent requests to more frequently reuse the credentials that are already created. The downside of increasing the token time-out is the exposure of having a token highjacked. The higher time-out setting provides the highjacker 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 Security cache properties for a list of these properties.

5. Consider changing your administrative connector from Simple Object Access Protocol (SOAP) to Remote Method Invocation (RMI). RMI uses stateful connections while SOAP is completely stateless. Run a benchmark test to determine if the performance has been improved in your environment. This control only affects the performance of the administrative application.

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 and or groups or if applications are stopped and started frequently. For more information, see The wsadmin administrative tool in the Administration topic.

7. Consider tuning the ORB because it is a factor in enterprise beans performance with or without security enabled. For more information, see Object Request Broker tuning guidelines.

8. Consider whether you really need SSL to be enabled for connections that are used by the Web server plug-in. These are long-lived connections, while those used to connect browsers to the Web server are typically short lived. Hence, enabling SSL for connections that are used by the Web server plug-in generally has a smaller impact on performance than enabling SSL for connections between browsers and the Web server. However, SSL protection for your plug-in connections may not be required if sufficient security is already provided. For example, you may decide plug-in connections are sufficiently secure if the Web server and application server are protected by a firewall.