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.
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
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.
- Restrict who can use a flow action
It is a best practice to limit flow actions to the users who really require them.
- 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.
- 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.
- 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.
- Validating user input and preventing invalid values
Ensure that only numbers can be entered for employee Social Security numbers.
- 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.
- 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.
- Masking the values of sensitive properties
You need to ensure that sensitive data such as Social Security number (SSN) are visible only to human resources staff and to the employee.
- Securing your application for mashup communication
Define the external URLs that are allowed to access Pega Platform so that the host page can communicate with the mashup gadget page, if you use the mashup feature to embed Pega Platform content in an external application.
- Securing Cosmos React-UI applications
If your application uses a Cosmos React-UI, then it authenticates operators using one of the newer (PRAuth) types of Pega Platform Authentication schemes. Requests are typically submitted using a URL that includes an application alias, for example: https://<host>:<port>/prweb/app/Alias. For an unauthenticated user, this type of request presents a page showing a list of authentication services available for login to the application. If the user chooses Basic authentication, then the password, lockout, and CAPTCHA policies are