Sam Ecore Security Manager Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for authentication and authorization. This package sits directly in the security-critical path — identity loading, role resolution, per-object access checks. Adopting it is a decision to inherit someone else's security model rather than design one, and the PM should force that comparison explicitly instead of letting it happen by default through a transitive dependency.
• Framing correction that changes the decision. Despite the Laravel-shaped brief, this is a Symfony bundle from CanalTP's Sam e-core / Navitia stack — a DI extension, firewall configuration, and user provider wired into Symfony's Security component. If the product is Laravel, the package is out of scope by architecture, and the only reusable asset is the authorization model. That reframing is itself a product decision: do we reimplement the intent natively, or do we reshape the stack around a dependency?
• Ecosystem and platform standardization. Choosing it is a commitment to the Sam/e-core conventions — service container wiring, config format, ACL data model — rather than framework-native primitives. That is a roadmap-level commitment, not a tactical convenience.
• Supply-chain and dependency policy. Zero stars, zero dependents, score 0 means adopting an effectively private library into the auth path. The PM decision is whether the org permits unmaintained security dependencies and, if so, who is accountable for patching them.
• Roadmap scoping for SSO / RBAC / multi-tenancy. If the bundle supplies entity-scoped role and permission plumbing you would otherwise build, it can shorten a milestone — but only after pricing in ownership. The real decision is whether the apparent time saving survives the maintenance cost.
• Legacy integration and migration sequencing. The one plausible legitimate use: an existing Sam/Symfony service needs to interoperate. The decision then becomes "bridge now, migrate later" versus "block on migration" — a sequencing call the PM owns, not engineering alone.
• Domain leverage in transit/mobility. CanalTP's Navitia lineage means the permission model (lines, stop areas, networks, vehicle journeys) may map onto your own transit domain objects. That makes the concepts valuable even when the code is not adoptable.

When to Consider This Package

Consider it only under a narrow, defensible set of conditions:

• You are already inside the CanalTP / Sam e-core / Navitia ecosystem, on a Symfony ≤3.4 application pinned to symfony/security-acl, and this bundle is the sanctioned wiring for services you already run.
• You have a named internal owner — a team or engineer who has read the source, can patch it, and will pin a version. Treat it as a vendored internal fork, never as a community dependency.
• You need behavioral parity with an existing Sam deployment (shared session, role hierarchy, token format) and reimplementing that parity would cost more than forking.
• You have completed a licence review (CanalTP's lineage includes AGPL-family projects — confirm before vendoring into a closed product) and a security review of the code path, plus PHP/Symfony compatibility verified against your runtime.
• The scope is bounded: a bridge or adapter with a documented exit, not the long-term auth foundation.

Look elsewhere when:

• You are on Laravel. This is the default outcome. Use Sanctum/Passport with Gate/Policy, plus spatie/laravel-permission if you need role plumbing. The Symfony container assumptions make adoption a rewrite in disguise; extracting the permission model as a written spec takes days and is the only transferable value.
• You need ongoing security patching. No stars, no dependents, no release cadence means no CVE triage, no PHP 8 fixes, no Symfony 5+ support, no community answers. For authorization code, that absence is the dominant risk — vulnerabilities there tend to fail open rather than throw.
• You are greenfield. New auth belongs on maintained primitives or a hosted IdP (Keycloak, Ory, Auth0, Cognito). Reversing that later is expensive; symfony/security-acl being removed in Symfony 4.0 is a concrete example of the exit cost.
• You need documentation, SLAs, or vendor support for a procured or audited system.
• You cannot establish licence clarity or an internal owner. Both are hard gates, not preferences.

How to Pitch It (Stakeholders)

For executives: This is a small, effectively private security library from a European transit-tech vendor's Symfony stack — no community, no dependents, no visible maintenance, and a hard framework mismatch with our Laravel target. It is not a platform component and should not be presented as one. Recommendation: do not adopt it as the foundation of authentication or authorization. The only value worth capturing is its authorization model — entity-scoped roles over transit referential objects — which we can extract as a spec in days and rebuild natively. The decision that matters is not "which library" but "who is accountable for patching auth code in two years"; with this package, the answer is unavoidably us.

For engineering: Treat the repository as a reference implementation, not a dependency. Read the voter/ACL and DI code, write the permission model down as a spec, then implement it on Laravel's native Gate/Policy with an explicit cache layer — because ACL-shaped authorization means per-object grant rows and join-heavy checks, and the data model, not the bundle, will be the scaling constraint. If a Symfony legacy service genuinely requires parity, vendor the code into our VCS, pin the SHA, add CI and a PHP version matrix, and own the fork explicitly. Do not let Composer resolution on a modern stack become the blocker that freezes the rest of the application's patch cadence.

For security and compliance: An unmaintained dependency in the authorization path is a standing finding. symfony/security-acl is deprecated and removed upstream; the transitive tree is unlikely to resolve on a current PHP/Symfony runtime, and automated scanning will not surface advisories for a package with no advisory footprint. Any adoption needs documented risk acceptance, a named owner, a quarterly manual review of the upstream repo, and licence confirmation before vendoring — especially given the AGPL-family lineage around Navitia.

Bottom line for the roadmap: Keep this off the critical path of any new product. Permit it only as a scoped, time-boxed integration artifact with an exit plan, and price the ownership cost into the estimate rather than treating it as free reuse.