Security best practices

As a precaution, avoid assigning permissive access roles, such as WorkMgr4, unless it is certain that the user requires Work-Perform Privilege. For example, a user's productivity may improve by accessing specific reports, but this does not justify defining their Access Role as WorkMgr4. Instead, add a Dashboard to the specialized user portal. 

Rule-Access-Role-Object (Access of Role to Objects or ARO) rules are non-versioned. It is not possible to override an ARO rule in a different ruleset. Only one instance of an ARO rule can exist based on its keys, pyAccessRole, and pyAccessToClass. 

Instead of updating the Work- ARO to remove Perform Privilege as the default, a more specific class, such as the work pool class (for example, FSG-Booking-Work), can be added. Within the new ARO, the Perform Privilege can be removed. Then, grant the Perform Privilege for the set of case types that the manager oversees. 

Obfuscating URLs does not guarantee that an attacker can never find a way to form a URL. If the URL is not secured by the system, such URLs grant access to information that the attacker should not view or allows the attacker to modify information in the system. 

Remember the saying, "obscurity is not security." If a member of a certain work group or someone with a specific primary access role should not create case types, define an authorization policy that explicitly prevents that access. Hiding the pyCreateCaseMenu within the Data-Portal pyPortalNavInner Section using a When rule is not a proper solution, although it can be part of the solution. This is true regardless of whether the When rule checks for a Privilege. 

Anyone who can make use of QueryString (?pyActivity=doUIAction&action=createNewWork&className=) can define a URL and create the case unless true security (via proper authorization) is implemented. 

Alternatively, a developer might use When rules to check whether the user has a specific access role or privilege. Security-checking When rules are useful when no better means of enforcement exists or in combination with proper authorization to enhance the user experience. 

You do not want to apply When rules in every situation that requires enforcement. Doing so is equivalent to writing code that contains if/else logic. Whenever a new "else" value is invented, if/else logic requires an update. The object-oriented way to enforce security is to secure the object that is ultimately accessed, not every path that leads to the object. 

Example:

Suppose an operator has read access to a case but not perform access. The user can issue a URL such as:

No error message is displayed. Instead, the screen says NoID and displays a button that says Open in Review.

Suppose you do not want that person to view the case in Review mode unless that person is either the current owner or the last person to update the case. Simply preventing access to the assignment is not sufficient. This is because Assign- Read access = canPerform only prevents the assignment from being performed. It does not prevent the associated case from being opened. Access must also be prevented or allowed at the case-level.

Notice the RBAC configuration below for FSG-Booking-Work. The pxRelatedToMe Access When rule allows the case to be opened only when last updated or resolved by the current operator or currently owned by the current operator. A co-worker is not allowed to open the case.

In the Booking application, the primary Access Role for Sales Executives should be cloned from - or even better, dependent on - PegaRULES:User4. The following figure shows what happens when SalesExecutive1@Booking attempts to open a case owned by SalesExecutive2@Booking after modification:

Pega defines multiple areas to review before deploying an application to production. Each Deployment Manager release pipeline includes a security review step to remind architects of this essential task. The security guidelines are included in the pxApplicationSecurityChecklist Application Guide rule which can be launched from the Documentation tab of the application rule.

For more details, review the Security Checklist.

For additional details on security design, see the Security excellence webinar.

Check your knowledge with the following interaction: