This topic describes configuration options for using the HTTP 1.0 transport in Client tools. In this section:

...

Security settings for the transport are spread across the following tabs.

Client side SSL

Enable the Use client key store option to specify the key store used to complete the handshake with the server.

HTTP Authentication

Enable the Perform authentication option to set up  basic, NTLM,  Digest, or Kerberos authentication. You can enable the Use Global Preferences option to use the authentication settings configured in the Security Preferences (see Security Settings) or choose an authentication type from the Type drop-down menu to configure authentication settings that apply to the client. You can specify the following types:

• Basic
• NTLM
• Kerberos 
• Digest

For Basic, NTLM, or Digest, enter the Username and Password to authenticate the request.

For Kerberos, enter the Service Principal to authenticate the request. If the correct username and password, or the correct service principal, are not used, the request will not be authenticated.

• Use Global Preferences: Alternatively, you can select Use Global Preferences if you have set Global HTTP Authentication Properties within 

OAuth Authentication 

Configure the OAuth Authentication settings for clients that connect to services that perform authentication under OAuth 1.0a. For OAuth 2.0, authentication is configured in the REST Client's Resource and Payload tabs. Refer to OAuth Authentication for additional details. You can configure the following settings: 

• Perform Authentication: Enabling this option indicates that OAuth Authentication should be performed. An Authentication field containing OAuth specific information will be added to the HTTP Header.
• Consumer Key and Secret Configuration: The Consumer Key and Consumer Secret are the credentials that the client uses to validate itself with the server. The Consumer Key is unique to each client using it. Both of these are required at all steps.
• OAuth Authentication Mode: Specifies what step of the OAuth Scenario you'd like to perform.
  • Obtain Request Token: Requests the Request Token from the server using the Consumer Key and Secret.
  • Scope: Restricts what information may be accessed. This information in embedded into the Consumer Key.
  • Exchange Request Token for Access Token: Exchanges the Request Token plus the verification code for the Access Token.
• Request Token: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
• Request Token Secret: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
• Verification Code: Specifies the verification code provided by the server; this confirms that the resource owner will grant permission.
  • Sign Request for OAuth Authentication: Uses the specified Access Token and Access Token Secret to give the client access to the user's private resources.
• OAuth Parameters: Allows you to specify additional parameters on the OAuth Token— for example, the timestamp and nonce.

Authentication

Allows you to select an authentication method for the tool. Unless otherwise specified, the default authentication method set up for the test suite is used (see Configuring Test Suite Properties), but you can change it by selecting Custom from the first dropdown and choosing the desired option from the next dropdown. Options include:

• One of the shared authentication methods created for the test suite. You can also create an authentication method for the test suite from here by clicking New. See "Global Authentications" on the Adding Global Test Suite Properties page for more information about adding shared authentication methods.

• Global Preferences, which uses the global authorization preferences set in Parasoft> Preferences> Security (if you have set them; see "Security Settings" on the Additional Preference Settings page for more information about global security preferences).
• No Authentication, which is particularly useful for things like negative tests.

Client side SSL

Enable the Use client key store option to specify the key store used to complete the handshake with the serverFor details on using OAuth authorization, see Using OAuth Authentication.

HTTP Headers

You can specify HTTP Headers to include with your request. Use the following controls to add header names and values:

...

This HTTP header is sent for SOAP 1.1 only. It is set in the SOAPAction field of the General settings

Image RemovedImage Added

Authorization

This header is constructed automatically based on the HTTP Authentication and OAuth settings specified in your preferences (under Security> HTTP Authentication and OAuthclient options (HTTP Options > Security> Authentication). The value for NTLM, Digest, and Kerberos authentication will vary depending on various factors, including dynamically-generated challenge responses and security tokens. 

Image Added

Connection

This header is added to the message with value of Keep-Alive if Keep-Alive connection is enabled. This header is not sent if Close connection is enabled (this is the default). Keep-Alive must be enabled for NTLM and Digest HTTP authentication.

...