Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Securing an Activity

Updated on July 1, 2021

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)
Note: Depending on the version of Pega Platform you are using, the Allow direct invocation from the client or a service checkbox does not need to be selected to run most out-of-the-box UI actions referencing activities. The more updated the version of Pega Platform, the less likely you are to need to use the Allow direct invocation from the client or a service checkbox.

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 RecordDeprecated: Summary viewFormat tab. Then, right-click Smart info settings, and then click the Content field.
Allow direct invocation from the client or a service is unchecked by default. If you select Allow direct invocation from the client or a service checkbox, you must add a privilege to the activity.
  • 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.

Note: Starting in Pega 7.1.5, you are no longer required to select the Allow direct invocation from the client or a service checkbox for activities called by Service rules.

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.

Note: A session remains unauthenticated until the user signs in using credentials, unless you are using an anonymous authentication service. For more information, see:

Note: If you unselect the Require authentication to run checkbox and select Allow direct invocation from the client or a service, this will allows any person with access to your server the ability to execute this activity. The default Authorization model stops unauthenticated users from having read and write access, so it is important to consider if your activities do something other than read and write.

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.

PrivilegePrivilege classRole NamesSpecial 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 @baseclassPegaRULES:WorkMgr4Used for rules visible for Non-Dev Studio users. This is used in rule delegation.
pxViewLimitedForm@baseclassPegaRULES:ViewerCollaboratorVarious DecisionManager RolesUsed for read-only rule forms, not in Dev Studio.
PerformWork-

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.
WorkUpdateWork-

PegaRULES:SysAdm4Pega

RULES:WorkMgr4

WorkReopenWork-

PegaRULES:SysAdm4Pega

RULES:WorkMgr4

PerformBulkWork-

PegaRULES:SysAdm4Pega

RULES:WorkMgr4

AccessAuditTrailWork-

PegaRULES:SysAdm4Pega

RULES:WorkMgr4

Standard administrative privileges are shown in the table below.

PrivilegePrivilege classRole NamesSpecial comments
OpenDeveloperForm@baseclass PegaRULES:SysAdm4Used 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@baseclassPegaRULES:SysAdm4This privilege allows the user to see details about in memory data called clipboard pages.
ActionEditAttachmentWork-PegaRULES:SysAdm4Run EditAttachment or ActionEditAttachment flow actions.
ReviewPolicyOverridesWork-PegaRULES:SysAdm4Privilege to perform assignments on a suspended work object.
PerformanceToolsCode-Pega-PegaRULES:SysAdm4Used 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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us