WS-Security Configuration

Configuration of WS-Security

Let’s understand the WS- Security Configuration. SoapUI manages WS-Security configurations at the project level. These configurations are useful at several places within a project:

Firstly, for outgoing requests and their responses.
Secondly, for incoming requests to MockServices and their MockResponses.
Subsequently, for monitored requests and their monitored responses in the SOAP Monitor.

If you click on the WS-Security Configurations tab on the project level, four sub-tabs are-

First of all, outgoing WS-Security Configurations: configurations that should be applied to outgoing messages.
Secondly, incoming WS-Security Configurations: configurations that should be applied to incoming messages.
Subsequently, Keystores: keystores used for encryption, decryption and signing.
Lastly, Truststores: truststores used for signature verification.

Steps for encrypting a soap request in SoapUI

First of all, add a keystore by clicking the Add button and browsing to your keystore file.
Secondly, enter the password for the keystore.
After this, make sure that the Status is OK. If not, check your password and Status for errors.
Subsequently, create a new outgoing configuration by clicking on the add button.
Further, name the outgoing configuration.
In addition, now create a new Outgoing configurations entry by clicking on the lower add button.
Add an Encryption entry.
Consequently, select the keystore and key alias (key) that you want to use along with the password for that alias.
Now, open the SOAP request that you want to apply the encryption to and click the Aut tab in the bottom corner and select the outgoing configuration.
Finally execute the SOAP request and click the Raw tab to verify that the encryption is added to the outgoing request.

Keystores and Truststores

The Keystores and Truststores tabs allows you to add an arbitrary number of keystores and truststores to your WS-Security configurations.

Add a new keystore or truststore by selecting the Add button in the toolbar. Then, browse to the corresponding file and press ok. Now, type the password to the file and it will be added to the list. The Status column will display if loading goes ok.

The following columns are available in the Keystores and Truststores table:

First of all, Source: the source file of the keystore / truststore.
Secondly, Status: the load status of the keystore / truststore.
Subsequently, Password: the keystore password.
Further, Default Alias: the default alias (key) to be selected when using the keystore / truststore.
Lastly, Default Password: the password for default alias.

Outgoing WS-Security configurations

Outgoing WSS configurations are helpful in processing outgoing messages, like adding encryption, signature, etc. Each configuration contains an arbitrary number of entries, each corresponding to some WSS related action to be taken on the outgoing message.

Outgoing WS-Security configurations

The following columns are available in the Outgoing WS-Security Configurations table:

First of all, Name: a unique name for the configuration.
Secondly, Default Username/Alias: The default username / alias to be used in entries.
Subsequently, Default Password: the default password for the username / alias.
After this, Actor: the actor name.
Last but not least, Must Understand: marks the header as must understand.

When selecting a configuration in the table, the lower half of the panel will display a list of applied entries. Now, select the outgoing configuration, in our case an Encryption and a Timestamp entry. The entries are applied to the outgoing message from top to bottom in the list. It’s also possible to reorder or remove entries by using the toolbar buttons.

Entries

These are the possible entries for the Outgoing WS-Security configurations.

Encryption

Encrypts outgoing messages. These are the configurable fields:

First of all, Keystore: The keystore to use when encrypting the message.
Secondly, Alias: The alias (key) to use when encrypting the message.
Thirdly, Password: The password for the alias.
Subsequently, Key Identifier Type: The type of key.
After this, Embedded Key Name / Embedded Key Password: If the key identifier type is Embedded KeyInfo then these fields are used to specify the name and password of the embedded key.
Further, Symmetric Encryption Algorithms / Key Encryption Algorithm: The algorithms to use. If you’re not sure which to choose, leave the preselected item as default.
After this, Create Encrypted Key: If checked this will encrypt the symmetric key into an EncryptedKey.
Moreover, Parts: By using this table, you are able to encrypt only certain parts of the outgoing message. If this is not checked the whole message will be encrypted.
Further, ID: The identifier of the XML element to encrypt.
Consequently, Name: The name of the XML element to encrypt.
After this, Namespace: The namespace of the XML element to encrypt.
Moreover, Encode: Use Content for encrypting the inner parts of the element and Element to encrypt the whole element.
Lastly, Observe! This cell is required when using the Parts table.

Signature

Signs the outgoing message. These are the configurable fields:

Firstly, Keystore: The keystore to use when signing the message.
Secondly, Alias: The alias (key) to use when signing the message.
Thirdly, Password: The password for the alias.
Subsequently, Key Identifier Type: The type of key.
Further, Signature Algorithm / Signature Canonicalization / Digest Algorithm: The algorithms to use. If you’re not sure which to choose, leave this as default.
Moreover, Use Single Certificate: If checked, a single certificate will be used.
After this, Parts: By using this table, you are able to sign only certain parts of the outgoing message. If this is not checked the whole message will be sign.
Subsequently, ID: The identifier of the XML element to sign.
In the same vein, Name: The name of the XML element to sign.
Further, Namespace: The namespace of the XML element to sign.
Moreover, Encode: Enter “Content” for signing the inner parts of the element and Element to sign the whole element.
Lastly, Observe! This cell is required when using the Parts table.

Username

Add a Username token to the outgoing message. These are the configurable fields:

First of all, Username: The username.
Secondly, Password: The password.
After this, Add Nonce: Adds a nonce (recommended).
Subsequently, Add Created: Adds a created element (recommended).
Lastly, Password Type: This specifies how the password should be serialized. The PasswordDigestExt option is non-standard and should only be used for interop issues where the message receiver desires an extra SHA-1 Hash of the password.

Timestamp

Adds a timestamp entry. The configurable fields are as follows:

On one hand, Time To Live: How long the message is valid. The default unit is seconds.
On the other hand, Millisecond Precision: If checked the unit will be milliseconds instead of seconds.

SAML (Form) – Adds SAML assertion. The configurable fields are as follows:

First thing first, SAML version: The SAML standard version.
Secondly, Signed: Check this if you want to sign your assertion.
Further, Assertion type: The type of assertion.
Subsequently, Keystore: The keystore to be used when signing.
After this, Password: The password used by the keystore.
Moreover, Issuer: The issuer.
Consequently, Subject name: The subject name.
Further, Subject Qualifier: The subject qualifier.
In the same vein, Digest Algorithm / Signature Algorithm: The algorithms to use.
In addition, Attribute name: If the assertion type is Attribute, you can use this field to specify the attribute name.
Lastly, Attribute values: A list of values that belongs to the attribute name specified above.

Adding outgoing configuration explicitly – As an alternative to using the Auth tab you can right click in a XML view of a request and select the Outgoing WSS menu item. This will try to generate and add the outgoing WSS to the current XML.

Incoming WSS

Incoming WSS configurations are useful in processing incoming messages like decrypting and validating signatures of the incoming messages. Since the WS-Security headers of an incoming message contain most of the information. Further, this information requires to decrypt or validate a message. The only configuration needed by SoapUI is which keystore or truststore that should be used.

WS-Security Configuration