Oneloginsaml Bundle Laravel Package

Technical Evaluation

Scope correction up front: despite the request framing this as a "Laravel/PHP package," mi-lopez/OneloginSamlBundle is a Symfony bundle, not a Laravel package. That distinction drives most of this assessment.

Architecture fit

• If the target stack is Symfony: structurally correct fit — bundles register through the kernel, wire into the DI container, and hook the security firewall as a custom authenticator. This is the idiomatic way to add SAML SP support to Symfony.
• If the target stack is Laravel: poor fit. Laravel shares Symfony components but not the bundle/kernel/DI-config model, and its auth is guard-based rather than firewall-based. Adopting this would mean reimplementing bundle bootstrapping inside a Laravel service provider — high effort, no upstream support, and the result diverges from both ecosystems' idioms.
• Underlying dependency is the OneLogin php-saml toolkit, which carries the actual cryptographic and protocol logic. The bundle is a thin integration layer; the real risk sits one level down in the upstream toolkit.

Integration feasibility

• Low for Laravel, moderate-to-high for Symfony. The bundle's surface is small: SP entity ID, ACS URL, IdP metadata, attribute mapping, optional signing/encryption of assertions, optional single logout.
• The hard work is configuration and IdP coordination (metadata exchange, certificate handling), not code. Expect 2–5 engineer-days for a first working SP-initiated flow in a Symfony app; materially more if you must port it to Laravel.

Technical risk (ranked)

1. Fork with zero social proof. 0 stars, 0 dependents, single maintainer. The upstream lineage is hslavich/OneloginSamlBundle; this appears to be a downstream fork. There is no community to catch regressions, no security review, and no guarantee it tracks upstream fixes. Treat it as self-maintained vendored code, not a dependency.
2. Upstream SAML toolkit lifecycle. OneLogin has signaled reduced/ending maintenance of its SAML toolkits; php-saml is not a fast-moving, well-resourced project. Verify the pinned version, whether it is current, and whether any known CVEs (XML signature wrapping, xmlsec handling, XXE) are patched in that pin. This is the single most important due-diligence item.
3. SAML protocol surface is a security boundary. Assertion signature validation, audience restriction, InResponseTo replay protection, clock-skew tolerance, and encrypted assertions are all places where a thin or stale wrapper becomes an auth bypass. Any adoption requires a security review, not just a code review.
4. Single-maintainer abandonment. No release cadence, no issue triage. Fork it internally on day one if you proceed.

Key questions to resolve before any commitment

• Which stack are we actually shipping on — Symfony or Laravel? (Recommendation: if Laravel, stop here and evaluate 24slides/laravel-saml2 or an OIDC/proxy approach instead.)
• Which fork/commit does this track from hslavich/OneloginSamlBundle, and how far behind is it?
• Which onelogin/php-saml version is pinned, and what is its CVE and EOL status?
• Which IdPs must we support (Entra ID, Okta, OneLogin, Google Workspace, in-house Shibboleth)?
• Do we need SP-initiated only, or also IdP-initiated and Single Logout? SLO is where most of these wrappers are weakest.
• Multi-tenant / multiple IdPs per deployment, or single IdP?

Integration Approach

Stack fit

• Symfony: use the upstream hslavich/OneloginSamlBundle unless there is a specific, documented reason this fork exists. Adopting a zero-signal fork over a maintained upstream needs justification, not the reverse.
• Laravel: do not use this package. Two viable paths:
  • Native: a Laravel SAML SP package (24slides/laravel-saml2) or a thin service around onelogin/php-saml directly, giving you control over the pin.
  • Broker: stand up Keycloak / Authentik / oauth2-proxy as the SAML SP and let Laravel consume OIDC. Adds an operational component but moves SAML off your application code and gives you one integration point for many apps. Preferred if more than one app needs SAML.

Migration path

1. Inventory current auth: local password, existing SSO, session lifetime, role source of truth.
2. Stand up the SP in staging with a test IdP tenant; complete metadata exchange both directions.
3. Map IdP attributes (NameID, email, groups) onto internal user records; decide JIT provisioning vs. pre-provisioning vs. SCIM.
4. Define group → role mapping explicitly and test the negative cases (unknown user, unmapped group, deprovisioned user with a live session).
5. Run IdP-initiated and SP-initiated paths, plus logout, in staging.
6. Cut over behind a feature flag with local auth retained as break-glass for at least one release cycle.

Compatibility

• Pin the php-saml version explicitly and commit the lockfile. Verify PHP version support against the app runtime (the toolkit has historically lagged newer PHP releases).
• Requires ext-openssl and typically ext-dom/ext-xml; confirm the container image has them.
• Proxy/load-balancer configuration matters: ACS URL and entity ID must match exactly what the IdP has registered, including scheme and trailing slash. This is the #1 source of "works in staging, fails in prod."

Sequencing Security review of the pinned toolkit → choose upstream vs. fork (or Laravel-native path) → staging integration with test IdP → attribute/role mapping → SLO and edge cases → flagged production cutover → decommission local auth later, not at cutover.

Operational Impact

Maintenance

• Assume you own this code. With 0 stars and 0 dependents there is no one else running it in production. Budget an internal mirror, a documented patch process, and a quarterly review of upstream php-saml security advisories.
• IdP metadata and signing certificates rotate. Someone must own that calendar, or logins break on a date nobody wrote down.

Support

• No vendor, no community, no SLA. Incidents resolve at your team's speed and require SAML literacy that may not exist on-call today.
• Upstream hslavich issues may or may not apply to this fork's state — an ambiguity that costs time during incidents.

Scaling

• Protocol cost is negligible; SAML is a per-login handshake, not a hot path. Real scaling concerns are session store coherence across app nodes (if assertions are cached or replay-protected server-side) and the IdP's own rate/availability limits.
• Metadata refresh and cert rollover are the operational scaling limits, not throughput.

Failure modes to instrument and alert on

• Expired or rotated IdP signing certificate → total login outage, hard failure, obvious.
• Clock skew beyond tolerance → intermittent signature/NotOnOrAfter validation failures, easy to misdiagnose as a code bug.
• ACS URL / entity ID mismatch after a proxy or domain change → login loop or Invalid audience.
• NameID format mismatch (persistent vs. email vs. unspecified) → users authenticate but can't be matched to local accounts.
• Attribute/group mapping drift → silent privilege change or lockout; the worst class, because it fails partially.
• Replay-protection gaps or missing InResponseTo validation → the security-review item that should block launch if unresolved.
• Stale session after IdP deprovisioning (no SLO) → offboarded users retain access until session expiry; mitigate with short session lifetimes plus a periodic revalidation.

Ramp-up

• Plan for one engineer to become the SAML owner: ~1–2 weeks to proficiency in SAML assertions, signatures, and IdP-side configuration.
• Debugging is opaque — you are reading base64-encoded XML and browser SAML traces. Budget for a documented runbook covering cert rotation, clock skew, and metadata refresh, or on-call will escalate every auth incident.
• Add a staging IdP tenant permanently; you cannot test this safely against production IdP config.

Bottom line: if the stack is Symfony and you accept ownership of a lightly maintained fork plus a security review of the underlying SAML toolkit, this is a workable but low-leverage dependency — prefer the maintained upstream. If the stack is Laravel, this package is the wrong tool and the evaluation should pivot to a Laravel-native SAML package or a SAML-to-OIDC broker before any engineering time is spent.