Integrating CyberArk Password Vault with Automation 360

You can integrate Automation 360 to retrieve credentials from the CyberArk Password Vault. The credentials become resident within the CyberArk Password Vault where they are managed, rotated, and synchronized.

You integrate the Automation 360 Control Room by connecting it to the CyberArk Password Vault through the CyberArk Central Credential Provider (CCP) APIs. No additional licensing is required to integrate with the CyberArk Password Vault or use the CCP APIs.

Recommendation： We recommend that you control access to the CyberArk Password Vault through an IP address.

You can integrate Automation 360 with the CyberArk Password Vault using either of these deployments:

Cloud
On-Premises

The following diagram shows an Automation 360 Cloud deployment where the Control Room is hosted on AAI Cloud:

Cyberark Cloud deployment

For On-Premises deployments, you deploy the following:

Control Room as software within your customer environment.
Bot Agent within your customer environment where automations run and access customer applications.

重要： You can edit the external key vault connection settings through the user interface in Cloud deployments only. External key vault settings in On-Premises deployments are only configurable during installation or with the key vault utility post-installation.

CyberArk Password Vault integration requirements

Install CyberArk Central Credential Provider
Implement X.509 client certificate authentication method
CyberArk Central Credential Provider API configuration requirements
Review CyberArk Credential terminology and identifiers
Define CyberArk application ID
Provision accounts in CyberArk Password Vault
Set up access to the application and password providers

Install CyberArk Central Credential Provider

You must install and configure the CyberArk Central Credential Provider on the CyberArk server. See CyberArk Central Credential Provider installation.

Implement X.509 client certificate authentication method

An X.509 client certificate is a type of digital certificate used by client systems to make authenticated requests to a remote server and uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer, or service identity contained within the certificate.

The Automation 360 Control Room uses a client certificate as the authentication method when connecting to the CyberArk CCP APIs.

This authentication method is highly secure and leverages the system's truststore to store the client certificate, server certificate, and private key. The truststore is a certificate storage location provided by the operating system's software and it contains the issuing Certificate Authority's (CA) certificate. You can import individual server certificates into the truststore. However it is more efficient to import the issuing Certificate Authority (CA) certificate.

The following image provides an overview of certificate-based authentication:

Certificate-based authentication method

The client (Automation 360 Control Room) sends a request to the CyberArk AIM server (protected resource).
The server then responds by sending a certificate back to the client.
The Automation 360 Control Room verifies the certificate sent by the CyberArk AIM server by validating it against the trusted server certification information stored in the public part of the Control Room truststore.
After validating the information in the truststore, the Automation 360 Control Room resends the certificate back to the CyberArk AIM server.
The CyberArk AIM server then validates the certificate sent by Automation 360 Control Room against the trusted client certification information stored in the public part of the AIM server truststore
Because client certificates (those with their private key) are generally distributed in password protected format, the certificate file (using .p12 format, such as: c:\PATH\aaeCyberArkCertificate.p12) requires a passphrase.
Both parties (client and server) gain access to the protected resources if the certificates pass validation based on the following:
- The Control Room certificate must be trusted by the CyberArk AIM server
- The Control Room must trust the certificate on the CyberArk AIM server
- The Subject field in the certificate matches the calling system's Fully Qualified Domain Name (DNS Name)
- The certificate has not expired

重要： As part of the integration planning phase, coordinate certificates and requests for certificates. You will have to request that certificates be issued by the Public Key Infrastructure (PKI) team before you can begin integration configuration. The certificate files are stored in the PKI folder and accessed with the Control Room passphrase when required. The Control Room passphrase is stored encrypted in the keyvault.properties file.

CyberArk Central Credential Provider API configuration requirements

You must have network connectivity between the Automation 360 Control Room and the CyberArk AIM server. The Automation 360 Control Room is connected to the CyberArk Password Vault through the CyberArk Central Credential Provider (CCP) APIs for both On-Premises or Cloud deployments.

CyberArk CCP API configuration

注： No additional licensing is required to use the CCP APIs.

To use the CCP API, you must set these required parameters:

Automation 360 v.20 (supports bootstrap credentials with On-Premises deployment only)
Automation 360 v.21 or later (supports all bootstrap and system use cases for On-Premises deployments, auto-login, and automation credentials for both On-Premises and Cloud deployments)
The Control Room Key Vault contains these connection details:
- CCP API vault connection URL – For example: https://<host:port>/AIMWebService/api/Accounts?
- CCP API AppID – You must configure the CyberArk AIM server with an Application ID (AppID). For example: AACompanyControlRoom1.
  See Define CyberArk application ID.
- X.509 client certificate with private key issued to the Automation 360 Control Room
  (The Control Room Fully Qualified Domain Name is in the Subject: field of the certificate) and configured with the CyberArk AIM server for authentication. For example: c:\PATH\aaeCyberArkCertificate.p12
  注： The .p12 format is required.

Review CyberArk Credential terminology and identifiers

CyberArk and Automation Anywhere use different terminology to describe and identify credentials:


Description	CyberArk	Automation Anywhere
Where credentials are stored	object	credentials
Primary partitioning of the key vault	safe (contains objects)	locker (contains credentials)

Credentials in CyberArk are stored in objects, and each object is contained in a safe.
A single CyberArk instance can have multiple safes, where each safe has access controls for users.
Credentials in Automation Anywhere are stored in lockers, where each locker has access controls for Control Room users.

CyberArk identifies credentials by safe name AND object name. The CCP API uses a CyberArk safe name and CyberArk object name to access credentials within the CyberArk Password Vault (the credential must exist in CyberArk).

The following is a code sample CCP API call and corresponding response:

https://<host:port>/AIMWebService/api/Accounts?AppID=BillingApp&Query=Safe=Billing;Object=MonthlyBilling

Response

{
       "Content":"",
       "PolicyID":"CyberArk",
       "CreationMethod":"PVWA",
       "Folder":"Root",
       "Address":"address tbd",
       "Name":"Application-CyberArk-address tbd-vb",
       "Safe":"aa_vb_safe",
       "DeviceType":"Application",
       "UserName":"vb",
       "PasswordChangeInProcess":"False"
}

The credential value or secret (for example, the password) is stored in the Content attribute and the User ID (the Control Room user name, for example vb) is stored in the UserName attribute.

Define CyberArk application ID

Automation 360 integrates with CyberArk Password Vault through the CyberArk Central Credential Provider (CCP) API. The application ID (AppID) is a required configuration parameter.

As a CyberArk Administrator, use the CyberArk Password Vault Web Access (PVWA) interface to define the application ID by following the specified procedure to prepare the CyberArk AIM server for integration with the Control Room. See CyberArk Password Vault Web Access.

You must log in as a user allowed to manage applications on the CyberArk platform (requires Manage Users authorization).
From the Applications tab, click Add Application.

From the Add Application panel, enter the following information:


Option	Action
Name	Specify the unique name (ID) of the application. We recommend using a name based on the Control Room name or function, for example: `AACompanyControlRoom1`.
Description	Enter a short application description used to help identify it.
Business owner	Enter contact information about the application's business owner.
Location	Select the application location in the Vault hierarchy. If a location is not selected, the application will be added in the same location as the user who is creating this application.

Click Add to add the new application and display it on the Applications Details page.
From the Applications Details page, select the Allow extended authentication restrictions check box to specify an unlimited number of machines and Windows domain OS users for a single application.
From the Authentication tab, click Add to add details to the new application.
A list of available authentication characteristics are displayed, which the Credential Provider uses to verify before retrieving the application password.
Optional: Select OS user and enter the name of the user who will run the application, and then click Add to add the OS user to the list of users in the Authentication tab.
Select Certificate Serial Number and enter the certificate serial number for the Control Room client certificate, and then click Add.
(Automation 360 recommended): From the Allowed Machines tab, click Add, and specify the IP/host name/DNS address where the application is allowed to run and request passwords.
CyberArk AIM uses this address to ensure that only applications which run from specified machines can access their passwords.
Click Add to add the IP address to the list of allowed machines.

Provision accounts in CyberArk Password Vault

Before an application can function, you must give the application access to existing user accounts or to new user accounts to provision in the CyberArk Password Vault.

Use the Password Safe to provision the privileged user accounts required by the application. You can provision accounts using one of these methods:

Manually add accounts one at a time, and then specify all the account details.
Automatically add multiple accounts using the Password Upload feature. To add account automatically, you must have authorization to the Add accounts feature in the Password Safe.

For details about adding and managing privileged accounts, see Privileged Access Manager - Self-Hosted.

Set up access to the application and password providers

After the user accounts have been provisioned by CyberArk, you must set up access to both the application and to CyberArk Application Password providers who are serving the application.

From where the Central Credential Provider is installed, add the provider user and application users as members of the Password Safes (where the application passwords are stored). You can add the users using one of these methods:

Manually from the Safes tab
By specifying the Safe names in the CSV file when adding multiple applications

To add users as safe members, from the Add Safe Member dialog box, add the provider as a safe member with these access authorizations selected, and then click Add:

Retrieve accounts (Access)
List accounts (Access)
View Safe Members (Monitor)

CyberArk add safe member

注： When installing multiple providers for the CyberArk Password Vault integration, we recommend that you first create a group for them, and then add that group to the safe with the same selected access authorizations.

To add application (AppID) as a safe member, perform these steps:

From the Add Safe Member dialog box, add the (AppID) as a safe member with Retrieve accounts (Access) selected as the access authorization.
Click Add.

If the safe is configured for object level access, ensure that both the provider user and the application have access to the passwords to retrieve. For details about adding and managing privileged accounts, see Privileged Access Manager - Self-Hosted.