Question
Last activity: 8 Aug 2019 13:35 EDT
Pega Robotics CyberArch Integration in 19.1 version
I want to integrate CyberArch with the BOTs developed in Pega Robotics to ensure multi factor authentication used by underline application works as per organization's policy.
It can be RPA or RDA BOTs which will be managed using Pega PRPC 8.2 & Robot Manager 8.2.2
Need detailed steps and any specific inputs required from CyberArch.
CredentialManagerConfig.xml file
The CredentialManagerConfig.xml file provides configuration information to the internal Credential Service. The Credential Service provides credentials to the Pega RPA Service, the ASO Manager, and the Credential Store. You specify the provider that you use in the CredentialManager server element in the CommonConfig.xml file.
Note: For more information, see CommonConfig.xml file.
The Credential Service supports the following providers for credentials:
· DPAPI – Local credential storage using the Microsoft’s built-in Data Protection Application Programming Interface.
· CyberArk - CyberArk’s Privileged Access Security Solution. Pega Robotic Automation interfaces with a client-provided CyberArk system.
· Custom – A custom combination of supported providers (DPAPI and CyberArk).
This file is installed with Pega Robot Runtime and located in the following folder:
C:\ProgramData\Pegasystems\CredentialManagerConfig.xml
The following is an example of the CredentialManagerConfig.xml file:
There are several credential types. You can store all credential types in a single provider or you can distribute them across the available providers. For example, you can store the credentials owned by the RPA Service in CyberArk and store the credentials owned by Pega Robot Runtime in DPAPI. The following credential types are listed by the application that owns them:
Pega RPA Service
-
RegistrationOperation
-
WindowsUser
-
Runtimeuser
Pega Robot Runtime
-
RegistrationOperator
-
ASOManager
-
CredentialStore
Element
|
Description
|
Providers
|
Contains a list of available credential providers. Choose from the following credentials providers:
|
Providers/Provider name=”DPAPI”
|
This credential provider has no additional parameters.
|
Providers/Provider name=”CyberArk”
|
This credential provider includes the following parameters:
|
Credentials
|
Lists the individual credentials for CyberArk. When mapping individual credentials, use the following dynamic values, which are determined at runtime:
Using a strategy that stores credentials in CyberArk using values that are unique but may be constructed using these dynamic values can reduce the need for individual customization for each robot.
For each credential, include the following information:
Credentials should be mapped to CyberArk based on these attributes for each credential provided by a CyberArk administrator.
|
Credentials/Credential name=”RegistrationOperator”
|
This credential retrieves the Registration Operator. This name is a reserved name in the system. Include the following information:
|
Credentials/Credential name=”WindowsUser”
|
This credential retrieves the Windows user. This name is a reserved name in the system. Include the following information:
|
Credentials/Credential name=”RuntimeUser”
|
This credential retrieves the Runtime user. This name is a reserved name in the system. Include the following information:
|
Credentials/Credential name=”{ASOManagerKey}”
|
This credential retrieves a value that is defined in the ASO Manager. This name is defined in an adapter credentials property configuration screen. Include the following information:
|
Credentials/Credential name=”{CredentialStoreKey}”
|
This credential retrieves a value that is defined in the Credential Store. The solution developer defines this name and it must include the following information:
|
Credentials/Credential name=”Default”
|
This credential retrieves a value when a request does not match another credential. You can use a credential naming strategy to reduce the need to individually specify credentials. Include the following information:
The following is an example of how you could use this credential type:
<Credential name="Default" safe="{RobotName}" folder="root" objectName="{AdapterFriendlyName}-{RobotName}" />
With these settings, each robot would have its own safe and each application credential would have an objectName with the Adapter Friendly Name and the Robot Name separated by a dash. Using this pattern, you can store many credentials in a safe that is only accessible by this robot and you do not need to list these individually.
|
Credentials/Credential name=”Custom”
|
This credential contains a list of CustomProviders that define which provider is responsible for providing each of the credential types. Custom providers are evaluated in the order that you list them, with first provider winning all ties.
Enter at least two CustomProviders, one for DPAPI and one for CyberArk. Specify each of the values and mark them True or False.
|
CustomProvider name=”CyberArk”
|
Use this custom provider to define the attributes for CyberArk. Set each attribute to True or False. If you enter True, then CyberArk provides this credential type. This custom provider has the following attributes:
|
CustomProvider name=”DPAPI”
|
Use this custom provider to define the attributes for DPAPI. Set each attribute to True or False. If you enter True, then DPAPI provides this credential type.This custom provider has the following attributes:
|
Cyberarch isn't on the support matrix, so functionality cannot be ensured. You'll need to interrogate the application and explore the extent of the current functionality, then if further granularity is required open a translator request or reach out to Services.
https://community.pega.com/knowledgebase/pega-robotic-automation-application-support-matrix