Security Guide
Release 13.1.0.1
E74489-03
June 2017
This document provides an overview of the security features in the Oracle Application Testing Suite.
If you have any questions or problems, please contact our support group at http://www.oracle.com/support/index.html.
This document has the following sections:
This section has the following topics:
The Oracle Application Testing Suite application installation includes the following security features:
Installation procedure password. The installation procedure includes setting a master Administrator password that is required for accessing the server-based applications (Administrator, Oracle Test Manager, and Oracle Load Testing).
Administrator access rights required for installation. The user/administrator installing the Oracle Application Testing Suite must have local administrator access rights and have the ability to run the 'elevated' installer.
User access right required for OpenScript (i.e. Oracle Functional Test, or OFT). Users working with OpenScript must have local administrative user access rights.
Oracle WebLogic server is installed as part of the Oracle Application Testing Suite to use with OATS server-based applications (Administrator, Oracle Test Manager, and Oracle Load Testing).
The Oracle Application Testing Suite installation includes setting a master Administrator password that is required for accessing the server-based applications (Administrator, Oracle Test Manager, and Oracle Load Testing).
During the installation for Oracle Application Testing Suite you will be asked to provide a master password. Remember this password. The master password specified during installation is used to set all of the following user passwords:
Oracle Test Manager users "default" and "administrator".
Oracle Load Testing users "default" and "administrator".
User "JMSAdmin" used for Oracle Load Testing agent to controller authentication.
User "oats" for Weblogic Server - this is a Weblogic superuser.
User "oats-agent" in Weblogic Server for JMS communication between agent and controller - this is not a Weblogic superuser.
Database users "oats", "olt", "otm".
Installation user/administrator must have local administrator access rights and have the ability to run the 'elevated' installer using right-click and select Run as administrator from the popup menu.
Users working with OpenScript must have local administrative user access rights. User working with OpenScript must have full access to change browser settings and to install add-ons to the browser (BHO/plug-ins).
When testing Oracle FORMS, users must have access right to start OpenScript as 'elevated' using right-click and select Run as administrator from the popup menu.
Oracle WebLogic server 12.1.3. is installed as part of the Oracle Application Testing Suite for use with OATS server-based applications (Administrator, Oracle Test Manager, and Oracle Load Testing). Refer to the Oracle WebLogic Server documentation for security information.
This section has the following topics:
The Oracle Application Testing Suite Administrator application includes the following security features:
Password-based Administrator log in.
Separate user databases for Oracle Test Manager and Oracle Load Testing users.
Ability to optionally enable authentication for Oracle Load Testing. When Oracle Load Testing login is enabled, users must login to access Oracle Load Testing.
Ability to specify users, passwords, and privileges for Oracle Load Testing. The Administrator allows you to create user accounts, assign them user names and passwords, and assign the type of access that they have in Oracle Load Testing, none, full control, or view only.
Ability to specify users, passwords, and role-based privileges for Oracle Test Manager. The Administrator allows you to create user accounts and assign users roles in specific projects. Roles determine the permissions the user has in each project.
Ability to configure LDAP-based login for Oracle Test Manager users. You can implement Lightweight Directory Access Protocol (LDAP) server authentication to allow Oracle Test Manager users authentication against the LDAP server providing users a single sign-on solution.
Ability to configure role-based field security settings to specify which roles have read/write permissions and which roles have read-only permissions for specific fields.
Specific users can be granted Administrator access to Oracle Application Testing Suite applications. This restricts access to the Administrator features to specific Administrator users who can set up user accounts and grant user privileges.
The initial Administrator password is specified during the Oracle Application Testing Suite installation.
Separate user databases allow OATS Administrators to limit access to either Oracle Load Testing or Oracle Test Manager to specific users.
When you log into the Oracle Application Testing suite Administrator, you select the database to access using the login screen.
The Oracle Application Testing Suite Administrator provides the ability to optionally enable authentication for Oracle Load Testing. When Oracle Load Testing login is enabled, users must login to access Oracle Load Testing. The Oracle Load Testing authentication is enabled by default.
Log into the Oracle Application Testing Suite Administrator and select the OLT Database. When you add or edit a user profile, you can specify the type of access that is granted to the user.
Oracle Load Testing users can be granted the following type of access:
None - the user cannot access Oracle Load Testing.
Full Control - the user has full control in Oracle Load Testing.
View Only - the user cannot run tests but can view reports.
The Oracle Application Testing Suite Administrator specifies the user authentication for Oracle Test Manager.
User authentication for Oracle Test Manager can be Oracle Test Manager database-based or configured to use Lightweight Directory Access Protocol (LDAP) server authentication. Select Setup LDAP Config from the Tools menu to specify the LDAP server configuration. LDAP authentication can be specified as follows:
User+Password
SSL+User+Password
The Oracle Application Testing Suite Administrator specifies the role-based privileges for Oracle Test Manager. The Roles tab lists the defined roles and the permissions provided to each role.
The default roles are as follows:
Developer
Full Access
Planner
QA Engineer
Tester
Viewer
Additional roles can be defined and have the read, write, delete, execute, and set/override results permissions specified for that role. The Roles tab shows the permissions specified for the selected role in the Permissions for <role> section.
Permissions for <role> - displays the read, write, delete, execute, and set/override results permissions for this role for projects, test plans, requirements, tests, issues and reports.
Project - displays the read, write, and delete permissions for projects for users assigned to this role.
Test Plan - displays the read, write, and delete permissions for test plans for users assigned to this role.
Requirement- displays the read, write, and delete permissions for requirements for users assigned to this role.
Test - displays the read, write, delete, and execute permissions for tests for users assigned to this role.
Issue - displays the read, write, and delete permissions for issues for users assigned to this role.
Public Reports - displays the read, write, and delete permissions for public reports assigned to this role.
My Reports - displays the read, write, and delete permissions for reports assigned to this role.
The default roles and permissions are as follows:
Permissions for Developer
Read: Project, Requirement, Test, Issue, Public Reports, My Reports
Write: Issue, Public Reports, My Reports
Delete: Public Reports, My Reports
Execute: <none>
Set/Override results: <none>
Permissions for Full Access
Read: Project, Test Plan, Requirement, Test, Issue, Public Reports, My Reports
Write: Project, Test Plan, Requirement, Test, Issue, Public Reports, My Reports
Delete: Project, Test Plan, Requirement, Test, Issue, Public Reports, My Reports
Execute: Test
Set/Override results: Test
Permissions for Planner
Read: Project, Test Plan, Requirement, Test, Issue, Public Reports, My Reports
Write: Project, Test Plan, Requirement, Test, Issue, Public Reports, My Reports
Delete: Test Plan
Execute: <none>
Set/Override results: <none>
Permissions for QA Engineer
Read: Project, Requirement, Test, Issue, Public Reports, My Reports
Write: Project, Requirement, Test, Issue, Public Reports, My Reports
Delete: Requirement, Test, Issue, Public Reports, My Reports
Execute: Test
Set/Override results: <none>
Permissions for Tester
Read: Project, Requirement, Test, Issue, Public Reports, My Reports
Write: Issue
Delete: <none>
Execute: Test
Set/Override results: <none>
Permissions for Viewer
Read: Project, Requirement, Test, Issue, Public Reports, My Reports
Write: <none>
Delete: <none>
Execute: <none>
Set/Override results: <none>
The default roles and permissions are customizable.
The Oracle Application Testing Suite Administrator defines the testing projects available to users. Oracle Test Manager users can be assigned to specific projects to restrict project access to a defined set o f users and roles.
To specify the user access for specific projects:
Start the Oracle Application Testing Suite Administrator
Select the Oracle Test Manger database and login with administrator credentials.
Select the Projects tab.
Select the project in the projects section.
Select one or more users in the Assignments for <project name> section. Hold the Ctrl key to select more than one user.
Click Assign.
Selec the rolesto assign to each user in the project.
Click OK.
The Oracle Application Testing Suite Administrator defines the fields that are used in Oracle Test Manager to describe issues, requirements, and tests. There are two types of fields that apply separately to requirements, tests, issues, and test runs:
Default fields - these are fields that come with the product such as Type, Priority, and Status for requirements. You cannot add or delete default fields. You can change whether they are required or enabled, and you can add, delete, or rename their associated options.
Custom fields - these are fields that you add that are specific to your product. For each custom field, you define its properties, then add options where appropriate.
Role-based field security settings specify which roles have read/write permissions and which roles have read-only permissions for specific fields. When you add or edit fields or field options, a Permissions link in the dialog box provide access to the Permissions settings for the selected field or field option.
This section has the following topics:
The Oracle OpenScript application includes the following security features:
SSL Version preferences. The Oracle OpenScript HTTP Preferences provides an option for selecting the Secure Socket Layer version to use for the proxy server.
HTTP Script Authentication during recording. Scripts can support Basic, NTLM v1, and Digest authentication during script recording.
User Configurable Data Encryption (Obfuscate/Encrypt script data) in the General Preferences.
Data Encryption (Obfuscate/Encrypt script data) for specific scripts from the Tools menu.
Encryption Service error recovery. The Oracle OpenScript Error Recovery options specify the error recovery action when the password encryption service was not initialized or if Encrypting/Decrypting failed.
Error recovery constants for the encryption service available to be used in Script programming code.
Built-in encoding and encryption script functions. The Oracle OpenScript built-in script functions include encode/decode, encrypt/decrypt, and obfuscate/deobfuscate functions.
The Oracle OpenScript built-in script functions for encode/decode, encrypt/decrypt, and obfuscate/deobfuscate functions can be used in the Function/Text Substitution Rules used for script correlation.
OpenScript API security features. The OpenScript API supports data encryption and decryption methods in the OpenScript Application Programming Interface.
Shared Data Service access credentials. The Shared Data Service module include preferences for setting the global shared data access credentials.
Security extensions and attachments to Web Services scripts. Security extensions for username and password (either Password Text or Password Digest) can be added the Web Services scripts created using the Web Service module.
Encryption properties supported with Agent command line settings.
The Oracle OpenScript HTTP Preferences provides an option for selecting the Secure Socket Layer version to use for the proxy server. When recording a secure site in the browser, the user only sees the Proxy Recorder's certificate not the secure web site's certificate. The Browser, Proxy Recorder, and Secure Server each have their own private and public keys which are used to encrypt/decrypt data.
To set the SSL version recording preferences for the HTTP module:
Start OpenScript.
Open or create a new HTTP script.
Select OpenScript Preferences from the View menu.
If necessary, expand the OpenScript node in the left pane.
If necessary, expand the Record node in the left pane.
Select HTTP.
If necessary, select the General tab.
Select the Secure Protocol:
SSL: Use Secure Socket Layer protocol with the proxy server. OpenScript supports SSLv1.0, SSLv2.0, SSLv3.0 and TLSv1.0.
TLSv1.2: Use Secure Socket Layer Transport Layer Security version 1.2.
Click Apply or OK when finished.
To set the SSL version playback preferences for the HTTP module:
Start OpenScript.
Open or create a new HTTP script.
Select OpenScript Preferences from the View menu.
If necessary, expand the OpenScript node in the left pane.
If necessary, expand the Playback node in the left pane.
Select HTTP.
If necessary, expand the Security section.
Select the Secure Protocol:
SSL: Use Secure Socket Layer protocol with the proxy server. OpenScript supports SSLv1.0, SSLv2.0, SSLv3.0 and TLSv1.0.
TLSv1.2: Use Secure Socket Layer Transport Layer Security version 1.2.
Click Apply or OK when finished.
For web sites that require NTLM v1 Authentication, the browser opens a login dialog and waits for user input of the username and password. Once the username and password are entered, the browser sends the last request again with the Authentication information in http request header. However, OpenScript uses a proxy to record the http request and response and cannot get the NTLM username and password information that the user inputs into the browser because the password is not included in the content transfer on the network. For NTLM v1 Authentication, OpenScript opens a second login dialog for entering the username and password again during recording. OpenScript records an Authentication step automatically with username and encrypted password as the step before the navigate step.
To add authentication to an HTTP script manually:
Record an HTTP script.
Select the Run node.
Select the Script menu and then select Other from the Add sub menu.
Expand the HTTP folder.
Select the Authentication node and click OK.
Enter the URL to access for authentication.
Enter a username.
Enter the password for the user. Passwords are encrypted using the Base-64 Crypt algorithm.
Click OK to add the Authentication node to the script tree.
In the Java Code view, the Authentication consists of the code executed in the http.addAuthentication procedure:
http.addAuthentication("http://testserver2", "username", decrypt("KRT|J|xJPDP"));
The General preferences set the default encryption setting for all scripts.
To set the default encryption setting:
Start OpenScript.
Select OpenScript Preferences from the View menu.
If necessary, expand the OpenScript node in the left pane.
If necessary, expand the General node in the left pane.
Select Encryption and set the default encryption type.
Click Apply or OK when finished.
These preferences set the default encryption preferences. The resulting dialog presents the following fields:
Do not encrypt script data: When selected, passwords are stored and displayed as plain text in the script.
Obfuscate script data: When selected, passwords are obfuscated before storing and displaying in the script. Obfuscated passwords are hidden but not securely encrypted.
Encrypt script data: When selected, passwords are encrypted in the script. You will be asked to specify a password for the script if you create new scripts containing sensitive data or when opening encrypted scripts for playback.
Caution:
HTTP scripts do not automatically obfuscate/encrypt sensitive script passwords.Use the Encryption options on the Tools menu to set the encryption password for specific scripts.
The Playback preferences set the default encryption setting for all scripts
To set the default encryption error recovery settings:
Start OpenScript.
Select OpenScript Preferences from the View menu.
If necessary, expand the OpenScript node in the left pane.
If necessary, expand the Playback node in the left pane.
Select Error Recovery.
If necessary, expand the General node in the right pane.
Set the encryption error recovery actions, as follows:
Encryption Service Not Initialized - specifies the error recovery action when the password encryption service was not initialized.
Encrypting/Decrypting Failed - specifies the error recovery action if an error occurs encrypting or decrypting a script.
The default action is "Fail" script playback.
Click Apply or OK when finished.
Error recovery constants for the encryption service available to be used in Script programming code.
To add error recovery to a script:
Open or create a script project.
Select the script node where you want to add the log message.
Select the Script menu and then select Other from the Add sub menu.
Expand the General node and select Error Recovery Action.
Exception: Select the type of exception error. The list will vary depending upon the script type. The exception for the encryption services is "General - Encryption Service Not Initialized".
Action: Select the error recovery action: Fail, Warn, Ignore, Report, or Pause as follows:
Fail: Report the error as failure and stop script execution.
Warn: Report the error as a warning and continue script execution.
Ignore: Ignore the error and continue script execution.
ReportErrorAndContinue: Report the error to the results log and continue script execution.
Pause: Pause playback and wait for user's decision to continue or abort script execution.
Click OK. The SetErrorRecovery node is added to the script tree.
In the Java Code view, the setErrorRecovery(scriptType.constant, ErrorRecoveryAction.action); method will be added to the script code:
setErrorRecovery(BasicErrorRecovery.ERR_ENCRYPTION_SERVICE_NOT_INITIALIZED, ErrorRecoveryAction.Fail);
Built-in script functions are used as variables to access or manipulate various type of data or parameters within OpenScript scripts. The built-in functions are indicated by the @ sign and include the following types of functions:
Encryption and encoding functions
File functions
Information functions
Random functions
Time functions
Built-in function are added to scripts using the Variable Substitution option available for the various script actions and parameters. Dialog boxes for script actions with parameter values include a Substitute Variable icon that opens the list of script variable and built-in @ functions available to use a script parameters. Built-in @ functions can also be added directly in the code view.
To access the built-in @ function using the Tree view:
Start OpenScript.
Open or create a new script.
Select the script node where you want to add an action or substitute a parameter with a variable or built-in function.
Double-click the node if editing an existing node to open the parameters.
Click the Substitute Variable icon.
Expand the @Functions node.
Select the function to use and click Finish.
Click OK.
To add the built-in @ function using the Code view, add the function name and parameters to the code using the @ sign and double-curly brace transform syntax {{}}, similar to the following example:
{{@today(MM/dd/yyyy)}}
Use the eval() function to transform strings of data, substituting the values of variables where applicable. For example:
info(eval("{{@today(MM/dd/yyyy)}}"));
This section describes the built-in encoding and encryption @ functions and the required parameters. See the Oracle Functional Testing OpenScript User's Guide and the Oracle Functional Testing OpenScript Programmer's Reference for additional information about script functions.
@encode({{myVariable}}) - encode the data in myVariable converting binary content to hexadecimal string. It converts \ to \\ and any non-printable chars to \##. Returns null when input bytes are null. The allowable printable characters are:
9 (tab)
10 (line feed)
13 (carriage return)
32 through 126
@decode({{myVariable}}) - decode the encoded data in myVariable converting hexadecimal string to binary content. It returns the decoded byte array for the given hexadecimal string. Returns null when input bytes are null.
The following code examples show the @encode and @decode functions both with and without the eval() function:
getVariables().set("varEncodeDecode", "abc\\%2Fxyz\\t\\r\\n \\0D\\0A");
info("no eval encode = {{@encode({{varEncodeDecode}})}}");
//-or-
info(eval("eval encode = {{@encode({{varEncodeDecode}})}}"));
getVariables().set("varEncode", "{{@encode({{varEncodeDecode}})}}");
info("no eval decode = {{@decode({{varEncode}})}}");
//-or-
info(eval("eval decode = {{@decode({{varEncode}})}}"));
@encrypt({{myVariable}}) - encrypts the data in myVariable to protect sensitive data within scripts and makes the data non-human readable.
@decrypt({{myVariable}}) - decrypts the encrypted data in myVariable and makes the data human readable.
The following code examples show the @encrypt and @decrypt functions:
getVariables().set("myVariable", "test123");
info("variable text is {{myVariable}}");
getVariables().set("encrypt", "{{@encrypt({{myVariable}})}}");
info("encrypted = {{encrypt}}");
//-or-
info("encrypted = {{@encrypt({{myVariable}})}}");
getVariables().set("decrypt", "{{@decrypt({{encrypt}})}}");
info("decrypted = {{decrypt}}");
//-or-
info("decrypted = {{@decrypt({{encrypt}})}}");
@obfuscate({{myVariable}}) - obfuscates the data in myVariable to protect sensitive data within scripts and makes the data non-human readable.
@deobfuscate({{myVariable}}) - deobfuscates the obfuscated data in myVariable and makes the data human readable.
The following code examples show the @obfuscate and @deobfuscate functions:
getVariables().set("myVariable", "test123");
getVariables().set("obfuscate", "{{@obfuscate({{myVariable}})}}");
info("obfuscated = {{obfuscate}}");
//-or-
info("obfuscated = {{@obfuscate({{myVariable}})}}");
getVariables().set("deobfuscate", "{{@deobfuscate({{obfuscate}})}}");
info("deobfuscated = {{deobfuscate}}");
//-or-
info("deobfuscated = {{@deobfuscate({{obfuscate}})}}");
@urlEncode({{myVariable}}) URL encode the value specified in myVariable. For example, the string, 'the file "abc" is in \root\etc', would be encoded as: the+file+%22abc%22+is+in+%5Croot%5Cetc. This function is only available for Load Testing scripts.
The following code example shows the @urlEncode function:
getVariables().set("myVariable", "the file \"abc\" is in \\root\\etc");
getVariables().set("urlEncode", "{{@urlEncode({{myVariable}})}}");
info("urlEncode = {{urlEncode}}");
//-or-
info("urlEncode = {{@urlEncode({{myVariable}})}}");
The above example returns the String the+file+%22abc%22+is+in+%5Croot%5Cetc.
@xmlEncode({{myVariable}}) XML encode the value specified in myVariable. For example, the string, 'the file "abc" is in \root\etc', would be encoded as: the file "abc" is in \root\etc. This function is only available for Load Testing scripts.
The following code example shows the @xmlEncode function:
getVariables().set("myVariable", "the file \"abc\" is in \\root\\etc");
getVariables().set("xmlEncode", "{{@xmlEncode({{myVariable}})}}");
info("xmlDecode = {{xmlEncode}}");
//-or-
info("xmlDecode = {{@xmlEncode({{myVariable}})}}");
The above example returns the String the file "abc" is in \root\etc.
@@xmlDecode({{myVariable}}) decodes the XML encoded value specified in myVariable. This function is only available for Load Testing scripts.
The following code example shows the @xmlDecode function:
getVariables().set("xmlDecode", "{{@xmlDecode({{xmlEncode}})}}");
info("xmlDecode = {{xmlDecode}}");
//-or-
info("xmlDecode = {{@xmlDecode({{xmlEncode}})}}");
The above example returns the String the file "abc" is in \root\etc.
The Oracle OpenScript built-in script functions for encode/decode, encrypt/decrypt, and obfuscate/deobfuscate functions can be used in the Function/Text Substitution Rules used for script correlation.
To add a new Function/Text Substitution correlation rule:
Start OpenScript.
Open or create an HTTP script.
Select OpenScript Preferences from the View menu.
If necessary, expand the OpenScript node in the left pane.
If necessary, expand the Correlation node in the left pane.
Select HTTP in the left pane.
If necessary, expand the Web Default correlation library.
Click Add Rule.
Select Function/Text Substitution as the type.
Enter a name for the new rule.
Select the Function/Text in the Source tab.
Click the Target tab.
Specify a Regular Expression to indicate the location in the HTML source to replace with the Function/Text selected in the source tab. Use (( )) to indicate the part to replace. For example: \?username=((.+?))&password=.+? . See the Oracle Functional Testing OpenScript User's Guide for additional information about correlation rules.
Click OK when finished.
The OpenScript API supports data encryption and decryption methods in the OpenScript Application Programming Interface.
To add encrypt and decrypt data in a script:
Open or create a script project.
Select the Java Code view and add the encrypt() and decrypt()methods with a String specifying the text to encrypt or decrypt, as follows:
String encrypted = encrypt("encrypt this string");
info(encrypted);
String decrypted = decrypt(encrypted);
info(decrypted);
To set Shared Data preferences:
Start OpenScript.
Open or create a new script.
Select Script Properties from the Script menu.
Select Modules in the left pane.
Select the Shared Data module and click OK.
Select OpenScript Preferences from the View menu.
Expand the OpenScript node and the Playback category.
Select Shared Data.
Set the Shared Data Preferences as follows:
OATS Credentials: Specifies the authentication credentials to use to establish the communication between the shared queue and the Virtual User.
Enable global shared data access credentials: When selected, when selected, the shard data access credentials are enabled. Specify the Address, User Name, and Password.
Address: Specifies the address of the Oracle Load Testing for Web Application server to use for the shared data service.
User name: Specifies the user name to use for authentication. The default name is oats unless changed in the Oracle Application Testing Suite configuration.
Password: Specifies the password to use for authentication. This should be the same password specified in the Encryption setting of the General preferences if the Encrypt script data setting is selected.
Actions on Shared Data: Specifies actions on shared data.
Timeout: Specifies the maximum number of seconds to wait for actions on shared data to occur before timing out.
Click OK.
The Web Services Module is an application module that supports testing of Web Services. Security extensions for username and password (either Password Text or Password Digest) can be added the Web Services scripts created using the Web Service module.
You can add security extensions to Web Services scripts.
To add security extensions to a Web Services script:
Create a Web Services script.
Expand the Run node.
Select the Web Services method node where you want to add the security and attachments.
Select the Script menu and then select Other from the Add menu.
Expand the HTTP node.
Select Web Services Security Attachments from the Web Services group and click OK.
If necessary click the WS-Security tab.
Enter a URL. If you selected a Web Services navigation node in the script tree, the URL will be automatically entered.
Select User Username Token
Enter the user name and password.
Username: specifies the user name to use for the Username Token in the XML request.
Password: specifies the password to use for the Username Token in the XML request.
Confirm Password: confirms the password.
Select the password type: Password Text or Password Digest.
Password Text: when selected, the password in the XML request is included as plain text. The URI attribute for the <wsse:Password> element is set to #PasswordText.
Password Digest: when selected, the password is encrypted. The URI attribute for the <wsse:Password> element is set to #PasswordDigest.
Select or clear the Add Created Header, Add Nonce and Add Timestamp options.
Add Created Header: when selected, a creation timestamp is included in the Username Token of the XML request for use in setting the server cache limit of used nonces.
Add Nonce: when selected, a cryptographically random nonce value is included in the Username Token of the XML request to provide a countermeasure for replay attacks.
Add Timestamp: when selected, a timestamp value is included in the Web Services security element of the XML request. The timestamp includes both Created and Expires elements. Specify the Valid For number of seconds.
Click OK to add the Security Attachment node to the script tree.
In the Java Code view, the Security Attachment consists of the code executed in the ws.addSecurityAttachments method (line breaks and spacing added for clarity), as follows:
ws.addSecurityAttachments("url",
ws.security("userName", deobfuscate("password"),addCreatedHeader,
addNonce, addTimestamp, validFor), null);
If you add security and file attachments together, the ws.addSecurityAttachments method includes both the ws.security and ws.attachments methods (line breaks and spacing added for clarity), as follows:
ws.addSecurityAttachments("url",
ws.security("userName", deobfuscate("password"),true, true, true, 10),
ws.attachments(AttachmentMechanism.transferType,
ws.attachment("filename","attachmentPart")));
You can add file attachments to Web Services scripts.
To add file attachments to a Web Services script:
Create a Web Services script.
Expand the Run node.
Select the Web Services method node where you want to add the security and attachments.
Select the Script menu and then select Other from the Add menu.
Select Web Services Security Attachments from the Web Services group.
If necessary click the WS-Security tab.
Enter a URL. If you selected a Web Services navigation node in the script tree, the URL will be automatically entered.
Click the Attachments tab.
Select the Transfer Type.
DEFAULT - uses the default transfer type specified by the Content-Type header.
SWA - Security SOAP Messages with Attachments
MTOM - SOAP Message Transmission Optimization Mechanism
DIME - Direct Internet Message Encapsulation
Click Add.
Enter the path and file name or click Browse to select a file.
If the Web Services method includes any Attachment Part object identifiers, select an Attachment Part from the list. If the Web Services method does not include any Attachment Part object identifiers, the list will be empty.
Click OK to add the Security Attachment node to the script tree.
In the Java Code view, the Security Attachment consists of the code executed in the ws.addSecurityAttachments method (line breaks and spacing added for clarity) as follows:
ws.addSecurityAttachments("url", null,
ws.attachments(AttachmentMechanism.transferType,
ws.attachment("filename","attachmentPart")));
If you add security and file attachments together, the ws.addSecurityAttachments method includes both the ws.security and ws.attachments methods (line breaks and spacing added for clarity), as follows:
ws.addSecurityAttachments("url",
ws.security("userName", deobfuscate("password"),true, true, true, 10),
ws.attachments(AttachmentMechanism.transferType,
ws.attachment("filename","attachmentPart")));
The following example Web Services script method shows the ws.addSecurityAttachments method with a ws.post postdata method used to upload a file. The ws.post method specifies the SOAP Envelope postdata, Content-Type, and SOAP Action.
ws.method("upload");
{
ws.addSecurityAttachments("http://myurl.com:8080/services/MTOMService",
ws.security("username", deobfuscate("5blNah5kX/XuZnepYwInFw=="),
true, true, true, 20),
ws.attachments(AttachmentMechanism.MTOM,
ws.attachment("C:\\OracleATS\\OFT\\test.txt", "<upload>776598931581")));
ws.post(15, "http://myurl.com:8080/services/MTOMService",
"<soapenv:Envelope
xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\"
xmlns:ser=\"http://service.interop.mtom.sample\">\r\n
<soapenv:Header/>\r\n
<soapenv:Body>\r\n
<ser:upload>\r\n
<!--Optional:-->\r\n
<ser:fileName>string</ser:fileName>\r\n
<!--Optional:-->\r\n
<ser:contents>cid:776598931581</ser:contents>\r\n
</ser:upload>\r\n
</soapenv:Body>\r\n
</soapenv:Envelope>",
http.headers(http.header("Content-Type", "text/xml;charset=UTF-8",
Header.HeaderAction.Modify),
http.header("SOAPAction", "\"urn:upload\"",
Header.HeaderAction.Modify)),
true, null, null);
}
ws.endMethod();
This section lists the command line options related to encryption settings. See the Oracle Functional Testing OpenScript User's Guide for additional information about command line options.
The following table lists the General Encryption command line settings.
| Setting | Description |
|---|---|
-ENCRYPTION_PROPERTIES_FILE path\encryption.properties |
Specify the full path and file name to use for encrypted password authentication. The file name is C:\Documents and Settings\username\osworkspace\.metadata\.plugins\oracle.oats.scripting.utilities\encryption.properties. |
The following table lists the Encryption command line settings:
| Setting | Description |
|---|---|
-encrypt.password password
|
Specify script passwords from the command line for encrypted scripts. Passwords specified as a parameter are different from playback settings, which are not kept or accessible by the getSettings() API, nor are they printable in scripts.
Example usage: -encrypt.password xxx -a.encrypt.password yyy -b@a.encrypt.password zzz In this example, a "master" script has a child script "a", script 'a' has a grand-child script "b". ("a", "b" are the aliases of the child scripts). |
-encrypt.password.global |
Specify a global password that can be applied to any encrypted scripts. The -encrypt.password and -alias.encrypt.password takes precedence over -encrypt.password.global. The -encrypt.password.global password is applied only when the password of a script is not found in other arguments or is incorrect.
Example usage: -encrypt.password.global mypass |
-encrypt.password.prompt |
Enables interactively entering password for encrypted scripts one-by-one using the console. Useful only when the CLI is started from the console.
If specified, CLI will interactively ask to input the correct script password in the console (if the console exists). The password is not shown in the console. If you do not want to input the password of a script, press ENTER to skip to next encrypted script. Example usage: -encrypt.password.prompt |
-streamProperties |
Enables a way of passing arguments to the CLI by reading from STDIN. If specified, the CLI reads arguments from STDIN until \endStream plus a line separator is entered. The line separator is any one of line feed (\n), carriage return (\r), or carriage return followed immediately by linefeed. The charset used to decode the bytes from STDIN can be specified using the -streamCharset argument. The default charset is UTF-8.
If the CLI is started from a console, CLI will wait for arguments followed by The arguments in Example usage: -streamProperties -streamCharset UTF-16LE [STDIN] -settingIds settingValues [...] \endStream\r\n |
-streamCharset charset |
Specify a charset that will be used to decode the byte array read from STDIN to a string. Used only when -streamProperties is specified. If an illegal charset is specified, -streamCharset shows a warning message and uses UTF-8 instead.
Example usage: -streamProperties -streamCharset UTF-16LE |
This section has the following topics:
The Oracle Load Testing application includes the following security features:
Password-based login. The login requires username and password configured using the Oracle application Testing Suite Administrator application.
Agent Authentication Manager. The Oracle Load Testing Agent Authentication Manager lets you define authentication profiles for multiple load testing agent machines.
SSL Version preferences. The Oracle Load Testing Java Client Preferences provides an option for selecting the Secure Socket Layer version to use for the proxy server.
Encryption Service error recovery. The Oracle Load Testing OpenScript Error Recovery options specify the error recovery action when the password encryption service was not initialized of if Encrypting/Decrypting failed.
The Oracle Load Testing application user login credentials are configured using the Oracle Application Testing Suite Administrator. The Oracle Load Testing login feature is enabled as the default.
The Oracle Load Testing Agent Authentication Manager lets you define authentication profiles for multiple load testing agent machines.
To start the Oracle Load Testing Agent Authentication Manager:
Select Oracle Application Testing Suite from the Start menu.
Expand the Tools folder and select Oracle Load Testing Agent Authentication Manager.
Click New to create new Authentication Profile.
Enter the Hostname, port, username, and password. Click Help for additional information.
Click Save.
Repeat steps 3-5 for each agent machine.
The Oracle Load Testing Java Client Preferences provides an option for selecting the Secure Socket Layer version to use for the proxy server. When recording a secure site in the browser, the user only sees the Proxy Recorder's certificate not the secure web site's certificate. The Browser, Proxy Recorder, and Secure Server each have their own private and public keys which are used to encrypt/decrypt data.
To set the SSL version preferences as the default for all scenarios:
Start the Oracle Load Testing Application.
Log in if required.
Select Options from the Tools menu.
Select Scenario Defaults in the left pane.
Set the Secure Protocol setting in the Java Client Preferences section.
To set the SSL version preferences for a specific Virtual User profile (script):
Start the Oracle Load Testing Application.
Log in if required.
Click the Build Scenarios tab.
Add a script to the Configure parameters of the scenario list.
Click the Configure all parameters button.
Set the Secure Protocol setting in the Java Client Preferences section.
The Oracle Load Testing OpenScript Error Recovery options specify the error recovery action when the password encryption service was not initialized of if Encrypting/Decrypting failed.
To set the OpenScript Error Recovery options as the default for all scenarios:
Start the Oracle Load Testing Application.
Log in if required.
Select Options from the Tools menu.
Select Scenario Defaults in the left pane.
Set the Encryption Service not Initialized setting in the OpenScript Error Recovery - General section.
Set the Encrypting/Decrypting Failed setting in the OpenScript Error Recovery - General section.
To set the SSL version preferences for a specific Virtual User profile (script):
Start the Oracle Load Testing Application.
Log in if required.
Click the Build Scenarios tab.
Add a script to the Configure parameters of the scenario list.
Click the Configure all parameters button.
Set the Encryption Service not Initialized setting in the OpenScript Error Recovery - General section.
Set the Encrypting/Decrypting Failed setting in the OpenScript Error Recovery - General section.
This section has the following topics:
The Oracle Test Manager application includes the following security features:
Password-based login. The user login can be Oracle Application Testing Suite database-based or LDAP server based. The users and LDAP server configuration are specified in the Oracle Application Testing Suite Administrator application.
Support for running encrypted OpenScript scripts. OpenScript scripts can be used as test in the Oracle Test Manager application. Oracle Test Manager supports running password encrypted OpenScript scripts.
The user login can be Oracle Application Testing Suite database-based or LDAP server based. The users and LDAP server configuration are specified in the Oracle Application Testing Suite Administrator application.
The Oracle Application Testing Suite Administrator specifies the role-based privileges for Oracle Test Manager. The Roles tab lists the defined roles and the permissions provided to each role. See Oracle Test Manager Role-Based Privileges in the OATS Administrator Security Features section for additional information.
The Oracle Application Testing Suite Administrator defines the testing projects available to users. Oracle Test Manager Users can be assigned to specific projects to restrict project access to a defined set o f users and roles. See Oracle Test Manager Project-Based Access in the OATS Administrator Security Features section for additional information.
OpenScript scripts can be used as test in the Oracle Test Manager application. Oracle Test Manager supports running password encrypted OpenScript scripts.
To add an Oracle OpenScript test:
Start Oracle test Manager and login.
Select the Tests tab.
Click the Add button.
Enter a name for the test.
Select Oracle OpenScript in the Type field.
Click Find to display the Select Script dialog box.
Select the Repository and Workspace.
Select the Oracle OpenScript script that you want to add.
Enter command line settings and OpenScript password if required. See the Command line settings in the Oracle Functional Testing OpenScript User's Guide or OpenScript online help for the available settings.
Click OK.
Select the owner and priority and enter any descriptive information in the Functionality and Description fields.
Click Save.
The OpenScript test can be executed in the Test Execution tab. See the Oracle Test Manager User's Guide or online help for more information about executing tests in Oracle Test Manager.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Oracle Application Testing Suite Security Guide Release 13.1.0.1
E74489-03
Copyright © 1997, 2017, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.