Adding user tokens

You can add user tokens if you want a simple user name and password authentication.

About this task

To add a user token:

Procedure

  1. Open a SOAP message for editing.
  2. Right-click the message node, and then click Properties.
  3. Click the WS-Security tab.
  4. Select the Enable check box.
  5. Select User Token from the list. The User Token editor is displayed.
  6. A user token adds a wsse:UsernameToken> element to the SOAP header. At a minimum, the user token defines a user name and password to authenticate the SOAP message.

    More (optional) steps can be taken to further secure the token and the message (that is, password digest, nonce, created, actor/role, and mustUnderstand).

    Note: If you want to sign a SOAP body with a User Token, the token must include the Nonce and Created elements.

    The following fields and options are part of the user token.

    Field Description
    Transformation Name (Required) User-defined name for the security action (helps identify the action in the main list).
    Username (Required) User name to include with the token.
    Password (Required) Password for the corresponding user name.
    Apply digest algorithm to password If enabled, encrypts the clear-text password by using the nonce and created elements.
    Generate Nonce A random number that makes the message more unique, designed to prevent relay attacks (that is, by replaying recorded SOAP packets). This option is enabled automatically if a digest is applied to the password.
    Created Adds a timestamp to the outgoing message. This option is enabled automatically if a digest is applied to the password.
    Millisecond precision for timestamps If enabled, the timestamp for the <wsu:Created> element is generated with milliseconds (2009-03-31T02:41:16.817Z). If disabled, the timestamp is generated without milliseconds (2009-03-31T02:41:16Z).
    Actor Indicates a specific message receiver (either the ultimate receiver or an intermediary). For each actor/role that is defined (that is, in multiple tokens), a separate security header is added to the SOAP header.
    Must understand If enabled, makes the SOAP header mandatory for the specified actor/role. In this case, either the header block must be processed or the entire SOAP message is ignored, and a SOAP fault must be generated.

    If not enabled, the specified actor/role may or may not process the SOAP header