application_security/architecture

265 notes in this subject, read out of this brain and free to use. This is page 5 of 5.

Kernel-Level Authentication pattern overview

Kernel-Level Authentication involves performing authentication at the operating system kernel level using cryptographic identities attached to either a service or a machine/node the service is running on. Implementation is based on protocols such as IPSec or WireGuard, where the identity of a peer is cryptographically verified on each exchanged packet at layer 3 (network layer), with enforcement transparent to applications.

Kernel-Level Authentication pattern pros

Kernel-Level Authentication is transparent to applications with no required authentication logic in services, protocol-agnostic applying to all traffic types not just HTTP, enables fast connection setup with strong isolation guarantees, and provides strong workload identity with verification tied directly to the transport channel, reducing risk of spoofing or replay and supporting Zero Trust networking models.

Kernel-Level Authentication pattern cons

Kernel-Level Authentication is not suitable for layer 7 application-level authentication since identities are tied to workloads or nodes only and cannot convey user-specific identity attributes, has limited observability confined to connection-level data such as source/target workloads lacking insight into user-driven actions, and requires infrastructure complexity including robust automation for identity management and OS- or kernel-level authentication policy enforcement mechanisms via eBPF.

Authentication patterns operational considerations comparison

Service-Level Embedded has high configuration and implementation burden, high operational overhead, and application-specific observability scope. Service-Level Code-Mediated has medium burden and overhead with IDP plus application-specific observability. Service-Level Proxy-Mediated has medium burden and high operational overhead with proxy plus application observability. Edge-Level has low burden and overhead with centralized proxy observability. Kernel-Level has low-medium burden and high operational overhead with network-level only observability.

Authentication patterns security considerations

Security risks increase significantly when authentication logic and credentials are handled directly within application code. Centralized enforcement approaches at the IDP, edge, or within the OS kernel help limit exposure, enforce stronger boundaries, and reduce misconfiguration risk. However, trust leakage must be prevented to enforce the principle of least privilege. Reliable authorization decisions depend not only on where authentication occurs but also on how identity information is propagated and verified downstream using trustworthy, tamper-resistant propagation.

Input data locality: three levels

Input data locality defines the boundaries of data relevance and reuse. Three levels are common: Service-Local Data (relevant only within a single service, such as service-specific configuration flags or ephemeral session attributes), Domain-Level Data (shared across multiple services within the same bounded context or business domain, such as ownership metadata or customer account status), and Organization-Level Data (relevant across domains or entire systems, such as regulatory data classification or tenant-level subscription tier).

Input data cardinality: three levels

Input data cardinality refers to the number of distinct attributes across all subjects or resources. High cardinality has many distinct data items often tied to individual requests, such as real-time risk scores or geo-IP information. Medium cardinality has a moderate number of distinct items typically shared across sets of subjects or resources, such as project IDs. Low cardinality has few distinct items that are usually stable and broadly reusable, such as environment labels (production or staging), deployment regions, or business unit identifiers (HR, Finance, R&D).

Input data freshness: three levels

Input data freshness describes the maximum acceptable delay between an attribute value changing and that change being reflected in authorization decisions. High freshness means changes must be reflected immediately or within seconds, such as real-time risk scores, breach detection flags, or emergency account locks. Medium freshness means changes should be reflected within minutes to hours, such as feature toggles or subscription tiers. Low freshness means changes can be reflected with delays of hours to days, such as slowly changing organizational classifications or planned configuration changes.

On-Demand Data Pull strategy: definition and characteristics

On-Demand Data Pull is a data distribution strategy where the PDP (Policy Decision Point) fetches required data from PIPs (Policy Information Points) at the time of policy evaluation, typically via APIs or database queries. PDPs supporting this option often allow configurable caching of the pulled data.

On-Demand Data Pull strategy: advantages

On-Demand Data Pull ensures data freshness by retrieving the latest attribute values from PIPs at evaluation time. It enables handling of high-cardinality data without preloading large datasets into the PDP. It requires no data synchronization mechanisms since the PDP always queries PIPs directly. Since the PDP does not need to maintain a local copy of data, the memory or storage demand of the PDP is low. Governance responsibility is at the policy author — the policy defines where the data is retrieved from.

On-Demand Data Pull strategy: disadvantages

On-Demand Data Pull increases latency due to network calls to PIPs during evaluation, which negatively impacts performance, especially for high-throughput systems. It introduces dependencies on external systems, reducing resilience if PIPs are slow or unavailable, potentially leading to cascading failures, degraded service, or fallback decisions. It limits usable PDP types, as ReBAC and NGAC implementations typically don't support this strategy. It degrades system performance when attributes are accessed repeatedly, especially for high-throughput systems. Caching can mitigate some drawbacks but undermines the freshness guarantee and negates the low-storage advantage, especially for high cardinality data.

Out-of-Band Data Push strategy: definition and characteristics

Out-of-Band Data Push is a data distribution strategy where data is proactively sent to the PDP in advance and stored in memory or a local data store for faster access during evaluation.

Out-of-Band Data Push strategy: advantages

Out-of-Band Data Push improves performance by storing data locally (in memory or a local database), enabling faster policy evaluation. It enhances resilience, as the PDP can operate independently of PIP availability. ReBAC/NGAC PDP types typically require access to complete relationship graphs or contextual data sets, which this strategy enables. It reduces the load on the PDP by shifting data synchronization to other system components, allowing PDP instances to remain lightweight and focused on evaluation, which improves their scalability.

Out-of-Band Data Push strategy: disadvantages

Out-of-Band Data Push requires robust data synchronization mechanisms to push updates to the PDP instances in real-time or near-real-time, especially for data with high-freshness requirements. It increases memory or storage demands on the PDP, which is usually problematic for high-cardinality data. It introduces governance complexity, as mechanisms for who can write to the event/topic the PDP listens to, who can invoke the PDP's API for updates, and which specific data each party is allowed to send must be established.

Request-Time Data Injection strategy: definition and characteristics

Request-Time Data Injection is a data distribution strategy where required data is passed directly in the request from the PEP (Policy Enforcement Point) to the PDP, an approach often referred to as inline data passing. Early-stage standardization efforts including the OpenID AuthZEN Initiative aim to make this interaction more consistent and interoperable.

Request-Time Data Injection strategy: advantages

Request-Time Data Injection ensures data freshness by providing the latest attribute values from PIPs. It enables handling of high-cardinality data without preloading large datasets into the PDP. It reduces load on the PDP by shifting data synchronization to other system components (the PEP), allowing PDP instances to remain lightweight and focused on evaluation, which improves their scalability. Since the PDP does not need to maintain a local copy of data, the memory or storage demand of the PDP is low. It is typically the only option for ReBAC and NGAC systems to provide attributes which are not stored in their databases.

Request-Time Data Injection strategy: disadvantages

Request-Time Data Injection increases request size, as additional data is included in the decision request, potentially impacting network performance. It places the burden on the PEP (such as a microservice or edge component) to collect and validate data from PIPs, increasing complexity in the calling component. It risks inconsistent data if the PEP fails to provide all required attributes or if data collection is misconfigured, potentially leading to incorrect decisions. It can degrade system performance when attributes are accessed repeatedly by the PEPs. It introduces governance complexity, as PEP configuration becomes a concern — it determines which attributes are fetched and sent to the PDP, and configuration changes directly impact authorization decisions. While caching can mitigate some cons, it introduces the risk of stale data, potentially leading to incorrect authorization decisions.

Embedded Data strategy: definition and characteristics

Embedded Data is a distribution strategy where data is baked directly into the PDP's configuration or code, rather than being pulled, pushed, or injected dynamically.

Embedded Data strategy: advantages

Embedded Data provides zero runtime dependencies on external PIPs. It has no synchronization concerns; the data is always available and consistent. It keeps deployments simple.

Embedded Data strategy: disadvantages

Embedded Data is useful only for static or rarely changing information. It requires rebuilding and/or redeploying the PDP when data changes. It introduces governance challenges as the team deploying the PDP effectively decides which data get bundled and used, even if those data elements are owned by different teams or organizational units.

Data distribution strategy comparison table

Strategy comparison across dimensions: On-Demand Data Pull supports high to low freshness (depends on source availability and caching), high cardinality support, higher and more variable decision latency, yes runtime dependency on PIPs, low PDP storage demand unless caching is used extensively, low PEP complexity, no synchronization mechanism required, medium governance complexity (policies define which sources are queried), and typical PDP fit is PBAC-oriented PDPs that support external data lookup. Out-of-Band Data Push supports high to low freshness (depends on synchronization guarantees), low to medium cardinality support (high only if storage and sync model can handle it), low decision latency, no runtime dependency after synchronization, medium to high PDP storage demand, low PEP complexity, yes synchronization mechanism required, high governance complexity (writers, topics, APIs, and data ownership must be controlled), and typical PDP fit is ReBAC/NGAC systems, graph-based models, or PDPs with local data stores. Request-Time Data Injection supports high to low freshness (depends on PEP-side data collection and caching), high cardinality support, medium decision latency (PDP stays lightweight but request preparation may add latency), indirect runtime dependency via the PEP, low PDP storage demand, high PEP complexity, no PDP-side synchronization but PEP-side data collection is required, high governance complexity (PEP configuration determines which data is sent), and typical PDP fit is PBAC, ReBAC, and NGAC when request-specific external attributes are needed. Embedded Data supports low freshness, low cardinality support, low decision latency, no runtime dependency on PIPs, low PDP storage demand, low PEP complexity, no synchronization mechanism required, medium governance complexity (deploying team controls bundled data), and typical PDP fit is simple PDPs with static configuration data.

Data characteristics to distribution strategy mapping

High freshness plus high cardinality: use On-Demand Data Pull or Request-Time Data Injection. High freshness plus low/medium cardinality: use Out-of-Band Data Push, On-Demand Data Pull, or Request-Time Data Injection. Medium freshness plus high cardinality: use On-Demand Data Pull or Request-Time Data Injection; Out-of-Band Data Push only if storage and synchronization are manageable. Medium freshness plus low/medium cardinality: use Out-of-Band Data Push or Request-Time Data Injection. Low freshness plus low cardinality: use Embedded Data or Out-of-Band Data Push. Low freshness plus medium/high cardinality: use Out-of-Band Data Push, On-Demand Data Pull, or Request-Time Data Injection depending on latency and storage constraints.

Architectural constraints and recommended distribution strategies

For a relationship graph or complete authorization model, use Out-of-Band Data Push. For request-specific context already known by the PEP, use Request-Time Data Injection. When the PIP must remain authoritative at decision time, use On-Demand Data Pull. When the PDP must keep runtime dependencies low, use Out-of-Band Data Push, Request-Time Data Injection, or Embedded Data. When data is static, stable, and globally applicable, use Embedded Data.

Security risks in input data distribution

Stale input data can lead to outdated decisions, especially when data is cached, pushed asynchronously, or embedded into PDP deployments. Missing or inconsistent request-time attributes can cause incorrect decisions when PEPs are responsible for collecting and injecting data. Unauthorized data updates can undermine pushed-data models if systems do not control who may publish which updates to PDPs. Untrusted input data can undermine policy evaluation if PDPs or PEPs do not validate the provenance, integrity, and meaning of authorization-relevant attributes. Changes to authorization-relevant data flows should be reviewed, tested, and audited. Broken access control often results not only from wrong policies, but also from wrong, stale, missing, or misapplied input data.

Policy change latency versus input data freshness distinction

Policy change latency describes how quickly changed policies must take effect. Input data freshness describes how quickly changed attribute values must affect authorization decisions. Both are independent dimensions and both influence architecture choices. Do not confuse them.

Give your agent this brain