Published Release Notes

Support for the JSON Web Token Bearer grant type for accessing external APIs

You can now access external APIs by using the new OAuth 2.0 JSON Web Token (JWT) Bearer grant type, in an OAuth 2.0 authentication profile. To use the JWT Bearer grant type as a client assertion, source the JWT from an active SSO session, a token profile, or a property reference. You can use JWTs that you obtain during an OpenID Connect SSO in connectors, to achieve user impersonation flows, such as the On-Behalf-Of (OBO) flow. The OAuth 2.0 type authentication profile now also supports authentication of client applications by using Private Key JWTs.

Instances of the OAuth 2.0 provider are now deprecated. As a best practice, use the new, unified authentication profile configuration instead.

For more information, see Configuring an OAuth 2.0 authentication profile.

Upgrade impact

After an upgrade to Pega Platform 8.4 and later, Authentication Profiles can take advantage of the new JWT based OAuth 2.0 grant type and client authentication features. To take advantage of this and other new security features, you must update any existing Authentication Profiles formats must to use those in Pega Platform 8.4 and later.

What steps are required to update the application to be compatible with this change?

Since these features are available only for profiles created in Pega Platform 8.4 and later, clients must open and then save existing 'Authentication Profile' instances to ensure that the configuration is compatible with the latest authentication formats.

Sign and encrypt signatures and content with additional algorithms

You can now authenticate using JSON Web Token (JWT) token profiles to symmetrically and asymmetrically encrypt both signatures and content. All algorithms in the Nimbus JWT library are supported, including nested tokens. Custom key identifier headers (kid) are also supported. Use token profiles to securely propagate identities and transfer data between systems.

For more information, see Creating a processing JSON Web token profile.

For more information, see Creating a generation JSON Web token profile.

Improvements for test cases and assertions

The process of modifying test cases and assertions has been improved. Adjusting test cases to application changes is now much easier.

You now can:

• Select a page on which to run a tested rule.
• Change the class and rule of unit test cases.
• Create assertions that validate specific error messages on pages, properties, and activities.
• Automatically update decision result assertions with property changes made to a rule.
• Modify a rule's properties directly from decision result assertions.

For more information, see:

• Updating scenario tests
• Setting up your test environment
• Configuring page assertions
• Configuring property assertions
• Configuring decision result assertions

Simulation of data pages and third-party connections

When configuring your unit test case environment, you can now set up simulated data for connector and data page rules, instead of connecting to external sources.

By simulating such data calls, you are not dependent on any third-party server when running your tests.

This feature supports the following rules:

• Data page
• Connect-Cassandra
• Connect-CMIS
• Connect-dotNet
• Connect-EJB
• Connect-HBase
• Connect-HTTP
• Connect-Java
• Connect-JMS
• Connect-MQ
• Connect-REST
• Connect-SAP
• Connect-SAPJCo
• Connect-SOAP

For more information about simulating third-party connections, see Simulating data pages and third-party connections.

New branch quality dashboard

Pega Platform™ 8.4 introduces a new branch quality dashboard that shows the following metrics:

• The branch’s guardrail compliance score and the number of guardrail violations
• The percentage and number of unit tests that passed for the branch
• The percentage and number of rules that the tests cover
• Potential merge conflicts that can be addressed directly from the branch quality dashboard

For more information about the new branch quality dashboard, see Viewing branch quality and branch contents.

Custom application URL alias in the application definition

Create application URL aliases that support your ability to launch multiple Pega applications simultaneously in a single browser. This feature makes it easier for clients and your customers to log into multiple applications using the same browser and access them simultaneously. You configure your application URL alias in the application definition. For details, see Adding an application URL alias.

For more information, see Simplify access with an Application URL alias (8.4). 

Upgrade impact

After an upgrade to Pega Platform™ 8.4 and later, review to determine if and how you must update your application rules to reflect the current URL aliasing format. As part of these application rule updates, Pega also updated the URL format and value components of the clipboard property, pxRequestor.pxReqServletNameReal, which you can use to discover a servlet name. If your application uses this property to discover a servlet name, update the pxRequestor.pxReqServlet property in the application rule to use the new, required URL and value formats.

For details steps, see the section, Upgrading from Pega 8.3 or earlier: Guidelines for any required changes in your application URL aliasing, in the appropriate Pega Platform Upgrade Guide available at Deploy Pega Platform. 

What steps should the customer take to update their application?

After upgrading, you must update your JMeter test scripts. For detailed steps, see Updating JMeter test scripts after migrating to Pega 8.4.

Expanded checks for Java injection vulnerabilities (8.4)

The Java injection vulnerability check feature has been enhanced in Pega Platform™ to further prevent Java injection, including Edit validate, Edit input, and JSP rules. Pega Platform reports errors at design time and run time, and does not run any rule that includes any of the following Java code:

• JavaCompiler
• new ProcessBuilder()
• org.dita.dost.invoker
• Runtime.getRuntime()

For more information, see Configuring the Java injection check.

Enhanced reliability and stability of scenario tests

Several enhancements have been made to scenario tests to increase their stability and reliability. With enhanced improvements, you can now:

• Delay the execution of a step within a scenario test to add latency to a web browser and actions on a web page. This prevents tests from failing when a dynamic web page does not load all page element at once, but the test finds page elements that are immediately rendered.
• Automatically rerun failed scenario tests, which might fail because there are temporal stability issues on the environment or because the application UI is slowly renders.
• View the run history of scenario tests so that you can analyze the history of a test over time.

For more information, see the following:

• Delay the execution of a step within a test and rerun failed scenario tests for enhanced scenario test stability (8.5)
• Changing application quality metrics
• Automatically rerunning failed scenario tests
• Creating scenario tests

New JWT access token format: Authorized Access Token

Pega Platform™ is changing from using opaque tokens to using JSON Web (JWT) tokens and the JWT access token format: Authorized Access Token (AAT). An AAT enables a client application to validate the server for user permissions and authorizes a specific application to access specific parts of a user’s data.

The major benefits to using the JWT format are:

• The JWT is a self-contained token that has authentication information, expire time information, and other user-defined claims digitally signed.
• A single token can be used with multiple applications.
• The tokens are short-lived and can minimize damage if transport security is compromised, as the token signature is verified.
• As the token is verified with the signature, there is no need to verify against a database, thus reducing latency (usually important for Web APIs).

For more information, see Understanding authorized access tokens.

Improvements to OAuth 2.0 Services with Token Introspection Service and Token Denylist Service

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.