Set WS-SecureConversation to work with WS-ReliableMessaging

Set secure conversation to expect the reliable messaging headers to be signed, and to verify the scoping security context token does not expire before reliable messaging recovers and resends persistent messages.

 

• Set secure conversation to expect the reliable messaging headers to be signed
• Set secure conversation to increase the timeout setting for the scoping security context token

 

Related tasks

Set a WS-ReliableMessaging policy set using wsadmin
Building a reliable Web service application
Set policy set bindings
Learn about WS-ReliableMessaging
Detecting and fixing problems with WS-ReliableMessaging
Set the WS-Security distributed cache
Set a WS-ReliableMessaging policy set

 

Related

WS-ReliableMessaging troubleshooting tips
Example: Establishing a security context token to secure reliable messaging

 

Related information

Configuring application and system policy sets for Web services using scripting

Set secure conversation to expect the reliable messaging headers to be signed

Although secure conversation allows message headers to remain unsigned, the reliable messaging policy requires the reliable messaging headers to be signed. To use secure conversation and reliable messaging policies in the same policy set, the secure conversation bindings must be configured to require that the reliable messaging headers are signed. To achieve this, complete one of the following steps:

 

• Create the policy set from a copy of one of the reliable secure profile default policy sets (WS-I RSP and WS-I RSP ND).

  These policy sets contain instances of the secure conversation and reliable messaging policies that are configured to work together.

• Create the policy set from a copy of the secure conversation policy set:

  1. Add the reliable messaging policy to the copy of the secure conversation policy set.

  2. Specify in the secure conversation bindings that the reliable messaging headers must be signed.

     See about how to do this, see Set policy set bindings.

  3. Save the changes to the master configuration.

  The reliable secure profile default policy sets (WS-I RSP and WS-I RSP ND) are specifically designed and configured to use secure conversation and reliable messaging in the same policy set. Only create the policy set from a copy of the secure conversation policy set if we have a clear business need to do so. Otherwise, always use a copy of one of the reliable secure profile default policy sets (WS-I RSP and WS-I RSP ND).

Set secure conversation to increase the timeout setting for the scoping security context token

When you use a persistent WS-I RSP policy set, which includes WS-SecureConversation, if the scoping security context token is expired when the server is restarted then WS-ReliableMessaging cannot resend its messages and system messages are written to the log file stating that the reliable messaging sequence was not secured using the correct security token.

To verify the scoping security context token does not expire before WS-ReliableMessaging can recover and resend its messages, use the admin console to complete the following steps:

 

1. In the navigation pane, click Services > Security cache. The Security cache detail form is displayed.

2. Set the following values for the security distributed cache:

   1. Set the Time token is in cache after timeout property to a value of at least 120 minutes. This value specifies the length of time to keep tokens after they expire. By default, this is 10 minutes. These expired tokens can be used for reliable messaging recovery.

   2. Select the Enable distributed caching check box, and the default sub-option Synchronous update of cluster members.

3. In the navigation pane, click Services > Trust service > Token providers . In the content pane, select a security context token.

   The Security Context Token detail form is displayed.

4. Set the following values for the security context token:

   1. Check that the Time in cache after expiration property is set to a value of at least 120 minutes.

   2. Check that the Token timeout property is set to a value of at least 120 minutes.

   3. Select the Allow renewal after timeout check box.

   4. Select the Distributed cache check box.

5. Save the changes to the master configuration.