Configuring AD FS and Robot Manager for single sign-on
|Description||Tips for configuring Pega Robot Manager for AD FS.|
|Version as of||8.5|
|Application||Robotic Process Automation|
|Capability/Industry Area||Robot Manager|
Configuring AD FS and Pega Robot Manager for single sign-on
Configuring AD FS and Pega Robot Manager for single sign-on is a straightforward process if you take into account the following factors:
- Pega Robot Runtime uses ws-trust (that is part of ws-federation) and requires a Security Token Service (STS) to connect to Pega Robot Manager.
- Pega Robot Runtime only uses AD FS STS to get a SAML token that allows it to request an OAuth token from Pega Platform. Pega Robot Runtime will use that token to access all the required services in Pega Robot Manager.
- Pega Platform OAuth token service requires the CLient ID and Client secret claims to be included in the SAML token. Their specific values are downloaded from the OAuth Client Registration configuration in Pega Platform.
- Pega Platform OAuth configuration requires a CA certificate with public keys. The certificate is stored in the Pega Platform database as a Truststore that is using JKS, PKCS12, and so on.
- When using SSO, the Service Package used by Pega Robot Runtime in Pega Robot Manager is roboticsSSO.
- Every user must be registered as Operator in Pega Robot Manager before trying to connect through SSO with Pega Robot Runtime.
See the following figure for architecture details:
See the following figure to learn about the sequence of service calls between Pega Robot Runtime, AD FS and Pega Robot Manager.
AD FS configuration
Pega Robot Runtime follows ws-trust standard and requires the Security Token Service (STS) to be configured in AD FS. For more information on the AD FS options and configuration, see Microsoft documentation.
Pega Robot Manager configuration
The single sign-on implementation with AD FS uses SAML token to obtain an OAuth token to be used for authentication in all the Pega Robot Manager services. The OAuth configuration starts by creating a OAuth Client Registration configuration. See the following figure for sample configuration:
For more information, see OAuth 2.0 client registrations.
From the OAuth Client Registration it is required to select an Identity Mapping for the SAML bearer. Typically you would use UPN to indicate the claim provided in the SAML token which identifies the operator but if the token uses a different claim this needs to be indicated in the Identity Mapping, as shown in the following figure:
For more information, see Identity mapping.
From the Identity Mapping it is required to select the Truststore. Use the Truststore to upload the certificate file with the public keys. The certificate imported must be in JKS, PKCS12 or other compatible formats. See the following figure for sample configuration:
For more information, see Keystores.
Once the configuration is ready and all the different artefacts saved. From the OAuth Client Registration it is possible to download the Client ID and Client Secret values required to be included in the SAML token as claims by AD FS STS, as shown in the following example:
Pega Robotic Process Automation (RPA) architecture has different components and configurations involved. The main components connecting to Pega Robot Manager are Pega Robot Studio, Pega Robot Runtime with attended configuration (RDA) and Pega Robot Runtime with unattended configuration (RPA). SAML OAuth with AD FS as IdP it is only supported by Pega Robot Studio and Pega Robot Runtime with attended configuration. for more information about all supported configurations, see Pega Robot Manager authentication mechanisms.