Tuning security configurations

We can tune security to balance performance with function. You can achieve this balance following considerations for tuning general security, Common Secure Interoperability version 2 (CSIv2), LDAP authentication, Web authentication, and authorization.

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

 

• Consider the following recommendations for tuning general security.

  • Consider disabling Java 2 security manager if we know exactly what code is put onto the server and you do not need to protect process resources. Remember that in doing so, you put the local resources at some risk.

  • Consider propagating new security settings to all nodes before restarting the dmgr and node agents, to change the new security policy.

    If the security configurations are not consistent across all servers, you get access denied errors. Therefore, propagate new security settings when enabling or disabling administrative security.

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

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

    For more detailed information about enabling security in a distributed environment, see Enable security for the realm.

  • Consider increasing the cache and token timeout if we feel the environment is secure enough. By increasing these values, we 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 timeout 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 Authentication cache settings for a list of these properties.

  • Consider changing the admin connector from SOAP to RMI because RMI uses stateful connections while SOAP is completely stateless. Run a benchmark to determine if the performance is improved in the environment.

  • 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. WAS maps user and group names to unique access IDs in the authorization table. The exact format of the access ID depends on the repository. The access ID can only be determined during and after application deployment. Authorization tables created during assembly time do not have the proper access IDs. See Commands for AdminApp for more information about how to update access IDs.

  • Consider tuning the (ORB) because it is a factor in enterprise bean performance with or without security enabled. Refer to the ORB tuning guidelines topic.

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

  • In some cases, using the unrestricted JCE policy file can improve performance. Refer to the article, Tuning WS-Security.

  • Distributing the workload to multiple Java virtual machines (JVMs) instead of a single JVM on a single machine can improve the security performance because there is less contention for authorization decisions.

• Consider the following steps to tune Common Secure Interoperability version 2 (CSIv2).

  • Consider using SSL client certificates instead of a user ID and password to authenticate Java clients. Because we are already making the SSL connection, using mutual authentication adds little overhead while it removes the service context that contains the user ID and password completely.

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

  • Consider putting only 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, the identity token is trusted. The SSL connection trusts the server through client certificate authentication.

  • Ensure that stateful sessions are enabled for CSIv2. This is the default, but requires authentication only on the first request and on any subsequent token expirations.

  • If communicating only with WAS V 5 or higher 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.

    SAS is supported only between V6.0.x and previous version servers that have been federated in a V6.1 cell.

• Consider the following steps to tune LDAP authentication.

  1. In the administration console, click...
     Security | Global security

  2. Under User account repository, click the Available realm definitions drop-down list, select Standalone LDAP registry and click Configure.

  3. Select the Ignore case for authorization option in the standalone LDAP registry configuration, when case-sensitivity is not important.

  4. Select the Reuse connection option.

  5. Use the cache features that the LDAP server supports.

  6. Choose either the IBM Tivoli Directory Server or SecureWay directory type, if we 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, authorization must be case insensitive to use IBM Tivoli Directory Server.

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

• Consider the following steps to tune Web authentication.

  • Increase the cache and token timeout values if we feel the 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 that are already created. A disadvantage of increasing the token timeout is the exposure of having a token stolen and providing the thief more time to hack into the system before the token expires.

  • Enable SSO. To configure SSO, click...
    Security | Global security

    Under Web security, click Single sign-on (SSO).

    SSO is only available when you configure LTPA as the authentication mechanism in the Authentication mechanisms and expiration panel. Although we can select Simple WebSphere Authentication Mechanism (SWAM) as the authentication mechanism on the Authentication mechanisms and expiration panel, SWAM is deprecated in V7.0 and does not support SSO. When you select SSO, a single authentication to one appserver is enough to make requests to multiple appservers in the same SSO domain. Some situations exist where SSO is not a desirable and you do not want to use it in those situations.

  • Enable or disable the Web Inbound Security Attribute Propagation option on the Single sign-on (SSO) panel if the function is not required. In some cases, having the function enabled can improve 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 can improve performance. This improvement is most likely when the user registry calls do not take considerable resources.

  • The following two custom properties might help to improve performance when security attribute propagation is enabled:

    • com.ibm.CSI.propagateFirstCallerOnly

      When this custom property is set to true the first caller in the propagation token that stays on the thread is logged when security attribute propagation is enabled. Without setting this property, all of the caller switches are logged, which can affect performance.

    • com.ibm.CSI.disablePropagationCallerList

      When this custom property is set to true the ability to add a caller or host list in the propagation token is completely disabled. This function is beneficial when the caller or host list in the propagation token is not needed in the environment.

• Consider the following steps to tune authorization.

  • Map the users to groups in the user registry. Associate the groups with your Java EE roles. This association greatly improves performance when the number of users increases.

  • Judiciously assign method-permissions for enterprise beans. For example, we can use an asterisk (*) to indicate all the 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 that is required to load the deployment descriptor. It also reduces the search time during method-permission match for the enterprise beans method.

  • Judiciously assign security-constraints for servlets. For example, we can use the *.jsp URL pattern to apply the same authentication data constraints to indicate all JSPs. For a given URL, the exact match in the deployment descriptor takes precedence over the longest path match. Use the *.jsp, *.do, *.html extension match if no exact matches exist and longest path matches exist for a given URL in the security constraints.

• Use new tuning parameters when using Java 2 security. The new tuning parameters can improve performance significantly, and introduce a new concept called Read-only Subject, which enables a new cache for J2C Auth Subjects when using container-managed auth data aliases.

  If the J2C auth subject does not need to be modified after it is created, the following new tuning parameters can be used to improve Java 2 Security performance:

  • com.ibm.websphere.security.auth.j2c.cacheReadOnlyAuthDataSubjects=true

  • com.ibm.websphere.security.auth.j2c.readOnlyAuthDataSubjectCacheSize=50 (This is the maximum number of subjects in the hashtable of the cache. Once the cache reaches this size, some of the entries are purged. For better performance, this size should be equal to the number of unique subjects (cache based on uniqueness of user principal + auth data alias + managed connection factory instance) when role-based security and Java 2 security are used together).

• Use new tuning parameters to improve the performance of Security Attribute Propagation. The new tuning parameters can be set through custom properties in the admin console to reduce the extra overhead of Security Attribute Propagation:

  • com.ibm.CSI.disablePropagationCallerList=true

  • com.ibm.CSI.propagateFirstCallerOnly=true (use to track the first caller only).

 

Results

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

 

Next steps

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 of configuration for your environment. Continue to run benchmarks if anything changes in the environment, to help determine the impact of these changes.

SSL performance tips
Tuning security performance

 

Related tasks

Tuning, hardening, and maintaining security configurations