Published Release Notes

Improving basic access control

Pega Platform™ has implemented a new basic access control (BAC) to protect your application from unauthorized server calls from otherwise authenticated users.

For more information, see Access Control Checks.

Upgrade impact

After you upgrade to Pega 8.5, all the functionality in the model configurations that use auto-generated controls and actions continues to work as before. However, you must secure any customized JavaScript in your application layer that makes AJAX (server) calls  by using registration or encryption mechanisms.

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

After upgrade, to migrate custom JavaScript functionality, see Access Control Checks.

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.

Privilege inheritance support through access roles

Privilege inheritance simplifies the process of defining privileges that are relevant in multiple classes. When determining whether a user should be granted a named privilege that allows a type of access to a class, Pega^® Platform searches for Access of Role to Object (Rule-Access-Role-Obj) rules that are relevant to the target class and to the access roles listed in the user's access group, and considers the privileges granted or denied in those rules. When privilege inheritance is enabled within an access role, the search for relevant Access of Role to Object rules begins with the target class and, if necessary, continues up the class hierarchy until a relevant rule is found.

For more information, see Privilege inheritance for access roles.

Property-level security for full-text search

Property-level security has been added to full-text search so that you can limit access to sensitive data. From the Search landing page, you can specify whether to include properties with access control policies in search results. In addition, for custom search, you can select which properties to include in full-text search by selecting options on the Search landing page and Custom Search properties instance.

For more information, see Specifying custom search properties and Excluding properties with access control policies from search results.

Monitor standard and custom security events

From the new Security Event Configuration landing page, you can select the standard and custom security events that you want the Pega 7 Platform to log automatically for every user session. The security events are grouped into the following types:

• Authentication
• Data access
• Security administration
• Custom

The API logCustomEvent() is provided so that you can create custom security events that are specific to your applications and that can be monitored by the Pega 7 Platform. For more information, see Security Event Configuration.

Security landing pages and features require privileges

Security-related landing pages and features are no longer visible and accessible to every user. To view and configure the following security features, you must have the appropriate privileges:

• Attribute-based access control (ABAC) policies require the pzCanManageSecurityPolicies privilege.
• The Authentication Services landing page requires the pzCanCreateAuthService privilege.

Restrict visibility of scalar property values for certain users

You can use the Access Control Policy rule to mask individual scalar property values from specified users. You can restrict visibility for the following property types:

• DateTime
• Integer
• Text

For more information, see Masking property visibility for users.

Disable inactive operators

As a system administrator, you can control access to an application by disabling Operator IDs. To disable an Operator ID, you can use one of the following options in Designer Studio:

• Call the Service REST: user.
• Change settings on the Operator Access tab on the System Settings landing page or on the Security tab on the Operator ID form.
• Define the number of inactive days in the security policies before an Operator ID is automatically disabled.

For more information, see System Settings - Operator Access tab, Enabling Security Policies, Security tab on the Operator ID form.

Cross-origin resource sharing (CORS) policies for APIs and REST services

You can now use cross-origin resource sharing (CORS) policies to control how external systems and websites (origins) are permitted to access resources such as APIs and services within your applications. For example, Pega^® Platform uses CORS policies to restrict which Pega Robotic client applications can connect to your Pega applications, and to limit which mobile apps can call Pega mobile services. Using CORS policies results in reduced cost and implementation times, while providing increased security when other systems or websites interact with your application.

For more information, see Creating a cross-origin resource sharing (CORS) policy and Mapping an endpoint to a cross-origin resource sharing (CORS) policy.

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.