Sso Auth Bundle Laravel Package

Technical Evaluation

Architecture fit The package is a Symfony 2 bundle, not a Laravel package. It ships a WebnetSsoAuthBundle with a DependencyInjection extension, a Security factory, and Symfony-specific config tree — none of which are loadable by Laravel's service container. There is no ServiceProvider, no facade, no Laravel-compatible config publishing. For a Laravel codebase this is a hard architectural mismatch, not an adapter-level gap. Even inside a Symfony codebase the fit is narrow: it targets Symfony 2.x security listeners and an SSO protocol integration that predates Symfony 3's authentication refactor, so it would require rewriting listeners against AuthenticatorInterface to run on supported Symfony versions. Net: the package cannot be dropped into a Laravel stack and carries meaningful rework even in its native framework.

Integration feasibility Feasibility is low without a fork. Assessment of the realistic paths:

• As-is in Laravel: not feasible — wrong framework contract entirely.
• Fork + port to Laravel: feasible in principle (the SSO handshake logic is the reusable core), but you would be adopting and maintaining an unmaintained 2018 codebase with 1 star and 0 dependents. You would own 100% of the risk with near-zero upstream signal to lean on.
• Use as reference implementation: the most defensible option. Read the SSO flow, reimplement against a maintained library (e.g., laravel/socialite with a custom provider, or a SAML/OIDC library) and keep only what you can verify.

Technical risk

• Abandonment risk: high. Last release 2018-06-26; ~7+ years without a tag. No active maintainer signal, 1 star, 0 dependents means no community to absorb CVE fixes or framework drift.
• Framework EOL risk: high. Symfony 2 (incl. 2.8) is end-of-life; PHP versions implied by that era are unsupported and will not run cleanly on modern PHP 8.x runtimes.
• Security-critical surface. This is authentication. Unmaintained auth code is the worst category to inherit — SSO flows touch token validation, signature/assertion checks, redirect handling, and session fixation. Silent regressions here are security incidents, not bugs.
• Supply chain / audit risk. Minimal public scrutiny (1 star) means no third-party review; you cannot lean on ecosystem hardening.
• Opportunity score signal. The 2.43 opportunity figure is not sufficient to offset the combination of framework mismatch, EOL target, and abandonment. Treat it as noise, not a green light.

Key questions for the engineering sponsor

1. Is the target genuinely Laravel, or is there a legacy Symfony 2 service in scope where this bundle is a stopgap? The answer changes the entire recommendation.
2. Which SSO protocol is actually required — SAML 2.0, OIDC, CAS, or a bespoke IdP handshake? Most modern IdPs are better served by a maintained library.
3. What is the acceptable CVE-response SLA for an auth component, and who owns it if we fork?
4. Has anyone validated the bundle's SSO logic against our IdP, or is the 2018 assumption still true?
5. Is there a hard deadline forcing reuse, or is this a "cheap option" evaluation?

TPM recommendation: do not adopt as a dependency. Use as a design reference only, and budget for a maintained SSO library.

Integration Approach

Stack fit Poor as-is. The bundle's assumptions (Symfony kernel, security.yml firewall config, Doctrine-era service wiring) do not map onto Laravel's config/auth.php, guards/providers, and middleware pipeline. Any integration would be a port, not an install. If a Symfony service is genuinely in scope, pin to a maintained Symfony LTS and rewrite the security listener — do not pin to Symfony 2.

Migration path Recommended path, in order of preference:

1. Greenfield replacement (preferred): implement SSO via a maintained library — SAML (onelogin/php-saml or lightsaml), OIDC (jumbojett/openid-connect-php), or Socialite with a custom provider for OAuth-based IdPs. Wrap it in a Laravel guard. This is the lowest total-cost path.
2. Reference port (fallback): extract only the protocol handshake logic from the bundle, rewrite as a Laravel-native auth guard with tests, and explicitly document the provenance and the 2018 assumptions inherited.
3. Fork-and-vendor (last resort): vendor the fork into the repo, pin the PHP/runtime constraints, and accept full ownership. Only justified if the IdP handshake is genuinely bespoke and undocumented.

There is no credible "lift and shift" migration. Budget the port as net-new work.

Compatibility

• Laravel: no compatible version — no composer.json framework constraint will resolve cleanly, and there is no ServiceProvider.
• Symfony: targets 2.x; incompatible with Symfony 3+ security changes and with the modern authenticator system.
• PHP: authored in the PHP 5.x/7.0 era; expect deprecations and potential breakage on PHP 8.x. Verify with a static analysis pass before anything else.
• Dependency graph: 0 dependents means no downstream validation; assume transitive dependencies are equally stale and audit them independently.

Sequencing

1. Discovery (1 sprint): confirm target framework and required SSO protocol; inventory the IdP's actual capabilities (SAML metadata, OIDC discovery, attribute mapping).
2. Spike (1 sprint): prove a maintained library against the IdP in a sandbox. Success here removes the need for the bundle.
3. Build (2–3 sprints): guard/middleware, attribute mapping, session lifecycle, logout/SLO handling, error paths.
4. Security review (1 sprint): assertion validation, replay protection, redirect allow-listing, session fixation.
5. Parallel run: shadow-mode login alongside the existing path before cutover.

Do not sequence the bundle port before step 2 — the spike often obviates it.

Operational Impact

Maintenance The dominant cost. An unmaintained 2018 auth package with a single star means you are the maintainer from day one. Estimate ongoing ownership as a standing allocation, not a one-time integration: framework upgrades, PHP runtime upgrades, IdP certificate/metadata rotations, and periodic security review. Every Laravel major upgrade becomes a manual compatibility exercise with no upstream to lean on. This is the single largest hidden cost and should be surfaced explicitly in any business case.

Support No vendor, no active maintainer, no issue tracker velocity, 0 dependents to consult. Escalation path is internal only. Any production auth incident is resolved by your team reading 2018 code under pressure — an unfavorable posture for a critical-path component. Recommend naming a specific owner (person or squad) and documenting it in the runbook before adoption, or declining.

Scaling Auth is low-throughput relative to application traffic, so raw scaling is not the concern. The scaling risk is operational: token/session stores, IdP-side rate limits, and multi-region session consistency. The bundle predates modern distributed-session patterns, so any session handling would likely be rewritten regardless.

Failure modes

• Silent auth bypass or acceptance of unvalidated assertions — highest severity; a 2018 signature-validation path may not meet current IdP requirements.
• Hard break on runtime upgrade — PHP or framework bump takes login down wholesale.
• IdP metadata/cert rotation — no upstream patch; breaks on schedule with no notice.
• Dependency rot — transitive packages flagged by SCA or removed from Packagist.
• No rollback story — if the fork is the only auth path, rollback is a deployment, not a config toggle. Insist on a feature flag from the start.

Ramp-up Ramp-up is slow and asymmetric. A new engineer can read the SSO handshake in a day, but building the confidence to change it safely takes substantially longer because there are no tests of record, no maintainer to ask, and the blast radius is total (all logins). Contrast with a maintained library where docs, changelogs, and an active issue tracker compress ramp-up considerably. Factor this into the team-velocity argument — an unmaintained auth component is a permanent onboarding tax.

Bottom line for the TPM: the integration cost is not the risk; the lifetime ownership cost of an abandoned, framework-mismatched auth component is. Recommend a maintained-library replacement, with the bundle used at most as a reference for the IdP handshake.