Security best practices

As a precaution, do not assign permissive access roles, such as WorkMgr4, early on if it is not completely certain the user needs to Work- Perform Privilege. For example, a case worker’s productivity might be enhanced by viewing certain reports, but this does mean case worker should be assigned the Manager Portal by way of defining their Access Role WorkMgr4 and allowing access to a Manager portal. Instead, a Dashboard can be added to the specialized Case Worker 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 within a different ruleset. There can only be one instance of an ARO rule based on its keys, pyAccessRole, and pyAccessToClass.

As opposed to updating the Work- ARO to remove Perform Privilege as the default, a more specific class can be added, such as the work pool class, for example, FSG-Booking-Work. Within that new ARO, the Perform Privilege can be removed. The Perform Privilege can then be granted for the set of case types that a manager oversees.

Obfuscation of URLs is not a guarantee that an attacker can never find a way to form a URL that, if not secured by the system, gives access to information the attacker should not be allowed to view, or worse, 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 certain primary access role should not be allowed to create case types, then you need to define an authorization policy that explicitly prevents that access. Hiding the pyCreateCaseMenu within the Data-Portal pyPortalNavInner Section using a When rule is not the proper solution, albeit it can be part of the solution. This is true regardless of the When rule is checking for a Privilege.

A URL can be defined by anyone who can leverage the QueryString (?pyActivity=doUIAction&action=createNewWork&className=) and can create the case unless true security (via proper authorization) is implemented.

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

You do not want to be in a situation where When rules must be applied in every situation that requires enforcement. Doing so is the same as writing code that contains if/else logic; whenever a new "else" value is invented, if/else logic needs an update. The object-oriented way to enforce security is to secure the object that is ultimately accessed, not every path that it takes to get 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 be 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 image shows what happens when SalesExecutive1@Booking attempts to open a case owned by SalesExecutive2@Booking after the modification.

The Bulk Actions option is present with the Case Worker and Case Manager portal’s operator menu. If the requirement is that a Facility Coordinator should not be allowed to create an Event case and you have not set up the proper authorization policy, then the Facility Coordinator can use the Bulk Actions option to create the case as follows:

Step 1:

Step 2:

Pega has defined multiple areas to review before deploying an application to production. Each Deployment Manager 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.