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 Platform, Enterprise Edition
(Java EE) 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.
- 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 the Commands for the AdminApp article
for more information about how to update access IDs.
- If using SSL, enable the SSL session tracking
mechanism option
as described in the information about session management settings.
- 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 >
Global security.
- 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 stand-alone 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.
- Enable single sign-on (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
you can select Simple WebSphere Authentication Mechanism
(SWAM) as the authentication mechanism on the Authentication mechanisms
and expiration panel, SWAM is deprecated in Version 8.0 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 enable 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
The
default value
of this property is true. 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. When this property is set to false, 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 Platform, Enterprise Edition
(Java EE) 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.