Links may not function; however, this content may be relevant to outdated versions of the product.
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, clickfield.
- In the panel of Dev Studio, click 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.
PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:User4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4 PegaRULES:SysAdm4Pega RULES:WorkMgr4Privilege Privilege class Role Names Special comments AllFlows @baseclass 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- 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- WorkReopen Work- PerformBulk Work- AccessAuditTrail Work-
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