Systemic IBM RPA Vault authentication method

Learn how IBM RPA Vault authenticates its requests for credentials when you use the systemic method.

Architecture of getting systemic credentials process

The following sequence diagram shows the process to request and decrypts a credential.

Systemic IBM RPA Vault authentication method

  1. The Bot Runtime, the sandbox that runs scripts, starts the request to the credential generating a pair of the public and private keys. The Get Vault Item (getVaultItem) command triggers this event.

  2. The Bot Agent receives the request. This request contains the credential name encrypted with the public key. The Bot Runtime might initialize sessions when running bots, and the Bot Agent is initialized for each of these sessions. This service has LocalSystem permissions, and it is the only one that can decrypt the credentials.

  3. The Bot Agent generates a new pair of private and public keys.

  4. The Bot Agent requests the credentials' data to the IBM RPA's API. The IBM RPA's API stores this data in a database where the credentials are encrypted. The communication is encrypted with HTTPS over TLS 1.2.

  5. The IBM RPA's API returns the encrypted credentials' data. As data, it returns the setting from where the private key is stored.

  6. The Bot Agent decrypts the user's public and private key settings to get the private key location. The private key is used to decrypt the credentials requested by the Bot Runtime. This key can be accessed in the following ways:

    • File system
      You can use the file system only for XML, PEM, and PKCS key types. XML doesn't accept passwords, while PEM and PKCS files do. Store these files in a secure environment that only authorized users can access. The Bot Agent can always access these files.

    • Certificate
      Certificates can be stored with passwords. It is stored on the Certificate Store that is managed by Windows®.

    Afterward, it gets the private key and the credential is decrypted. The computer that runs the bot must have the private key in the path that the API returned.

  7. The credentials are encrypted one more time before being sent back to the Bot Runtime.

  8. The Bot Runtime uses the private key to decrypt the credentials. The decrypted credentials are placed in a secure memory location. See Data Encryption for details.

Note:The keys generated by IBM RPA use an RSA algorithm.

Support for passphrase on private keys

Protect your private keys with a passphrase. It is available only for file types such as PKCS#12, PEM, and certificates. You need to provide the passphrase in the private key file and on the Tenant credentials configurations page. For more information, see Tenant configuration credentials.

Restrict runtime access to the private key

In versions prior to 21.0.2, the Bot Runtime accesses the private key to decrypt vault credentials.
In newer versions, only the Bot Agent, which runs under a privileged Windows™ account, can access the private key to decrypt vault credentials. With this, you can restrict access to the private key by using the default Windows™ policies, enabling only privileged users such as Local System to access these credentials.
For more architectural details, see Architecture of getting systemic credentials process.

One-Time-Public-Key (OTPB) protection for credential request

In versions prior versions to 21.0.2, all credentials were encrypted over-the-wire, which then is only decrypted by the Bot Agent.
Newer versions introduce a new technique by using a One-Time-Public-Key (OTPB) for each credential request. In this way, only the instance of the Bot Agent that requested the credential is able to decrypt it, as it’s the only instance that holds the One-Time-Private-Key.