Big ACL for Architects
This page explains how Big ACL fits into a modern architecture and how it supports architectural concerns such as consistency, impact analysis, and long-term maintainability.
Modern authorization architectures work best when responsibilities are clearly separated. Big ACL focuses on the Policy Administration Point (PAP), while integrating with the Policy Decision Points (PDPs) and leaving Policy Enforcement Points (PEPs) inside the applications.
The PAP is where policies are designed, modeled, reviewed, versioned, and deployed. This is Big ACL’s role. It encodes business concepts such as resources, roles, relationships, ownership, and constraints in a way that is explicit and analyzable.
In practice, this means that modeling choices live in one place instead of being scattered across services, configuration files, and custom scripts. Policies can be validated, tested, and diffed before they reach any runtime engine.
The PDP evaluates policies in real time. Typical examples include Rego / Open Policy Agent, Cedar / Amazon Verified Permissions, or custom decision engines. A PDP only answers a precise question: given a principal, an action, a resource, and a context, is this allowed?
Big ACL generates policies for these engines, so the decision logic is consistent across different PDP implementations.
The PEP lives inside each application, API gateway, or service. It extracts identity context from tokens or sessions, builds an authorization query, calls the PDP, and enforces the decision.
Big ACL does not replace PEPs. Instead, it ensures that all PEPs talk to PDPs that share the same underlying semantics, avoiding duplicated and inconsistent business logic in each application.
Enterprise architecture repositories contain data that is directly relevant to authorization: applications, ownership, domains, capabilities, and dependencies. Instead of being an external documentation layer, this information can feed into the policy model.
Big ACL can consume data from architecture tools to anchor policies in actual systems and teams. This makes rules more stable than ad-hoc per-application role definitions.
Examples of architecture-driven rules include:
When policies are grounded in architectural data, changes in ownership or system boundaries can be reflected systematically in authorization rules, instead of relying on manual clean-up in each application.
IGA platforms and identity providers manage identities, roles, entitlements, and lifecycle events. Big ACL does not try to replace these systems. Instead, it consumes their data as input to the policy model.
This allows architects to keep a clear separation of concerns: IGA handles who exists and which high-level roles they have, while Big ACL defines how these roles translate into concrete permissions on resources, based on architecture and domain boundaries.
The benefit is a more coherent story for “who can do what”, combining identity lifecycle, application ownership, and authorization rules into one consistent model.
Architects often need to understand the impact of changes before they are deployed. Moving a service, changing ownership, introducing a new PDP, or refactoring a domain boundary all have consequences on access.
Because Big ACL stores policies as structured, versioned artifacts, it becomes possible to compare versions, run checks, and attach policies to applications, domains, and capabilities. This makes impact analysis a repeatable step instead of an informal discussion.
Typical questions include:
Having a single policy model makes these questions answerable using data, not guesswork.