Published Release Notes

Application Express and the Content Security Policy

Application Express copies (if defined) the Content Security Policy (CSP) name (pyContentSecurityPolicyName) from the built-on application in a new application. It also sets the CSP mode (pyContentSecurityPolicyMode) to report. The values appear in the Content Security area on the application rule's Integration & Security tab.

When checking an application in the DCO Compatibility tool, a warning appears if the CSP name is missing.

Password hashing using SHA-256/SHA-512

Password hashing using the SHA-256 and SHA-512 hash functions is available for use during the the Pega 7 authentication process with operator, ruleset, and update lock passwords. The SHA-256/SHA-512 hash functions join the previously available MD5 and SHA-1 hash functions.

Using SHA-256/SHA-512 hashing when creating or upgrading a password hash results in increased complexity of the hash, making it extremely difficult and time-consuming to determine hashed password values stored in a database.

Note that once you have updated your system to Pega 7.1.7 and have applied password hashing using the SHA-256/SHA-512 hash functions, reverting back to a previous version of Pega 7 is not advised as this causes hashed passwords using SHA-256/SHA-512 to fail.

See About password hashing for more information.

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.

Enhanced refresh token strategy

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.

Enhancements to token lifetime limits

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.

Scenario tests now honor application stack settings

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

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

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.