[BUG] ABAC needs a populated ISecurityContextAccessor, but AddEncinaABAC does not register it and nothing populates SecurityContext from HttpContext.User

[dlrivada]

Description

ABAC requires a populated ISecurityContextAccessor, but AddEncinaABAC neither registers it with the DI container nor does Encina provide a mechanism to populate SecurityContext from HttpContext.User. Applications following the quick-start receive abac.missing_context on every request after PR #1701 merges.

Steps to Reproduce

1. Configure ABAC using only AddEncinaABAC (per docs/features/abac/quick-start.md:21-41)
2. Create an endpoint decorated with [RequirePolicy] or [RequireCondition]
3. Make an authenticated request to that endpoint
4. See abac.missing_context error

Expected Behavior

The ABAC PEP evaluates against a security context the framework provides, opt-in and fail-closed:

1. AddEncinaABAC registers everything it resolves, or fails at startup with a message naming the missing registration (AddEncinaSecurity); a DI test builds ABAC alone with ValidateOnBuild and ValidateScopes (AGENTS.md section 3).
2. An opt-in ASP.NET Core integration in Encina.AspNetCore populates SecurityContext from HttpContext.User per request (user id from the configured claim, roles, IsAuthenticated), registered by an explicit extension method; tests with an authenticated and an anonymous request.
3. A documented service-identity pattern for background jobs and message handlers (an explicit scope that sets a service principal).
4. The ABAC quick-start and README show the complete registration.

Actual Behavior

After PR #1701 merges, every request decorated with [RequirePolicy] or [RequireCondition] fails with abac.missing_context. Before #1701, the behavior was fail-open: the request was evaluated as user "" (#1676).

Environment

• Encina Version: main (pre-1.0) with PR fix(abac): missing security context and failed policy retrieval deny; no exception messages in PEP/PDP output (#1676, #1685) #1701
• .NET Version: .NET 10
• OS: any
• Package(s) Affected: Encina.Security, Encina.Security.ABAC, Encina.AspNetCore

Code Sample

// docs/features/abac/quick-start.md:21-41 registers only ABAC:
services.AddEncinaABAC(options => { /* ... */ });
// No AddEncinaSecurity() and nothing sets ISecurityContextAccessor.SecurityContext,
// so [RequirePolicy] requests are denied with abac.missing_context.

Stack Trace

Not applicable: the request returns Left(abac.missing_context); no exception is thrown.

Additional Context

Root Cause

1. AddEncinaABAC resolves ISecurityContextAccessor in pipeline behavior but never registers it with the DI container. Unit tests manually add a substitute; no test validates ABAC registration alone with ValidateOnBuild/ValidateScopes.
2. Nothing in src/ sets ISecurityContextAccessor.SecurityContext. The only reference is a hand-copied snippet in src/Encina.Security/README.md:58-65. Encina.AspNetCore does not provide an integration to populate the context from HttpContext.User.
3. No documented pattern exists for populating the security context in non-HTTP flows (background jobs, message handlers).

Related

• [BUG] ABAC PEP evaluates with an empty user id when the security context is missing, and the PDP decides on partial policies when standalone-policy retrieval fails #1676 / PR fix(abac): missing security context and failed policy retrieval deny; no exception messages in PEP/PDP output (#1676, #1685) #1701 (makes this gap visible)
• [BUG] ABAC ignores RequirePolicy.PolicyName and RequireCondition at request time, and ObligationExecutor lets handler exceptions escape #1634 / PR fix(abac): enforce RequirePolicy and RequireCondition as documented; obligation handler exceptions fail closed (#1634) #1650
• [FEATURE] Add formal audit trail for ABAC authorization decisions #751 (decision audit uses the same accessor)
• [BUG] Open-generic TryAddTransient of IPipelineBehavior silently skips behaviors registered after another one (about 20 packages) #1635 (open-generic registration of security behaviors)
• [SPIKE] Pipeline behavior order independent of registration order (named stages) #1678 (pipeline stages)

[dlrivada]

Maintainer decision (2026-10-03): one identity model. Encina keeps a single ambient identity: a core RequestIdentity (user or service, authenticated flag, principal, roles, permissions) carried by IRequestContext.Identity, with UserId as a projection of it. ISecurityContext, ISecurityContextAccessor and SecurityContext are removed (pre-1.0, no aliases), and every consumer (ABAC PEP, persistent PAP, the #751 decision audit, Security behaviors, audit, repositories, caching) reads the same identity.

• HTTP: the existing UseEncinaContext() builds the identity through one claim mapping (sub, then NameIdentifier, then the Azure AD object id).
• Non-HTTP: an explicit service-identity scope API with identities declared at startup; dispatches without an identity stay anonymous and every gate denies them.

A design workflow (three independent designs, three judges, unanimous) produced docs/plans/security-context-population-implementation-plan-1705.md; it goes through an adversarial plan review and its own plan PR (reserving ADR-035) before implementation. #1707 (PR #1720) touches the same PAP file and lands first.

[dlrivada]

Adversarial review of the implementation plan (2026-10-04, five lenses: decision fidelity, completeness, security/fail-closed, cross-cutting, testing): 63 findings (1 blocker, 37 major, 25 minor) with 2-vote refutation for blockers/majors; part of the refutation was cut by the usage limit, so every finding is re-verified by the worker that revises the plan before it is applied. Headline items: (1) blocker: service identities turn the fail-closed DSR restriction gate into an allow; (2) follow-ups F1/F4 conflict with SPEC-002 REQ-015/DEC-011 and duplicate P-50 (#1164): deferred dispatch must rebuild the originating actor, not run as a service; (3) UserId is not enforced as a projection of Identity; (4) user ids and claim values still reach logs and tags; (5) IPrincipalResolver and the EF Core interceptors keep second identity channels; (6) scope lifetime (AsyncLocal outliving scopes, out-of-order disposal) and tenant binding unspecified; (7) missing test, coverage-per-flag, CRAP and documentation scope (9 sections of security-authorization.md, AspNetCore samples). Next: plan revision worker, then the plan PR reserving ADR-035.

[dlrivada]

Maintainer decision (2026-10-05): one PR per phase, no release until Phase 3 lands. Phase 1 leaves authenticated HTTP requests anonymous until Phase 3. That window is accepted pre-1.0: gates still deny, and no user is affected.

Carried into Phase 2 from the Phase 1 self-review:

• M3's "issuing scope no longer active" scope_conflict check. Phase 1 refuses only when the ambient identity is a User, because no scopes exist yet.
• TestIdentity.Service, which needs ServiceIdentityDefinition.

Carried into Phase 7:

• ADR-035 is already cited in code.
• docs/architecture/request-pipeline.md:61 and docs/INVENTORY.md:3390 still describe WithUserId.
• EncinaAspNetCoreOptions.UserIdClaimType has no effect until Phase 3 removes it.

[dlrivada]

Phase 1 review notes for Phase 2 (2026-10-05, adversarial review of #1824), recorded so they are not lost:

• Push and Pop are static members of the concrete RequestContextAccessor, while AddEncinaRequestIdentity lets an application register its own IRequestContextAccessor. The Phase 2 scopes must then fail or refuse, not write to a store the dispatcher never reads (otherwise dispatches silently run anonymous).
• Encina.Testing (a published package) exposes TestIdentity.User publicly, and nothing stops production code from referencing it. Phase 2's architecture test (task 9) should also forbid production assemblies from referencing Encina.Testing.

The review's other findings (accessor chain, setter bypass, VaryByUser caching and ExcludeSystemAccess fail-open, identity hardening, tests) are being fixed in #1824 itself.