Published Release Notes

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.

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.

REST services support password credentials and JWT Bearer grant types

Pega^® Platform REST services now support password credentials and the JWT (JSON Web Token) Bearer grant type when you enable OAuth 2.0-based authentication. By using password credentials, you can quickly migrate clients from direct authentication schemes, provide additional flexibility when other grants are not available, and integrate your application with REST services in other applications. You can add compatibility with modern JWT-based cloud security IDPs by using the JWT Bearer grant type.

For more information, see About OAuth 2.0 Provider data instances, OAuth 2.0 Client Registration data instances - Completing the Client Information tab, Creating an Identity Mapping data instance.

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.

Two-factor authentication with one-time passwords

Pega® Platform now supports two-factor authentication in custom authentication services and case flow processing, by sending a one-time password to an operator through email and requiring the operator to provide it back to your application for verification. Use REST API OTP Generation to generate and store one-time passwords, and REST API OTP Verification to verify passwords against user entries. You can also use the pxSendOTP and pxVerifyOTP activities called by these APIs to implement two-factor authentication of users in case flows prior to performing a critical operation (e.g. before completing a critical transaction such as a funds transfer in excess of a certain amount). Settings on the Security Policies landing page control the behavior of the two-factor authentication process.

For more information, see Enabling security policies.

Updated Word merge support with Microsoft Silverlight plug-in

Starting in this release, Pega 7 features that integrate with the Word merge capability are now cross-browser. ActiveX controls (which are only compatible with Internet Explorer) have been replaced with Microsoft Silverlight. This plug-in must be downloaded separately from Microsoft because it is not shipped with Pega 7.

Common features that are affected by this change include the Specification form and Case Type landing page.

Prior to using these features, see the release note Word merge support with Microsoft Silverlight plug-in for more information about setting up their client systems.

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.

Create single sign-on authentication services from App Studio

You can create and enable single sign-on (SSO) authentication services from a new landing page in App Studio. From this new landing page you can also configure new SAML and OpenID Connect authentication services to provision users. For more information, see Creating a SAML SSO authentication service and Creating an OIDC SSO authentication service.

Link URLs to applications, requirements, and specifications

In addition to files, you can now attach URLs to applications, requirements, and specifications by using the Add/Edit Attachment modal dialog box in Pega 7. This change allows you to link directly to dynamic content in other URL-based systems rather than link to a static file of that content.

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.​