Oneloginsaml Bundle Laravel Package

Technical Evaluation

Architecture fit. The single most consequential finding for a TPM is that this artifact is not a Laravel package. bloomatwork/oneloginsaml-bundle is a Symfony bundle: its public surface is Symfony-specific plumbing — a legacy Bundle subclass, a DependencyInjection extension, YAML config tree, a security firewall authenticator, and a shipped ACS/metadata controller. None of that composes with Laravel's service container, middleware pipeline, or Auth guards. The reusable asset is the underlying framework-agnostic onelogin/php-saml toolkit; the bundle is Symfony glue around it. If the product roadmap assumes "add SAML SSO to our Laravel app via this Composer package," that premise is false and the work item needs re-scoping before any engineering hours are spent. The right framing is: we are evaluating the OneLogin SAML toolkit, and this bundle is one (Symfony-only) reference implementation of how to wire it.

Integration feasibility. For a Laravel codebase, direct integration is not feasible without effectively rewriting the bundle. A Laravel path exists and is well-trodden: depend on onelogin/php-saml directly and wrap it in a Laravel-native integration — a controller for ACS and metadata, a guard or socialite-style driver, config under config/services.php or a dedicated config/saml.php, and a user-provisioning seam. The bundle's design still has reference value: its separation of "toolkit settings object" from "Symfony service wiring" maps cleanly onto "SAML settings object" plus "Laravel service provider." For a Symfony team the bundle is closer to feasible, but the legacy Bundle base class and Symfony 2.x/3.x-era constraints mean it targets an end-of-life framework generation; a modern Symfony 5+/6+ app would need a fork or the maintained hslavich/OneloginSamlBundle / nbgrp/onelogin-saml-bundle instead.

Technical risk. Ranked by business impact:

1. Abandonment / supply-chain risk (high). Zero stars, zero dependents, low visibility fork, Symfony2-era code. There is no credible community to absorb a CVE or a breaking upstream change. Assume the team owns a fork indefinitely.
2. Framework mismatch risk (high, but cheap to retire). The risk is spending a sprint discovering the obvious. Retire it in a one-day spike.
3. Protocol operational risk (medium, inherent to SAML). Clock skew on NotBefore/NotOnOrAfter, certificate format ambiguity (PEM headers vs. raw base64 body producing misleading "invalid signature" errors), audience/recipient mismatch from trailing slashes or http-vs-https, SameSite cookie behavior across the IdP redirect, reverse-proxy baseurl drift, and attribute naming divergence across Okta / Entra / ADFS / OneLogin. These are all solvable, none are novel, and all consume calendar time during first-IdP onboarding.
4. Security-configuration risk (medium). Debug mode leaks full assertions to logs; the ACS endpoint must be exempt from CSRF and from WAF body inspection; replay protection is not enabled by default. These are config-governance items, not library defects.
5. Scope-creep risk (medium). SAML SSO is table stakes, but the adjacent asks — OIDC, SCIM provisioning/deprovisioning, per-tenant IdP config, admin self-serve metadata upload — will arrive immediately after the first SSO deal closes. A pure-SAML SP does not address them.

Key questions. A TPM should force answers to these before approving build:

• What is our actual target framework — Laravel, Symfony, or both? This single answer invalidates or validates the package.
• Is SSO a sales unblocker (buy or build the cheapest credible thing) or a platform capability (invest in multi-tenant, self-serve admin, OIDC+SCIM)? The answer changes the build-vs-buy recommendation.
• Which IdPs must we support at launch, and which have contractual deadlines attached? Each additional IdP is a real onboarding and testing cost.
• Do we require IdP-initiated flows (Okta/Azure app-tile launches), or is SP-initiated sufficient? IdP-initiated changes the routing and default-landing design.
• Who owns SAML certificate rotation and IdP metadata refresh as a standing operational duty — not a project task?
• Has anyone audited the php-saml version pinned by this fork against its CVE history, and what is the upgrade path?
• Is a managed identity vendor (WorkOS, Auth0, Stytch) an acceptable alternative to owning this integration? For many teams it is cheaper than the total cost of ownership of a hand-rolled SP, especially once OIDC and SCIM enter scope.

Integration Approach

Stack fit. For a Laravel product, re-baseline the technical plan on onelogin/php-saml and treat this bundle as design documentation. Concretely, the Laravel shape is: a SamlServiceProvider binding a configured OneLogin\Saml2\Auth singleton, routes for /saml/acs, /saml/metadata, and /saml/sls, a controller that consumes the assertion and delegates to a SamlUserResolver contract, and a guard or middleware that reads the resulting session identity. That mirrors the bundle's seams — settings object, user factory, ACS/metadata controller — without inheriting its framework coupling. If a maintained Laravel SAML wrapper backed by php-saml exists that meets the audit criteria, prefer it over bespoke wiring; the TPM's job is to make that a build-vs-buy line item rather than an engineering preference.

For a Symfony product, do not adopt this fork. Specify the actively maintained bundle as the dependency and only fall back to this artifact if a concrete constraint (pinned legacy version, existing internal fork) requires it — in which case vendor it and assign explicit ownership.

Migration path. There is no meaningful migration path from this bundle — it's greenfield either way. The realistic path is: (1) spike the framework-agnostic toolkit in a throwaway branch against one real IdP sandbox; (2) prove the full SP-initiated round trip; (3) only then productionize. If a Laravel SAML package is adopted instead, the "migration" is the eventual swap of the wrapper, which is why the user-resolution seam should be an application-owned interface rather than a direct dependency on the package's types.

Compatibility. Two axes to validate explicitly and record as acceptance criteria: the php-saml toolkit version against the PHP runtime we deploy, and the wrapper (if any) against our framework major version. For Symfony, the legacy Bundle class is a hard incompatibility with modern versions. For Laravel, check the package's supported PHP range and whether it depends on the deprecated php-saml 3.x line. Also confirm license compatibility — this is an Apache/MIT-family ecosystem but should be asserted, not assumed.

Sequencing. A defensible phased plan:

• Phase 0 — Decision spike (days, not weeks). Answer the framework question, audit the toolkit's release/CVE history, pick the dependency, and get security sign-off on the config posture. Output: a one-page dependency decision record.
• Phase 1 — One IdP, SP-initiated, pre-provisioned users. Lookup-only user resolution that fails closed. No JIT provisioning yet. This is the deal-unblocking slice.
• Phase 2 — Operational hardening. Certificate rotation runbook, IdP metadata as config not code, baseurl behavior behind the load balancer, SameSite=Lax, ACS excluded from CSRF/WAF interference, debug disabled in prod, replay protection if the toolkit supports it.
• Phase 3 — IdP-initiated flows and logout. SLO is the historically brittle piece; many teams ship local logout plus redirect to the IdP's logout URL and treat federation-wide session termination as best-effort. Say so in the acceptance criteria rather than discovering it late.
• Phase 4 — Only if demand justifies. JIT provisioning, multi-tenant IdP config, admin self-serve metadata upload, then OIDC/SCIM as a separate initiative with its own business case.

Operational Impact

Maintenance. Treat this as a standing operational duty, not a closed project, and staff it accordingly. The recurring load is: tracking php-saml security releases and upgrading, rotating IdP and SP signing certificates before expiry, refreshing IdP metadata when a customer's IdP changes, and maintaining per-IdP attribute mapping as customers onboard. Because this specific fork has zero dependents and no visible maintainer cadence, the team inherits the entire burden with no shared-cost amortization — that is the core TPM argument against adopting it, and it should be quantified in the business case as ongoing FTE fraction rather than ignored. Preferring an actively maintained upstream bundle or a vendor-backed SDK is a hedge that converts some of this cost into a subscription.

Support. Support surface splits into two tiers. Tier 1 is ordinary user support: "SSO isn't working," which is usually a configuration drift, an expired certificate, or a customer-side IdP change. Tier 2 is the genuinely hard class: signature validation failures, audience/recipient mismatches, clock skew. These produce cryptic errors and require someone who can read the toolkit's last_error_reason and inspect the raw assertion. Plan for at least two engineers able to operate at Tier 2 — a single-person dependency on a SAML expert is a real continuity risk and should be an explicit staffing decision. Also pre-write the "customer asks us to configure their IdP" runbook; enterprise SSO support is a documentation product as much as a code product.

Scaling. Protocol-level scaling is not a concern — SAML validation is CPU-cheap and stateless per request; the ACS endpoint handles enterprise login volumes trivially. The scaling pressure is configuration cardinality. One IdP is a YAML block; fifty enterprise tenants each with their own IdP means per-tenant settings resolution, per-tenant certificates, and an admin surface to manage them. If the roadmap points at many enterprise accounts, decide early whether to build that multi-tenant config plane or push it onto a managed identity vendor that already has it. Retrofitting it later is the expensive path, and it's the most likely source of underestimated cost.

Failure modes. Enumerate these in the runbook with symptoms and first-response steps:

• Expired or rotated IdP signing certificate → all logins fail simultaneously, hard. Highest-severity, highest-likelihood. Mitigate with expiry monitoring and a documented overlap procedure.
• Audience/ACS URL mismatch → intermittent, per-environment failures that look like "works for me." Almost always a trailing slash, scheme, or reverse-proxy baseurl issue.
• Clock drift → sporadic validation failures that correlate with nothing and reproduce poorly. NTP plus a small skew allowance.
• Cookie dropped on the return POST → login loops or silent anonymous sessions, often after a security-header change. SameSite=Lax plus Secure.
• Debug mode left on → assertions containing PII in logs; a compliance finding, not an outage. Gate it in config review.
• ACS endpoint blocked by CSRF or WAF body inspection → wholesale login failure with a misleading 403/400. Exemption must be codified, not tribal knowledge.
• Upstream toolkit CVE with no patch for this fork → the structural failure mode of adopting an unmaintained dependency. The only real mitigation is not adopting it, or vendoring plus a patching commitment.

Ramp-up. Budget one to two weeks of engineering for a competent PHP developer with no prior SAML exposure to reach first working SP-initiated login against a real IdP sandbox, plus additional time per IdP for attribute mapping and flow-specific quirks. The learning curve is not in the code — the code is thin — it's in the protocol's failure modes and in the IdP admin consoles, which are inconsistent and poorly documented. Two accelerants worth funding: a debug: true walkthrough of a real assertion early (one dump of the full attributes array resolves most mapping ambiguity), and a signed assertion fixture checked into the test suite so CI never touches a live IdP.

Bottom line for the decision meeting. The capability is strategically necessary — SSO unblocks enterprise procurement and strengthens the compliance narrative. This specific artifact is the wrong dependency: it is a Symfony-only, Symfony2-era, zero-adoption fork being evaluated for a Laravel stack. Approve the SSO initiative, reject this package as the implementation vehicle, and task engineering with a short, time-boxed spike to select a framework-appropriate, maintained dependency on top of onelogin/php-saml — or, if the roadmap includes OIDC and SCIM, to price a managed identity vendor against the fully-loaded total cost of ownership of owning this integration.