Chapter 1. System Components

Architecture boundaries, component inventory, working principles, and exception handling

1.1 System Architecture

The authorization system is structured into three distinct deployment zones — Core, Optional, and Supporting — each with clearly defined responsibilities and boundaries. This separation enables teams to implement the minimum viable authorization layer first (Core zone), then progressively add context-awareness (Optional zone) and integrate with enterprise infrastructure (Supporting zone). The architecture follows a defense-in-depth model where enforcement occurs at multiple layers: the API gateway, individual service middleware, and the data access layer.

The Core zone contains the minimum components required for a functioning, auditable RBAC system. The Optional zone adds ABAC capabilities, data-level security, approval orchestration, and risk scoring. The Supporting zone represents external dependencies that the authorization system integrates with but does not own — including the identity provider, MFA service, ITSM platform, SIEM, key management, and infrastructure services.

Figure 1.1: Component Architecture with Core/Optional/Supporting Zones — Three-zone deployment model showing core components, optional extensions, and supporting infrastructure with request and decision paths

Module Relationships

Each module in the Core zone has a precisely defined role and interface contract. The Identity Adapter ingests claims from the IdP and SCIM provisioning system, normalizing them into internal subject identifiers and attribute sets. The Permission Registry acts as the single source of truth for all resource and operation definitions, maintaining versioned permission IDs that are referenced by all other components. The Role Service stores the role catalog, role-to-permission mappings, and role bindings to subjects, publishing change events when bindings are modified.

The PDP Engine sits at the center of the authorization decision flow, receiving the normalized request tuple (subject, action, resource, context) and evaluating RBAC grants, ABAC conditions, and data-level constraints to produce an allow/deny decision with associated obligations. The PEP exists at both the API gateway and within individual service middleware, ensuring that enforcement occurs at multiple layers and cannot be bypassed by calling services directly. The Audit Emitter standardizes authorization events from all enforcement points into a consistent schema before forwarding them to the message bus.

Data and Control Flows

The control flow follows a strict path: Gateway PEP intercepts the request, forwards it to the PDP for decision evaluation, and then either allows the request to proceed to the target service or returns a deny with reason code. The Service PEP provides a second enforcement layer within each microservice, ensuring that even internal service-to-service calls are subject to authorization checks. This defense-in-depth approach prevents bypass scenarios where an internal caller might circumvent the gateway.

The data flow is optimized for performance through short-TTL caching of entitlement data (role-to-permission expansions) in a distributed cache layer. Cache invalidation events are published by the Role Service whenever bindings change, ensuring that revocations propagate within the configured TTL window. Audit events are emitted asynchronously to a message bus to avoid adding latency to the critical path, with the SIEM forwarder consuming events and indexing them for near-real-time detection.

1.2 Components & Functions

The component inventory defines the full set of modules required to operate the authorization system, along with their engineering KPIs and the risks introduced when components are misconfigured or mismatched. Each component has clearly defined inputs, outputs, and measurable performance targets that serve as acceptance criteria during deployment and ongoing operations.

Figure 1.2: Component Inventory Board — Card-based infographic showing all authorization system components with inputs, outputs, and KPIs

1.3 Working Principles

Startup Sequence

During system startup, the authorization components initialize in a specific order to ensure that enforcement is active before any requests are processed. The Permission Registry loads the current version of the permission taxonomy into cache and validates the schema against the expected structure. The Role Catalog and Binding Manager warm their caches for high-traffic tenants to minimize cold-start latency. Connectivity to all external dependencies — IdP, MFA, ITSM, SIEM, and KMS — is verified before the PEP enforcement is activated.

The PEP is configured to operate in "fail-closed" mode for privileged actions by default, meaning that if any required dependency is unavailable, the system denies the request rather than allowing it through. For read-only dashboards where business continuity requires availability, a "fail-safe" mode may be explicitly configured with appropriate compensating controls documented and approved.

Normal Operation

During normal operation, every incoming request is normalized into a tuple of (subject, action, resource, context) before being evaluated by the PDP. The PDP computes effective permissions by combining RBAC grants (role-to-permission mappings), ABAC conditions (context constraints such as network zone, device trust, and time window), and data-level filters (row and column restrictions). If the evaluation produces obligations — such as requiring MFA step-up, an approval ID, or PAM session recording — these are returned to the PEP as enforcement requirements that must be satisfied before the operation proceeds.

Every authorization decision and its execution result generate audit events containing the request details, decision outcome, reason code, and any obligations applied. These events are emitted asynchronously to the message bus and forwarded to the SIEM for near-real-time detection and long-term retention.

Exception Chains