Securing persona-based access

From PegaWiki
Securing application access to specific personas / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Securing persona-based access

Description Best practices to follow when setting up an application and allowing certain personas to access certain information.
Version as of 8.4
Application Pega Platform
Capability/Industry Area Security

The information here has not been covered on Pega Community.

Follow these leading practices when setting up an application and allowing certain personas to access certain information:

  • Use role dependencies instead of the old method of copying default roles and modifying them. Create roles that are dependent on the default Pega Platform or application roles for Pega Platform, and then implement changes to these dependent roles. When using the role dependencies, your application’s roles will automatically inherit changes made to the default roles in future releases and during updates.
  • The authorization model of your application should implement the principle of least privilege access, where users with a persona only have access to the data and features of the application that are required to perform their jobs, and nothing else. Data access and features required to perform certain tasks are described below:
    • If a persona does not need read, write, or update access for users with that persona to do their jobs, they should not have that access. The role for the persona can be modified to contain Rule-Access-Role-Obj (RAROs) for unnecessary classes with zeros for all settings, and no privileges.   
    • Prevent access to application functions and features, such as reporting, if the persona does not really require them. 
    • The principle of least privilege access should of course be applied in the attribute-based access control (ABAC) model where access to individual cases or individual properties is configured.  For example, a user can be prevented from accessing cases they have not created, modified, or been assigned to work on.  And of course, encryption and obfuscation or masking policies should be defined to protect especially sensitive PII and other data, such as social security numbers or account numbers, using PropertyEncrypt and PropertyRead access control policies.

For more information, see: