Application roles and access groups

An access role identifies a job position or responsibility defined for an application. For example, an access role can define the capabilities of a LoanOfficer or CallCenterSupervisor. The system grants users specified capabilities, such as modifying instances of a certain class, based on the access roles acquired from the access group in use.

Before you create access roles for your application, assess the role-based access control needs for the application to determine how many distinct access roles are needed. Also, determine what each access role should be named to describe the authorization for each grant. An access role defines what its holder is authorized to do in the application.

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

Consider that a lead system architect (LSA) has the following three access role design options to fulfill the access control needs of fulfillment operators and managers in the Ordering application example:

Option 1:

Option 2:

Option 3:

The design consideration for which option an LSA should take is whether the access control needs of the Manager nearly always “build on” (or are a superset of) those of the Fulfillment Operator.

Option 1 allows for the access control needs of each persona (user role) to evolve independently of each other, with the maintainability overhead of some access control settings being duplicated across each access role.

Option 2 requires the access control needs of the Manager always to be a super-set of the Fulfillment Operator, as a grant returned 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 to be predominantly based on the FulfillmentOperator access role, whilst allowing the Manager access role to both introduces Manager specific settings as well as override settings specified in the dependent FulfillmentOperator access role.

Solution: Option 3 typically yields an 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 additional Journeys are added that inevitably invalidate some of the authorization decisions reached in earlier releases.

Applications created from 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 used for access roles is <ApplicationName>:<RoleName> where RoleName is singular.

Use the Roles for Access landing page (Dev Studio > Configure > Org & Security > Tools > Security > Role Names) to create new application specific roles.

Use an Access of Role to Object to grant access permissions to objects (instances) of a given class and named privileges to a role. Access permissions and named privileges can be granted up to a specified Production Level between 1 through 5 (1 being Experimental, 2 being Development, 3 being QA, 4 being Staging, and 5 being Production) or conditionally with Access When rules.

When planning the set of AROs to specify for an Access Role Name, consider the following:

• Does the access role they apply to inherit authorization from Dependent Roles? If so, the AROs needed for your access role can be limited to those that alter the authorization outcomes otherwise derived from its Dependent Roles.
• Is the access role utilizing Privilege Inheritance? If not, some privileges from superclass AROs may need to be re-specified in subclass AROs in the same Access Role.
• Leaving settings blank in an ARO results in Pega deferring to superclass AROs and Dependent Roles to determine the authorization for that setting. This is a legitimate, object-oriented approach to configuring authorization but needs design.
• Is the access role used in access groups that “short-circuit” testing access roles once access is explicitly granted or denied?. If so, be conscious of the distinction between configuring a setting value (either an Access When rule or a Production Level number), both of which could explicitly deny access, and leaving the setting blank (delegating the authorization outcome to a superclass ARO, dependent role or subsequent roles on the Access Group).

Use an Access Deny rule to explicitly deny authorization before evaluating whether any corresponding AROs for the same Class and Access Role may grant access to the same action.

Defining Access Roles that only contain Access Deny rules, sequencing these Access Roles earlier in the list shown 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 be granted to the Access Group by Access Roles listed after it on the Access Group. Roles that contain only Access Deny rules can be described as 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. Create an Access Deny rule for each affected class.

The typical use case is where a persona (user role) requirement emerges whose authorization is very close to — but a subset of — an existing persona (user role). For example, given an Ordering application with an existing Manager persona (using an 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 they are authorized to open. An implementation approach for this using Access Deny rules might be:

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 required by the business rule
3. Create an Access Deny rule for the new Access Role on the Order class, applying for the new Access When as the Read Instance setting

4. Create the Ordering:AssociateManagers Access Group, adding the following Access Roles:

   1. Ordering :AssociateManagerDeny – denying Open Order access according to the business rule
   2. Ordering:Manager – granting the same authorization that existing Managers have

5. Select the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access setting on the Ordering:AssociateManagers Access Group.

An access group is associated with a user through the Operator ID record. The Access Group determines the Access Roles the users in the Access Group hold, the aggregate of which are the actions those users are authorized to perform. The naming convention used for access groups is application name, colon, group of users.

The naming convention used for Access Groups is <ApplicationName>:<GroupsName> where GroupsName is in plural form, for example, Customers.

Having an access role 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, the user roles in an HR application 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 called <ApplicationName>:DelegatedRulesAdmin. This access role can then be added to the Access Groups for both HR managers and executives so that they can update delegated rules in addition to their respective primary responsibilities.