You 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), Lightweight Directory Access
Protocol (LDAP) authentication, Web authentication, and authorization.
About this task
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 you can disable in your environment. For example, if your application
servers are running in a Virtual Private Network (VPN), consider whether you
can disable Secure Sockets Layer (SSL). If you have a lot of users, can they
be mapped to groups and then associated to your Java 2 Platform, Enterprise
Edition (J2EE) roles? These questions are things to consider when designing
your security infrastructure.
Procedure
- Consider the following recommendations for tuning general security.
- 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.
- 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,
you must propagate new security settings when enabling or disabling administrative security.
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, you must 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, you 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 Enabling security for the realm.
- Consider increasing the cache and token timeout if you feel your environment
is secure enough. By increasing these values, 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 timeout is
the exposure of having a token hacked and providing the hacker more time to
hack into the system before the token expires. You can 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.
- Consider changing your administrative connector from Simple Object Access
Protocol (SOAP) to Remote Method Invocation (RMI) because RMI uses stateful
connections while SOAP is completely stateless. Run a benchmark to determine
if the performance is improved in your 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.
WebSphere Application Server 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 the AdminApp object for
more information about how to update access IDs.
Consider tuning the Object Request Broker (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 Java Cryptography
Extension (JCE) policy file can improve performance. Refer to the article, Tuning Web services 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 the following steps to tune Lightweight
Directory Access Protocol (LDAP) authentication.
- In the administration console, click Security
> Secure administration, applications, and infrastructure.
- Under User account repository, click the Available
realm definitions drop-down list, select Standalone LDAP registry and
click Configure.
- Select the Ignore case for authorization option
in the standalone LDAP registry configuration, when case-sensitivity is not
important.
- Select the Reuse connection option.
- Use the cache features that your LDAP server supports.
- Choose either the IBM Tivoli Directory Server or SecureWay directory
type, 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,
authorization must be case insensitive to use IBM Tivoli Directory Server.
- 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 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 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 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.
See
the article Security cache properties for a list of these properties.
- Enable single sign-on (SSO). To configure SSO, click Security
> Secure administration, applications, and infrastructure. 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 you can select Simple WebSphere Authentication Mechanism (SWAM)
as the authentication mechanism on the Authentication mechanisms and expiration
panel, SWAM is deprecated in Version 6.1 and
does not support SSO. 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. Some situations exist where SSO is not a desirable
and you do not want to use it in those situations.
- Disable or enabling 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.
- WebSphere Application Server Version 6.1.0.9 contains
APAR PK43270, which introduces the following two custom properties that might
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 your users to groups in the user registry. Associate the groups with
your Java 2 Platform, Enterprise Edition (J2EE) roles. This association greatly
improves performance when the number of users increases.
- Judiciously assign method-permissions for enterprise beans. For example,
you 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, you
can use the *.jsp URL pattern to apply the same authentication data
constraints to indicate all JavaServer Pages (JSP) files. 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 administrative console
to reduce the extra overhead of security attribute propagation:
- com.ibm.CSI.disablePropagationCallerList=true
- com.ibm.CSI.propagateFirstCallerOnly=true (use if you want 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 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
that 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 of configuration for
your environment. Continue to run benchmarks if anything changes in your environment,
to help determine the impact of these changes.