Sso Library Laravel Package

Technical Evaluation

Architecture fit

The first thing a TPM must reconcile is the mismatch between the package's framing and its repository. The description positions this as a Laravel/PHP SSO package with broker-client architecture, middleware, routes, and configurable user attachment — all Laravel-native vocabulary. The underlying repository is korotovsky/SingleSignOnLibrary, described in its own metadata as a Symfony2 library. Both cannot be true of the same codebase, and the resolution matters enormously to planning: either (a) the description is aspirational/marketing copy over a Symfony2 bundle, (b) there are two artifacts and one is being mislabeled, or (c) the Laravel surface is a thin, undocumented wrapper. A TPM should not proceed to estimation until this is resolved, because the effort delta between "install and configure" and "port a dead framework's security stack" is roughly two orders of magnitude.

Even granting the most favorable reading — that the broker-client protocol logic is framework-agnostic and only the wiring is Symfony-specific — the integration seam does not exist in Laravel. Symfony2 bundles hang off the DependencyInjection container, kernel.request subscribers, and a custom security.firewalls.* factory. Laravel's equivalents are the Auth manager, guards, middleware, and service providers. There is no adapter path; there is only reimplement the wrapper and reuse the protocol core, if the core is separable.

Integration feasibility

Conditional and cheap to test. The decisive experiment is a one-to-two day spike: clone, read the composer constraints, attempt an install on the target runtime, and determine whether the validation/assertion code is decoupled from Symfony Request/Session/Container access. That single test converts speculation into a go/no-go.

Expect the install to fail. Symfony2-era code targets PHP 5.x–7.x and routinely breaks on PHP 8.2+ via dynamic properties, ${var} interpolation, each(), and interface method signatures. Composer constraints will likely block installation outright before runtime errors even surface.

The social signals reinforce the technical ones: zero stars, zero dependents, a composite score of 0, and no visible downstream users. For authentication code specifically, that means no bug-report corpus, no third-party testing in the wild, and no patch cadence. Absence of adoption is not proof of poor quality, but it removes every external safety net a TPM would normally price in.

Technical risk

• Security (high): The package's whole job is assertion parsing, signature validation, redirect handling, and session establishment — the highest-blast-radius surface in any application. Unmaintained auth code means every future CVE is yours to find, triage, and patch on your own timeline, with no upstream to notify you.
• Platform EOL (high): Symfony 2.8 and PHP 5.x/7.0–7.2 are out of security support. A successful port inherits design assumptions from that era — notably SHA-1 signature defaults that modern IdPs reject or that auditors will flag.
• Ambiguity (high): The protocol is never named. "SSO library" could mean CAS, SAML 1.1/2.0, OAuth/OIDC, or a bespoke cookie-token broker. Each carries different conformance, tooling, and vendor-interop burdens. This is a blocking unknown, not a detail.
• Knowledge concentration (medium-high): The only documentation is Symfony2-oriented. The design intent lives in the source, so the artifact that de-risks the project is a written protocol note produced by whoever reads it.
• Opportunity cost (medium): Maintained alternatives exist for every protocol in scope — league/oauth2-client/Socialite for OIDC, OneLogin or SimpleSAMLphp toolkits for SAML, apereo/phpcas for CAS. Choosing the abandoned path requires a positive justification, not just inertia.
• Licensing (low, but verify): Confirm an explicit license before forking; dormant repos sometimes lack one.

Key questions

1. Scope: Is the actual requirement to adopt this library, to ship SSO on Laravel, or to interoperate with an existing Symfony2 broker already in production? The third is a compatibility project with a real answer; the first is almost certainly a no-go.
2. Protocol: Which standard does it implement, and does it validate Destination, Audience, InResponseTo, NotBefore/NotOnOrAfter, and enforce nonce/replay protection? Any missing check is work we inherit.
3. Estate: Does anything internal already depend on this — a legacy Symfony2 IdP or service provider? If so, this becomes a replacement decision with a cutover date, not a selection decision.
4. Runtime: What do the composer constraints actually permit, and does it install on PHP 8.2+ / Laravel 10–11?
5. Separability: Is the protocol core isolated from Symfony classes, or is validation interleaved with framework access?
6. Ownership: Is there any upstream commit activity in the last 24 months, and is there a named engineer willing to own a permanent fork?

Integration Approach

Stack fit

Plan for a Laravel 10/11 target on PHP 8.2+ and assume the package will not install. Reframe the deliverable: the package is a protocol reference and a wire-format spec, not a dependency. Our output is a thin first-party Laravel package — a custom guard registered via Auth::extend (or middleware), a service provider for config and bindings, config/sso.php for non-secret settings, secrets in the environment or secret manager — with the extracted validation core behind it and the Symfony classes deleted rather than shimmed. Shimming dead framework plumbing is how you inherit a decade of debt you cannot explain to an auditor.

Migration path

1. Due diligence spike (1–2 weeks, fixed): Attempt install with --ignore-platform-reqs, record exactly what breaks, and in parallel write a short design note specifying the protocol — endpoints, parameters, token format, crypto steps, session/cookie handoff, logout propagation. That note is the durable artifact regardless of outcome, and it is what makes every later estimate credible.
2. Extract: Move protocol/validation classes into an internal namespace, replace Symfony Request/Session with PSR-7 or Laravel equivalents, add type declarations, fix PHP 8 deprecations, and write tests around signature validation and replay handling — the two places where a silent regression is a breach.
3. Wrap: Implement the Laravel guard and middleware over the extracted core. Fail closed on every error path; no broad catch around validation.
4. Parallel run: If a legacy Symfony2 client is live against the same IdP, run the new Laravel client in a non-production environment and compare assertions and behavior against the legacy client before any cutover.

Compatibility

Validate against the IdP's actual published metadata, not the library's assumptions: accepted signature algorithms (reject SHA-1), clock-skew tolerance, certificate rotation procedure, and entity/audience identifiers. Expect to add checks the library omits — the original author had no reason to anticipate today's IdP defaults. Budget an independent security review of the validation path as a gate, not a nice-to-have.

Sequencing

Spike first; commit only on a positive finding. Gate production on four conditions: PHP 8 compatibility proven by tests, coverage on the validation path, third-party security review passed, and a documented exit path to a maintained library. Schedule a decision review at the end of the spike and make "no-go, reimplement against a maintained toolkit using this as a wire-format reference" an easy outcome to select. Structurally, that is the most likely correct answer, and the plan should not punish it.

Operational Impact

Maintenance

This is the dominant cost and it is permanent. Post-fork, we own bug fixes, PHP and Laravel upgrades, crypto deprecations, and security patches with no upstream to merge from — the source repo is itself dormant, so "track upstream" is not an available mitigation. Budget a standing fraction of an engineer's time, not a one-off project allocation. If no owner is named before the first commit, the project should not start; an unowned auth dependency is worse than no SSO feature because it fails silently and late.

Support

There is none — no vendor, no maintainer, no SLA, no issue tracker with traction, no community corpus to search. Internal documentation becomes the only support surface, which raises the value of the spike's design note from "nice artifact" to "operational prerequisite." Plan a runbook covering IdP metadata changes, signing-certificate rotation, and rollback to password authentication.

Scaling

Technically undemanding: SSO is low-throughput and validation is CPU-bound signature checking plus a redirect, so horizontal scale is not the constraint. Keep it stateless — validate the assertion, mint a normal Laravel session, avoid session affinity — and the load story is trivial. The real scaling risk is topology: cross-subdomain cookie scope, multi-tenant IdP configurations, and logout propagation across many apps. These break in ways that are hard to reproduce locally and expensive to diagnose in production, so treat them as design decisions made up front rather than bugs discovered later.

Failure modes

• Silent auth bypass — validation exceptions swallowed by an over-broad handler. Fail closed, log loudly, alert on it.
• Replay acceptance — missing or unenforced nonce / InResponseTo tracking.
• Clock skew — windows too tight (intermittent rejections) or too loose (accepting stale assertions).
• Certificate rotation — IdP rolls its signing cert and every login fails at once with an opaque error; the runbook must exist before this happens.
• Cookie-domain misconfiguration — login redirect loops across subdomains, intermittent and user-visible.
• Silent divergence — the fork drifts from a dormant upstream, leaving no merge path and no way to distinguish our changes from inherited ones.

Mitigate with structured authentication logging, failure-rate alerting, and a documented break-glass path for administrators.

Ramp-up

Two to four weeks for a mid-level Laravel engineer to become productive, because the job requires two unfamiliar skills at once: SSO protocol fundamentals and enough Symfony2 Security-component literacy to read code that was ported without a rewrite. That is a recurring tax on every future maintainer, and it should be weighed explicitly against the adoption cost of a maintained toolkit where the same engineer ramps in days.

TPM bottom line: Leverage this package as an input to a buy-versus-build decision and as a protocol reference, not as a dependency. It contributes market signal (real SSO demand, thin OSS supply in PHP), a readable walkthrough of the broker-client and assertion-handling flow, and a concrete risk register for any SSO effort we do fund. It does not contribute code we should ship. The recommendation is to scope SSO as a funded capability on a maintained library or managed IdP, name an owner, and keep this repository off the dependency list.