Improvements to OAuth 2.0 Services with Token Introspection Service and Token Denylist Service
Valid from Pega Version 8.5
Increase the security of user sessions by using the newly supported Token Introspection and Denylist services for OAuth 2.0.
Token Introspection service
Use the Token Introspection service to validate JSON Web Tokens (JWT). The Token Introspection service requires authentication.
Pega now uses OAuth 2.0 access tokens called Authorized Access Tokens (AAT).
Token Introspection service endpoint
The Token Introspection service endpoint provides the information about the status of access token and refresh token. Token introspection can be used to validate if a given token is still active or inactive. The token introspection endpoint determines whether the token is valid. The status indicates whether an access token or refresh token is valid or invalid:
- Valid tokens have the
“active”:true
status - Invalid tokens have the
“active” :false
status.
The inactive status can also be due to revocation.
Token Denylist service
You can add tokens to the deny list in cases where suspicious activity might have occurred. The Token Denylist service provides a method for denying user access to the application by revoking the user's access token. This service can prevent a token from being used more than the specified number of times, which can be helpful in preventing replay attacks. Stolen tokens should be revoked using this service. A GET API is also available to get the list of denied tokens.
Keys endpoint
Pega Platform™ is changing from using opaque tokens to JSON Web (JWT) tokens. If this JWT is used by any other system, the public key is needed for signature verification. A new endpoint is exposed to provide these public keys in JWK format: https://host:port/prweb/api/oauth2/v1/token/keys.
For more information, see OAuth 2.0 Management Services.
Enhanced refresh token strategy
Valid from Pega Version 8.5
You now have more precise control over your refresh token expiration strategy. When a refresh token is enabled, you can choose to set its initial expiration based on the value provided by the IDP. The refresh token expiry can be derived from IDP’s session timeout when SSO is used with external IDP for user authentication in the authorization code grant flow. You can also specify a separate refresh token expiration strategy based on your use-case.
These can be configured in the OAuth2 Client registration rule form.
For more information, see Enhanced refresh token strategy.
External data flow rules are deprecated
Valid from Pega Version 8.5
External data flows are now deprecated and no longer supported. To improve your user experience with Pega Platform™, the user interface elements associated with these rules are hidden from view by default. Identifying unused features allows Pega to focus on developing and supporting the features that you need.
For more information, see Deprecated: External data flows.
Enhancements to token lifetime limits
Valid from Pega Version 8.5
Pega Platform™ uses OAuth 2.0 authorization codes, access tokens, and refresh tokens to provide flexible token-based security for applications. Expiration settings for these codes and tokens now adhere to certain strict value range based on industry leading practices. For example, the lifetime specified for the authorization code must be in the range 1-600 seconds.
These can be configured in the OAuth2 Client registration rule form.
For more information, see OAuth 2.0 Management Services.
Visual Business Director data is automatically cleaned after a retention period expires
Valid from Pega Version 8.5
To avoid negative impact on system resources, such as memory and disk space, Pega Platform™ automatically cleans out collections data accumulated in Visual Business Director after the time period specified in the vbd/dataRetentionTimeout dynamic system setting.
Upgrade impact
In versions of Pega Platform earlier than 8.5, collections data was not automatically removed. From version 8.5, the data is removed after 465 days (15 months) by default.
What steps are required to update the application to be compatible with this change?
If the default data retention period does not meet your requirements, you can change it by editing the vbd/dataRetentionTimeout setting.
For more information, see "Configuring the data retention period for Visual Business Director" in the Pega Customer Decision Hub 8.5 Upgrade Guide on the Pega Customer Decision Hub product page.
Optimization check utility available for legacy strategies
Valid from Pega Version 8.5
Ensure that your strategies are compatible with the optimized strategy execution engine introduced in Pega Platform™ 8.1 by running a post-upgrade utility that checks strategies within your application for areas that you can optimize, for example, by reducing the number of page properties that are copied from one shape to another. Running the utility produces a report that you can use to plan the required updates to your strategies.
For more information, see Make your strategies compatible with the optimized strategy execution engine by using a check utility.
Scenario tests now honor application stack settings
Valid from Pega Version 8.5
The application stack defined on the Application Quality Settings page of Dev Studio now serves as a foundation for creating, viewing, and running scenario tests.
Dev Studio will now:
- Display scenario tests based on the application stack settings on the Dev Studio landing page.
- Store scenario tests with the configured stack settings.
- Report metrics in the application quality dashboard with respect to the configured stack settings.
For more information, see Creating UI-based tests with scenario testing.
Run an application test suite from a CI/CD pipeline
Valid from Pega Version 8.5
Deployment Manager, as well as the existing REST service used to call scenario tests, now accepts a test suite ID when running scenario tests from an application pipeline. By using test suites, you can customize a set of select scenario tests to run as a group, instead of running all the scenario tests that are applied to a particular application.
Only the tests that belong to the suite are run as part of the task.
For more information, see Creating UI-based tests with scenario testing.
Access PegaUnit compliance metrics from a centralized location
Valid from Pega Version 8.5
PegaUnit compliance metrics and execution rate have been added to the PegaUnit metrics tile of the Application Quality dashboard. This dashboard provides a centralized location for all PegaUnit data for a specific application.
The dashboard also supports granular PegaUnit test information for each case type and data type, similar to the process currently available on the branch quality dashboard.
For more information, see Analyzing application quality metrics.
Run PegaUnit tests by using an API call
Valid from Pega Version 8.5
A new REST API is now available to create and run PegaUnit tests from an external continuous improvement (CI) tool. This synchronous method allows for the processing of large quantities of tests while reducing the possibility of time-out issues. This additional method of performing PegaUnit testing does not impact users who want to continue using their current testing workflow.
For more information about setting up your environment and making API calls with Deployment Manager, see the Documentation/readme-for-swagger.md file in the DeploymentManager04_08_0x.zip file, found in the Deployment Manager download package.