WAS v8.5 > Secure applications > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services > Secure requests to the trust service using system policy sets > Enable secure conversation

Secure conversation client cache and trust service configuration

For both distributed and local clients, the WebSphere Application Server secure conversation client cache stores tokens on the client.

WAS supports caching of the security context token for both the distributed client and local client. If the security context token is distributed, a client in the same replication domain uses the same security context token. Distributed caching also supports disk offload to save the security context token to disk for recovery. When the client runs applications using secure conversation, and is part of a cluster setup, then the client can use the distributed cache mechanism to replicate the token data among the cluster members.

To use the dmgr console to modify the cache settings, click Services > Security Cache.

We can configure the cache settings, such as the following.

• Set the time the token remains in the cache after timeout. Default is 10 minutes. This value is a time window to renew an expired token.

• Set the renewal interval before the token expires. Default is 10 minutes, and the minimum value is 3 minutes. Entering a number less than 3 minutes causes an error.

  This setting is critical. This setting represents the maximum roundtrip time for a client to make a request, the transport request to go to the server, the server to process the request, and the transport response (if applicable) back to the client. If the time specified is too small and there is not enough time specified, then the token might expire during the roundtrip, and the client receives a failure response. If the time specified is too large, then performance diminishes.

  If the security context token is renewed too often, it might cause Web Services Secure Conversation (WS-SecureConversation) to fail or even cause an out-of-memory error to occur. It is required set the renewal interval before the token expires value for the Secure conversation client cache to a value less than the token timeout value for the security context token. It is also suggested the token timeout value be at least two times the renewal interval before the token expires value.

• Select the Enable distributed caching check box to support distributed clients. You must ensure the WAS dynamic cache service, and cache replication, are enabled. For more information on enabling the dynamic cache service, refer to the topic Enabling the distributed cache using synchronous update and token recovery.
• Define a custom property, edit, or remove existing custom properties.

The WS-SecureConversation client rejects a security context token that is issued at a future time. If we cannot synchronize the clock between the client machine and service machine, the clock skew could be configured to prevent the rejection of a valid token. The default clock skew is 3 minutes. To modify the default clock skew setting, add the following custom property to the desired minutes:

clockSkewToleranceInMinutes

Alternatively, use wsadmins to manage secure conversation client cache configurations.

Thin client

For a web service application client running outside WAS, the security context token is cached only in the local Java process. The following system properties can be used to override the default cache setting on the thin client:

com.ibm.wsspi.wssecurity.SC.cache.cushion

Time in minutes to renew a security context token to be used with WS-SecureConversation on the client side so the security context token has enough time to complete the downstream call. Default is 10 minutes, and the minimum value is 3 minutes.

com.ibm.wsspi.wssecurity.SC.token.clockSkewTolerance

Tolerant clock skew time for a token between two machines. Default is 3 minutes.

WS-Reliable Messaging settings

When WAS applications use policies such as WS-I RSP with managed persistent WS-Reliable Messaging, modify the cache and trust configuration values.

Set the cache configuration time value to 120 minutes.

1. In the WAS dmgr console, click Services > Security Cache.

2. Modify the value of the Time token is in cache after timeout field from 10 to 120.

3. Click Apply, and then click Save.

Increasing the cache time value means the token remains in the cache for a longer period after token expiration, so the token is available for renewal. The WS-Reliable Messaging runtime scopes the CreateSequence message to the security context token. Therefore, it is important to maintain the same security context for the life time of the Reliable Messaging sequence.

Enable distributed caching using the default option, Synchronous update of cluster members, to support distributed clients. For more information, refer to the topic Enabling the distributed cache using synchronous update and token recovery.

Additional recommended changes

Other important configuration changes are also recommended.

• Modify the life time of the Security Context Token by changing the value from the default of 120 minutes, to 600 minutes.

• Modify the Renew after expiration value by changing the value from false to true.

• Modify settings for the token providers, as follows:
  1. In the dmgr console, click on Services > Trust service > Token providers.

  2. Click Security Context Token.

  3. Change the value in the Token timeout field from 120 to 600.

  4. Click the check box to select Allow renewal after timeout.

  5. Click Apply, and then click Save.

Related

Manage WS-Security distributed cache configuration
Enable the distributed cache using synchronous update and token recovery
Configure the Web Services Security distributed cache
Enable distributed cache and session affinity when using Secure Conversation

Reference:

Security cache settings

+

Search Tips   |   Advanced Search