This new feature in the Management Console provides a comprehensive approach to securely manage user authentication and other sensitive data for robot access, such as passwords and OAuth credentials. Also, the Vault integrates the CyberArk application to securely manage secrets outside of the Management Console.

Select Management Console > Repository > Vault to access the Vault.

• Highlights

• Configuration notes

• OAuth limitations

• Backward compatibility

• Backups and upgrades

• Restore backups

• Box added as OAuth provider

  
  

Highlights

The Vault provides security and centralized access management.

• Provides an integrated approach for both user (from Design Studio) and robot (from RoboServer) access for secrets and OAuth.

• Secrets interface supports both CyberArk and built-in store to work simultaneously.

• Encrypts data, which is included in Management Console backups.

• Supports token grant flows "Client credentials" and "Client credentials with certificate" for Microsoft Azure AD OAuth provider.

• Extends robot access to OAuth, not just secrets.

• Grants robot access based on a robot path that is visible in the user interface.

• Introduces the target system entity for better organization. Secrets and OAuth are accessed from within a target system.

• Supports REST API calls.

  
  

Configuration notes

In Configuration.xml, passwordStore is renamed to vaultConfig. To select between the built-in store and CyberArk, configure builtInStoreEnabled or cyberArkEnabled.

In Docker, the CONFIG_PASSWORDSTORE environment variable is renamed to CONFIG_VAULT_BUILTIN_STORE_ENABLED, the CONFIG_VAULT_CYBERARK_ENABLED environment variable is added.

OAuth limitations

Although you can use the OAuth tab in the Vault for both Robots and Basic Engine Robots, be aware that functionality is limited with Basic Engine Robots. For this reason, we recommend using OAuth with Robots.

• Basic Engine Robots have limited access to OAuth authentication.

• Legacy OAuth users, now OAuth clients, are supported for legacy Basic Engine Robots, but limited feature availability is provided.

  If you configure OAuth clients for Basic Engine Robots, select the Allow access for Basic Engine Robots option.

• Using Basic Engine Robots with OAuth service providers may be an issue, because only Robots are updated with the Show menu Update to latest option.

Backward compatibility

Legacy Basic Engine Robots are supported, but with limitations on new features. For Robots, previous releases did not provide support for OAuth and Lookup Password, so backward compatibility issues are not applicable for this release. A new Lookup Secret step provides functionality for Robots.

Backups and upgrades

When you create backups from releases 11.2.0 and newer to import data into this release, the following actions occur:

• Passwords are transformed into Secrets.

• CyberArk applications are migrated within the Vault (target system scope).

• CyberArk entries are treated as Secrets.

• OAuth apps and users are migrated to Vault OAuth.

• Target systems are auto-created from passwords and OAuth configurations.

• Robot hashes are converted to folder/names if available, otherwise they are removed.

  
  

Restore backups

Restore global and project backups, including passwords and OAuth data, from versions 11.2.0 and newer. Additionally, create backups on the current version and restore them on the same version.

All of the following data are migrated to the Vault:

• Passwords

• Password access entries

• CyberArk applications, records, and access entries

• OAuth applications

• OAuth users (renamed to OAuth clients)

When restoring from backups created on older versions to migrate data to the Vault, use the following information to understand how data are processed and migrated.

• Password store records:

  Corresponding target systems are automatically created in the Vault, based on the target system names specified for the password store records.

• Password store access records:

  The Management Console attempts to locate a robot by matching the checksum to the access token value. If a matching robot is found, the record is restored in the Vault with robot access folder and name fields auto-filled. If no match is found, the record is skipped and not restored. Skipped records are not tracked and not shown on the import result dialog, because they are considered invalid.

• OAuth applications:

  Mapped to existing target systems (matched by name: OAuth application name → target system name), or new target systems are created with OAuth support enabled. The "Token grant flow" setting for imported OAuth applications is automatically set to "Authorization code."

• OAuth users:

  Renamed to OAuth clients. They are referenced by target systems, and the "Allow access for Basic Engine Robots" option is enabled by default for all imported OAuth users.

• CyberArk applications:

  Mapped to existing target systems (matched by CyberArk application ID → target system name), or new target systems with CyberArk support enabled are created with the relevant fields configured.

• CyberArk store records:

  Corresponding target systems are automatically created if needed in the Vault, based on CyberArk store record names.

• CyberArk access records:

  The Management Console attempts to locate a robot by matching the checksum to the access token value. If a matching robot is found, the record is restored in the Vault with robot access folder and name fields auto-filled. If no match is found, the record is skipped and not restored. Skipped records are not tracked and not shown on the import result dialog, because they are considered invalid.

Box added as OAuth provider

Box now is a supported OAuth provider.