Securing an activity
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 checkbox when your activity meets one or more of the following criteria:
- You need to be able to call this activity directly from JavaScript code in a non-autogenerated Section or non-autogenerated Control or Text File rule.
- 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 checkbox 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 checkbox 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.
Standard privileges
The following tables list the most common end-user and administrative privileges.
Standard end-user privileges are shown in the following table:
Privilege | Privilege class | Role names | Comments |
AllFlows | @baseclass | PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:User4 | Use this privilege during case processing. You would not
normally use this privilege because most users already have it.
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. |
UpdateLimitedForm | @baseclass | PegaRULES:WorkMgr4 | Use this privilege for rules visible for non-Dev Studio users. Delegating a rule or data type uses this privilege. |
pxViewLimitedForm | @baseclass | PegaRULES:ViewerCollaboratorVarious DecisionManager Roles | Use this for read-only rule forms, not in Dev Studio. |
Perform | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | 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- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | None |
WorkReopen | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | None |
PerformBulk | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | None |
AccessAuditTrail | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | None |
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 UpdateLimitedForm and pxViewLimitedForm privileges. Delegating a rule or data type 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 ActionEditAttachment flow 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.
Previous topic Configuring an activity to process a JSON Web Token Next topic Setting a privilege to secure an activity