Skip to main content

Configuring authorization

The role-based access control (RBAC) and attribute-based access control (ABAC) authorization models always coexist. RBAC is defined for every user through the roles specified in the access group, and ABAC is optionally added to complement RBAC.

RBAC is typically used to specify the access control requirements that pertain to the persona (user role) an operator observes when using a Pega application.

  • Stephen is a Call Center Worker when using the Customer Service application, needing authorization to create Service cases, but is unauthorized to perform account changes for VIP customers.
  • Rebecca is a Senior Account Manager when using the Customer Service application, and is granted the authorization to perform account changes for VIP customers.

Stephen’s and Rebecca’s organizational roles determine what they are each authorized to do in the Customer Service application. RBAC can restrict the operator to accessing specific UI components, such as audit trail and attachments, or restrict the operator from performing specific actions on a case using privileges. You can also use RBAC to limit access to rules and application tools, such as Tracer and Access Manager during design time.

You use ABAC to restrict access on specific instances of classes using policies that are not role-based, but instead based on other attributes known about the user. For example, each operator may be tagged with a Security Classification, which in itself applies limitations on which data the operator is authorized to access.

For example, in the Customer Service application used by Stephen and Rebecca above, a Security Clearance of AAA is needed to see a Customer’s address history older than five years and their Social Security Number.

  • Stephen holds a Security Clearance of AAA. Whenever he accesses Customer information in the application, he should be authorized to see full address history and the customer’s Social Security Number, even though the RBAC for his persona (user role) prohibits him from performing account changes if that customer is a VIP.
  • Rebecca holds a Security Clearance of B. She is authorized to see only a Customer’s address history up to five years old. She is not authorized to see the Customer’s Social Security Number, even though the RBAC for her persona (role) allows her to make changes to VIP customer accounts.

The above access control policies driven by conditions that are not role-based are typically implemented using ABAC. The policies can apply at both the record-level (such as the visibility of Address records) and attribute-level (such as the visibility of the Customer’s Social Security Number).

The following table shows actions supported by RBAC and ABAC.

Action Description RBAC ABAC
Open/read instances Open a case and view case data in reports and searches X X
Property Read in instances Restrict data in a case the user can open   X
Discover instances Access data in a case without opening the case   X
Modify/Update instances Create and update a case X X
Delete instances Delete and update a case X X
Run report Run reports X  
Execute activity Execute activities X  
Open rules Open and view a rule X  
Modify rules Create and update a rule X  
Privileges Execute rules requiring specified privileges X
Note: You can only define ABAC for classes inheriting from Assign-, Data-, and Work-. 

Use the Access Manager to configure RBAC. ABAC is configured by implementing Access Control Policy and Access Control Policy Condition rules, which may in turn reference Access When rules. 

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

100% found this content useful

Want to help us improve this content?

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

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice