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

Enable the distributed cache using synchronous update and token recovery

To support secure conversation in a cluster environment, the distributed cache stores the shared state information. v7.0 and later of WebSphere Application Server uses MBeans to improve synchronous update of the cache across the cluster. In addition, persistent token support is provided by storing the token data in a database.

Synchronous update of shared information in the distributed cache is implemented in the product using an MBean solution. When update of the shared state information across cluster members is required, a synchronous blocking call is issued to replicate the token state changes to all the servers in the cluster. This solution removes the limitations of using session affinity for secure conversation in a cluster environment.

Perform the following high-level steps to enable distributed cache when using secure conversation for message-level protection in a cluster environment.

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

  2. Click the check box to select the Enable distributed cache setting.

  3. The distributed cache setting has three options. The first option is Synchronous update of cluster members. This option is selected by default, enabling the runtime to update all the cluster members with token information synchronously. If this is selected, then session affinity does not have to be enabled.

    The second option is Asynchronous update of cluster members, which we can select by clicking the corresponding radio button. For this option to work successfully, session affinity must be enabled. For information on enabling session affinity, read the topic Enable distributed cache and session affinity when using Secure Conversation. If Asynchronous update of cluster members is selected, skip steps 4 and 5.

    The third option is Token recovery support. To enable this option, click the corresponding radio button, then select a data source (database) from the Cell level data sources menu list. To create a data source, click the Manage data sources link. If Token recovery support is selected, skip steps 4 and 5.

  4. This step is needed only if Synchronous update of cluster members is selected. Create a replication domain, as follows:

    1. In the dmgr console, click Environment > Replication domains > New.

    2. Enter a name for the domain. For example, ABCDomain.
    3. In the Number of replicas section, click the radio button to select the Entire Domain option.

    4. Click OK, then Save, to save the modified configuration.

  5. This step is needed only if Synchronous update of cluster members is selected. Enable the dynamic cache by performing the following steps for each server in the cluster:

    1. In the dmgr console, click Servers > Server Types > WebSphere application servers > server_name > Container Services > Dynamic cache service.

    2. Select the Enable cache replication option.

    3. Select the replication domain name created in the previous step. For example, ABCDomain.

    4. Under Replication type. select Both push and pull from the menu list.

    5. Click OK, then click Save to save the modified configuration.

    Different clusters should use different replication domains. Likewise, cluster members from the same cluster should use the same replication domain. This ensures that synchronous update of cluster members performed by the Web Services Security runtime, and dynamic replication service updates of cluster members performed by the WAS dynamic cache runtime, are in sync.


Results

When the configuration steps are complete, we have enabled the distributed cache with either the default option, which is synchronous update of cluster members, or with asynchronous cluster update or with token recovery support. The token recovery support option uses a JDBC database to store the token state. This provides failover support for high availability of the token. If the server processing the request does not have access to the secure conversation token, the request fails, producing an error such as "null secure conversation token" or "invalid secure conversation token".


Related


Enable distributed cache and session affinity when using Secure Conversation


Reference:

WSSCacheManagement command group for AdminTask


+

Search Tips   |   Advanced Search