Skip to main content

Creating roles and access groups for an application

Each user (operator) of an application has a defined persona (user role) for processing cases. Applications typically allow some groups of users to create and process cases and other groups of users to approve or reject those cases.

AccessManager
This figure illustrates a manager persona accessing a manager portal on the left and a non-manager persona on the right attempting to access the same manager portal. The manager persona on the left is allowed access. The non-manager persona on the right is denied access.
 

For example, in an application for managing purchase requests, any user can submit a purchase request, but only department managers can approve purchase requests. Each group of users has specific responsibilities and plays a particular persona (user role) in processing and resolving the case.

Access roles and their design considerations

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:

Type Name Description
Access Role Ordering:FulfillmentOperator Allows Open access for Customer
Access Role Ordering:Manager Allows Open and Modify access for Customer
Access Group Ordering:FulfillmentOperators References the Ordering:FulfillmentOperator Access Role only granting Open access to Customer objects
Access Group Ordering:Managers References the Ordering:Manager Access Role only granting Open and Modify access to Customer objects

Option 2:

Type Name Description
Access Role Ordering:FulfillmentOperator Allows Open access for Customer
Access Role Ordering:Manager Allows Modify access for Customer
Access Group Ordering:FulfillmentOperators References the Ordering:FulfillmentOperator Access Role only granting Open access to Customer objects
Access Group Ordering:Managers References both the Ordering:FulfillmentOperator and Ordering:Manager Access Roles granting Open and Modify access to Customer objects granting Open (from FulfillmentOperator) and Modify (from Manager) access to Customer objects

Option 3:

Type Name Description
Access Role Ordering:FulfillmentOperator Allows Open access for Customer
Access Role Ordering:Manager Allows Modify access for Customer and specifies Ordering:FulfillmentOperator as a Dependent Role
Access Group Ordering:FulfillmentOperators References the Ordering:FulfillmentOperator Access Role only granting Open access to Customer objects
Access Group Ordering:Managers References the Ordering:Manager Access Role only granting Open (inherited from FulfillmentOperator) and Modify (from Manager) access to Customer objects

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.

Note: The use of Access Deny rules or the Stop access checking once a relevant Access of Role to Object instance explicitly denies, or grants access option on the access group rule-form can help Option 2 achieve the same outcome as Option 3, but this adds more rules and complexity to the design.

Applications created from the New Application wizard have three foundation Access Roles:

  • <ApplicationName>:User
  • <ApplicationName>:Manager
  • <ApplicationName>:Administrator
Note: Other access roles are also created for RBAC pertaining to Pega API and APP Studio usage but are inconsequential for this module.

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.

Note: A capability to clone the AROs from an existing access role to another is available from the Access Roles landing page. This is typically for backward-compatibility only with Pega RBAC capabilities from earlier versions that preceded the availability of Dependent Roles.

Access roles created in newer versions of Pega typically use Dependent Roles as a preference over cloning.

Access of Role to Object (ARO) design considerations

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.

ARO Design
The image summarizes the usage of access when rules in Access role of object and privileges to grant access to the 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).

Access Deny (RDO) design considerations

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.

Note: Access Deny rules cannot be configured to deny a Privilege that AROs otherwise grant in any of the Access Roles in the Access Group.

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.

Note: This scenario can also be implemented using Dependent Roles. Think about how a Dependent Roles design can achieve the same outcome. What are the advantages and disadvantages? Could this be used to address the Access Deny rule’s inability to deny Privileges?

Access group design considerations

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.

Note: Pega Platform delivers some fine-grained access roles to allow particular access groups to be granted specific Privilege-based capabilities. Examples include: PegaRULES:BasicSecurityAdministrator and PegaRULES:AgileWorkbench.
If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice