Secrets Management and Encryption
Automation honors the following principles with regard to passwords and secrets:
- Automation never exposes secrets in clear text in its UI or log files.
- Automation never transmits secrets in clear text over networks. This includes localhost connections.
- Automation does not rely on encryption keys that are built into the software (as these can be extracted by reverse compilation). These are always used in combination with a user-supplied secrets password that is used to salt the encryption.
- Secrets passwords are never stored by Automation but instead supplied by the user when required.
Secret types
Automation needs to store various secrets depending on the type of connection.
- Passwords are required for Salesforce, secured websites, Email and Database connections.
- Security Tokens and Client Secrets are required for certain types of Salesforce connection.
Browser providers
User account passwords are required to connect to third-party browser and mobile device hosting services such as Perfecto Mobile and SauceLabs.
Test environments
Test Environments allow you to specify alternate details for connections in Provar:
- The Test Environment is built into the tool.
- Additional Test Environments can be defined in the Test Settings view.
When a new connection is created, details are always supplied for the Test Environment. Alternate details can then be supplied for specific Test Environments, if desired.
For example, a SalesUser connection can be defined that:
- Connects using UatSalesUser / password1 for the Test Environment
- Connects using ProdSalesUser / password2 for the PROD Test Environment.
At runtime, Provar uses any specific connection details for the active Test Environment, failing which the connection details are used.
Storage
Provar stores all secrets in centralized .secrets files. These are stored at the root of the Test Project and can either be encrypted or in plain text.
The main .secrets file contains all secrets for the Test Environment and also the secrets for Test Environments that do not have their own encryption passwords.
Where Test Environments have been encrypted with their own passwords, their secrets are stored in a separate .secrets file.
External secrets management
Some customers would prefer not to store their .secrets files in their Source Control Repositories (e.g. GitHub).
To accommodate this, Provar’s ANT task allows secrets to be supplied via specially named environment variables. This allows the secrets to be managed outside of Provar, for example, by the password plugin for Jenkins.
Encryption
Provar allows secrets to be encrypted for entire Test Projects and also for individual Test Environments. This allows a PROD Test Environment, for example, to have its own secrets password that is only known to selected Provar users.
These approaches can be mixed and matched as follows:
- All secrets can be unencrypted. This is the default state for newly created Test Projects.
- The main .secrets file can be unencrypted and selected Test Environments encrypted with their own secrets passwords.
- The main .secrets file can be encrypted with the main secrets password and selected Test Environments encrypted with their own secrets passwords.
Encryption scheme
The encryption is done via the Jasypt open-source library using the user-supplied secrets password as the encryption salt:
- If the Test Project is encrypted then all secrets for the Test Environment are encrypted in the main .secrets file together with the secrets for any unencrypted Test Environments.
- If a Test Environment is encrypted then its secrets are encrypted in a separate .secrets file.
Secrets Password Requirements
Secrets passwords need to meet the following requirements.
- Must be at least 8 characters long
- Must contain an uppercase character
- Must contain a lowercase character
- Must contain a numeric character
- May contain special characters.
Enabling encryption
Newly created (and pre-existing) Test Projects are not encrypted by default:
The Encrypt Secrets context menu item against the Test Project’s entry in the Navigator view allows the Test Project to be encrypted.
After selecting ‘Encrypt Secrets’, a modal will appear asking for your password for encryption.
Once your password is confirmed, you should see a success message.
After successfully Encrypt .secrets file looks like this with encrypted format.
The Encrypt context menu item against Test Environments in the Test Settings view allows individual Test Environments to be encrypted.
After selecting ‘Encrypt Secrets’, a modal will appear asking for your password for encryption.
After entering a password, an entry will be created under test project file with the name of [Test Environment].secrets.
Encryption management
Once encrypted, the following context menus are available against the Test Project’s entry in the Navigator view and Test Environments in the Test Settings view.
Change Secrets Password
Change Secrets Password allows the secrets to be re-encrypted with a new password. Change Secrets Password requires the existing password to be entered.
Unencrypt Secrets
For Test Environments, Unencrypt Secrets moves the secrets into the main .secrets file. For the main .secrets file, it decrypts the secrets and stores the .secrets file as plain text.
Unencrypt Secrets requires the existing password to be entered.
The .Secrets file comes in original format (un-encrypted format) with all the values except if there is any test environment encrypted value present.
Reset Secrets Encryption
For Test Environments, Reset Secrets Encryption moves all the secrets into the main .secrets file and sets them to empty values. For Test Projects, it removes the encryption and sets all secrets to empty values.
The existing password is not required for Reset Secrets Encryption.
Secrets password entry in Automation
When a Test Project is opened in Automation:
- The user is prompted for the main secrets password if the Test Project is encrypted. Automation shuts down if no valid password is supplied after three attempts.
- If the pre-selected Test Environment (in Automation’s Settings Toolbar) is encrypted, the user is then prompted for the Test Environment’s secrets password. The Test Environment is automatically selected after three unsuccessful attempts.
Switching to encrypted test environments
The user is subsequently prompted for Test Environment passwords if:
- They select an encrypted Test Environment in the Settings Toolbar. The Test Environment is automatically selected after three unsuccessful attempts.
- They attempt to edit the alternate connection details for an encrypted Test Environment. The edit dialog does not open after three unsuccessful attempts.
- When they change the Test Environment on for an alternate connection to an encrypted one.
Invalid password attempts
Automation shuts down if the main secrets password is not supplied within 3 attempts.
- Automation automatically switches to the Test Environment if the password for an encrypted Test Environment is not supplied within three attempts.
- Automation does not allow alternate connection details to be modified if the password for an encrypted Test Environment is not supplied within three attempts.
- Automation prevents the Test Environment for alternate connection details being modified if the password for an encrypted Test Environment is not supplied within three attempts.
Note:
- Because Automation has no reliable way of storing invalid password attempt counters, these counters are reset when Test Projects are re-opened.
- The number of unsuccessful password attempts is tracked independently for each Test Environment until the Test Project is reopened.
- Secrets password entry under ANT
Main secrets password
The main secrets password can be supplied in two different ways when running under ANT:
- Via the secretsPassword property of the TestRunner task.
- Via the ProvarSecretsPassword environment variable.
Test environment secrets passwords
The secrets passwords for Test Environments can be supplied:
- Via the testEnvironmentSecretsPassword property of the TestRunner task.
- Via the ProvarSecretsPassword environment variable.
Invalid password processing
Automation validates the main and Test Environment passwords when the ANT task starts. If either password is invalid then:
- No tests are run
- An error outcome is returned.
- Provar Automation
- Installing Provar Automation
- Updating Provar Automation
- Using Provar Automation
- API Testing
- Behavior-Driven Development
- Creating and Importing Projects
- Creating Test Cases
- Custom Table Mapping
- Functions
- Debugging Tests
- Defining a Namespace Prefix on a Connection
- Defining Proxy Settings
- Environment Management
- Exporting Test Cases into a PDF
- Exporting Test Projects
- Override Auto-Retry for Test Step
- Managing Test Steps
- Namespace Org Testing
- NitroX
- Provar Desktop
- Provar Test Builder
- Refresh and Recompile
- Reintroduction of CLI License Check
- Reload Org Cache
- Reporting
- Running Tests
- Searching Provar with Find Usages
- Secrets Management and Encryption
- Setup and Teardown Test Cases
- Tags and Service Level Agreements (SLAs)
- Test Cycles
- Test Plans
- Testing Browser Options
- Tooltip Testing
- Using the Test Palette
- Using Custom APIs
- Callable Tests
- Data-Driven Testing
- Page Objects
- Block Locator Strategies
- Introduction to XPaths
- Creating an XPath
- JavaScript Locator Support
- Label Locator Strategies
- Maintaining Page Objects
- Mapping Non-Salesforce fields
- Page Object Operations
- ProvarX™
- Refresh and Reselect Field Locators in Test Builder
- Using Java Method Annotations for Custom Objects
- Applications Testing
- Provar Manager
- DevOps
- Introduction to Test Scheduling
- Apache Ant
- Configuration for Sending Emails via the Automation Command Line Interface
- Continuous Integration
- AutoRABIT Salesforce DevOps in Provar Test
- Azure DevOps
- Running a Provar CI Task in Azure DevOps Pipelines
- Configuring the Automation secrets password in Microsoft Azure Pipelines
- Parallel Execution in Microsoft Azure Pipelines using Multiple build.xml Files
- Parallel Execution in Microsoft Azure Pipelines using Targets
- Parallel execution in Microsoft Azure Pipelines using Test Plans
- Bitbucket Pipelines
- CircleCI
- Copado
- Docker
- Flosum
- Gearset DevOps CI/CD
- GitHub Actions
- Integrating GitHub Actions CI to Run Automation CI Task
- Remote Trigger in GitHub Actions
- Parameterization using Environment Variables in GitHub Actions
- Parallel Execution in GitHub Actions using Multiple build.xml Files
- Parallel Execution in GitHub Actions using Targets
- Parallel Execution in GitHub Actions using Test Plan
- Parallel Execution in GitHub Actions using Job Matrix
- GitLab Continuous Integration
- Travis CI
- Jenkins
- Execution Environment Security Configuration
- Provar Jenkins Plugin
- Parallel Execution
- Running Provar on Linux
- Reporting
- Salesforce DX
- Git
- Team Foundation Server
- Version Control
- Salesforce Testing
- Best Practices
- Troubleshooting
- Release Notes