Role-based access control (RBAC)

Consider a Process for employee review that includes an Assignment to authorize a raise for an employee. The Assignment is routed to a common Work Queue that is accessible by all members of the Human Resources (HR) department. Stakeholders want to keep employee compensation information, such as raises, private. Only members of the HR department may have access to compensation data. By granting authorization to specific members of the HR department, you can reduce the chance of unauthorized access to personal identifying information (PII).

To satisfy the requirement to restrict access to PII, you can implement role-based access control (RBAC). RBAC is an access-control model that organizes users into roles and assigns permissions to each role as appropriate. With RBAC, you can create a role for HR members who are authorized to access compensation information and grant that role permission to authorize employee raises. Users in other roles that are not granted permission are prohibited from authorizing raises.

Authentication versus authorization

The Pega Platform™ implementation of role-based access control is based on two factors: authentication and authorization:

• Authentication confirms the identity of the user by validating login credentials such as the user name and password. In Pega Platform, the operator ID record contains information needed to authenticate a user.
• Authorization determines the applications that the users can access, including Actions that the user can perform and information that the user can view. In Pega Platform, the Access Group record lists any authorized applications and roles assigned to members of the Access Group.

When a user signs in, Pega Platform™ identifies the default Access Group for the user and opens the corresponding application in the specified Portal. A user can belong to multiple Access Groups, but only one Access Group is active at a time.

Match the numbers to the following image to learn more about how Pega Platform uses authentication and authorization to identify the correct application and Portal to open when users sign in:

1. Login: First, users enter their username and password on the login screen.

2. Verification against stored data: Next, Pega Platform identifies the operator ID record from the entered username and verifies the entered password against the password stored in the operator ID record.

3. Identification of the Access Group: After authenticating users, authorization ensures that the users have access to only the features and data that they need for their work. Access Groups define the Actions that groups of users can do in an application. Users can use a URL that specifies an application, which resolves to the appropriate Access Group based on the operator.
   For example, https://examplepegaapplication.com/prweb/PRServlet/app/GoGoRoad where /app/GoGoRoad is the app. The operator ID that is used to log in to the unique URL is associated with the appropriate Access Group.

4. Access to applications, Portals, and allowed Actions: Finally, using the default Access Group, Pega Platform identifies:

   1. The application that is available to users, which determines the Rules, Case Types, and data types that are available.

   2. The Portal in which users interact with the application.

   3. Through the roles listed on the Access Group, the permissions that are granted to users.

The RBAC model provides several types of records that are used to configure behavior satisfying access control needs:

• Access Group – Identifies the application, default Portal, and assigned Access Roles for a group of users
• Role –  Logical grouping that references AROs and privileges to define what users can do
• Access Deny – Restricts users' access under certain conditions
• Access of Role to Object (ARO) – Specifies permissions that are granted to a role and access class
• Class – Defines the data types whose instances are secured through ARO and Access Deny Rules
• Privilege – Associates an Access Role with a Rule that needs to be secured
• Rule – Defines the behavior of an application by serving as the building block

The following image demonstrates each type of access control record: 

Access Group

An Access Group record is the starting point for the RBAC access control model. Each user belongs to at least one Access Group. An Access Group identifies the available application, default Portal, and one or more assigned Access Roles for a group of users.

Access Deny

In certain situations, regulations and policies require explicit denial of access to specific capabilities. You use an Access Deny record to explicitly deny access to an Action for instances of a class.

For example, a data privacy requirement may state that users assigned the User role are denied access to PII. To satisfy this requirement, stakeholders decide to deny the ability to run reports on purchase requests to the User role. You can configure an access deny record to deny the User role the ability to run reports on the Purchase Request Case Type instances.

If an ARO and an access deny record are defined for the same combination of role and class, the settings on the Access Deny record override the settings on the ARO.

Access Role Name

Each Access Group references one or more Access Role Name records, or roles.

An Access Role name record identifies the name of an Access Role, and aggregates all of the individual access of role to object and access deny records for that role. No access control configuration occurs on the Access Role name record itself.

Access of Role to Object (ARO)

The foundation of the RBAC model is the Access of Role to Object (ARO) record. You use an ARO record to define the access control settings for instances of a specific class.

Each ARO identifies the actions that a role can perform on instances of the specified class.

For example, an ARO named PurchaseRequest:Administrators associated with a class that describes purchase request Cases may allow users to open Cases but not run reports. Each ARO corresponds to a unique combination of access role and class which allows Pega Platform to apply permissions configured in the ARO to the users in a particular role.

Privilege

A Privilege record is used to control access to a specific Rule. A privilege record acts as a token. If a Rule requires a privilege to run, only users granted the privilege can run the Rule. To grant a privilege to a role, add the privilege record to the appropriate ARO.

You can add a privilege directly to a Rule on the Security tab of the Rule form. Flow Rules list the required privileges on the Process tab. A Rule can list multiple privileges. If a Rule lists multiple privileges, a user must have at least one of the required privileges to run the Rule.

If a Rule requires a privilege, the system checks whether the user’s role includes that privilege before allowing the Rule to run. If users attempt to run a Rule without a required privilege, the application returns an error rather than attempting to run a different version of the Rule.

For example, you add a privilege to a Flow Action used to approve purchase requests. Only the roles that have been granted the privilege are allowed to approve a purchase request. If a user attempts to perform the Action without the privilege, the application returns an error.

Classes and access control

AROs and access deny records specify whether users assigned a role are granted or denied Actions for instances of the class. Examples of these actions include:

• Opening instances
• Modifying instances
• Saving new instances
• Deleting instances
• Running reports
• Viewing history

Rules

You can update a Rule to specify that a privilege is required to access or use that Rule. Only certain Rule forms include the Privilege field, and for the Rules that do, entering privileges is optional.

The following table lists the Rules that can be configured to require privileges, and the function of the privilege for each of the Rules:

• Activities: Only users with the privilege can run the activity.
• Attachment category Rules: Only users with the privilege can perform certain operations on an attachment.
• Correspondence: Only users with the privilege can use the Rule.
• Data Pages: Only users with the privilege can access the Data Page at runtime.
• Flows: Only users with the privilege can start the flow.
• Flow Actions: Only users with the privilege can select certain Actions.
• Parse structured Rules: Only users with the privilege can run Rules.
• Report definition Rules: Only users with the privilege can produce the report or chart.