Mjr Security Integration Bundle Laravel Package

Technical Evaluation

Architecture fit — none for a Laravel stack; narrow but coherent for its own. The package is a Symfony bundle, not a Laravel package, and its stated purpose is a glue layer: wire Symfony's Security component (firewalls, authentication providers, voters, access control) into MJR, Modera's JSON-RPC stack, so that RPC endpoints are gated the same way HTTP routes are. As a pattern this is sound — centralized policy enforcement at the transport boundary, decorator-style guards around the dispatcher, no auth logic in business handlers. As a dependency for us, it is inert: there are no service providers, facades, publishable config, Laravel middleware, or Gate/Policy bindings. The only reusable asset is the design idea, and it can be extracted in an afternoon.

Integration feasibility — very low, effectively a re-implementation. Adopting it in Laravel would mean (1) understanding MJR's auth contract, (2) re-expressing Symfony DI service definitions as container bindings, (3) translating firewall/listener hooks into Laravel middleware plus Gate/Policy, and (4) reconciling two different auth lifecycles. That is not a configuration exercise; it is a port with the original as a reference document. The repo is flagged read-only, so there is no upstream path to upstream fixes either.

Technical risk — severe and likely disqualifying. The signals are unanimous: 0 stars, 0 dependents, last release 2016-07-18, score 0, no maintainer activity. A 2016 Symfony bundle should be assumed to carry PHP 5.6/7.0-era constraints and Symfony 2.x/3.x APIs. Most importantly, it is security-adjacent code with no patch path for roughly a decade — unacceptable for the one dependency category where patching cadence is non-negotiable. MJR itself is a niche, low-adoption ecosystem, so there is no community to lean on for triage, no Stack Overflow corpus, and no candidate pool.

Key questions for the product/engineering owner:

• Do we actually depend on MJR / JSON-RPC anywhere, or was this surfaced by a naive "PHP auth" search? If MJR is not a hard constraint, the package is irrelevant.
• Is the Laravel categorization an error in our evaluation pipeline that should be corrected at the source, so Symfony artifacts stop entering Laravel intake?
• If it already appears in a legacy dependency graph, who owns the replacement and by what date?
• Do we have audit or compliance obligations (SOC 2, PCI, ISO 27001) that prohibit an unpatched authentication dependency outright?
• What is the exit cost if a team adopts it and it later proves unmaintainable?

Integration Approach

Stack fit — conceptual only. There is no supported bridge from a Symfony bundle into Laravel's container and auth pipeline. The transferable content is architectural: one enforcement point where requests are authenticated and authorized before reaching business logic, with the principal / resource / policy triple made explicit. That maps cleanly onto Laravel middleware plus Auth guards for authentication and Gate/Policy for authorization.

Migration path — do not migrate; re-implement natively.

1. Confirm the requirement behind the evaluation. If MJR is genuinely in play, treat this bundle as a specification artifact, not a dependency.
2. Extract the security semantics — what it authenticates, what it authorizes, how MJR calls map to identities and permissions — and record them in an ADR.
3. Rebuild in Laravel idioms: guards and providers in config/auth.php, request-level middleware for enforcement, Gate/Policy for authorization, Sanctum or Passport where token auth is needed.
4. If JSON-RPC is the actual requirement, select a maintained Laravel package rather than resurrecting Modera's stack.
5. Archive the original as a reference; do not add it to composer.json.

Compatibility — assumes and requires the legacy stack. Expect Symfony 2.8/3.0-era service definitions and PHP 5.x/7.0 syntax. It will not resolve cleanly against Laravel 10/11/12 on PHP 8.1+, and even if forced in, the runtime contracts will not bind.

Sequencing

• Week 0: Correct the categorization (Symfony ≠ Laravel); reclassify or close the intake ticket; note the pipeline gap that let it through.
• Week 1: Requirements workshop — is MJR/JSON-RPC a real constraint anywhere in the estate? Document the answer either way.
• Week 2: If MJR is required, publish an ADR recommending native re-implementation with an owner and a date; if not, close as "not applicable."
• Week 3+: Build the native auth/authz layer, add tests around the security boundary, and add a dependency-policy gate requiring an active maintainer and a recent release for security-adjacent packages.

Operational Impact

Maintenance — no upstream; full ownership if adopted. The repository is read-only, with zero releases since 2016 and zero dependents. There is no maintainer to file against, no release cadence, no security response. Adoption converts an unowned dependency into an unowned dependency we must maintain — in the highest-consequence code category we have. Do not fork it into a supported internal library.

Support — self-support only. Documentation is sparse and 2016-vintage, there is no community, and MJR-specific questions have no external corpus. Every incident becomes an internal archaeology project.

Scaling — not the binding constraint, but not a virtue. Request-level auth listeners scale the way the host application scales. The real scaling concern is organizational: sustaining a bespoke, undocumented auth integration concentrates scarce expertise and creates a single point of failure in the team.

Failure modes

• Silent auth bypass — a stale listener that fails to fire produces no error, only unauthorized access. This is the failure mode that matters.
• Unpatched vulnerability exposure — no CVE response path for nine-year-old authentication code.
• Dependency-resolution blockage — conflicts with modern PHP and framework constraints halt unrelated upgrades.
• Knowledge evaporation — the one engineer who understood the Modera/MJR mapping leaves and the integration becomes untouchable.
• Audit failure — inability to evidence a patched dependency posture for auth code.

Ramp-up — steep and low-yield. Engineers would have to learn two dead ecosystems (Symfony 2/3 security internals and MJR's JSON-RPC contract) to operate code they cannot fix upstream, and none of that learning transfers to the modern stack. The ROI is negative relative to spending the same effort on Laravel-native auth.

Bottom line: Do not integrate. Reclassify as a Symfony/MJR artifact outside our Laravel scope, preserve it as a requirements reference if MJR is genuinely in play, and satisfy the underlying need with native Laravel auth and authorization. Zero stars, zero dependents, a 2016 release, a read-only archive, and a score of zero are not a maturity barrier to overcome — they are the answer. The one durable output is a policy change: security-adjacent dependencies must have an active maintainer and a recent release before they clear review.