Sso Idp Bundle Laravel Package

Technical Evaluation

Architecture fit — fails on the first criterion. korotovsky/sso-idp-bundle is a Symfony 2 bundle, not a Laravel package. It ships as a Bundle subclass with a DependencyInjection\Extension, compiler passes, and service definitions in Symfony's XML/YAML DI format — none of which Illuminate\Container can load. There is no service provider, no facade, no config/*.php file, and no extra.laravel block in composer.json. A Laravel target will fail at autoload/bootstrap, not at runtime logic, so there is no "try it and see" spike available.

The second architecture issue is scope and direction. This implements the Identity Provider role — the party that authenticates users and mints assertions. A Laravel application is far more commonly a Service Provider asking "is this user who they claim?" Standing up an IdP from an application monolith is legitimate, but it is an architectural commitment: your app becomes the trust root for every downstream system, and that decision must be driven by a protocol standard (SAML 2.0, OIDC), never by the availability of an unmaintained bundle.

Integration feasibility: low, and the cost is asymmetric. Zero stars, empty star metadata, score 0, zero dependents is the signature of an abandoned or archived repository, not a merely niche one. Symfony 2.x reached end of life in 2018; PHP 5.x security support ended in December 2018. Porting onto Laravel 10/11 + PHP 8.2 means rewriting DI wiring, replacing Symfony\Component\HttpKernel request/response with Illuminate\Http, migrating session and security context onto Laravel guards, and re-validating every cryptographic primitive on a modern runtime. That is a fork-and-rewrite, not an integration.

Technical risk is severe and concentrated where "move fast" is never acceptable — authentication.

• Unvetted crypto and token handling. An IdP mints bearer credentials. An unaudited ticket format, weak signature algorithm, missing replay protection, or non-constant-time comparison is a full account-takeover primitive. No visible security review, CVE history, or test suite.
• Protocol non-standardness. A bundle plus a sibling SP bundle implies a bespoke handshake — no off-the-shelf federation with Okta, Entra ID, or Google Workspace, and every downstream SP becomes a custom integration you own forever.
• Metadata integrity. Empty stars and a 0 score suggest the scoring pipeline could not resolve the repo at all. Confirm the repository and its license still exist before any investment; an unlicensed fork is a legal problem, not a technical one.
• Compatibility cliff. Symfony 2 code routinely breaks on PHP 8 (removed each(), create_function, dynamic property deprecation, stricter type juggling). The port is not a formality.

Key questions for the requester — each one can kill the initiative:

1. What protocol does this speak, and is there a written spec? If not, the protocol is the code, and the code is the risk.
2. Is the requirement to be an IdP or an SP? If SP, this package is irrelevant and a SAML SP library or socialiteproviders is the fit.
3. Which downstream systems must federate? Any commercial SaaS is a hard requirement for a standard protocol and disqualifies this package.
4. Who owns the code after adoption? With zero dependents and no maintainer activity, the answer is "we do, forever."
5. What is the license, and has legal cleared a fork?
6. What SLA and compliance posture are we promising? EOL software in the auth path surfaces as a SOC 2 / ISO 27001 finding.

The TPM leverage here is not adoption — it is scoping. Read the repository as a requirements specification: metadata endpoint, AuthnRequest handling, assertion signing and encryption, certificate lifecycle and rotation, attribute mapping, session and SLO semantics. That list is the estimate input for build-vs-buy, and it is the asset worth keeping.

Integration Approach

Stack fit. Assume Laravel 10/11 on PHP 8.2+ as the only defensible target. Direct use is out. Three viable shapes, in order of preference:

1. Replace with a standard protocol (recommended). If the goal is "users log into other apps with our credentials," implement OIDC on Laravel Passport (first-party, maintained) with an OIDC layer, or SAML 2.0 IdP on a maintained library. Higher upfront than a fork, far cheaper across three years, and it keeps you on a protocol with a written spec and an ecosystem.
2. Sidecar service. Run the legacy bundle in an isolated Symfony 2.8 / PHP 5.6 container behind a reverse proxy, exposing only auth endpoints, with Laravel calling it over HTTP. Preserves the original code but knowingly runs EOL software in the auth path — acceptable only as a 6–12 month bridge with a published decommission date, network isolation, and OS-layer patching.
3. Port into a Laravel-native package. Fork, extract protocol logic behind interfaces, reimplement DI and HTTP layers, wrap in a ServiceProvider. Highest control, highest cost, and you inherit the security review obligation in full.

Migration path. There is no upgrade path in the conventional sense — no Laravel version this was ever compatible with. Whichever of options 1 or 3 you choose, the first deliverable is a protocol reverse-engineering artifact: endpoint list, message formats, signing scheme, session/ticket lifecycle, logout semantics. That document, not the code, is the reusable asset and the thing you can hand to an auditor or a vendor.

Compatibility. Catalog hard blockers before estimating: PHP version floor (5.x), Symfony component pins (http-kernel, dependency-injection, security-core at 2.x), sensio/framework-extra-bundle-era conventions, and assumptions about Symfony session/security firewalls. Laravel already ships Symfony components at 6.x/7.x — a 2.x pin will produce Composer resolution conflicts the moment it sits beside a modern Laravel app. Expect composer why-not to be the first debugging session.

Sequencing — five gates, each able to stop the work, each with a TPM-owned exit criterion:

1. Verification spike (2–3 days). Clone, confirm license, read the protocol surface, run any existing tests on PHP 5.6. Exit: protocol summary + written go/no-go.
2. Threat model (1 week, security co-sign). Enumerate token forgery, replay, session fixation, logout propagation, key compromise. Exit: named security approver. If nobody will sign, stop here.
3. Direction decision. Standardize vs. port vs. sidecar, with a written cost comparison, a named owner, and a funded timeline.
4. Parallel run. New IdP issues assertions alongside the existing auth path; downstream SPs consume both; compare outcomes. No big-bang cutover on an auth path.
5. Cutover and decommission. Retire the legacy path, publish key rotation and incident runbooks, and confirm the old container is actually switched off.

Recommendation to communicate: unless IdP is a genuine product differentiator, stand up Keycloak (or buy Okta/Auth0/Entra) and integrate over OIDC. It answers the customer's "do you support SSO?" in weeks with vendor-backed security, and removes an entire class of security work — and every related audit finding — from the roadmap.

Operational Impact

Maintenance: total ownership. Zero dependents, zero stars, no visible release cadence means no upstream fixes, no PHP 8.x compatibility work, no dependency bumps. Every CVE in a transitive Symfony 2.x component becomes yours to patch or mitigate. Budget roughly 15–20% of one engineer's time indefinitely for security patching alone, plus a spike whenever PHP or Laravel ships a major. The TPM should treat that as a permanent line item in capacity planning, not a one-off migration cost.

Support: entirely internal. No vendor, no community, no Stack Overflow corpus for a package nobody uses. Incident response is internal, and the first responder may be whoever wrote the port — a bus factor of one unless you deliberately document the protocol and rotate ownership. If this lands in audit scope (SOC 2, ISO 27001), expect findings on unsupported/EOL components in the authentication path; that is a compliance cost carried on the roadmap, and it affects which enterprise deals you can accept.

Scaling: volume is not the constraint, state is. IdP traffic is low and bursty — login events, not API calls. The real concerns are stateful: the ticket/session store becomes a single point of failure, and key material must be shared across instances via a secrets manager or HSM, never local files. The sidecar route inherits a per-request Symfony 2 kernel boot, which is fine at SSO volumes but caps you to a handful of instances and complicates horizontal autoscaling in containers.

Failure modes, ranked by blast radius:

• Signing key expiry or mishandled rotation — every downstream SP rejects assertions simultaneously; total login outage across all integrated products.
• Clock skew between IdP and SP — intermittent, hard-to-reproduce validation failures that erode customer trust in the platform.
• Session/ticket store outage — users authenticate successfully but cannot complete the handshake; presents as a UI bug, is actually infrastructure.
• Replay or forgery if the token format is weak — silent, and the worst outcome in the set; potentially a breach rather than an outage.
• Logout propagation failure — the user believes they are globally logged out and is not. A recurring audit finding and a common support-ticket source.
• PHP/runtime upgrade breaks the sidecar — forces an unscheduled rewrite on the vendor's timeline, not yours.

For the TPM, each of these needs a pre-written runbook, a named on-call owner, and a customer-comms template before launch — particularly the key-rotation and logout cases, which fail loudly and are visible to every downstream partner at once.

Ramp-up. A senior engineer fluent in both Symfony and Laravel needs roughly a week to map the code thoroughly enough to trust an estimate, and several weeks to port it responsibly. The TPM does not need the code — the TPM needs the protocol artifact, the threat model, and the build-vs-buy cost comparison. Those three documents are what convert this repository from a dependency decision into a defensible roadmap decision, and they are deliverable within two to three weeks regardless of which integration shape is ultimately chosen.