Skip to main content

Using Attribute-Based Access Control (ABAC)

This guide provides a practical walkthrough of implementing Attribute-Based Access Control (ABAC).

Architecture Note: IAM vs. Downstream Services​

It is important to distinguish between how ABAC is used within the IAM service versus how it is used by downstream services.

  1. Downstream Services (e.g., Finance, Sales):

    • IAM's Role: IAM acts as the Policy Information Point (PIP). It stores user attributes and injects them into headers (via the Gateway or directly to service). IAM does not make access decisions for downstream business logic.
    • Downstream's Role: The downstream service acts as the Policy Enforcement Point (PEP). It reads the attributes provided by IAM and uses its own evaluator to decide access.

  2. IAM Service (Internal):

    • IAM's Role: When accessing IAM's own administrative endpoints (e.g., creating tenants, managing users), IAM acts as both the PIP and the PEP. It uses its InternalPolicyEvaluator to enforce security on its own API.

This guide focuses on Scenario 2: Configuring IAM to protect its own resources.

Scenario: Securing Tenant Creation​

In this example, we will secure the IAM endpoint POST /api/iam/v1/tenants so that it can only be accessed by users who have the attribute department set to "platform_engineering".

Step 1: Define the Policy​

Policies are defined in the IAM service's configuration file.

Add the following entry to your service configuration:

policies:
  - path: "/api/iam/v1/tenants"
    method: "POST"
    # The CEL rule:
    # Check if 'department' exists and equals 'platform_engineering'
    rule: >
      has(attributes.department) && attributes.department == 'platform_engineering'

Step 2: Define Attribute Validation (Optional)​

To ensure data integrity, you can define a schema for these attributes using the YAMLSchemaValidator.

Update your attribute validation schema (YAML):

attributes:
  department:
    type: string
    allowed_values:
      - "platform_engineering"
      - "sales"
      - "hr"

Step 3: Assign Attributes to a User​

Now, we need to assign the required attribute to the user who needs access.

Prerequisites:

  • USER_ID: The ID of the user.
curl -X POST "http://localhost:1111/api/iam/v1/users/$USER_ID/attributes" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <valid_token>" \
  -d '{
    "key": "department",
    "value": "platform_engineering"
  }'

Step 4: Verification​

When this user attempts to create a new tenant via POST /api/iam/v1/tenants:

  1. The request is intercepted by the IAM service's PolicyMiddleware.
  2. The service loads the user's attributes: {"department": "platform_engineering"}.
  3. The InternalPolicyEvaluator executes the CEL rule.
  4. The rule evaluates to True, and the tenant creation proceeds.

If a user from department: "sales" attempts the same action, the rule evaluates to False, and they receive a 403 Forbidden.