Role-based access control (RBAC)
Application and data security are major concerns due to the risk of a data breach leading to customer loss and legal or financial penalties. You can satisfy common security requirements by controlling the application features and functions users can access.
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 accessible by all members of the Human Resources (HR) department. Due to privacy concerns, stakeholders want to restrict access to raise proposals to only members of the HR department that are authorized to access compensation information. By granting authorization to specific members of the HR department, you can reduce the chance of unauthorized access to personal identifying information (PII).
The role-based access control model
In the preceding example, to satisfy the requirement to restrict access to PII, you can implement role-based access control (RBAC). RBAC is an access-control model based on organizing users into roles and assigning permissions to each role as appropriate. With RBAC, you can create a role for members of HR 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.
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 the user 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.
In the following image, click the + icons to explore how Pega Platform uses authentication and authorization to identify the correct application and portal to open when a user signs in.
An access role categorizes users according to their job function. Each access role represents how a set of users interacts with an application to create and process cases. For example, in an application for managing purchase requests, any user can submit a purchase request, but only a manager can approve a purchase request.
Each access group references one or more access roles. By allowing references to multiple roles on an access group, Pega Platform encourages the design of a modular application security model in which you combine granular roles to meet complex security needs.
For each access role, you configure permissions to control actions on instances of a specific class, such as the types of cases that a user can create or modify. If the roles referenced by an access group provide conflicting access control configurations, Pega Platform applies the most permissive setting across all the conflicting roles. In the following example, a manager belongs to an access group that includes both the User and Manager access roles. The Manager access role allows users to approve and submit a time-off request, while the User access role prohibits approval and submission actions. Because the Manager access group references both roles, members of the access group can approve and submit time-off requests.
Check your knowledge with the following interaction.
Role-based access control record types
The RBAC model provides several types of records that are used to configure behavior satisfying access-control needs. In the following image, click the + icons to learn about each type of access control record.
Access of Role to Object
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 to run reports.
Each ARO corresponds to a unique combination of access role and class. This allows Pega Platform to apply permissions configured in the ARO to the users in a particular role.
With an ARO, permissions are granted on a 0-5 scale, where 0 denies permission to perform an action. The values 1-5 grant permission on a system with the same or a lower production level, as indicated in the following list.
- Test/Quality assurance
For example, entering a permission setting of 5 for the View case history action allows a user to view the case history on a production system or any system with a lower production level setting. Entering a permission setting of 3 would allow a user to view the case history on a development or testing system, but not a staging or production system.
By default, Pega Platform denies access to all instances of a class unless you explicitly grant access to users. In situations where regulations and policies require explicit denial of access to specific capabilities you can configure an Access Deny record.
Access deny records are functionally similar to AROs. As with an ARO, each access deny record corresponds to a unique combination of role and class. With an access deny record, you deny permission for an action using a 0-5 scale, where 0 indicates that the action is allowed. The values 1-5 indicate that the action is denied on a system of the same or a higher production level.
For example, if an access deny record sets the permission for viewing case history on instances of the Purchase Request case type to 5, then the action is denied on a production system.
Note: 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.
A Privilege record is used to control access to a specific rule. Most rules list any required privileges on the Security tab of the rule form, except for flow rules, which list required privileges on the Process tab. A rule can list multiple privileges. Granting any of the listed privileges to the user allows the user to run the 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.
Privileges are considered during the rule resolution process, but only after a candidate rule has been added to the rules cache. If a user attempts to run a rule without a required privilege, the application returns an error rather than attempting to run a different version of the rule.
Similar to a when condition, you configure an Access When record to define logic for configuring conditional permissions for actions. Access when records return a result of either true or false. If the record returns false, the access control setting is considered to be zero (0). If the record returns true, the access control setting is considered to be five (5). This ensures that any conditional permissions are not affected by the production level of the system.
To apply conditional logic to an access control setting, enter the name of the access when record in the field that corresponds to the action or privilege on either an access deny or ARO record.
Check your knowledge with the following interaction.