Published Release Notes

New hashing algorithm for Password property types

To provide extra protection against brute-force attacks, a new hashing algorithm has been added to the Pega 7 Platform. Bcrypt is used as a default hashing algorithm for Password property types. The bcrypt key setup algorithm takes a long time to process. This means that potential attackers would have to spend a substantial amount of time testing every possible key.

For more information, see Using the bcrypt hashing algorithm for Password property types.

Discovery features for access control policies

Access control policies now support discovery features that allow end users to view limited, customizable information about class instances that fail Read policies but satisfy Discover policies. Two types of Discovery gadgets are provided, and when discovery features are enabled, a Discovery gadget is included in the Report Viewer and in search results. Developers can customize these gadgets and include them in other parts of an application user interface.

For more information, see Discovery features for access control policies.

Update and delete actions available in access control policies

Access control policies support update and delete actions on objects. These actions control which specific instances of a class can be created, updated, or deleted by an end user in a case.

For more information, see Creating an access control policy.

Terminate sessions for operators from outside the Pega 7 Platform

The newly added Users REST API allows an authorized administrator to terminate sessions for one or more operator IDs from outside the Pega^® 7 Platform. A typical use case for this API is to terminate a user’s session when the user's security credentials, which are stored externally, are known to have changed.

Access the Pega API by clicking Resources > Pega API.

Conditional filter logic supported in access control policy conditions

In the Access Control Policy Condition rule form, you can now add conditional logic that allows you to apply different access control policy conditions based on different situations, such as different types of users. The policy condition filters that are enforced  are based on the results of Access When rules. Conditional filters can be configured to allow certain highly privileged users to bypass access control security in certain situations. This is accomplished by entering an Access When but leaving the conditional logic field blank.  When such a filter is applied to a read access policy it also should be applied to the corresponding discover policy.

For more information, see Creating an access control policy condition.

Use Kerberos credentials in a Pega application to authenticate and access external systems

Authentication services now support Kerberos as an authentication type. When you connect from the Pega 7 Platform to external systems and services that require Kerberos authentication, the Pega 7 Platform stores the user Kerberos credentials and makes them available in Pega 7 Platform connectors.

For more information, see Using Kerberos credentials in a Pega application to authenticate and access external systems.

SAML 2.0 single sign-on authentication in multitenant environments

Multitenant application environments can now use SAML 2.0 for single sign-on (SSO) and single logout (SLO). Application users can access any authorized SSO multitenant applications without logging in to each application individually. SAML simplifies the login and logout process for users, mitigates security risks, and reduces the implementation costs that are associated with identity management.

For more information about configuring SAML 2.0 for single sign-on, see Web single sign-on (SSO) with SAML 2.0.

New PegaRULES:PegaAPISysAdmin​ role

The role PegaRULES:PegaAPISysAdmin​ has been added to the Pega 7 Platform. This required role gives system administrators access to the Pega API REST User Services and is not required for other services.

For more information, see Securing the Pega API.

Issue with the Sandbox directive on the Content Security Policy rule form has been fixed

An issue that related to the Sandbox directive not being applied, even after a value in the Content Security Policy rule form was selected, has been fixed. As a result, restrictions that are applied based on the settings in the Sandbox directive are now more closely aligned with the World Wide Web Consortium (W3C) specification than in previous releases. You should test your Content Security Policy to ensure that this change does not cause unexpected behavior in your application, such as making the security policy too restrictive.

Addition of Data Access Tab to access control policy condition rules

You can now select associations and declarative index classes when creating access control policy condition rules. The Column source field in the policy condition can now accept properties from available associations and indexes. For ease of reference, the selected associations and indexes are available on the new Data Access tab. 

Using the new tab, you can build complex authorization models in which access restrictions for a class depend on the attributes present in the associated and indexed classes, along with the attributes in the current class. For example, a project management application can now separately maintain project lists for each operator and use that information to restrict read/write access to unique projects.

The information available on the new Data Access tab reflects rule form changes, which are similar to the existing functionality of the Report Definition in the Application Data Model. 

For more information, see Creating an access control policy condition.