Securing an Activity
You can better protect your application by limiting how an Activity can be executed and who may execute it by configuring Activity-specific access control.
In most cases, the system-wide Authentication in Pega Platform is sufficient to secure your application.
To alter these settings, use the Restrict access section of the Security tab, as shown in the image below.
There are three levels of security available In the Restrict access section:
- Allow direct invocation from the client or a service
- Require authentication to run
- Privileges (Privilege Class and Privilege Name)
Allow direct invocation from the client or a service
The Allow direct invocation from the client or a service checkbox should be selected 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 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 Finding the right privilege.
One use case where the Allow direct invocation from the client or a service checkbox should not be selected 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 checked by default. In most cases, this should not be changed.
De-select 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 provided in the PRPC:Unauthenticated access group. In many instances, clients overwrite this with their own unauthenticated authentication group. Therefore, your unauthenticated access group may have another name, similar to <application name>:Unauthenticated.
Privileges
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.
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 access roles alone.
Standard Privileges
The most commonly used end-user privileges and administrative privileges are detailed in the tables below.
Standard end-user privileges are shown in the table below.
Privilege | Privilege class | Role Names | Special comments |
AllFlows | @baseclass | PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:User4 | Used during case processing. You wouldn't normally use this privilege since 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 Reporting users may not run those activities. |
UpdateLimitedForm | @baseclass | PegaRULES:WorkMgr4 | Used for rules visible for Non-Dev Studio users. This is used in rule delegation. |
pxViewLimitedForm | @baseclass | PegaRULES:ViewerCollaboratorVarious DecisionManager Roles | Used for read-only rule forms, not in Dev Studio. |
Perform | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | Used to restrict taking 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 only take action on cases assigned to you. |
WorkUpdate | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | |
WorkReopen | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | |
PerformBulk | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 | |
AccessAuditTrail | Work- | PegaRULES:SysAdm4Pega RULES:WorkMgr4 |
Standard administrative privileges are shown in the table below.
Privilege | Privilege class | Role Names | Special comments |
OpenDeveloperForm | @baseclass | PegaRULES:SysAdm4 | Used to restrict anything related to rule form usage in Dev Studio. This is the most generic Dev Studio privilege. It is often used along with UpdateLimitedForm and pxViewLimitedForm privileges if this activity could also be used by delegated rules as well. |
clipboardViewer | @baseclass | PegaRULES:SysAdm4 | This privilege allows the user to see details about in memory data called clipboard pages. |
ActionEditAttachment | Work- | PegaRULES:SysAdm4 | Run EditAttachment or ActionEditAttachment flow actions. |
ReviewPolicyOverrides | Work- | PegaRULES:SysAdm4 | Privilege to perform assignments on a suspended work object. |
PerformanceTools | Code-Pega- | PegaRULES:SysAdm4 | Used to allow admins to do specific expensive performance-related analysis. By default, this is not available in a production environment. |
Using privileges
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, the following two areas are important to consider:
- When to use a privilege
- Setting a privilege
When to use a privilege
However, there are cases where you must add a privilege to an activity to keep your application secure:
- If an activity performs a task that should only be performed by specific
access groups or access roles.
- For example, a bulk processing activity for administrators which would be dangerous if executed by a normal end user should have a privilege.
- The user must have a privilege when Allow direct invocation from the client or a service is checked.
- Setting a privilege
To secure an activity, you need to choose the correct privilege. The task described below is an example step-by-step process to find an existing privilege in your application in order to secure an Activity.
Previous topic Securing your application for mashup communication Next topic Setting a privilege