Authorization design considerations

Authorization is about who can do what and who can see what in the application. In general, give the minimum access needed to perform the job. This rule applies to both end users and developers.

As you are designing your authorization scheme:

• Create a matrix of access roles, privileges, and attributes to be secured. Determine where to use role-based access (RBAC) and attributed-based controls (ABAC) in your authorization scheme. For more information on RBAC and ABAC, see the Pega Community article on Authorization.
• Define security on reports and attachments and background processes. Background processes such as agents need an associated access group.
• Determine the level of auditing (history) required for each case type. Write entries only when necessary. Otherwise, you can impact performance when history tables become too large.
• Determine what level of rule auditing is required for developer roles.
• Secure developer access. Not every developer should have administrator rights. Your organization may also have restrictions on which developers can create activity rules or SQL connector rules.
• Ensure that developers cannot update passwords for other users.
• Use the Deny Rule security mode when defining access groups. Some organizations enforce a deny first policy. In this model, users must be explicitly granted privileges to access certain information. If you have similar requirements for the application you are designing, review the usage of the Rule Security Mode setting on each access group. For more information on the use of this setting, see the Pega Community article Setting role privileges automatically for access group Deny mode.

Grasping the importance of security design and analysis of your application is essential. For an overview, refer to the Security Checklist for Pega Platform applications throughout the design of your application.