+

Search Tips   |   Advanced Search

Configure WS-SecureConversation to work with WS-ReliableMessaging

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


Tasks


Related:

  • Flow for establishing a security context token to secure reliable messaging
  • Configure a WS-ReliableMessaging policy set
  • Add assured delivery to web services through WS-ReliableMessaging
  • Define and manage policy set bindings
  • Configure application and system policy sets for web services using scripting
  • WS-ReliableMessaging
  • Detect and fix problems with WS-ReliableMessaging
  • Configure the Web Services Security distributed cache
  • WS-ReliableMessaging troubleshooting tips


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


    About this task

    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:


    Tasks

    • Create your 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 configured to work together.

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

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

      2. Specify in the secure conversation bindings that the reliable messaging headers must be signed. For more information about how to do this, see Define and manage policy set bindings.

      3. Save 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 your 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).


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


    About this task

    When we 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 ensure that the scoping security context token does not expire before WS-ReliableMessaging can recover and resend its messages, use the administrative console to complete the following steps:


    Tasks

    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 changes to the master configuration.