A tested web server can provide anonymous or authenticated access to its contents. If you connect to a web server anonymously, LoadComplete will be able to test the server without any restrictions. There are some restrictions when you are testing a web server that requires authentication. This topic describes the authentication types supported by LoadComplete and explains how you can specify authentication parameters.
Supported Authentication Types
LoadComplete supports the most popular authentication types:
LoadComplete simulates operations with the supported authentication types through the Security Support Provider Interface (SSPI). In order for LoadComplete to be able to reproduce load tests successfully, the appropriate SSPI support components must be installed in the operating system.
How Authentication Support Works
Typically, when a client tries to access restricted resources, the server denies access if no proper authentication data is specified. To get access, the client sends a request with authentication data (usually, it is a name/password pair). The server verifies the credentials and either grants access to the requested resource or denies it.
During scenario recording, LoadComplete detects this data exchange and records it in the same way it records regular requests and responses:
Depending on the authentication type (see below), LoadComplete does one of the following:
It records the credentials as part of a scenario (in a plain or encoded format, depending on the authentication type):
It does not capture the credentials, nor does it store them in the recorded scenario. Instead, it adds the server providing the restricted resources to the Authentication table of your project. You specify your credentials for the server manually in the table so that LoadComplete can use them during simulation:
During traffic simulation, LoadComplete automatically detects any authentication challenges coming from the tested web server and sends the credentials provided during the recording or specified in your project. If the credentials are valid and access is granted, LoadComplete will get and validate the server response:
We recommend that you start recording before sending any requests to your tested web server and before sending any authentication data. If you start recording after the authentication data is provided, during simulation, the needed data will not be sent, and your tested web server will deny access to the requested resources. If the needed authentication data is specified in the Authentication table of your project, LoadComplete will try to use it to get access to the resources (see Automatic Authentication). If it fails to do that, for example, if no credentials are specified or if they are invalid, your simulation will fail.
For details on how each authentication type is supported and how you specify the credentials to be used during simulation, see the sections below.
Authentication Support Details
Some authentication types require that the user specify the user name and password. Other types rely on other data like a Windows user account or a security certificate installed on the user computer.
To configure a connection for certain authentication types, you may need to specify user credentials in the Authentication editor of your project (see below). For other authentication types, you can modify the user name and password by editing the recorded traffic in the scenario editor. For some other types, you need to configure the computer or computers where you run tests. See below for details.
When this authentication type is used, the browser displays a dialog or a form where a user enters their credentials: the user name and password. The password is passed to the web server in a request header as Base64 encoded clear text, which means that this password can be intercepted, decoded and reused.
LoadComplete records the requests that contain the user name and password. You can see them in the Scenario editor. During the test run, LoadComplete will use the recorded user name and password. To use other name and password during the test run, you can modify the recorded credentials in the scenario. You can also specify the needed credentials in the Authentication table of your project. LoadComplete will use them instead of the recorded ones. See below.
This authentication type implies using the Secure Sockets Layer (SSL) to authenticate user access to the server. Only the users that have special client security certificates are allowed to access the server resources.
To use certificate authentication, you need to install a client security certificate on your computer. If you use Remote Agents to simulate virtual users on remote machines, you need to install that certificate on these machines too. See Certificate Authentication for details.
Digest authentication sends the user name and password through the network as an MD5 hash, which is also known as a message digest. Original user names and passwords cannot be deciphered in this case.
During scenario recording, LoadComplete detects web servers that use Digest authentication. If a server is an IIS server, LoadComplete creates an item for it in the Authentication editor. You need to specify the user name and password in this editor. During test run, LoadComplete will use the name and password you specify in the editor.
If a server is not an IIS server (for example, if it is an Apache server), LoadComplete does not create any items for it in the Authentication editor. You can see the encoded user name and password in the Scenario editor. You cannot change these values in your load tests.
Form-Based Authentication (FBA)
This authentication type presents the form on a web page in which a user specifies the credentials. These credentials are then transferred to the server as part of the request. LoadComplete records this request, and you can modify it as needed in the Scenario editor. For example, you can connect to web servers with Microsoft SharePoint Forms Based Authentication.
This authentication type uses the Key Distribution Center (KDC) service to provide both the client and the server with session keys. It uses the session keys to encrypt and decrypt data transferred between the client and the server.
During scenario recording, LoadComplete detects web servers that use Kerberos authentication and creates an item for them in the Authentication editor. You can then change the user name and password in this editor. When LoadComplete reproduces the recorded traffic to web servers that support Kerberos authentication, it uses the user name and password specified in the Authentication editor.
|Note:||LoadComplete can neither record, nor reproduce authorization requests for web servers that use Kerberos Authentication with Extended Protection for Authentication enabled. The Extended Protection should be disabled on such a server if you want to authorize on it when recording or reproducing traffic. Note, however, that this will impair your server security.|
This authentication is sometimes called Integrated Windows authentication. It uses either NTLM, Kerberos or Digest authentication depending on which operating systems the client and server computers have.
A secure authentication type. It hashes the user name and password before sending them through the network. This type of authentication does not require a user name or password. Instead, it uses the information about the current Windows user account registered on the client computer. Currently, LoadComplete supports NTLM ver. 2.0.
When LoadComplete reproduces the recorded traffic to web servers that support NTLM authentication, it uses the user name and password specified in the Authentication editor. During scenario recording, LoadComplete detects web servers that use NTLM authentication and creates an item for them in the Authentication editor. If needed, you can then change the user name and password in this editor.
|Make sure to enter the user name and password of the Windows account you will use to run LoadComplete or its Remote Agent (if you run tests on remote computers).|
During scenario recording, LoadComplete records the credentials the web application sends to the resource owner. You can view and edit these credentials in the Scenario editor. During the test run, LoadComplete will use the recorded credentials to get the access token and will provide all subsequent requests with access to the needed resources.
In this table, you can manage the authentication parameters the scenarios of your project use. Before sending an authentication request during the test run, LoadComplete will check the name or IP address of the target server and will retrieve the appropriate user name and password from the table to use them in the the request.
To open the table, double-click the Authentication node in the Project Explorer panel. (If the panel is hidden, choose View > Project Explorer from LoadComplete main menu to make it visible):
The table has the following columns:
The name or IP address of the tested server. If the server is the current computer (where LoadComplete is running), Server can be localhost, 127.0.0.1 or an empty string.
The user account or the certificate you use to log in to the tested web server.
The password you use to connect to the tested web server.
Each row in the table corresponds to one server. This means you can use only one login-password pair for a server. If you need to simulate different user logins, specify variables in the Login and Password cells. Put the
@character before the variable name. For example,
Specify the server value that exactly matches the server name or address LoadComplete uses in its work. Otherwise, LoadComplete will be unable to use the provided authentication information. For example, testserver.domain.com and testserver are two different computer names, so, you cannot specify testserver.domain.com if the server’s computer name is testserver.
To find the correct name, open your scenario for editing and look at the Host List panel. Specify the server name as it is displayed in this panel (minus the colon and port number, of course). To verify you have specified the server name correctly, check if the Summary page of the top-level Scenario item displays an error or not. See below.
If the tested web server uses the Negotiate authentication and the Authentication table does not have an entry for that server (this may be, for instance, if server is specified incorrectly), LoadComplete will use the login and password of the user account that it is running under.
Working With the Editor
Right-click somewhere in the Authentication table and choose New Item from the context menu.
This will add a new row to the table.
Change the cell values to specify the needed settings.
Right-click an existing account in the Authentication table and choose Copy or Cut from the context menu.
Right-click somewhere in the table and choose Paste from the context menu.
|Note:||Since the table does not allow entering several credentials for the same server, it will automatically change the server name when you paste the data.|
Click the needed cell to select it and then press F2, or click the cell twice (not a double-click). This will open the in-place editor.
Enter the needed data in the editor.
Press Enter to confirm the changes and to close the in-place editor, or press Esc to cancel the changes.
Right-click the account you want to delete and choose Delete from the context menu.
To save the changes you have made in the table, select File > Save from the main menu of LoadComplete.
To close the table and discard the changes, close the table and answer “No” when asked if you want to save the changes.
Checking Authentication Data
To check if you specified the authentication data correctly:
Open your scenario for editing.
In the scenario editor, select the top-level Scenario node and switch to the Summary page.
If your scenario has a server that requires authentication and for which you have not specified authentication data, the Summary page will report the “Failed to find credentials for Server_Name” error.
Open the Authentication editor and add the correct web server name.
A possible cause of the “Failed to find credentials...” error is a misprinted or incorrect server name in the Authentication settings. When configuring the settings, specify the server as it is specified in the Host List panel of the scenario editor (ignore the port, of course).
Wrong Login Credentials Error
When LoadComplete fails to find authentication information for a server in the Authentication table, it posts an error message to the test log informing you about the problem:
Unable to find credentials for the "HOST_NAME" host which the tested server requested. These data are not specified in the Authentication Information table…
To solve the problem, specify the correct server name, user name and password in the Authentication table.