Role-based access control (RBAC)
Application and data security are major concerns due to the risk of a data breach that leads to customer loss and legal or financial penalties. You can satisfy common security requirements by controlling user access to application features and functions.
Note: Securing access to features occurs during each feature development and not towards the end of the development cycle.
Roles
A role defines how users interact with the application, what user interface is presented, and what users can and cannot do within the application. Assigning application users to specific roles enables users to perform their work during case processing. Some examples of roles are customer, case worker, manager, and auditor. Developers, administrators, and managers also have roles that enable them to perform their work. Assign a user to a role to specify how that user interact with an application.
For example, in a health care application, patients and doctors must be able to perform different tasks. Patients can check records and schedule appointments. Doctors can check patient records, record prescriptions, and add follow-up comments for patients after office visits. Define different roles for patients and doctors so that individual users with the appropriate role specified can see the correct user interface and have access to the desired application features.
When you create an application, four roles are created by default: Admin, Author, User, and Manager. Create additional roles if a unique combination of the user interface, page permissions, and routing is required. In Pega Platform™, user interfaces are also referred to as channel interfaces. Work can be routed to work queues, which are lists of all open assignments for a group of users. Assignments are tasks that users perform. Each newly created role has its own work queue, channel, and set of permissions.
For example, the Author role shows the App Studio interface. The User role shows the Case Worker interface. The Author role has permission to create new users and roles, so users with the Author role see those actions in their user interface. Users with the User role can create and work on cases; they cannot modify the application.
You can associate roles to Studio channels (App Studio, Admin Studio, and Dev Studio) and web channel interfaces (Case Manager and Case Worker).
The role-based access control model
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. 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).
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 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.
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.
Note: The following example describes the OOTB authentication. However, SSO authentication is the most typical implementation. For more information, see the Pega Academy topic Single sign-on (SSO).
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.
Access roles
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.
- No access
- Experimental/Sandbox
- Development
- Test/Quality assurance
- Pre-Production/Staging
- Production
For example, entering a permission setting of 5 allows a user to view a case on a production system or any system with a lower production level setting. Entering a permission setting of 3 allows a user to view a case on a development or testing system, but not a staging or production system.
Access Deny
You can configure an Access Deny record in situations where regulations and policies require explicit denial of access to specific capabilities.
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.
Privilege
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. Flow rules list the 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.
Check your knowledge with the following interaction.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?