Authorization models

Authorization models define a user's access to specific features of Pega Platform. For example, you can restrict an end user's ability to view data or perform certain actions on a specific instance of a class at run time. You can restrict a business or system architect's ability to create, update, or delete rules at design time or determine access to certain application development tools such as the Clipboard or Tracer.

The Pega Platform offers two authorization models that are different but complementary: Role-based access control (RBAC) and Attribute-based access control (ABAC). Role-based and Attribute-based access control coexist.

Pega Applications typically bring many personae (“user roles”) together to get work done. Personae (roles) include Customers, Call Center Workers, Managers, and Administrators. Most users fulfill one of the persona’s (role's) applicable for a given Application. RBAC defines the actions that one persona (role) is authorized to perform on a Class by Class basis, including:

• Class-wide actions: Execute Activities, Run Reports
• Record-level actions: Open, Modify (Create and Update), Delete
• Rule-specific actions as governed by Privileges

Review of role-based access control (RBAC) rule types

Every application has distinct personae (roles) that form the basis for authorization. You configure RBAC using the following rule types.

• Class: the type of data that is subject to authorization
• Access When: rule defining conditional access control (like a regular When rule) which typically evaluates one or more properties on the Class subject to authorization. The intent is that the access control outcome yielded from the Access When rule will vary between different instances of the same Class. For example:
  • Is the Purchase Request case currently in the “Approval” stage?
  • Is the Employee’s salary greater than 50,000?
• Privilege: rule that can be attached to certain rule types (or parts of them) to authorize who can execute (part of) that rule. For example:
  • Only holders of an “ApprovePR” Privilege can perform the Approve Purchase Request Flow Action
  • Only holders of a “ShowPR” Privilege can see a “Show Purchase Requests” menu item configured within a Navigation rule
• Access Role: a collection of Access of Role to Object and Access Deny rules defining all role-based access control settings that govern what access is granted (and denied) to those users who are allocated the Access Role
• Access of Role to Object (ARO): association of an Access Role to the operations that holders of that Access Role are granted/denied to perform on an Object (i.e. an instance of a Class).
• Access Deny: association of an Access Role to the operations that holders of that Access Role are explicitly denied to perform on an Object.
• Access Group: the collection of Access Roles that, when aggregated together, form the role-based access control portfolio for a single persona (role).

Recently emerged RBAC features

The following features have emerged in recent releases of the Pega Platform that further influence role-based access control. Examples of each are discussed in later modules.

• Dependent roles: allows Access Roles to be configured and resolve at runtime based on a dependency hierarchy of Access Roles
• Privilege inheritance: allows Privileges granted to a Class for an Access Role (by its ARO) to include those Privileges specified on AROs of its superclasses within the same Access Role
• Short-circuited access checking: Access Roles that yield an explicit grant or deny outcome can return this outcome immediately without checking subsequent Access Roles on the Access Group when – particularly in the case of an explicit grant – the eventual access control decision will be to grant access
• App Studio managed authorization: App Studio provides a basic authorization configuration capability which supplements the RBAC foundation provided from Dev Studio

Why Privileges are so important

Privileges provide better security because they can be used to control access to individual rules, sometimes parts of them.

Privileges are a critical component of your authorization strategy, because they provide an opportunity for the execution of certain rules to be explicitly authorized “just in time”. This is regardless of how the application may have reached a state where that authorization check is being made, reducing the exposure that other changes to the authorization model or unforeseen usage of the application implicitly authorize the unintended execution of a rule.

Runtime role resolution and privilege inheritance

When you define Access of Role to Object (ARO) rules on a class basis. Pega navigates the class hierarchy and determines the most specific ARO relative to the class of the object for that Role. Any less specific AROs in the class hierarchy for that Role are ignored. The operation being performed is allowed if the most specific ARO allows the operation. If the Operator has been granted multiple Roles, the most specific ARO rules are determined for each Role. The Pega platform performs the operation if the operation is allowed in any of the most specific AROs.

As stated, privileges can provide more granular security because they are defined on individual rules. For example, in order to execute a flow action secured by a privilege, the user must be granted the privilege. The privilege is granted through the most specific AROs for the Class of the object. There is, however, an option on the Role for inheriting privileges within AROs defined in the class hierarchy. Selecting this option provides the operator with all the privileges granted by the AROs defined for the classes in the the class hierarchy of the object.

In the following example, the Role has the option for inheriting privileges selected. If the user works on an Expense Report case, the access rights are defined in the row highlighted in bold. Additional privileges are inherited from the class hierarchy (TGB-HRApps-Work and Work-).

ABAC complements RBAC by enabling Access Control Policies to control access to specific attributes of a record (so long as RBAC has granted access to the record), regardless of where those attributes are used in the Application (on a screen, in a report). ABAC can also be used to define record-level access control (additional to RBAC) where the conditions for accessing those records are NOT determined by the persona (role) that the operator fulfills for the Application.

ABAC is optional and used in conjunction with RBAC. ABAC compares user information to case data on a row-by-row or column-by-column basis. You configure ABACusing Access Control Policy rules that specify the type of access and Access Control Policy Condition rules defining a set of policy conditions that compare user properties or other information on the clipboard to properties in the restricted class.

You define access control policies for classes inheriting from Assign-, Data-, and Work- and use the full inheritance functionality of Pega Platform. Access control policy conditions are joined with AND when multiple same-type access control policies exist in the inheritance path with different names. Access is allowed only when all defined access control policy conditions are satisfied.

In the following example, if the HR application user wants to update a Purchase case, the conditions for the access control policies defined in the class hierarchy are joined with AND. The user is granted access for updating the Purchase case only if WorkUpdate AND HRUpdate AND HRPurchaseUpdate evaluates to true.

To enable ABAC, in the Records Explorer, go to Dynamic System Settings and update the EnableAttributeBasedSecurity value to True.