Published Release Notes

SAML single sign-on is easier to configure

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

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

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

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

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

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

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.

New privilege required to access the Search landing page

After upgrading to Pega^® Platform 7.4, users who do not have the pxAccessSearchLP privilege cannot access the Search landing page. The pxAccessSearchLP privilege is automatically assigned to the SysAdm4 role. If you have other roles that require access to the Search landing page, you must add the pxAccessSearchLP privilege to those roles.

For more information about assigning privileges to roles, see User privilege authorization. (Link to: basics/v6portal/landingpages/accessmanager/customizeprivilegestab.htm)

Known issue: SAML IdP import uses only the last certificate

When you configure the identity provider for a SAML SSO authentication service, the backing keystore rule for the verification certificate is created with only the last certificate from the IdP metadata, instead of using all of the certificates. 

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.