Relevant for: API testing only
The default Web Service scenario is based on the WS-Security specification. This scenario lets you place security credentials in the actual SOAP message.
When a SOAP message sender sends a request, the security credentials, known as tokens, are placed in the SOAP message. When the Web server receives the SOAP request, it does not need to send additional requests to verify the integrity of the sender. The server verifies that the credentials are authentic before letting the Web Service execute the application. By not having to go back to the source of the credentials, the application performance improves significantly.
To further secure Web Services, it is common to use digital signatures or encryption for the SOAP messages. Digitally signing a SOAP message verifies that the message has not been altered during transmission. Encrypting a SOAP message helps secure a Web Service by making it difficult for anyone other than the intended recipient to read the contents of the message.
The transport level security includes the authentication and proxy server information. You can also specify Keep Alive preferences and connection timeout.
The WS-Security tab lets you set the message level security through tokens, signatures and encryption.
To support WS-Security, UFT enables you to create security tokens for your script. You can create multiple tokens and set their properties. After creating a token, you use it to sign or encrypt a SOAP message.
The Web Services security mechanism associates security tokens with messages. This mechanism supports several security token formats to accommodate a variety of authentication requirements. For example, a client might need to provide a proof of identity or a security certificate.
The following tokens are available:
When you add a security token to a SOAP message, it is added to the SOAP message in the form of an XML element in the WS-Security SOAP header. The message, however, is exposed and therefore requires additional security. This is especially true when the credentials, including the password, are sent in plain text as it is with role-based security.
The two methods used to secure the data are message signatures and message encryption:
Message Signatures. Message Signatures are used by the recipients to verify that messages were not altered since their signing. The signature is in the form of XML within the SOAP message. The recipient checks the signature to make sure it is valid.
Message Encryption. Although the XML message signature offers a mechanism for verifying that the message has not been altered since it was signed, it does not encrypt the SOAP message—the message is still plain text in XML format. To secure the message in order that it should not be exposed, you encrypt it, making it difficult for an intruder to view and obtain a user's password.