You can better protect your application by limiting how an activity can be run and who may run it by configuring activity-specific access control.
In most cases, the standard Authentication in Pega Platform is sufficient to secure your application.
To alter the Activity-specific access control settings, use the Restrict access section of the Security tab, as shown in the following figure.
Three security fields are available in the Restrict access section:
- Allow invocation from browser
- Require authentication to run
- Privileges (Privilege Class and Privilege Name)
Allow invocation from browser
Select the Allow invocation from browser check box when your activity meets one or more of the following criteria:
- You need to be able to call this activity from a URL Mappings rule.
- You need to use the deprecated List Views or Summary Views and you need to
call an Activity in the Content field. To access
these deprecated views:
- In the panel of Dev Studio, click . Then, right-click Smart info settings, and then click the Content field.
For more information, see Setting a privilege to secure an activity.
One use case where you should not select the Allow invocation from browser check box is when you are configuring an external system to call this activity by URL. Instead, create a Service REST rule.
- For more information, see Creating a REST integration.
Require authentication to run
Require authentication to run is selected by default. In most cases, do not change this selection.
Clear the Require authentication to run check box to allow
guest users to run this activity if they meet other security and access criteria.
Guest users — unauthenticated requestors — typically have access to rules in the
RuleSets in the PRPC:Unauthenticated access group. In many
instances, clients overwrite this with their own unauthenticated authentication
group. Therefore, your unauthenticated access group might have another name, similar
to <application name>:Unauthenticated.
Privileges: Privilege Name and Privilege Class
Privilege inheritance simplifies the process of defining privileges and access settings that are relevant in multiple classes.
Use privileges to differentiate the capabilities of different groups of users within your application. The privilege form defines only the existence (name and Applies To class) of a new privilege. It contains no other information and conveys no capabilities by itself.
Privileges has two fields that you can enter information into, the Privilege Name field and Privilege Class field.
A privilege is an application-specific access control element associated with a class and access role. A privilege rule only names a privilege; it does not convey the privilege to anyone. A privilege has two parts: the privilege class and the privilege name.
To have access to a privilege, a requestor session must "hold," in the access role list, at least one of the access roles that grant access to the privilege. The association between access roles and privileges is defined by instances of the Rule-Access-Role-Obj rule type.
Using privilege rules in an application is optional, but they can offer finer control over access than using access roles alone.
The Privilege Class field contains the auto-generated rule classes that are associated with the privilege.
The Privilege Name field contains the auto-generated list of privilege names.
The following tables list the most common end-user and administrative privileges.
Standard end-user privileges are shown in the following table.
PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:User4 If, however, you created an Access Group and Role only
used for reporting purposes, users with that access group
should not do any flow processing. You can add
AllFlows to your activities to
ensure that reporting users cannot run those
activities. PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4
Privilege Privilege class Role names Comments AllFlows @baseclass Use this privilege during case processing. You would not
normally use this privilege because most users already have it.
UpdateLimitedForm @baseclass PegaRULES:WorkMgr4 Use this privilege for rules visible for non-Dev Studio users. Rule delegation uses
this privilege. pxViewLimitedForm @baseclass PegaRULES:ViewerCollaboratorVarious DecisionManager
Roles Use this for read-only rule forms, not in Dev Studio. Perform Work- Restricts the ability to take action on an assignment. This
privilege allows a user to perform an assignment on another
individual's list (including workbaskets). Without this
privilege, you can take action only on cases assigned to
you. WorkUpdate Work- None WorkReopen Work- None PerformBulk Work- None AccessAuditTrail Work- None
If, however, you created an Access Group and Role only used for reporting purposes, users with that access group should not do any flow processing.
You can add AllFlows to your activities to ensure that reporting users cannot run those activities.
Standard administrative privileges are shown in the following table.
Privilege Privilege class Role names Comments OpenDeveloperForm @baseclass PegaRULES:SysAdm4 Restricts anything related to rule form usage in Dev Studio. This is the
most generic Dev
Studio privilege. It is often used with
pxViewLimitedForm privileges. Rule delegation can
also use this privilege. clipboardViewer @baseclass PegaRULES:SysAdm4 Allows the user to see details in memory data called
clipboard pages. ActionEditAttachment Work- PegaRULES:SysAdm4 Runs EditAttachment or
actions. ReviewPolicyOverrides Work- PegaRULES:SysAdm4 Performs assignments on a suspended work object. PerformanceTools Code-Pega- PegaRULES:SysAdm4 Allows administrators to do specific expensive
performance-related analysis. By default, this privilege is not
available in a production environment.
Using privileges to control access
Most access control is granted through authorization, which controls many common use cases around creating, updating, and deleting cases and data. However, when using privileges, consider the following two areas:
- When to use a privilege
- Setting a privilege to secure an activity
When to use a privilege
In some cases, you must add a privilege to an activity to keep your application secure, for example:
- If an activity performs a task that only specific access groups or access
roles should perform.
- For example, a bulk processing activity for administrators should have a privilege so that users cannot run the activity.
- When Allow invocation from browser is selected, a user must have a privilege.
- Setting a privilege to secure an activity
To secure an activity, determine the correct privilege, then assign that privilege to the role that is authorized to run that activity.