Authorization design considerations

Authorization is about who can do what and who can see what in the application. In general, give the minimum necessary access to perform the job. This rule applies to both 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 about RBAC and ABAC, see 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 that the developer roles require.
• Secure developer access. Not every developer should have administrator rights. Your organization might 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 you define access groups. Some organizations enforce a deny-first policy. In this model, users require explicit 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. 

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.

Check your knowledge with the following interaction: