Security Core Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization (RBAC/ABAC): This package lets you buy the decision engine (voters, AccessDecisionManager, role hierarchy, authentication trust resolution) instead of hand-rolling role checks. Relevant when your roadmap includes roles beyond simple gates — hierarchical roles, attribute/context-based rules, per-tenant or per-object permissions — where Laravel's Gate/Policy layer starts needing custom plumbing.
• Feature: reusable authorization domain layer. Because authorization logic lives in voters decoupled from user providers and framework wiring, the same rules can serve multiple surfaces (HTTP, queue workers, CLI, API) and multiple apps (e.g., a Symfony service and a Laravel app sharing a domain package). This supports a "shared policy core" initiative rather than duplicating rules per app.
• Feature: role hierarchy and access-decision strategies. RoleHierarchy (e.g., ROLE_ADMIN implies ROLE_USER) and pluggable decision strategies (affirmative/unanimous/priority) are capability gaps in stock Laravel; if the product needs "admin inherits editor inherits viewer" semantics for many roles, this is directly on the roadmap.
• Roadmap: identity/authorization modernization. If enterprise customers ask about SSO, impersonation, remember-me, or auditable authorization decisions, this codebase already models these concerns (impersonation fixes, remember-me cookie hardening, trust resolvers) and serves as a reference design even if you don't adopt it.
• Build vs. buy for security-critical plumbing: The maintenance record shows active security patching across four major branches (5.4, 6.4, 7.4, 8.x) — __unserialize hardening, login-link race narrowing, session-usage tracking. That is a strong argument for buying rather than owning this class of code.
• Use case: migrating or merging a Symfony codebase into a PHP/Laravel estate. Where an existing Symfony app already uses Security Core, keeping the component avoids a rewrite of authorization rules during consolidation.
• Use case: complex product entitlements. Modeling plan tiers, seat roles, and org-level overrides as voters with a priority strategy is a cleaner fit than nested Gate::before callbacks.

When to Consider This Package

Consider it when:

• Authorization requirements exceed Laravel's Gate/Policy model: role hierarchies, multiple composable rules per decision, or non-HTTP enforcement points (workers, scheduled jobs, console commands, separate services).
• You need authorization logic that is framework-agnostic and shareable across a Laravel app, a Symfony app, or a standalone PHP package.
• You are already operating Symfony components (via symfony/* packages) and want one consistent authorization primitive rather than two.
• You need a documented, battle-tested set of security primitives (tokens, user providers, trust resolvers, impersonation) and are willing to own the wiring.
• Your platform requires long-term, multi-branch maintenance guarantees and prompt security releases — the release cadence here is a real asset.

Look elsewhere when:

• The need is simple: route middleware, a handful of policies, @can in Blade. Laravel's built-in Gate is the correct answer; this package adds concepts and wiring for no gain.
• You want batteries-included Laravel integration. There is no service provider, config, or Eloquent-aware user provider here — integration is custom code you must own and test.
• Your team is Laravel-only. The docs, examples, and mental model are Symfony-first; the onboarding cost is real and lands on whoever maintains auth.
• You dislike low-level control over authentication. UsernamePasswordToken, decision managers, and firewall-adjacent concepts are powerful but easy to misconfigure; security misconfiguration is an expensive failure mode.
• PHP version is a constraint. Symfony 8.x requires PHP 8.4; adopting the newest line may force a platform upgrade on your roadmap.
• You cannot absorb an extra dependency surface. Note the sparse dependent count recorded here and the fact that this is a subpackage split out of the monorepo — dependency and version-alignment hygiene (keeping all symfony/* packages on one branch) becomes your responsibility.

How to Pitch It (Stakeholders)

For executives: Symfony Security Core is the authorization engine underneath one of the most widely deployed PHP frameworks — MIT-licensed, actively security-maintained across four release branches, with a predictable release rhythm and a track record of shipping fixes rather than sitting on them. The strategic question is not "is it good code" (it is) but "should we own authorization plumbing or consume it." Adopting it buys us a proven decision engine for complex, hierarchical, multi-surface permissions; declining it keeps us on Laravel's native Gate, which is simpler, free, and already in the stack.

For engineering: This is a low-level component, not an integration. There is no Laravel service provider — we would write and own the glue: user providers, token storage, voter registration, and a facade over AccessDecisionManager. Adopt it only if we have authorization requirements that outgrow Gate (role hierarchies, composable voters, enforcement outside HTTP, or shared policy across a Symfony and Laravel estate). If we do adopt, budget for: a thin integration layer with tests, a deliberate decision on which Symfony branch we track (8.x requires PHP 8.4), and a rule that all symfony/* packages stay on the same minor line to avoid dependency skew. Treat the security-sensitive nature of the component as a review gate — every voter and trust resolver we wire should be code-reviewed and covered by tests that assert deny-by-default behavior, not just the happy path. Recommendation: pilot behind one non-critical authorization surface before committing the platform's access control to it.