Caching service caller credentials for authenticated services
By default, Pega Platform™ does not cache service call credentials, which leads to unnecessary queries when retrieving service operators. This behavior might have a negative effect on high volume service applications, such as customer decision hub.
To avoid this issue, configure service caller IDs and passwords to be cached using a parameterized node-level data page, which eliminates the need to query the Pega Platform database operator table for every service caller. The password remains encrypted on the clipboard for security reasons.
The following example is for operator caching for a service that uses basic authentication, however, you can use the same steps for other authentication methods, such as LDAP, and so on.
At a minimum, you must configure the following rules:
Create a node-level data page in the Data-Admin-Operator-ID class to cache the operator IDs of the service callers. The parameterized data page must:
- Accept an operator ID as a parameter
- Be read-only and be sourced using the Lookup option against the Data-Admin-Operator-ID class.
- Use the operator ID as the class key for the lookup.
- Use an unauthenticated access group because the data page is referenced before an operator context is established.
- Have the PegaRULES:Guest role in the access group.
- Be stored in a ruleset associated with the application's unauthenticated access group. In the following example, the ruleset PegaNBAM-Rules is on the ruleset list of the application associated with the access group Jamie:Unauthenticated.
Data page Load authorization
For more information about configuring data pages, see Data pages.
Add a custom authentication service that references authentication and timeout activities. Associate the authentication service with a ruleset that is associated with the unauthenticated application rule. One authentication service can be shared by all authenticated Pega services.
Authentication service configuration
For more information about authentication services, see Authentication services.
Create an authentication activity that resides in a ruleset on the unauthenticated application rule and ensure that Require authentication to run is not selected. Configure the steps as follows:
- Step 1: Get and decode, using Base64 encoding, the operator ID and password from the authorization header of the request. Use the following function to retrieve the authorization header variable:
- Step 2: Get the corresponding data page instance containing the encrypted password.
Steps 1 and 2
- Step 3: Use the @pxSamePassword function to compare the clear text password from the request to the encrypted password on the data page.
The condition is checked in the When pre-condition of step 4 as follows:
- Step 4: If the passwords are the same, establish the operator context. If the passwords are not the same, execute steps 5 and 6.
Steps 3 and 4
- Step 5: If the passwords do not match, log the unauthenticated access attempt.
- Step 6: If the passwords do not match, use the pyChallenge parameter to tell Pega that the authentication attempt failed. Use pyFailMessage to return the default fail stream associated with the authentication service back to the caller. pyFailMessage can be referenced from the default fail stream HTML rule.
Steps 5 and 6
For more information about activities, see Activities.
Add a reference to the authentication service on each service package instance.
Service package configuration
For more information about service packages, see About service package data instances.
Add the following response condition as the first condition for each service. The condition tells Pega to return an HTTP 401 error if authentication fails, that is, if the pyChallenge parameter is set in the authentication activity.
- Condition: Security Error
- Content type: application/text/plain
- Status code: 401
Service rule configuration
For more information about service rules, see Integration-services category.