Authorization policy configuration

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.

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.