Application roles and access groups

An Access Role identifies a job position or responsibility for an application. For example, an access role can define the capabilities of a loan officer or a call center supervisor. The system grants users specific capabilities, such as modifying instances of a certain class, based on the access roles in the Access Group in use. 

Before you create access roles for your application, assess the needs for role-based access control to determine how many distinct access roles you need. Also, determine what to name every access role to describe the authorization for each grant of access. An access role defines what its holder can do in the application. 

For example, an access role might represent the actions that a manager, fulfillment operator, clerical worker, or auditor can perform. A given user can hold multiple access roles at once. The collection of access roles of a user acts as a group of capabilities and represents the set of actions that the user can perform. For example, fulfillment operators might have access to open customer order records, while managers might have access to open and modify customer order records. 

In the following scenario, a Lead System Architect (LSA) has three options for designing access roles to fulfill the access control needs of fulfillment operators and managers in an ordering application: 

To decide which option to choose, the LSA needs to answer the question whether the access control needs of the manager are nearly always based on (or are a superset of) the needs of the fulfillment operator:

• Option 1 enables each persona's access control needs (user role) to evolve independently of each other, which results in some maintainability overhead because some access control settings are duplicated across each access role. 

• Option 2 requires that the access control needs of the manager must always be a superset of the fulfillment operator needs because a grant from the FulfillmentOperator access role (without more advanced RBAC configuration) is enough to grant access to the Managers access group, even if the Manager access role denies access. 

• Option 3 allows the access control needs of the manager can be predominantly based on the FulfillmentOperator access role, while allowing the Manager access role to manager-specific access control settings as well as override settings that the dependent FulfillmentOperator access role specifies. 

Solution: Option 3 typically generates the intended authorization design with the fewest AROs and the lowest likelihood of duplication. This option promotes a maintainable and understandable solution and has the flexibility to adapt as you add more journeys that inevitably invalidate some of the authorization decisions in earlier application versions.

Applications that you create in the New Application wizard have three foundation access roles:

• <ApplicationName>:User
• <ApplicationName>:Manager
• <ApplicationName>:Administrator

With the introduction of dependent roles, the best practice is to create application-specific access roles that specify the foundation access roles as dependencies. 

The naming convention for access roles is <ApplicationName>:<RoleName> where RoleName has the singular form. 

To create new application-specific roles, you use the Roles for Access landing page in Dev Studio, which is accessed in the header of Dev Studio by clicking Configure > Org & Security > Tools > Security > Role Names. 

Use an Access of Role to Object (ARO) to grant access permissions to objects (instances) of a given class and named privileges to a role. You can grant access permissions and named privileges up to a specific production level between 1 through 5 (1 is Experimental, 2 is Development, 3 is QA, 4 is Staging, and 5 is Production), or conditionally with Access When rules. The following figure summarizes the usage of Access When rules in AROs and privileges to grant access to the rules: 

When you plan a set of AROs for an access role name, consider the following aspects: 

• Does the access role to which the AROs apply inherit authorization from dependent roles? If yes, you can limit the AROs for your access role to those AROs that alter the authorization outcomes otherwise derived from its dependent roles. 

• Does the access role use privilege inheritance? If not, you might need to respecify some privileges from superclass AROs in the subclass AROs in the same access role. 

• If you leave settings blank in an ARO, Pega Platform defers to superclass AROs and dependent roles to determine the authorization for that setting. This behavior is a legitimate, object-oriented approach to configuring authorization. 

Setting rules 

In Pega applications, a setting rule is used to control access to different parts of your application. You can create different settings for different roles, and these settings determine what each role can access. These settings are linked to users through their access group, which is identified in their Operator ID. This allows you to control access to various parts of your application based on the user's role. These settings are of Rule-Access-Setting and have no relation to application settings rules (the Rule-Admin-System-Settings rule type), or dynamic system settings (the Data-Admin-System-Settings Class). 

For more information on settings, see Using setting rules, Defining access settings for an Access of Role to Object rule

Use an Access Deny (RDO) rule to explicitly deny authorization before evaluating whether any corresponding AROs for the same class and access role might grant access to the same action. 

Defining access roles that only contain Access Deny rules, sequencing these access roles earlier in the list on an access group, and activating the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access option facilitates restricting authorization that is otherwise granted to the access group by access roles that are listed after that role on the access group. Roles that contain only Access Deny rules are Access-Deny-Only access roles. 

Rule resolution does not apply to Access Deny rules. Your system can contain at most one Access Deny rule for each Applies To class and role name combination. Class inheritance does not apply. You create an Access Deny rule for each class that is affected. 

A typical use case for RDO rules is when a persona (user role) requirement emerges whose authorization is very close to (but a subset of) an existing persona (user role). For example, in the Ordering application with an existing manager persona that uses the Ordering:Manager access role, the need for an associate manager persona (user role) arises, where the only difference in authorization is the value of orders that they can open. An implementation approach for this scenario through Access Deny rules might include the following steps: 

1. Create an Access-Deny-only access role named Ordering:AssociateManagerDeny. 

2. Create an Access When rule on the Order class that compares the order value to the threshold the business rule requires. 

3. Create an Access Deny rule for the new access role on the Order class, applying to the new Access When rule as the Read Instance setting.

4. Create the Ordering:AssociateManagers access group, adding the following access roles: 
   • Ordering:AssociateManagerDeny that denies Open Order access according to the business rule. 
   • Ordering:Manager that grants the same authorization that existing managers have. 

5. For the Ordering:AssociateManagers access group, select the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access setting. 

A user is associated with an access group through the Operator ID record. The access group determines the access roles that the users in the group hold, the aggregate of which are the actions that those users can perform. The naming convention for access groups is <ApplicationName>:<GroupName> where GroupName is in plural form, for example, Customers. 

Having an access role that is dedicated to a particular capability can be useful when multiple personas (user roles) perform a similar responsibility in addition to their distinct primary responsibilities. For example, in an HR application, the user roles are Employee, HR generalist, HR manager, and Executive. Both HR managers and executives can update delegated rules. In this case, create an additional access role named <ApplicationName>:DelegatedRulesAdmin. Then, add this access role to the access groups for both HR managers and executives so that they can update delegated rules in addition to their respective primary responsibilities. 

Check your knowledge with the following interaction: