Attribute-based access control (ABAC) security model
Attribute-based access control (ABAC) is used to control access to an object (Case, report, property) by comparing characteristics of the object to attributes of the operator requesting access to the object. The Access Control Policies determine whether specific users can access the objects, doing so independently of an Access Group, and may leverage the inheritance functionality of Pega Platform™. For example, you can assign the attribute Customer to a Case to decide whether a user has permission to delete a Case based on whether or not the Customer is on a list of customer names for which the user is responsible.
Restrictions that broadly limit users by their membership in Access Group are configured through role-based access control (RBAC). In contrast, ABAC affords more granular control over row-level and column-level security based on defined user attributes. ABAC supplements and extends the security capabilities of RBAC. Use cases that are more suited to an ABAC approach include those that redact information from users without an appropriate clearance level or allow users to perform Actions only if they are assigned to a particular department. The following table illustrates using the Clearance Level attribute to control task access:
To configure attribute-based access control in your application, first, determine the attributes used for access control purposes. Then, define the Access Control Policy Condition that compares the object's attribute values to the user's. Finally, define the Access Control Policy to specify the Action that is controlled by the evaluation of the Condition logic.
Tip: If you have disabled ABAC in the past, you can re-enable ABAC by updating a dynamic system setting. In Dev Studio, search for the dynamic system setting EnableAttributeBasedSecurity and open it. In the Value field, enter true and click Save to enable attribute-based access control.
Access Control Policy Conditions
Use ABAC to restrict access to specific instances of classes using policies that are not role-based but instead based on other attributes known about users. For example, each user might have a Security Classification, which in itself applies limitations on which data the users have the authorization to access.
Access Control Policies that specify the type of allowed access enforce the restrictions in ABAC. For each policy, one or more Access Control Policy Conditions determine whether or not to grant access.
After you configure the attributes that you intend to use, configure the Access Control Policy Condition Rule form (Rule-Access-PolicyCondition). In an Access Control Policy Condition Rule form, you define a set of filters and add logic that combines Conditions for the Access Control Policy. The Rule form describes the Conditions in which the access type is granted to the protected object. If the Conditions in the Access Control Policy Condition Rule form are met, users can perform the Actions that are defined in the Access Control Policy. For example, Conditions that are defined on an Access Control Policy Condition Rule form can ensure that only the manager for a specific team of support agents can approve service credits processed by members of that team.
On the Access Control Policy Condition Rule form, you can enter multiple sets of Conditions with filter logic values. Each filter logic specification is associated with an Access When Rule. Each set of filters compares a Case attribute (property value) to any Clipboard property value at runtime that you want. This comparison value typically represents information about the user who attempts to access the protected object.
Note: For more information about how Access When Rules work with attribute-based access control, see Understanding Access When Rules.
In the center of the following image, slide the vertical line to compare RBAC and ABAC:
Access Control Policies
After you configure the Access Control Policy Condition Rule form, configure an Access Control Policy Rule form (Rule-Access-Policy). In the policy form, you choose from one of the following Actions that limit what the user is allowed to do when accessing an object:
- Read: The user can open a Case that meets the policy Conditions or view data for the Case in lists, reports, searches, and so on.
- Update: The user can create a Case that meets the policy Conditions or update data for a Case that meets the policy Conditions.
- Discover: The user can see limited information (defined by a developer) about a Case that does not meet Read policy Conditions but does satisfy the Discover policy Conditions.
- Delete: The user can delete a Case that meets the policy Conditions.
- PropertyRead: The user has restricted visibility to property values, including property values with read and update access.
- PropertyEncrypt: The property is encrypted in the database, Clipboard, logs, and search indexes. If no PropertyRead policy restricts the visibility of the property, then the decrypted property value is visible to the user in a UI control.
You can define Access Control Policies for only the Assign-, Data-, Index-, and Work- classes in the Pega Platform database, and Access Control Policies can inherit from multiple classes. The policy Conditions combine from all relevant policies and allow access only when all policy Conditions are satisfied. Unlike RBAC, ABAC policies leverage the inheritance functionality.
If an ABAC policy grants access, RBAC may still deny access. In this Case, access would not be granted.
Note: To learn how to review Access Control Policies, see Reviewing Access Control Policies.
Assignment of attributes
To configure the attribute-based access control in your application, define the user and object attributes that you use. You can define user attributes in various ways. For example, if you use an external identity provider (IDP) for authenticating users, you can assign the attributes to users in the information stored in the IDP. You then map those attributes to the Pega Platform application to the user's operator record or a requestor-level Data Page. Optionally, add an attribute for an object by adding the attribute value to a property field of the object's class.
You can use three data types to represent an attribute: a single string value, a list of string values, and a numerical value. An encrypted field cannot be used.
Single string value
You can use string type properties to define specific attributes that must match before granting access to a user. In the following example, access is granted to the user who has a Security Clearance of Top Secret:
Operator.SecurityClearance = “Top Secret”
List of string values
You can evaluate a comma-separated list of string values using the special comparison operators All of and One of. For example, if security policies require a Security Clearance level of Top Secret or Secret, the One of operator grants access to users with either attribute. The All of operator evaluates all attributes in the list of string values and grants access only if all attributes are present.
Note: Comparison values referenced in policy Condition filters must be existing Requestor properties or requestor-scoped Data Pages.
You can represent attributes as a numerical data type. Attribute values must be mapped to a top-level numeric property on both the object (Case) and the subject (operator). This is helpful if security specifications require an access hierarchy. For example, using the Top Secret, Secret, and Unclassified attributes, you can create the following numerical mapping:
You can then use a single Condition with a numerical comparison to determine the access level:
Operator.SecurityClearance >= .SecurityClearance
Check your knowledge with the following interaction: