As a security administrator, you permit or restrict groups of users to access various actions in an application, such as having access to a case type, flow action, or button.

When you create an application, some access groups are created automatically. You can create additional access groups and assign users to access groups based on the type of work they do. For example, in most applications, managers have permission to do tasks that ordinary employees cannot. As a security administrator, you configure an access group for managers and an access group for regular employees. When a new employee is hired, human resources staff assigns the employee to the proper access group.

Use case

The examples below assume that you have a human resources application named HRApp in which various access groups, such as managers and human resources staff, can do different actions. The examples also assume that you have access to the Dev Studio portal for HRApp and have the PegaRULES:SecurityAdministrator role. Some of the examples assume that you have created specific case types and access groups, which are described in each example.

Securing an application user interface involves these sorts of tasks:

• Controlling access to an entire case type
• Controlling access to flow actions
• Controlling access to sections, buttons, and other UI controls
• Controlling access to reports
• Validating user input and preventing invalid values
• Controlling access to individual cases
• Encrypting the values of sensitive properties
• Masking the values of sensitive properties

Controlling access to an entire case type

Authorized users process salary reviews by using the SalaryReview case type in the HRApp application. You need to ensure that only human resources staff and managers can access the SalaryReview case type.

Before you begin

Assume that these steps have already been done:

1. Access groups are defined for human resources staff (HRApp:HRStaff) and managers (HRApp:Managers).
2. A role is defined for salary review processing (HRApp:SalaryReview).
3. The HRApp:SalaryReview role is assigned to the HRApp:HRStaff and HRApp:Managers access groups.

Configuration

Do these steps to ensure that only operators with the HRApp:SalaryReview role have permission to open the SalaryReview case type.

1. In Dev Studio, go to the Work & Process tab of the Access Manager landing page by clicking Configure > Org & Security > Access Manager > Work & Process.
2. In the Access group field, enter HRApp:Managers. The tab lists permissions that the HRApp:Managers access group has for various roles, case types, and actions.
3. Expand the SalaryReview case type and the Open action, and ensure that a green check mark is shown for the HRApp:SalaryReview role. A green check mark indicates that permission is granted. You can change the value by clicking the icon.
4. Repeat the steps above for the HRApp:HRStaff access group.
5. Repeat the steps above for the other access groups, but ensure that a red X is shown for the Open action of the SalaryReview case type and that the HRApp:SalaryReview role is not listed, showing that no access is permitted. You can change the value by clicking the icon.

For more information, see Editing authorizations for case type items in a single access group.

Back to top

Controlling access to flow actions

Authorized users approve salary changes by using the SalaryReview case type in the HRApp application. You need to ensure that only managers have access to the flow action for salary approval.

Before you begin

Assume that these steps have already been done:

1. Access groups are defined for human resources staff (HRApp:HRStaff) and managers (HRApp:Managers).
2. A role is defined for salary approval processing (HRApp:SalaryApproval).
3. The HRApp:SalaryApproval role is assigned to the HRApp:Managers access group.
4. A flow action named SalaryChangeApproval is used to approve salary changes in the HRApp application.

Configuration

Do these steps to ensure that only operators with the HRApp:SalaryApproval role have permission to select the SalaryChangeApproval flow action.

1. In Dev Studio, go to the Work & Process tab of the Access Manager landing page by clicking Configure > Org & Security > Access Manager > Work & Process.
2. In the Access group field, enter HRApp:Managers. The tab lists permissions that the HRApp:Managers access group has for various roles, case types, and actions.
3. For the SalaryReview case type and the SalaryChangeApproval flow action, ensure that a green check mark is shown for the HRApp:SalaryApproval role. A green check mark indicates that permission is granted. You can change the value by clicking the icon.
4. Repeat step 2 for HRApp:HRStaff and other access groups that might have access to the SalaryReview case type but cannot approve salary changes. Ensure that a red X is shown for the SalaryChangeApproval flow action of the SalaryReview case type and that the HRApp:SalaryApproval role is not listed, showing that no access is permitted. You can change the value by clicking the icon.

For more information, see Editing authorizations for case type flows and flow actions in a single access group.

Back to top

Controlling access to sections, buttons, and other UI controls

Authorized users approve salary changes by using the SalaryReview case type in the HRApp application. You need to ensure that only managers have access to the button that is used to approve salary changes.

Before you begin

Assume that these steps have already been done:

1. Access groups are defined for human resources staff (HRApp:HRStaff) and managers (HRApp:Managers).
2. A role is defined for salary approval processing (HRApp:SalaryApproval).
3. The HRApp:SalaryApproval role is assigned to the HRApp:Managers access group.
4. The user interface includes a button named pyApproveSalary which a user clicks to approve a salary change.

Configuration

Do these steps to ensure that only operators with the HRApp:SalaryApproval role have permission to click the pyApproveSalary button.

1. Create the CanApproveSalary privilege by doing the following steps:
   1. In Dev Studio, click Create > Security > Privilege.
   2. In the Label field, enter CanApproveSalary.
   3. In the Apply to field, enter SalaryReview, and then click Create and open.
   4. Click Save.
2. Associate the CanApproveSalary privilege with the pyApproveSalary button by doing the following steps:
   1. In Dev Studio, open the section that contains the button pyApproveSalary, and select the pyApproveSalary button.
   2. Click the View Properties icon.
   3. In the Privilege field, enter CanApproveSalary.
   4. Click Submit.
   5. Click Save.
3. In Dev Studio, go to the Privileges tab of the Access Manager landing page by clicking Configure > Org & Security > Access Manager > Privileges.
4. In the Role field, enter HRApp:SalaryApproval, and in the Case type field, enter SalaryReview. The tab lists privileges that apply to this role and case type.
5. Click the Add a privilege icon and in the Privilege field, enter CanApproveSalary.
6. In the dialog box for this privilege, click Full Access, and then click OK.
7. For other roles for the SalaryReview case type, repeat the above steps, but ensure that the CanApproveSalary privilege is not listed or that the privilege is shown with a red X icon. You can change the value by clicking the icon.

For more information, see Granting privileges by using Access Manager.

Back to top

Controlling access to reports

Ensure that only senior executives can run reports in the HRApp application, because these reports include confidential information related to hiring and compensation.

Before you begin

Assume that these steps have already been done:

1. An access group is defined for senior executives (HRApp:SeniorExec).
2. A role is defined for running reports in this application (HRApp:RunAllReports).
3. The HRApp:RunAllReports role has been assigned to the HRApp:SeniorExec access group.

Configuration

Do these steps to ensure that only operators with the HRApp:SeniorExec access group have permission to run all reports in the HRApp application.

1. In Dev Studio, go to the Tools tab of the Access Manager landing page by clicking Configure > Org & Security > Access Manager > Tools.
2. In the Access group field, enter HRApp:SeniorExec. The table lists common tools that can be conditionally available in all applications and the roles that have access in the HRApp:SeniorExec access group.
3. In the table, expand User & manager > Reports and find the value for Provide criteria on reports that is listed for the HRApp:RunAllReports role. Ensure that a green check mark is shown, which means that access is granted. You can change the value by clicking the icon.
4. For access groups that should not be able to run reports, repeat the above steps, but ensure that the HRApp:RunAllReports role is not listed and that any other roles show a red X icon, which means that access is not granted. You can change the value by clicking the icon.

For more information, see Editing tools authorization for a single access group.

Back to top

Validating user input and preventing invalid values

Ensure that only numbers can be entered for employee Social Security numbers.

Before you begin

Assume that in the Employee class, a property named SSN defines the employee’s Social Security number.

Configuration

Do these steps to ensure that only numbers can be entered for the SSN property.

1. In Dev Studio, in the navigation pane, click App, and in the class field, enter Employee.
2. In the navigation area for Employee, expand Data Model > Property and click the SSN property.
3. On the Advanced tab, enter the following values:
   1. To ensure that 9 characters must be entered for SSN values, enter 9 in the Max length field and enter 9 in the Expected length field.
   2. To ensure that only numbers can be entered for SSN values, in the Use validate field, press the Down arrow key and click IsPositiveInteger. The IsPositiveInteger edit validate rule, which is part of Pega Platform™, ensures that only positive integers can be entered. You can create additional edit validate rules for custom edit checks.

For more information, see Property form - Completing the Advanced tab.

Back to top

Controlling access to individual cases

Ensure that only the employee, the employee’s manager, and the human resources staff can view an employee’s timesheet.

Before you begin

Assume that these steps have already been done:

1. A case type named Timesheet is created.
2. In the Timesheet class, the EmployeeID property identifies the employee and the EmployeeManagerID property identifies the employee’s manager.

Configuration

Do these steps to ensure that only the employee, the employee’s manager, and human resources staff can view the employee’s timesheet.

1. In Dev Studio, create an access control policy for an Apply to class equal to Timesheet and Action equal to Read. For more information, see Creating an access control policy.
2. Next to the Permit access if field, click the Open icon to create a new Access control policy condition instance.
3. Create an access control policy condition named CanViewTimesheet to define who can view the timesheet. Enter the following values. For more information, see Creating an access control policy condition.
   1. Policy condition A = Requestor.AccessGroup = HRApp:HRStaff (the user works in human resources)
   2. Policy condition B = Requestor.OperatorID = EmployeeID (the user is looking at the user’s own timesheet)
   3. Policy condition C = Requestor.OperatorID = EmployeeManagerID (the user is the manager of the employee on the timesheet)
   4. Conditional logic = A OR B OR C
4. On the Access control policy instance, in the Permit access if field, enter CanViewTimesheet. Only users who satisfy the condition in step 3d can view the timesheet.

Back to top

Encrypting the values of sensitive properties

In the HRApp application, ensure that the Social Security number and salary properties are encrypted in all Pega Platform data stores (the database and Elasticsearch index files, in memory, and on the clipboard). Ensure that they are decrypted only when they are displayed in the user interface.

Before you begin

Assume that these steps have already been done:

1. An encryption key is defined in a key management system (KMS) outside of Pega Platform.
2. A keystore instance is defined in Pega Platform that refers to the encryption key.
3. The Keystore field in the Application data encryption section of the Data Encryption landing page refers to the keystore in step 2, and the Activate button has been clicked to activate the keystore.
4. In the Employee class, a property named SSN defines the employee’s Social Security number and a property named Salary defines the employee’s salary.

Configuration

Do these steps to ensure that the SSN and Salary properties are encrypted in all Pega Platform data stores, in memory, and on the clipboard.

1. In Dev Studio, create an access control policy for an Apply to class equal to Employee and Action equal to PropertyEncrypt.
2. Click Add property and in the Property field, enter SSN.
3. Click Add property and in the Property field, enter Salary.

For more information, see Configuring the platform cipher and Creating an access control policy.

Back to top

Masking the values of sensitive properties

You need to ensure that sensitive data such as Social Security number are visible only to human resources staff and to the employee.

Before you begin

Assume that in the Employee class, a property named SSN defines the employee’s Social Security number.

Configuration

Do these steps to ensure that the SSN property is masked (that is, not readable) for everyone except human resources staff and the employee.

1. In Dev Studio, create an access control policy for an Apply to class equal to Employee and Action equal to PropertyRead. For more information, see Creating an access control policy.
2. Next to the Permit access if field, click the Open icon to create a new Access control policy condition instance.
3. Create an access control policy condition named CanViewSSN to define who can view the SSN value. Enter the following values. For more information, see Creating an access control policy condition.
   1. Policy condition A = Requestor.AccessGroup = HRApp:HRStaff (the user works in human resources)
   2. Policy condition B = Requestor.OperatorID = EmployeeID (the user is looking at the user’s own employee record)
   3. Conditional logic = A OR B
4. On the Access control policy instance, in the Permit access if field, enter CanViewSSN.
5. Click Add property and in the Property field, enter SSN.
6. In the Restriction Method list, select whether to fully mask all values or to mask only the values in a certain position. For example, you might want to permit viewing the last 4 digits of the SSN. The value is masked for everyone except the users who satisfy the condition in step 3c.

Back to top