Policy Evaluation

The IAM service includes an internal policy evaluator that allows administrators to define fine-grained access control rules using the Common Expression Language (CEL).

Overview

The InternalPolicyEvaluator intercepts requests to specific resources and evaluates a configured logic rule against the user's attributes. If the rule evaluates to true, access is granted.

Note: This internal evaluator is intended for self-contained policy enforcement. A future update will introduce a PolicyServiceEvaluator adapter to integrate with an external, centralized policy service.

Configuration

Policies are defined in the service configuration. Each policy targets a specific API endpoint and HTTP method.

Policy Structure

Field	Description	Example
path	The URI path of the resource.	/api/finance/reports
method	The HTTP method to match.	GET
rule	A CEL expression defining the access logic.	attributes.department == 'finance'

Evaluation Logic

1. Match: The evaluator checks if the incoming request matches a defined path and method.
2. Evaluate: If a match is found, the associated CEL rule is executed.
3. Decision:
   • If the rule returns true, access is allowed.
   • If the rule returns false or errors, access is denied.
   • If no policy matches the request path/method, access is allowed by default (open by default, restricted by exception).

Writing CEL Rules

Rules are written using Common Expression Language (CEL). The evaluator provides the following variables to the CEL environment:

Variables

• attributes: A map containing the authenticated user's attributes (e.g., roles, department, clearance level).

Examples

1. Role-based Access Require the user to have the 'admin' role.

has(attributes.role) && attributes.role == 'admin'

2. Attribute-based Access (ABAC) Require the user to be in the 'finance' department AND have a level greater than 3.

attributes.department == 'finance' && attributes.level > 3

3. Boolean Logic Allow if the user is an admin OR (is in sales AND the status is active).

attributes.role == 'admin' || (attributes.department == 'sales' && attributes.status == 'active')

Configuration Example

Below is an example of how policies might be structured in the configuration file (YAML format):

policies:
  - path: "/api/admin/system"
    method: "POST"
    rule: "has(attributes.role) && attributes.role == 'super-admin'"

  - path: "/api/hr/salary"
    method: "GET"
    rule: "attributes.department == 'hr' || attributes.role == 'auditor'"