IBM WebSphere Application Server Performance Cookbook

Security

Authentication Cache

The authentication cache should generally be enabled (which it is by default) and its maximum size tuned:

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.

Java Security

Java Security is disabled by default which is generally recommended as it has a significant performance cost. For a discussion of the limitations of the Java Security Manager, see the proposed JEP 411 to deprecate and remove it.

Java security typically reduces throughput by 15-40%. However, Java Security is not a fixed cost; rather, the cost is proportional to the number of security calls. One common manifestation of this is that one application has an overhead with Java Security enabled of X%, and then another application has a much higher overhead; in most cases, this is caused by a difference in the number of calls to security between those applications, rather than a product issue. A sampling profiler such as IBM Java Health Center is usually the best way to gauge the overhead of Java Security. Use the call stack invocation paths to reduce the number of security calls if possible.

Single Sign On (SSO)

Consider configuring Single Sign On (SSO) so that:

a single authentication to one application server is enough to make requests to multiple application servers in the same SSO domain.

Security Attribute Propagation

Security attribute propagation shares authenticated security Subjects and security context information between servers. Consider some potential tuning:

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.
Horizontal Security Attribute Propagation

The Single Sign On option will first check the local JVM's authentication cache. A Subject used often can remain here until the LtpaToken expiration. Next, if security attribute propagation and Dynacache are enabled, WAS will check the ws/WSSecureMap DistributedMap:

When front-end servers are configured and in the same data replication service (DRS) replication domain, the application server automatically propagates the serialized information to all of the servers within the same domain using ws/WSSecureMap.

The size of this map may be tuned:

The WSSecureMap security cache settings can be adjusted through custom properties in the administrative console.

  • com.ibm.ws.security.WSSecureMapInitAtStartup=true
  • com.ibm.ws.security.WSSecureMapSize (integer of 100 or greater).

Explicit invalidations for ws/WSSecureMap are sent out on user logout. To disable this, use com.ibm.websphere.security.web.removeCacheOnFormLogout=false

If the subject is not found in ws/WSSecureMap, WAS will try to make an MBean call back to the server that originally created the subject. The originating server's host:port is found in the SSO token. In some cases, this may cause worse performance than simply re-authenticating:

You must determine whether enabling this option improves or degrades the performance of your system. While the option prevents some remote user registry calls, the deserialization and decryption of some tokens might impact performance. In some cases propagation is faster, especially if your user registry is the bottleneck of your topology. It is recommended that you measure the performance of your environment both by using and not using this option. When you test the performance, it is recommended that you test in the operating environment of the typical production environment with the typical number of unique users accessing the system simultaneously.

There is also a timeout value that can be set to manage this condition: com.ibm.websphere.security.tokenFromMBeanSoapTimeout. You can also disable the mbean callback with com.ibm.websphere.security.disableGetTokenFromMBean.

Note: Security attribute propagation may be set at multiple levels: cell, server, and security domain. For security domains, the option is set as a custom property with the name com.ibm.ws.security.webInboundPropagationEnabled and a value of true or false.

LDAP Authentication

When using LDAP authentication, consider various common tuning:

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.

Also consider tuning the LDAP connection and context pools (see below) and the virtual member manager LDAP cache.

LDAP Context Pooling versus Connection Pooling

When using a federated repositories configuration, the virtual member manager (VMM) supports two pooling mechanisms for LDAP repositories. Context pooling is the recommended mechanism; connection pooling should remain disabled (its default in VMM) and the two should not be enabled together.

Context pooling Connection pooling
Provided by WebSphere Application Server (VMM) Java Runtime Environment, at the Java Naming and Directory Interface (JNDI) layer
What is pooled The LDAP context, including the authenticated bind The underlying socket connection only
Bind on reuse Not required Required each time a pooled connection is reused
Configuration scope Per LDAP repository in the federated repositories configuration Per JVM
How it is configured Administrative console or the setIdMgrLDAPContextPool command Generic JVM arguments (the com.sun.jndi.ldap.connect.pool.* system properties)

Context pooling is the better choice for the following reasons:

  • Fewer binds. Because the bind is pooled along with the connection, the LDAP server is not repeatedly bound to. With connection pooling, only the socket is reused, so a bind is required each time it is reused.
  • Centralized configuration. Context pool settings are part of the LDAP repository configuration, so a single change applies to all nodes through configuration synchronization, and settings can be isolated by security domain. Connection pool settings are JVM arguments, so each JVM must be configured separately, and they affect all JNDI LDAP connections in that JVM rather than only VMM.
  • Predictable behavior with concurrent authentication. VMM authenticates a user by binding as that user rather than by using the context pool, which creates a new socket for each authentication. With connection pooling disabled, these sockets are closed immediately after the authentication completes. With connection pooling enabled, they remain open until they time out, which can exceed the number of connections the LDAP server can handle.
  • No added benefit from enabling both. Context pooling already provides the benefit of connection pooling. Enabling both does not improve performance and may produce adverse effects such as connection timeouts.

To use context pooling, select Enable context pool and clear Use connection pooling on the Performance panel of each LDAP repository (Security > Global security > Federated repositories > Configure > Manage repositories > repository_name > Performance).

Secure Sockets Layer (SSL), Transport Layer Security (TLS)

When using TLS/SSL, review various common tuning.

J2C Authentication Subjects

When using container-managed authentication data aliases, consider using read-only subjects:

Read-only Subject 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).

CSIv2 Cache

If using CSIv2, consider setting stateful sessions:

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.

Administrative Security

Review the performance difference between SOAP and RMI:

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.

Expired Certificates

  1. On the SSL certificate and key management page, click the Keystores and Certificates link in the Related Items list.

  2. Click the Keystore,

  3. Click Personal certificate > Additional Properties.

  4. Renew the certificate and exchange the signer certificates between the DMGR and Nodes:

    1. Go to SSL certificate and key management > Manage endpoint security configurations > Click on inbound on the node (NodeDefaultSSLSettings,null) > click on Key stores and certificates

    2. Select both CellDefaultKeyStore and CellDefaultTrustStore by checking the box and click on exchange signers under CellDefaultKeyStore personal certificates. Choose all certificates and click add click add and it will add all those certificate under CellDefaultTrustStore signers and then click OK

    3. Same thing but select both CellDefaultKeyStore and NodeDefaultTrustStore by checking the box and click on exchange signers under CellDefaultKeyStore personal certificates. Choose all certificates and click add and it will add all those certificate under NodeDefaultTrustStore signers and then click OK

    4. Same thing but select NodeDefaultKeyStore and CellDefaultTrustStore by checking the box and click on exchange signers under NodeDefaultKeyStore personal certificates. Choose all certificates and click add and it will add all those certificate under CellDefaultTrustStore signers and then click OK

    5. Same thing but select NodeDefaultKeyStore and NodeDefaultTrustStore by checking the box and click on exchange signers under NodeDefaultKeyStore personal certificates. Choose all certificates and click add and it will add all those certificate under NodeDefaultTrustStore signers and then click OK

  5. Save the changes with the master configuration and restart the dmgr.

  6. Stop the nodeagent and JVMs and manually sync the node with dmgr using syncNode

    1. If the syncNode fails (e.g. ADMU0127E), then manually copy the key.p12 file from the node's configuration in the DMGR profile to the node's configuration.

  7. Start the nodeagent and see the status in the admin console and sync the node from the console and see if sync is going smooth by tailing the nodeagent logs.

Clock synchronization

Clock synchronization (e.g. NTP) may be important for security performance:

Use a clock synchronization service to keep system clock values as close as possible. Security processing depends on time stamp validation and having clocks out of synchronization more than five minutes can affect performance due to unnecessary re-authentication and retry processing.

Trace

Tracing login: *=info:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all and search for login

PasswordEncoder

Password encoder:

$WAS/java/bin/java -Djava.ext.dirs=$WAS/plugins:$WAS/lib com.ibm.ws.security.util.PasswordEncoder $PASSWORD

Password Decoder:

$WAS/java/bin/java -Djava.ext.dirs=$WAS/plugins:$WAS/lib com.ibm.ws.security.util.PasswordDecoder $PASSWORD