Adding binary tokens

You can add binary tokens if you want authentication by using a keystore and certificate alias.

Before you begin

Note: If you did not define identity store in Architecture School (refer to identity store), you must create one before you create a binary token. You can create only one binary token for each certificate alias in the keystore.

About this task

To add a binary token:

Procedure

  1. Open a SOAP message for editing.
  2. On the Config page, right-click the node and click Properties.
  3. In the Field Properties dialog, click the WS-Security tab.
  4. On the WS-Security page, ensure that the Enable field is selected.
  5. Select Binary Token from the list. The Timestamp Token editor is displayed.
    Note: If you did not define identity store in Architecture School (refer to identity store), you must create one before you create a binary token. You can create only one binary token for each certificate alias in the keystore.

    A binary token adds a <wsse:BinarySecurityToken> element to the SOAP header. The binary token defines a keystore ( HCL OneTest™ API Identity Store) and public key alias to authenticate the SOAP message.

  6. Optionally, you can define Actor/Role information to further secure the token and the message (actor/role and mustUnderstand).

    The following fields and options are part of the binary token:

    Field Description
    Transformation Name (Required) User-defined name for the security action (helps identify the action in the main list).
    Keystore The HCL OneTest™ API identity store to use.
    Certificate Alias The public key alias to use (defined in the selected keystore).
    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 must be ignored, and a SOAP fault must be generated. If not enabled, the specified actor/role may or may not process the SOAP header.