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 the following steps to tune Common
Secure Interoperability version 2 (CSIv2).
- Consider using Secure Sockets Layer (SSL) client certificates
instead of a user ID and password to authenticate Java clients. Because
you 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 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.
- 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.
You can
further enhance performance by optimizing the values for the CSIv2
session cache. For more information on these settings, see the following
custom properties in the Security custom properties topic:
- com.ibm.websphere.security.util.csiv2SessionCacheLimitEnabled
- com.ibm.websphere.security.util.csiv2SessionCacheIdleTime
- com.ibm.websphere.security.util.csiv2SessionCacheMaxSize
- If you are communicating only with WebSphere
Application Server Version 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.
- For a pure Java
client, you can disable the creation of server sockets used for Object
Request Broker (ORB) callbacks. Do this step only if you are communicating
with servers running WebSphere Application Server, Version 5 or later.
- In the sas.client.props file, add com.ibm.CSI.claimTransportAssocSSLTLSRequired=false and com.ibm.CSI.claimTransportAssocSSLTLSSupported=false.
- 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.
- Consider the following steps to tune Lightweight
Directory Access Protocol (LDAP) authentication.
- In the administration console,
click Security > Global Security.
- Under User registries, click LDAP.
- Select the Ignore case for
authorization option in the WebSphere Application Server LDAP
User 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.
- 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.
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.