Sam Ecore Security Manager Bundle Laravel Package

Technical Evaluation

TPM framing first: this is not a Laravel package, and that changes the decision. canaltp/sam-ecore-security-manager-bundle is a Symfony bundle (DI extension, *Bundle class, firewall/user-provider wiring, likely Doctrine mappings) from CanalTP's Sam/e-core transit stack. For a Laravel roadmap item, the package itself is out of scope; the only transferable asset is the permission model embedded in its source. A TPM should evaluate it as either "a Symfony dependency for a legacy Sam service" or "a reference implementation we read and rebuild," never as a composer require into a Laravel app.

Architecture fit

• It plugs into Symfony's kernel, container, and firewall — not Laravel's service provider or auth guards. Any Laravel story is a reimplementation story.
• Its real function is authorization over e-core domain entities (lines, networks, stop areas, journeys) — entity-scoped roles, ownership, hierarchical referential permissions. That is a legitimate product concern (RBAC/multi-tenancy/SSO milestones), but the bundle is thin glue over Symfony's Security component and security-acl.
• Zero stars, zero dependents, no visible release cadence = effectively private vendor code. The TPM decision is "do we accept ownership of auth code we did not write."

Integration feasibility

• Low. The likely pin is Symfony 2.x/3.x with symfony/security-acl, deprecated in 3.4 and removed in 4.0. Composer resolution against PHP 8.2 / Symfony 6–7 will almost certainly fail.
• The transitive tree (old Doctrine ORM, old ACL schema, possibly abandoned canaltp/* siblings) is the cost centre, not the bundle's few files.

Technical risk

• Abandonment: critical. Nothing upstream will patch it; on the auth path that is a standing finding.
• Security: high. ACL/voter logic is exactly where silent behavioural drift fails open rather than throwing.
• Licence: unverified. Navitia lineage includes AGPL-family licensing — a hard gate before vendoring or forking into a closed product.
• Behavioural: unknown. No docs, no tests in evidence, no dependents — semantics must be reverse-engineered.

Key questions a TPM must get answered before committing a milestone

1. Laravel or Symfony target? If Laravel, this is a spec-extraction exercise only.
2. What PHP/Symfony range does it actually install against, and does composer why-not resolve?
3. What licence, and are we cleared to fork and redistribute internally?
4. Who is the named owner, and what is the review cadence? No owner = no adoption.
5. Does it deliver anything beyond stock Symfony voters/ACL that we would not write in a week?
6. Is there a maintained fork or successor inside Sam/Navitia?
7. What is the exit plan if a CVE lands in the pinned transitive stack?

Integration Approach

Stack fit (as a TPM decision matrix)

• Laravel target — do not integrate. Rebuild the intent on Gate/Policy plus a maintained permission package (spatie/laravel-permission or equivalent). Entity-scoped roles and referential hierarchies map cleanly onto policies and are cheaper to own than a Symfony bridge. This is the default and should be the roadmap default.
• Existing Symfony ≤3.4 Sam service — candidate, but only if it already uses security-acl. Then it is a shortcut, not a new capability.
• Symfony 4+ — not viable without a fork we own.

Migration / adoption path

1. Treat the repo as a reference implementation, not a dependency. Extract the permission model (roles, ownership, hierarchy, token/credential semantics) into a written spec — that spec is the reusable artifact.
2. Rebuild on the host framework's native authorization primitives, with tests.
3. Only if a hard dependency is unavoidable: vendor into our VCS (no Packagist pull at install), pin the SHA, and record ownership explicitly in the risk register.

Compatibility and sequencing (TPM-owned gates)

• Gate 1 — Spike (timebox: days, not weeks): throwaway branch, dependency-resolution trial, confirm PHP/Symfony matrix.
• Gate 2 — Licence + security review sign-off.
• Gate 3 — Spec extraction and build-vs-fork decision (with estimate including ownership cost, not just integration cost).
• Gate 4 — Implementation with CI, PHP matrix, dependency scanning.
• Do not sequence this ahead of a working auth model or a populated e-core schema — the bundle has nothing to guard otherwise. Treat any ACL schema migrations as first-class host migrations so they survive removal of the bundle.

Operational Impact

Maintenance

• Upstream maintenance is effectively zero; ownership transfers to us on day one — PHP upgrades, Symfony upgrades, CVE response, schema evolution. Budget a named owner and quarterly review. A fork without an owner rots within two release cycles; price that into the estimate rather than treating the package as free reuse.

Support

• No maintainer, no triage, no docs, no dependents. Ramp-up is entirely reverse-engineering; for a Laravel team, time spent on the mechanics is wasted effort.

Scaling

• ACL-style authorization means per-object grant rows and join-heavy checks. On a referential with many lines/journeys and many users this becomes a database hot path. Caching and query-shape work are required regardless of implementation — which argues for native policies with an explicit cache layer over inherited ACL plumbing.

Failure modes (ranked by likelihood × cost)

1. Composer resolution breaks on any PHP/Symfony bump, blocking unrelated upgrades and the whole app's patch cadence. Highest probability, highest cost.
2. Unpatched vulnerability in a pinned transitive dependency with no upstream fix path.
3. Silent permission drift after a framework upgrade — authorization bugs that fail open.
4. Schema drift between bundle Doctrine mappings and host migrations.
5. Licence exposure if vendored without confirmation.

Ramp-up

• Low for a Symfony engineer fluent in the Security component/ACL on the mechanics; high on e-core domain semantics, which is the actual learning curve. For a Laravel team, the transferable asset is the permission spec — a day or two of reading — not the code.

TPM recommendation: do not adopt as a dependency on a Laravel roadmap. Extract the authorization model into a spec, confirm the licence, assign an owner, and implement on native primitives. If a live Sam/Symfony integration forces use, scope it as a time-boxed bridge with a pinned fork, an explicit risk acceptance, and a documented exit — and reflect the ownership cost in the milestone estimate rather than booking the package as free reuse.