Designing your Access Control Model

The following is taken from the Pega Academy course "Pega 7 for Project Managers":

To design a good, scalable, robust access control model, we need to approach the task the same way we design a good, scalable, robust application: with a lot of up-front analysis to determine our needs, and a lot of planning and review to ensure that those needs are met.

The best security model for a Pega application is object-oriented, just like the application itself. But what does an object-oriented security model look like and how do we describe one in requirements and specifications?

When we develop an object-oriented application, we think of the work our application manages as an object. This object – a case – is described by its state and behaviors, which correspond to the data that describe the case and configured rules that govern its processing.  The term “behaviors” corresponds to authorization, or the permissions granted to or denied the user in our access control model.

When we design an access control model for our application, we want to first determine the types of users that will access the application, and then determine the permissions needed by each group of users. So, we might divide our users into groups such as:

•User – someone who creates a case, such as an expense report.

•Manager – someone who reviews and approves or rejects the case.

•Administrator – someone responsible for managing the functionality of the application itself, rather than the cases it produces.

•Developer – someone responsible for configuring the cases and rules that make up the application.

With a Pega application, we collect users into groups, called access groups. Each access group corresponds to one or more roles. And each role maps to a set of permissions that are granted or denied to the role by an administrator. This makes the system scalable. To add a new user, the administrator only needs to determine the access group in which to include the user. The user then automatically inherits all of the permissions granted to the roles listed for that access group.

So, to describe our access control model, we would create requirements that describe each of the roles. For example, we might create a requirement that users be able to create, update, and withdraw an expense report, while managers are allowed to run reports that describe the expense reports filed for their department, or even the entire organization. We can then discuss the implementation with developers, system administrators, and IT to determine the specific permissions needed to satisfy these requirements.

Implementing your Access Control Model

The following is taken form the Pega Academy course "System Administration Specialist"

To understand access control we need to understand the relationship between objects and rules that make up the implementation of the access control model.  The relationships can be summarized by following diagram:

Let’s start with the operator object, which is an instance of Data-Admin-Operator-ID.  Each Operator ID represents a named user in the system. An operator belongs to an access group.  At a high level the access group defines the application the operator has access to and the roles they use to access it.  For example, “purchase requestor”.

An operator can have multiple access groups, however only one application is active at a given time.  This allows a single operator to be a manager in one application and a regular user in another application. The standard naming convention for an access group is Application Name, colon, application role. For example, “PurchaseFW:PurchaseRequestor”. The access group defines a number of settings but the two most important are the application and roles. The application points to a versioned instance of a Rule-Application, which defines the RuleSets that make up the application.

The access group also defines a list of roles that the access group grants.  Unlike multiple access groups, multiple roles are all in effect at the same time to effectively form a composite role.  The roles listed on the access group are instances of Rule-Access-Role-Name. The ability to have multiple roles improves reusability as a Manager access group can include a User role and a Manager role thus avoiding the need to copy the user privileges to the manager role.

A role itself is really just a grouping for granular access controls and permissions.  These controls are managed at a class level by the access role to object instances, or R-A-R-O rules.  R-A-R-O is short for the rule instance name, Rule-Access-Role-Obj rules. Each R-A-R-O definition applies to a specific class.  It defines what can be done to rules that apply to that class and instances of that class.  So for example, if we want to grant someone the ability to open an instance of a specific work type we set that here.

The access role object definition also defines the privileges granted to the user for that specific class.  Think of a privilege as a token.  The token itself doesn’t really do much, however, other rules can require the token.  For example, a manager may be granted the “CanApprove” privilege which by itself doesn’t provide any functionality.  However if the “Approve” flow action requires CanApprove then only those users with the privilege can execute the flow action.  Privileges can be directly added to a number of specific rule types and can also be programmatically checked by utility functions. When using a privilege with a rule type make sure that is applied to the resource you want to protect not just to a path to that resource. 

Privileges can also be conditionally granted within a R-A-R-O by production level or by Access-When rules.