Authorization policy configuration

The role-based access control (RBAC) and attribute-based access control (ABAC) authorization models always coexist. Use RBAC to define every user through the roles specified in the access group; you can optionally add ABAC to complement RBAC in Pega Platform.

With RBAC, you specify the access control requirements that pertain to the persona (user role) that a user observes when using a Pega Platform™ application. 

• Stephen is a Call Center Worker who uses the Pega Customer Service™ application. Stephen is authorized to create Service cases but is unauthorized to perform account changes for VIP customers.
• Rebecca is a Senior Account Manager who uses the Customer Service application and is authorized to perform account changes for VIP customers.

Stephen's and Rebecca's organizational roles determine what they have the authorization to do in the Customer Service application. With RBAC, you can allow users to access only specific UI components, such as audit trails and attachments, or use privileges to restrict users from performing specific actions on a case. You can also use RBAC during design time to limit access to rules and application tools, such as the Tracer and Access Manager.

You use ABAC to restrict access on specific instances of classes by using policies that are not role-based but instead based on other attributes known about the user. For example, each user might have a Security Classification, which applies limitations on which data users can access.

For example, in the Customer Service application that Stephen and Rebecca use, the system requires users to have a Security Clearance of AAA to see a customer's address history that is older than five years and their Social Security Number. In the Customer Service application, Stephan and Rebeccas have the following configurations:

• Stephen holds a Security Clearance of AAA. Whenever he accesses the information about the customer in the application, he can see the entire address history and the 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 can only see a customer's address history up to the last five years. She is not authorized to see the Social Security Number of the customer, even though the RBAC for her persona (role) allows her to make changes to VIP customer accounts.

The access control policies driven by conditions other than role-based conditions use ABAC for implementation. The policies can apply at the record level (such as the visibility of Address records) and attribute level (such as the visibility of the Social Security Number for the customer).

The following table shows actions supported by RBAC and ABAC:

Use the Access Manager to configure RBAC. You configure ABAC by implementing Access Control Policy and Access Control Policy Condition rules, which might reference Access When rules. 

Check your knowledge with the following interaction: