Security Http Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Security HTTP remains a standalone component of the Symfony ecosystem designed to integrate with Symfony Security Core, providing firewall-based security, authentication mechanisms, and authorization logic for HTTP applications.
• Laravel Compatibility: Laravel uses Fortify and Sanctum for authentication; Symfony’s security-http offers fine-grained control over authentication flows (OAuth, CAS, LDAP, JWT, OIDC) that are not natively available in Laravel’s default stack.
• Baseline Change (v8.1.8 — unchanged): The package moved off the v8.1.0-BETA3 baseline onto a stable 8.1.x patch line (current: v8.1.8). We are no longer planning against a beta API surface, and a maintained patch stream exists for security fixes.
• New Release Reviewed: v5.4.54 — a different branch, not our upgrade target: The newly published release is on the legacy 5.4 LTS line, not the 8.1.x line this assessment pins. v5.4.54 does not supersede v8.1.8 and is not something we install. It is nonetheless material because:
  • It is tagged a [SECURITY] release, and the fixed defects live in code lineages that also exist in 8.1.x (PersistentRememberMeHandler, the login-link handler, and session-token logging).
  • #66629 (token copied into logs) is a data-hygiene defect, not a functional one — it can leak session token material into log sinks on any branch that shares the logging path.
  • #65685 (login-link max_uses race) and #65734 (malformed login-link parameters) are authentication-strength issues in the login-link subsystem.
  • #65735 (malformed remember-me cookie → failure) is a robustness/DoS-adjacent fix in PersistentRememberMeHandler.
• Architectural conclusion unchanged: The decision to use Symfony Security HTTP behind a Laravel facade stands. No API surface in 8.1.x is altered by this release. What changes is our patch-verification obligation: we must confirm these fixes are present in our pinned 8.1.x build rather than assume cross-branch propagation.

Integration Feasibility

• Laravel’s Middleware System: Symfony’s firewalls are kernel-level; they are emulated in Laravel via middleware groups (web, api), custom middleware (AuthenticateMiddleware, CsrfTokenMiddleware), and extension of Laravel’s auth middleware to delegate to Symfony’s AuthenticatorManager.
• Authentication Providers: Laravel’s UserProvider is wrapped behind Symfony’s UserProviderInterface; OAuth/JWT/LDAP/OIDC require custom adapters (e.g. league/oauth2-client).
• Feature-Surface Exposure from v5.4.54 (new): Three of the four fixes touch subsystems we may or may not actually use. Confirm scope before sizing:
  • Remember-me (PersistentRememberMeHandler): only relevant if we enable persistent login. If we do, we inherit the malformed-cookie failure mode until the equivalent fix is verified in 8.1.x.
  • Login links: only relevant if we adopt passwordless email login. If we do not, #65685/#65734 are informational — but they must still be recorded as accepted-and-not-applicable, not silently ignored.
  • Session token logging: relevant to every deployment, regardless of authenticator choice, because the defect is in the logging path rather than a specific auth flow.
• OIDC Hardening (v8.1.8, retained): #66421 binds discovered OIDC keys to their issuers. For multi-IdP Laravel deployments this closes a key-confusion class of weakness. We pin symfony/security-http >= 8.1.8; this constraint is set now, not migrated to later.
• Authorization: Symfony’s attribute-based access control (#[IsGranted]) maps to Laravel’s policy system or custom middleware.

Technical Risk

Key Questions for TPM

1. Why Symfony Security over Laravel’s Native Auth? Is this for enterprise-grade auth (SAML, CAS, MFA, multi-IdP OIDC) not covered by Laravel? Does the team have Symfony expertise to maintain custom integrations?
2. Fix Equivalence (new, blocking): Has anyone confirmed at commit level that the four v5.4.54 fixes are present on 8.1.x? Who owns that confirmation, and by when? A "probably backported" answer is not sufficient for a [SECURITY]-tagged release.
3. Do we use remember-me or login links? If neither, say so explicitly and close those two items as not applicable. If either, they become scoped acceptance criteria rather than background reading.
4. Log Exposure (new): Do our application logs, and any third-party log aggregators, currently receive serialized session/token objects? What is our retention window, and can we purge it?
5. Multi-IdP Topology: Do we authenticate against more than one OIDC issuer? If yes, the 8.1.8 key/issuer binding fix is a hard prerequisite, and the issuer allowlist must be explicit rather than derived at runtime.
6. Middleware vs. Kernel-Level Security: Replace Laravel’s auth middleware entirely, or coexist with Symfony’s firewalls?
7. Session vs. Stateless Auth: API-first (JWT/OAuth) or session-based? Symfony handles both; the answer determines whether the remember-me and login-link fixes are on our critical path at all.
8. Testing & Debugging: How will we mock AuthenticatorManager in Laravel’s suite, and can we build a negative-path auth suite (foreign issuer, tampered token, revoked key, replayed login link) before cutover?
9. Long-Term Maintenance: Who owns Symfony security updates in a Laravel codebase, and what is the SLA for absorbing a fix — whether it arrives on our 8.1.x line or first appears on 5.4.x?

Integration Approach

Stack Fit

Migration Path

1. Phase 0: Version Baseline and Fix Verification
   • Pin symfony/security-http to ^8.1.8 in composer.json; do not carry the BETA3 baseline forward.
   • New: Record the v5.4.54 review outcome in the ADR — for each of the four fixes, state fixed-on-8.1.x, not applicable to our flows, or open finding with owner/date.
   • Do not change the pin to 5.4.x. That line is not our target and downgrading would forfeit the 8.1.8 OIDC key/issuer binding.
2. Phase 1: Authentication Layer
   • Replace Laravel’s AuthenticatesUsers trait with a Symfony Authenticator extending AbstractAuthenticator; hook into Laravel’s auth.attempt.
   • Add log redaction for session/token objects at this stage, before any auth traffic exists in production.
3. Phase 2: Authorization Layer
   • Create a Laravel policy decorator delegating to Symfony’s AuthorizationCheckerInterface.
4. Phase 3: Firewall & Middleware
   • Register Symfony’s FirewallMap and route requests to firewalls via Laravel’s middlewareGroups; enforce priority-based ordering.
5. Phase 4: Multi-IdP OIDC Validation
   • Register each issuer explicitly; verify discovered key sets are issuer-bound under 8.1.8 semantics.
   • Regression coverage: a token signed by Issuer A presented to Issuer B’s firewall must be rejected.
6. Phase 5 (conditional): Remember-Me and Login Links
   • Only if these flows are in scope: single-use login-link enforcement must be atomic server-side, malformed parameters must yield 4xx not 500, and malformed remember-me cookies must fail closed without an unhandled exception.

Compatibility

Sequencing

1. Fix-Equivalence Check (new, gates Phase 2) — resolve the v5.4.54 items to fixed / not-applicable / open before OIDC work begins.
2. PoC — single authenticator (form login) in a new Laravel module, tested with Symfony’s DebugListener; confirm debug output does not emit token material.
3. Incremental Rollout — Step 1 form auth → FormLoginAuthenticator; Step 2 OAuth/JWT/OIDC on the 8.1.8 floor; Step 3 policies → #[IsGranted].
4. Full Cutover — deprecate Laravel’s AuthManager in favor of Symfony’s AuthenticatorManager; move CSRF, logout, and session handling to Symfony components.

Operational Impact

Maintenance

Support

• Upstream Support: Symfony maintains 8.1.x as an active branch, and continued security releases on 5.4 demonstrate responsive handling of auth defects — a positive signal for the "who patches?" concern. It also means the maintainers’ attention is split across lines; do not assume forward-porting is automatic.
• Internal Support Gap: Laravel-native auth() semantics are not natively understood by the Symfony firewall. Our facade layer is bespoke code and will be the durable support burden, not the upstream package.
• Log/Telemetry Ownership (new): The #66629 class of defect crosses team boundaries — application auth, platform logging, and any SIEM/observability vendor. Assign an owner for token redaction and log retention, not just for auth code.
• Escalation Path: Auth incidents must be triaged against both stacks (Laravel session/CSRF vs. Symfony authenticator/firewall). Name a single owner for this boundary.

Scaling

• Request Path Cost: Firewall evaluation and token validation run per request; cache firewall configuration and avoid per-request key-set discovery where caching is permitted.
• Multi-IdP Scaling: Key discovery scales with issuer count; 8.1.8 issuer binding adds per-issuer key-set resolution. Model this before onboarding a large tenant-to-IdP matrix.
• Log Volume Scaling (new): Redaction and token-safety checks add per-log-line work. Implement redaction at the serializer/formatter boundary, not per log call, so cost stays flat as traffic grows.
• Horizontal Scale: Session strategy delegates to our session driver; confirm a shared store (Redis/DB) across nodes or auth state diverges.

Failure Modes

Ramp-Up

• Team Skills: Requires Symfony security-model literacy (firewalls, passports, voters, authenticator manager) alongside Laravel fluency — a narrow but real skill gap.
• Ramp Estimate: PoC-sized for one authenticator. Multi-IdP OIDC plus policy migration is multi-sprint with a security review gate. The v5.4.54 review adds roughly 1–3 days of verification and log-hygiene work — small, but it sits on the critical path to Phase 2.
• Enablement: Produce an internal note on the Laravel↔Symfony auth boundary (who owns session, CSRF, authorization, and log redaction) before Phase 2, and require security sign-off on the OIDC issuer configuration and on the fix-equivalence findings prior to cutover.