Published Release Notes

Guardrails compliance score

The Application Guardrails landing page has been enhanced to help you build more guardrail-compliant applications. Increase transparency and accountability on your projects by responding to the following compliance score metrics:

• A weighted compliance score (0-100) based on warnings, severity, and justification
• A percentage of compliant rules in your application
• Total number of rules in your application
• Total number of rules in your application with warnings (justified and unjustified)

Additional metrics include alert and interaction count trends over the last four weeks.

For more information, see Guardrails compliance score.

Access Manager portal

Changes to the Access Manager simplify the process of modifying the access rights of features for an application. The changes, including creation of an Access Manager portal, make it easier for non-technical users, such as business architects, to set access rights even if they may not have a deep understanding of Pega 7's security model and class inheritance structure.​

Directed inheritance view in Application Explorer

You can now specify which inheritance model is used to populate classes in the Application Explorer. From the top level menu, use the “Explorer Inheritance” option to choose between:

• Pattern: only display class names whose prefix matches the root node class name.
• Directed: first display classes that explicitly name the root node as the parent class; then display classes with pattern inheritance.

By default, the Application Explorer loads using Pattern inheritance. 

Save Application Explorer filter selections

Application scoping control selections made in the Application Explorer are now persisted between sessions. These preferences are stored in an operator record on an access group level. If you delete (and later re-add) an access group on your operator form, the application scoping control defaults to all layers selected:

External access control DASS

A new Dynamic Admin System Setting (DASS) controls the Designer Studio's access to external systems, specifically the PDN RSS feed found on the home page.

By default, Pega-Desktop.AllowAccessToExternalSystem is set to TRUE. Update this setting to FALSE to hide the PDN RSS feed and ensure that no RSS fetch is performed.

Business logic-based routing cards enhancements

To ensure that the sequence of business logic-based routing cards conforms to your business requirements, you now have the option to change the order of the cards. For easier navigation across multiple routing cards, the system automatically collapses the cards for you, and you can then easily expand the cards that you need to display.

For more information, see Navigate easier across business logic-based routing cards (8.5), Assigning users automatically at run time.

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.