This topic explains configuration options for using HTTP 1.1 with selected supporting tools and provisioning action tools1 transport in Client tools.
Sections include:
| Table of Contents | ||
|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
Security> Client side SSL page options include:
- Use Client Key Store: Specifies the key store used to complete the handshake with the server.
Security> HTTP Authentication page options include:
- Perform Authentication: To set up basic, NTLM, Digest, or Kerberos authentication, select the Perform Authentication check box, then select Basic, NTLM, Kerberos, or Digest from the Type drop-down list.
- 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 the Security Preferences. For more information, see Security Settings.
Security> OAUth Authentication page options include:
- 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.
For details on using OAuth authorization, see Using OAuth Authentication.
Authentication allows you to select an authentication method for the tool. By default, the default authentication method set up for the test suite is selected, 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.
Security> Client side SSL options include:
- Use Client Key Store: Specifies the key store used to complete the handshake with the server.
| Anchor | ||||
|---|---|---|---|---|
|
...
This HTTP header is sent for SOAP 1.1 only. It is set in the SOAPAction field of the General page
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.
Connection
This header is added to the message with the value of close if Close connection is enabled. This header is not sent if Keep-Alive connection is enabled (this is the default). Keep-Alive must be enabled for NTLM and Digest HTTP authentication.
...