Access Control

 Role-based Access Control (RABC)

RABC is an access control model that organizes user into roles and assign permissions to each role as appropriate

Authentication vs Authorization

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 (Operator ID record)
• Authorization - Determines the applications that the user can                      access (Access Group record lists the any                          authorized applications and roles assigned to the                  members of the access group)

Role-based access control record types 

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 group of users
• Role - Maintains a list of all access records associated with a role 
• Access Deny - Restricts user access under certain conditions
• Access of Role to Object (ARO) - Specifies the permissions that are granted to a role and access class
• Class - Defines a collections of objects that are available to other classes or to instances of the class
• Privilege - Associates an access role with a rule that needs to be secured
• Rule - Defines the behavior of an application by serving as a building block

Important Notes : - if ARO and access deny records 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 control access to a specific rule. Most rules list any required privileges in the security tab of the rule form. Flow rules list the required privileges in the process tab.

Privilege record acts as a token. To grant 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 users attempt to run a rule without a required privilege, the applications returns an error.

Permission inheritance and dependent roles

Pega Platform allows developers to simplify permission management by inheriting access control settings from parent classes, which allows you to override only the permissions that need customization while keeping other permission settings in their default configuration.

When creating a new application, Pega Platform creates access roles for administrators, authors, managers and users. Each application specific role inherits from a standard access provided as part of core Pega Platform functionality. Standard access role from which permissions are inherited is called a dependent role.

Standard access roles 

By default, Access Role Name records reference at least one standard role as a dependent role. For example, the <ApplicationName>:Authors created for application is based on standard PEGARULES:SysAdmin4 role which lists the default access control settings for application developers.

Some of the standard access role provided with Pega platform are listed in the following table.

Question

Service Agents at a marina belong to two access groups that inherit permissions from different dependent roles: Service Agents inherit permissions from the PegaRULES: User1, and Service Managers inherit from PegaRULES: WorkMgr4.
Application requirements state that Service Agents and Managers can view data in Marina-Service-Data-Painting and Marina-Service-Data-Repair. Only the Service Managers can delete data from Marina-Service-Data-Painting and Marina-Service-Data-Repair.
What is the best approach to implement this requirement?

Configure an Access of Role to Object (ARO) record in Marina-Service-Data- class to include the Service Manager's delete permissions.