Auth and Audit Foundation in a Real System

1. The real problem: a successful login is not universal permission

A system can identify a user correctly and still authorize the wrong action. Authentication answers which identity is attached to a request; authorization decides whether that identity may perform a specific action on a specific resource. In this lesson, every conclusion must trace to a synthetic request, principal, resource, action, server-side decision, and reviewable evidence. A login screen or a valid session alone does not prove permission for a protected action [OWASP-AUTHN][OWASP-AUTHZ].

2. See the evidence chain before touching implementation

The bounded model is request → authentication context → principal → protected action → authorization decision → outcome → security/audit event → correlation → review evidence. If one link is missing, do not replace it with a guess. Auth-Audit Runtime Foundation Record v1 exists to keep direct observations, inferences, policy choices, and OPEN states separate.

3. What authentication proves

Authentication verifies identity only within the local fixture boundary: whether the synthetic session is valid and whether a principal can be attributed. A result such as authenticated=true and principal=user-17 is useful, but it does not prove that user-17 may read a finance report, rotate an administrative key, or modify another tenant. Those are authorization questions [OWASP-AUTHN].

4. Authorization must be server-side and action-specific

Every protected action needs a server-side policy check. The small matrix in this lesson makes resource, action, and permission conditions explicit. OWASP authorization guidance emphasizes least privilege, deny by default, and permission validation on every request [OWASP-AUTHZ]. If a protected synthetic route has no authorization check, an audit event cannot compensate for the missing preventive control.

5. Deny by default means unknown does not become allow

Deny by default means that an absent rule, unknown principal, unknown action, or insufficient context does not silently become allow. The principle survives whether the policy model is role-based, relationship-based, or attribute-based. The record should contain policy evidence explaining an allow or deny rather than only the final outcome.

6. Make least privilege visible with a negative test

A happy path is insufficient. Authenticate a low-privilege synthetic user and request an admin-only action. The correct result is deny with a defensible reason code. This negative test directly falsifies the shortcut “authenticated means authorized.” If the route allows the action, the case remains a blocker even when a later log line records what happened.

7. Audit follows the decision; it does not replace the decision

Audit evidence helps review what happened. Authorization determines whether the action should be allowed in the first place. If a route executes without an authorization check and a logger records allowed, the foundation is still defective. Logging cannot reconstruct a missing authorization control after the action has occurred [OWASP-LOGGING].

8. What makes an audit event useful here

This lesson records at least actor/principal, target/resource, action, outcome, reason code, event time, request/correlation id, and event source. The goal is not maximum logging; it is enough attribution for a bounded review. If actor identity or correlation is wrong, the mere existence of an event does not close the row. The evidence state remains OPEN until the attribution problem is repaired.

9. Correlation connects request, decision, and event

A request id or correlation id should let a reviewer connect the incoming request, authorization decision, and audit event for the same interaction. When the action is correct but correlation points to a different request, attribution is not trustworthy. One fixture deliberately uses the wrong actor/correlation to show that “a log exists” is weaker than “attributable evidence exists.”

10. Sensitive-data exclusion is a gate, not decoration

OWASP logging guidance recommends useful security logging without exposing sensitive secrets [OWASP-LOGGING]. The bearer token in this lesson is entirely synthetic, yet it still must not appear in the audit sink. If the naive logger writes Bearer SYNTHETIC-SECRET-..., the case is a blocker. The correct pattern is to retain necessary actor/context evidence while redacting or omitting the secret.

11. Record event source and trust boundary

Not every event has the same evidentiary value. Data from a client or weaker trust zone can be missing, forged, or incomplete. The record therefore includes event source and trust limitations. The local append-only test sink is useful for deterministic evidence, but it is not a claim of legal non-repudiation or production-grade tamper resistance [OWASP-LOGGING].

12. Do not collapse an audit gap into an authorization failure

Two distinct failures are possible: authorization correctly denies an action but the expected event is missing, or the authorization check is absent while a logger still writes an event. The first is an audit/evidence gap; the second is a preventive-control blocker. Repair must target the actual boundary rather than labeling both as a generic security problem.

13. Complete Auth-Audit Runtime Foundation Record v1

For each request record: Request, Authn State, Principal, Resource, Action, Policy Evidence, Authz Decision, Reason, Audit Event, Correlation, Sensitive-data Check, Supported/Open, and Repair. Keep observation separate from inference. If principal attribution, source trust, or correlation is incomplete, OPEN is more accurate than a fabricated PASS. This record is a MAKNOW instructional artifact, not an OWASP-mandated template.

14. Repair closes only when the failed probe turns green

For a route missing authorization, repair means restoring the server-side check and rerunning the low-privilege case. For a deny with no audit event, repair means emitting attributable evidence and rerunning that case. For a secret leak, the redaction test must pass. Broad unrelated changes weaken evidence; a repair should be bounded, repeatable, and connected to the failed probe.

15. Transfer from role matrix to relationship/attribute rules

The second fixture renames actions, separates authentication and audit components, and no longer relies on a simple role matrix. Rebuild the evidence chain from raw facts: principal, relationship/attribute, target, action, policy evidence, decision, and event correlation. If you can defend allow, deny, and OPEN states without copying the first matrix, the skill transferred. The policy model changes; the evidence standard does not.