Enterprise Security Bundle Laravel Package

Technical Evaluation

Architecture fit — the framing needs correcting first. Despite the brief describing a "Laravel/PHP package," this is a standalone Symfony bundle with no Laravel port, bridge, or service provider. It depends on the Symfony DI container, HttpKernel abstract controllers, the Validator/Form components, Twig, the Symfony security firewall, and scheb/2fa-bundle. On a Laravel stack this is a non-starter — adopting it would mean reimplementing it, not integrating it. The evaluation below assumes our target is Symfony 6.4/7.4 on PHP 8.3+ with Doctrine ORM; if that assumption is wrong, the decision is made and we should evaluate Laravel-native equivalents (Fortify, Socialite, web-auth/webauthn-lib) instead.

Assuming a Symfony host: the bundle is deliberately contract-first. It ships interfaces, abstract flow controllers, security engines and Twig extensions — but no wired UI, no entities, no routes, no templates. The architecture inverts normal package consumption: we implement ~5 persisted-record interfaces plus repositories and the UserAnonymizerInterface, add per-feature user mixins, subclass ~15 abstract controllers, own all routes, and build the settings UI and GDPR cron ourselves. That is an intentional design, not a gap — but it means "architecture fit" is really a question about our capacity to build a security platform on top of primitives.

Integration feasibility. composer require plus a one-line bundle registration gets us to roughly 10% of the work. The remaining 90% is: Doctrine schema design for magic-link tokens, passkey credentials, sessions, social links and deletion requests; entity/repository implementations; controller subclassing and route wiring; firewall and scheb_2fa configuration; templates and translations; browser-side WebAuthn JavaScript; a session-revocation listener; a settings UI; and a scheduled deletion processor. Realistic sizing for a competent Symfony team: 1–2 engineer-weeks for a 3–4 feature subset, 3–6 engineer-weeks for a full 16-feature rollout, before external security review and pen testing.

Technical risk. The domain is high-consequence and the adoption signal is near-zero (0 stars, 0 dependents, score 21.6). Specific concerns:

• Fail-open by omission. The 2.2.1 changelog documents exactly this class of defect: a documented outcome that the code only delivers once the integrator wires a listener. Security controls that silently no-op are worse than absent controls, because they show up as satisfied in compliance evidence while enforcing nothing.
• Delegated 2FA. scheb/2fa-bundle is a second supply chain with its own release cadence and CVE surface.
• Active hardening. 2.2.0 fixed a genuinely material issue (OAuth state/link cookie had no signed exp, making a captured link cookie a permanent sign-in) and added IP-companion rate counters. This is a positive maintenance signal but a caution on maturity — the code is still being tightened. Pin to ≥2.2.1.
• Test posture is credible but narrow. 384 unit tests, PHPStan level 8 with strict rules, ECS. That validates services and abstract controllers; it does not validate our wiring against a real firewall, which is where the failures will be.
• Vendor concentration. Single agency (3BRS), Sylius-aligned, with a companion Sylius plugin. Diligence item: the listed last release is future-dated (2026-10-13) — verify actual release history on Packagist before planning around it.

Key questions. Is our stack Symfony at all? Which of the 16 features do we actually need versus what the bundle happens to offer? Who owns the threat model and signs the pen-test scope? What CVE-response window is acceptable for an MIT package with no SLA? Do we need Apple OAuth (paid developer account, key rotation) and Microsoft tenant configuration? GeoIP: MaxMind licensing and data-residency implications? Are we resourced to own the settings UI, WebAuthn JS and GDPR cron in perpetuity? Is commercial support available from 3BRS, and at what price?

Integration Approach

Stack fit. Symfony 6.4/7.4, PHP 8.3+, Doctrine ORM, Redis for the rate-limiter cache pool, Twig, scheb/2fa-bundle, and a scheduler/cron for due deletions. Any missing piece of that list becomes prerequisite work. On Laravel: no viable path — recommend a Laravel-native authentication stack rather than a shim.

Migration path. There is no drop-in migration; this is an additive, parallel auth surface. Password hashes are standard Symfony encoders, so a pre-existing credential store should carry over without rehashing — verify against our current scheme explicitly. Everything else (sessions, passkeys, social links) is net-new state, so the migration is really a feature-by-feature rollout behind flags, not a cutover.

Compatibility. Symfony 8 is not supported (7.4 ceiling) — that sets our framework upgrade horizon. PHP 8.3 floor may conflict with older services. The Doctrine mapping is entirely ours, so schema drift is our migration to write and our data to back up. Front-end constraints are real: WebAuthn needs HTTPS and a stable, per-environment relying-party ID; OAuth needs registered applications and secrets per environment (and per provider).

Sequencing. Do not attempt breadth-first. Recommended order:

1. POC spike (1–2 weeks). One feature end-to-end — I'd pick password policy or IP lists — to validate DI wiring, firewall config, and the abstract-controller pattern before committing budget.
2. Primitives only, flagged. CidrMatcher/IP lists, PasswordPolicy/PasswordHistory, PasswordExpirationChecker, RateLimitGuard. Low blast radius, no UI, immediate security value.
3. 2FA via scheb_2fa — the highest-value user-facing control, and the one with the most mature upstream dependency.
4. Magic link, then OAuth (Google → Microsoft → Apple, in ascending setup cost).
5. Passkeys last. Browser JS, RP-ID management and a fallback path make it the longest pole.
6. GDPR deletion gated on legal/privacy sign-off, not engineering readiness.

Gates. Each phase should exit only with: security review sign-off, integration-test coverage of the wired flow (not just the bundle's unit tests), a documented rollback (flag off), and an ops runbook entry. Critically, do not ship 2FA or passkeys until lockout and the session-revocation listener are working — those are the primitives that make account takeover recoverable.

Operational Impact

Maintenance. MIT, no SLA. We permanently own: entity and repository implementations, schema migrations, all controller subclasses, templates, WebAuthn JS, the settings UI, the deletion cron, and the session-revocation listener. Bundle upgrades are ours to track. Changelog discipline is genuinely good — 2.2.0 and 2.2.1 are detailed, and 2.2.1 explicitly retracts an overclaim rather than quietly editing it — but upgrade guidance is integrator-facing prose, not automated. Budget roughly 10–15% of one engineer ongoing, spiking on any release touching security.

Support. Assume informal GitHub-only support for a zero-star repository. Before committing, we should test whether 3BRS offers a paid maintenance/support arrangement — they're a commercial agency with a Sylius plugin built on this bundle, so the conversation is plausible. If not, we are effectively forking: name an internal maintainer, vendor a read-only mirror, and set a policy for applying upstream patches.

Scaling. The rate limiter requires a shared cache pool — in-memory pools in a multi-node deployment silently weaken limits to per-node accuracy. Session and fingerprint records grow unboundedly and need a retention policy from day one. GeoIP lookups add request-path latency and require scheduled MaxMind database refresh plus licensing review. The deletion processor runs as cron and needs idempotency and a dry-run mode before it touches production data at volume.

Failure modes. Ranked by severity:

• Unregistered listener → control silently no-ops. Highest severity, hardest to detect, and the exact defect class the 2.2.1 changelog describes. Mitigate with integration tests that assert the effect, not the service's existence.
• Session revocation without the listener leaves "blocked" users with live sessions — documented, and the reason 2.2.1 exists.
• Lockout weaponized for DoS against known usernames. The IP-companion counters added in 2.2.0 close password spraying but the map is empty by default — enabling it is our configuration decision, not a default.
• Mis-keyed rate limiter either fails to enforce or enforces globally against all users.
• Environment RP-ID mismatch for WebAuthn, locking users out on promotion.
• TOTP clock skew and recovery-code exhaustion — both need user-facing recovery paths we build.
• OAuth state/link cookie replay — mitigated in 2.2.0; a hard floor on version.
• Anonymizer bugs in the GDPR flow cause irreversible data loss.

Ramp-up. Steep: contract-first, no UI, security domain. Partially offset by documentation that is unusually thorough for a zero-star package — ten integration guides plus per-feature narrative. Plan one senior Symfony engineer as named owner, 1–2 weeks of docs-plus-POC onboarding, a paired security reviewer, and an external pen test before any production exposure. Do not distribute this across multiple engineers without a single design owner; the wiring knowledge is the asset, and it is tacit.