Admin Security Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel auth: If your roadmap includes an internal back-office or admin console built on fsi-open/admin-bundle, this bundle answers the "do we hand-roll login and role checks?" question with a cheap "no." It is a thin integration layer that wires authentication and authorization into the admin bundle's UI, so it primarily saves glue-code hours, not architecture decisions.
• Scoping the first release of an admin surface: It sets a realistic baseline for what "authenticated admin" means out of the box (session-based login, access gating on admin resources). That lets you defer finer-grained permissions, SSO, and MFA to later milestones with an explicit, documented gap rather than an implicit one.
• Ecosystem lock-in as an explicit trade-off: Adopting this is a package-level commitment to the FSI admin stack. That is a legitimate roadmap decision for internal tooling where speed beats portability, but it should be recorded as a deliberate constraint — not discovered later during a framework migration.
• Portfolio triage across internal tools: For low-traffic, employee-facing CRUD consoles, this is a defensible default. For anything customer-facing, regulated, or revenue-bearing, the same decision should route to a maintained, widely adopted auth solution instead.
• Prioritizing auth hardening work: Because the package is deliberately "simple," it gives you a clean checklist of what you still own — password policy, session lifetime, audit logging, role model design. Those become backlog items you can size and schedule rather than surprises in a security review.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to fsi-open/admin-bundle; this package has essentially no standalone value without it.
• Your stack is Symfony, not Laravel — despite the framing, this is a Symfony bundle and will not drop into a Laravel application. Laravel teams should look at Breeze, Fortify, or a maintained RBAC package.
• The application is an internal admin tool with a small, known user population and low blast radius if auth behavior is imperfect.
• You are comfortable pinning an exact version and treating the source as fork-ready, given 4 stars and 0 dependents — there is effectively no community to catch regressions for you.
• You need basic login and coarse authorization only, and are willing to own MFA, SSO, password reset policy, and audit trails separately.

Look elsewhere when:

• You need OAuth/OIDC, SAML, MFA, fine-grained or attribute-based permissions, or enterprise directory integration — reach for Symfony's native Security component plus a mature provider instead.
• Your organization requires vendor support, a security disclosure process, or a maintenance SLA. A single-maintainer package with negligible adoption will not survive procurement or a security questionnaire.
• You are not on fsi-open/admin-bundle. The cost/benefit collapses entirely; standard Symfony security wiring is the lower-risk path.
• Long-horizon roadmap includes replacing the admin panel — layering this in deepens a dependency you already intend to exit.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed add-on that gets authentication working on an internal admin console quickly, letting the team spend its time on business logic rather than login screens. The trade-off is concentration risk: it is a niche package with minimal community adoption, maintained by a single organization. That is an acceptable trade for internal, non-customer-facing tools where a hiccup costs us hours, not revenue or compliance exposure — and it is not acceptable as the foundation for anything customer-facing or regulated. Recommend a scoped pilot on one internal tool, with the code vendored or pinned and a documented exit path.

To engineering: This is a thin authentication/authorization adapter for fsi-admin-bundle — it does not replace Symfony's Security component, it complements it. Expect it to handle session login and basic admin access gating, and expect to own everything beyond that: password policy, session hardening, role modeling, and audit logging. Because there are zero dependents and four stars, treat upgrades as manual reviews, pin the version, and keep our integration isolated behind our own service boundary so swapping it out later is a contained change rather than a rewrite. Flag any place where it fights the framework's native security configuration; those are the seams most likely to break first.