Attribute-based Access Control (ABAC)

Learn how to set up ABAC conditions in AuthZ

Pangea’s AuthZ service allows you to extend the RBAC and ReBAC authorization model with Attribute-Based Access Control (ABAC) , enabling more dynamic, granular, and context-sensitive permission management. This is useful for enforcing specific access rules that depend on attributes of the subject (e.g., user), object (e.g., resource), or environment (e.g., time of day, device type, or the user's IP address).

You can add, remove, or modify attribute-based policies for any role permission, whether a global RBAC role or a resource-specific ReBAC role, by creating ABAC functions for a resource type on the Roles & Access page in the Pangea User Console. These functions can be reused and combined across different permissions for the same resource type and will be invoked whenever the permission is checked.

(Optional) Prerequisites

To follow the examples below, initialize or reset your authorization schema using the Application Dashboard option under AuthZ General settings in the Pangea User Console .

On the AuthZ Overview page, copy the Default Token and Domain from the Configuration Details section, and save them in environment variables:

export PANGEA_DOMAIN="aws.us.pangea.cloud"
export PANGEA_AUTHZ_TOKEN="pts_nqkkzx...rgemva"

Promote Erlich to the feature manager role for the compression feature on the Assigned Roles & Relations page in the Pangea User Console.

Assign Role or Relation dialog

Create ABAC function

1. Navigate to the Roles & Access page and click the filter icon next to a permission that has been checked.

   

   Link to ABAC conditions editing page

2. The filter icon for the permission becomes blue, and the Attribute-based conditions for a role permission screen opens on the right. Click + Function.

   You have to create your first function. After saving your functions, the + Function button will let you select an existing one.

   

   Attribute-based conditions editing page

3. In the Create Function for <resource-type> dialog, provide a descriptive Name for your function. Note that this name cannot be changed after the function is saved.

   

   Create ABAC function dialog

A function evaluates its conditions using attribute data at runtime to determine whether permission to act is granted. You can add, remove, or modify individual conditions, which are combined using AND logic.

The next section explains how to set up function conditions.

Add ABAC conditions

4. Click + Condition to add a new condition.

   In the right and left parts of each condition, specify a variable path pointing to the request data submitted to the /v1/check endpoint, or provide a value for comparison.

   Variables paths

   To reference a request attribute value using the variable path, use the suggested data structure from the dropdown in a condition input.

   

   Specify variable path for a condition attribute

   Hover over the information icon next to each variable path type for a detailed description and examples.

   Request

   Select attributes.{name} under Request (or type in request.attributes.) and add an attribute name to reference properties in the "attributes" parameter of a check request.

   For example:

   

   Attribute-based conditions

   Attribute references are marked with VAR. If you use a hard-coded value for comparison, its interpreted type is labeled on the right as STR, BOOL, and NUM. Hover over a label to see the description of the type.

   When you Update and Save your function, these conditions are defined using the request.attributes.ip_verdict and request.attributes.is_work_laptop paths would be met in the following request:

   POST: /v1/check for attribute-based condition

   curl --location "https://authz.$PANGEA_DOMAIN/v1/check" \
   --header 'Content-Type: application/json' \
   --header "Authorization: Bearer $PANGEA_AUTHZ_TOKEN" \
   --data '{
     "resource": {
       "type": "feature",
       "id": "compression"
     },
     "action": "configure_feature",
     "subject": {
       "type": "user",
       "id": "erlich"
     },
     "attributes": {
       "ip_verdict": "Benign",
       "is_work_laptop": true
     }
   }'

   The response to a request that includes attribute-based information will be the same as a role and/or relationship-based check:

   /v1/check response

   {
     "status": "Success",
     "summary": "Allowed",
     "result": {
       "allowed": true,
       "depth": 2,
       "schema_id": "pzs_ckpw7xrhppyhsbaeocxeghtarwl6ygwj",
       "schema_version": 12
     },
     ...
   }

   Object

   Under the Object label in the condition dropdown, you can see the paths for the resource type for which you set the permission.

   To reference the resource ID in your check request, select id. Alternatively, type in object.id to reference the resource ID. The ID value will be compared against the resource.id value in the request body sent to the check endpoint.

   To reference resource-specific attributes in your check request, select attributes.{name} under the resource type label for which you set the permission. Alternatively, you can type object.attributes. and add the attribute name to reference the resource-specific properties. In the "attributes" parameter of a check request, the resource is identified by a key that consists of the resource type and ID, separated by a colon.

   For example:

   

   Resource-specific ABAC condition

   When you Update and Save your function, these conditions will be met in the following request:

   POST: /v1/check for attribute-based condition

   curl --location "https://authz.$PANGEA_DOMAIN/v1/check" \
   --header 'Content-Type: application/json' \
   --header "Authorization: Bearer $PANGEA_AUTHZ_TOKEN" \
   --data '{
     "resource": {
       "type": "feature",
       "id": "compression"
     },
     "action": "configure_feature",
     "subject": {
       "type": "user",
       "id": "erlich"
     },
     "attributes": {
       "ip_verdict": "Benign",
       "is_work_laptop": true,
       "types": [
         "middle-out",
         "edge-in"
       ],
       "feature:compression": {
         "type": "middle-out"
       }
     }
   }'

   Request Subject

   Select id under Request Subject (or type in request.subject.id) to reference the subject ID. The ID value will be checked against the subject.id value in the request body sent to the check endpoint.

   Select type under Request Subject (or type in request.subject.type) to reference the subject type. The type value will be checked against the subject.type value in the request body sent to the check endpoint.

   Select attributes.name under <resource-type> (or type in request.subject.attributes.) and add an attribute name to reference the subject-specific properties. In the "attributes" parameter of a check request, identify the subject using a key that consists of the subject type and ID separated by a colon.

   For example:

   

   Subject-specific ABAC conditions

   When you Update and Save your function, these conditions will be met in the following request:

   POST: /v1/check for attribute-based condition

   curl --location "https://authz.$PANGEA_DOMAIN/v1/check" \
   --header 'Content-Type: application/json' \
   --header "Authorization: Bearer $PANGEA_AUTHZ_TOKEN" \
   --data '{
     "resource": {
       "type": "feature",
       "id": "compression"
     },
     "action": "configure_feature",
     "subject": {
       "type": "user",
       "id": "erlich"
     },
     "attributes": {
       "ip_verdict": "Benign",
       "is_work_laptop": true,
       "types": [
         "middle-out",
         "edge-in"
       ],
       "feature:compression": {
         "type": "middle-out"
       },
       "user:erlich": {
         "group": "staff"
       }
     }
   }'

   Variables and values

   The comparison values can be hard-coded in the conditions and provided in the request to the /v1/check endpoint, as shown in the examples above:

   • The IP reputation data can be obtained by your application using the IP Intel service.
   • Your application can check the user's session information and pass in their hardware and other environment details.
   • etc.

   You can also reference both values in a condition dynamically, using the variable path.

   For example:

   

   Compare resource-specific and subject-specific attributes using variable path

   When you Update and Save your function, these conditions will be met in the following request:

   POST: /v1/check for attribute-based condition

   curl --location "https://authz.$PANGEA_DOMAIN/v1/check" \
   --header 'Content-Type: application/json' \
   --header "Authorization: Bearer $PANGEA_AUTHZ_TOKEN" \
   --data '{
     "resource": {
       "type": "feature",
       "id": "compression"
     },
     "action": "configure_feature",
     "subject": {
       "type": "user",
       "id": "erlich"
     },
     "attributes": {
       "ip_verdict": "Benign",
       "is_work_laptop": true,
       "types": [
         "middle-out",
         "edge-in"
       ],
       "assignees": [
         "richard",
         "erlich",
         "jack"
       ],
       "feature:compression": {
         "type": "middle-out",
         "department": "3D-video"
       },
       "user:erlich": {
         "group": "staff",
         "department": "3D-video"
       }
     }
   }'

   Operators

   The left and right parts will be compared using the selected operator, such as ==, !=, >, <, >=, <=, or in.

   note

   For restrictive and predictable results, use explicit value operators like == to ensure that conditions are only met when the value is present in the request context. An implicit operator, such as !=, may return true when an attribute value is not missing from the request data.

   note

   The in operator behaves like contains when comparing strings. For example, request.subject.id in jackerlichrichard would return true.

5. Click Update to close the Create Function for <resource-type> dialog.

6. Click Save either on the Roles & Access or Attribute-based conditions for screen to apply your changes.

   

   Save function for a role permission

Reuse function

Reusing functions across different role permissions saves time, ensures consistency, reduces duplication, and simplifies authorization management. Any updates made to a function will automatically propagate to all policies using it.

To apply an existing function to a different role permission, click its filter icon, click the + Function button on the Attribute-based conditions screen, and select the existing function.

Select the function for a role permission

note

Making reusable functions saves time and ensures consistency across different authorization policies, reduces duplication, and simplifies the management of your authorization logic. This approach also makes it easier to update policies, as changes to a function automatically propagate to all policies that use it.

Add, modify, or delete conditions and functions

1. After updating a function, click the pencil icon in the Attribute-based conditions for screen to modify its conditions. At the bottom of the Edit Function for <resource-type> dialog, you will see the function description.

   

   Edit ABAC function dialog

2. Use the + Function button to combine functions for a role permission using AND logic.

3. To remove a condition or a function from a role permission use the circular - buttons.

   

   Remove buttons

4. After making any changes in the Create/Edit Function for <resource-type> dialog, click Update.

5. Click Save to apply your changes.

6. To remove a function from the schema and all permissions using it, click + Function in the Attribute-based conditions for screen for a permission that doesn't use the function, then click the trash bin icon next to the function name. The Remove function dialog will display a list of permissions associated with the function.

   

   Remove ABAC function dialog

Was this article helpful?

Contact us