Policy Management

Policy management is the discipline of defining, storing, evaluating, and governing the rules that control access to resources. In modern IAM architectures, policies are the central mechanism for translating business requirements into enforceable access controls, and they must be managed with the same rigour as application code.

Well-managed policies provide consistent enforcement across heterogeneous systems, clear audit trails for compliance, and the agility to respond to changing business and security requirements.

The Policy Architecture

The XACML standard defines the canonical policy architecture, which has been widely adopted beyond XACML itself:

Policy Decision Flow — Full Context

┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐
│  User   │────→│   PEP   │────→│   PDP   │────→│   PIP   │
│(Subject)│     │(Enforce)│     │(Decide) │     │  (Attr) │
└─────────┘     └─────────┘     └─────────┘     └─────────┘
                     │               │               │
                     │          ┌────┴────┐     ┌────┴────┐
                     │          │  PAP    │     │  HR DB  │
                     │          │(Policies)│     │  AD/LDAP│
                     │          └─────────┘     └─────────┘
                     ▼
               ┌──────────┐
               │  Access  │
               │  Grant/  │
               │  Deny    │
               └──────────┘

Policy Decision Responses

Policy combining algorithms determine the final decision when multiple rules apply:

Policy Lifecycle

Policies should be managed through a defined lifecycle, analogous to software development:

Design → Develop → Test → Deploy → Monitor → Retire
   ↑                                        │
   └────────────────────────────────────────┘
                   Review

Phase 1: Design

• Identify the business requirement driving the policy change
• Define the policy objective in plain language
• Identify required attributes and their data sources
• Assess impact: which users, resources, and actions will be affected?
• Document the policy intent and expected behaviour

Phase 2: Develop

• Write the policy in the chosen policy language (XACML, Rego, Cedar)
• Structure policies for clarity and maintainability
• Define test cases covering Permit, Deny, and edge cases
• Store the policy in version control (Git)

Phase 3: Test

Phase 4: Deploy

• Deploy to staging environment for validation
• Run canary deployment (apply to 5% of traffic, monitor for issues)
• Full rollout with rollback capability
• Update policy version in the policy repository

Phase 5: Monitor

Phase 6: Review and Retire

• Periodic policy certification (annual or quarterly)
• Review policy effectiveness — is it achieving the intended outcome?
• Identify orphaned policies — no longer referenced by any application
• Rationalise overlapping policies — merge or replace
• Archive retired policies for audit reference

Policy Languages Comparison

Rego (OPA) — The Cloud-Native Standard

Rego is the policy language for Open Policy Agent. It uses a rule-based, declarative approach:

package api.authz

# Default deny
default allow = false

# Admin override — full access for admin users
allow {
    input.user.roles[_] == "admin"
}

# Self-service — users can read their own data
allow {
    input.method == "GET"
    input.path == sprintf("/users/%s", [input.user.id])
}

# Project-based access — users can read project resources for projects they belong to
allow {
    input.method == "GET"
    input.path == sprintf("/projects/%s", [input.project.id])
    data.projects[input.project.id].members[_] == input.user.email
}

Cedar (AWS) — The AWS-Native Option

Cedar is a purpose-built policy language developed by AWS for use in AWS Verified Permissions and Amazon Verified Permissions:

// Permit policy: allow user to read their own documents
permit (
    principal in [user::"alice"],
    action in [Action::"read"],
    resource in [Document::"report.docx"]
) when {
    resource.owner == principal
};

// Forbid policy: deny access to classified documents
forbid (
    principal,
    action,
    resource
) when {
    resource.classification == "confidential" &&
    principal.clearance_level < 5
};

Policy Repository and Versioning

Policies should be stored in a centralised, version-controlled repository:

Recommended approach: Store policies in Git with the following structure:

policies/
├── production/
│   ├── api-authz/
│   │   ├── admin.rego
│   │   ├── self-service.rego
│   │   └── project-access.rego
│   ├── data-access/
│   │   ├── pii-protection.rego
│   │   └── row-level-security.rego
│   └── network/
│       └── network-policies.rego
├── staging/
│   └── (mirrors production structure)
├── test/
│   ├── api-authz_test.rego
│   └── data-access_test.rego
└── policy-metadata.yaml

Enterprise Policy Management Platforms

Key Takeaways

• The XACML architecture (PAP, PDP, PEP, PIP, PRP) is the canonical framework for policy-based access control — adopted beyond XACML itself by OPA, Cedar, and other modern systems
• Policies return four possible decisions: Permit, Deny, NotApplicable, or Indeterminate — with combining algorithms (deny-overrides, permit-overrides, first-applicable) resolving conflicts
• The policy lifecycle mirrors software development: design → develop → test → deploy → monitor → review → retire, with each phase requiring specific tooling and practices
• Rego (OPA) is the leading policy language for cloud-native environments; Cedar (AWS) is the leading option for AWS-native architectures
• Policies should be stored in Git with a structured repository, enabling versioning, review workflows, CI/CD testing, and rollback
• Enterprise policy platforms range from XACML-based (Axiomatics) for regulated industries to OPA/Styra for cloud-native and Zanzibar for relationship-based models