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 Apply Encryption context menu item against the Test Project’s entry in the Navigator view allows the Test Project to be encrypted.
After selecting ‘Apply Encryption’, 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 Apply Encryption context menu item against Test Environments in the Test Settings view allows individual Test Environments to be encrypted.
After selecting ‘Apply Encryption’, 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 Encryption Password
Change Encryption Password allows the secrets to be re-encrypted with a new password. Change Encryption Password requires the existing password to be entered.
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.
Lock Encryption User Flow
To Lock Encryption
Considering the project or environment is already encrypted.
- Users will see a new context menu option to Lock Encryption.
- Users have the option to lock the Encryption using a separate password.
Unencrypt Locked Project
Once the Project is encrypted and locked, it can be shared with other users.
- When other users import the project, they must enter the password to access and use it, following a flow similar to our current process.
- The Unencrypt option will always be enabled for the users if the Project is Encrypted.
- When users attempt to unencrypt the project, they will be prompted to provide both Encryption and Lock passwords.
It can not be unencrypted if both passwords are not provided.
To Change Lock Password
- Choose Change lock Password on the context menu item:
- Only the users who have the Encryption password will be able to change the lock password.
Find more information on the Additional Security feature here.
- Provar Automation
- System Requirements
- Browser and Driver Recommendations
- Installing Provar Automation
- Updating Provar Automation
- Licensing Provar
- Granting Org Permissions to Provar Automation
- Optimizing Org and Connection Metadata Processing in Provar
- Using Provar Automation
- Understanding Provar’s Use of AI Service for Test Automation
- Provar Automation
- Creating a New Test Project
- Import Test Project from a File
- Import Test Project from a Remote Repository
- Import Test Project from Local Repository
- Commit a Local Test Project to Source Control
- API Testing
- Behavior-Driven Development
- Consolidating Multiple Test Execution Reports
- 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
- Japanese Language Support
- Override Auto-Retry for Test Step
- Customize Browser Driver Location
- Mapping and Executing the Lightning Article Editor in Provar
- Managing Test Steps
- Namespace Org Testing
- NitroX
- Provar Test Builder
- ProvarDX
- 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 Data Generation
- 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
- How to Use Provar Manager
- Provar Manager Setup
- Provar Manager Integrations
- Release Management
- Test Management
- Test Operations
- Provar Manager and Provar Automation
- Setting Up a Connection to Provar Manager
- Object Mapping Between Automation and Manager
- How to Upload Test Plans, Test Plan Folders, Test Plan Instances, and Test Cases
- Provar Manager Filters
- Uploading Callable Test Cases in Provar Manager
- Uploading Test Steps in Provar Manager
- How to Know if a File in Automation is Linked in Test Manager
- Test Execution Reporting
- Metadata Coverage with Manager
- Provar Grid
- DevOps
- Introduction to Provar 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
- 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
- Version Control
- Salesforce Testing
- Recommended Practices
- Salesforce Connection Best Practices
- Improve Your Metadata Performance
- Java 21 Upgrade
- Testing Best Practices
- Automation Planning
- Supported Testing Phases
- Provar Naming Standards
- Test Case Design
- Create records via API
- Avoid using static values
- Abort Unused Test Sessions/Runs
- Avoid Metadata performance issues
- Increase auto-retry waits for steps using a global variable
- Create different page objects for different pages
- The Best Ways to Change Callable Test Case Locations
- Working with the .testProject file and .secrets file
- Best practices for the .provarCaches folder
- Best practices for .pageObject files
- Troubleshooting
- How to Use Keytool Command for Importing Certificates
- Installing Provar After Upgrading to macOS Catalina
- Browsers
- Configurations and Permissions
- Connections
- DevOps
- Error Messages
- Provar Manager 3.0 Install Error Resolution
- Provar Manager Test Case Upload Resolution
- Administrator has Blocked Access to Client
- JavascriptException: Javascript Error
- macOS Big Sur Upgrade
- Resolving Failed to Create ChromeDriver Error
- Resolving Jenkins License Missing Error
- Resolving Metadata Timeout Errors
- Test Execution Fails – Firefox Not Installed
- Selenium 4 Upgrade
- Licensing, Installation and Firewalls
- Memory
- Test Builder and Test Cases
- Release Notes