Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

SAML single sign-on is easier to configure

Valid from Pega Version 7.4

Implementing SAML single sign-on (SSO) login authentication in your application is now less complex. You can now configure most requirements that used custom activities or Java code in previous releases from the Authentication services form.

For more information, see Creating an authentication service.

Configure role dependencies to grant access rights

Valid from Pega Version 7.4

You can configure role dependencies in a role to grant access rights, which are inherited from the role. Role dependencies are relationships between roles that mirror an organization hierarchy or a more complex relationship among groups of operators, roles, or functional areas. Use role dependencies to simplify role configuration, minimize the number of roles needed by an access group, and minimize the number of privileges that you have to manually define for roles in your application.

For more information, see Access Role rules, Access Role form – Using the Role tab.

Improved operator security

Valid from Pega Version 7.4

To improve security, Pega® Platform now requires the following:

  • During deployment, you must configure a password for [email protected].
  • The administrator must enable new out-of-the-box operators.
  • The administrator and new Pega-supplied operators must change their passwords after the first login.

These requirements replace the optional secured mode in earlier versions of Pega Platform.

Multifactor authentication now supports SMS

Valid from Pega Version 7.4

Multifactor authentication now supports short message service (SMS) as well as email. Amazon Simple Notification Service (SNS) is supported as a provider.

For more information, see Security policies settings.

Operator provisioning is supported by SAML and OpenID Connect authentication services

Valid from Pega Version 7.4

When you use SAML and OpenID authentication services, operators can be automatically provisioned without the need to write custom activities. Users can now be authenticated and provisioned from authentication providers that adhere to the OpenID Connect specification, such as Auth0, NetIQ, and Google.

For more information, see Configuring operator provisioning for a SAML SSO authentication service and Configuring operator provisioning for an OpenID Connect authentication service.

Support for OpenID Connect authentication

Valid from Pega Version 7.4

Pega® Platform now supports authentication services that use OpenID Connect, an emerging standard for government and enterprise cloud environments. This standard facilitates interoperability among identity management solutions and authentication through authentication providers that adhere to the OpenID Connect specification, including Auth0, NetIQ, and social media sites such as Google.

For more information, see Configuring an OpenID Connect authentication service.

New access control policy for encrypting properties

Valid from Pega Version 7.4

With attribute-based attribute control, you can now encrypt property values in the database, clipboard, logs, and search indexes for any property type. If no policy obfuscates an encrypted property, its value is visible in UI controls and reports.

For more information, see Creating an access control policy.

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

Valid from Pega Version 8.5

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

Valid from Pega Version 8.5

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

Valid from Pega Version 8.5

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.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us