Oneloginsaml Bundle Laravel Package

Technical Evaluation

Architecture fit (important caveat): Despite being referenced here as a "Laravel/PHP package," hslavich/oneloginsaml-bundle is a Symfony bundle, not a Laravel package. It ships Symfony-specific glue — a DependencyInjection extension, a security firewall factory for a SAML guard authenticator, event subscribers for user creation/attribute mapping, and config tree definitions bound to Symfony's security.yaml model. None of that maps cleanly onto Laravel's guard/provider/middleware model. The reusable asset is the underlying onelogin/php-saml library plus the reference implementation of SAML flow handling; the bundle itself is a poor direct fit for a Laravel codebase.

Integration feasibility: Feasible but not drop-in. Three realistic paths:

• Broker pattern (recommended if the IdP integration must be shared): stand up a small Symfony service using this bundle as a SAML SP, exchange a signed assertion for an app-issued JWT, and have Laravel authenticate against that. Keeps the bundle in its native habitat and isolates SAML parsing from the Laravel app.
• Port/adapt: lift the bundle's auth flow into a Laravel package — middleware for ACS, a user provider for attribute mapping, an event/listener for JIT provisioning. Moderate effort, inherits upstream risk.
• Replace: use a Laravel-native SAML SP (aacotroneo/laravel-saml2, a Socialite SAML provider, or onelogin/php-saml directly with a thin controller). Often lower total cost than adapting this bundle.

Technical risk (elevated):

• Staleness: last release 2022-11-23. SAML is a security-critical surface with a history of XXE, XML signature wrapping (XSW), and comment-truncation vulnerabilities. Any unpatched dependency window is a finding in a security review, not a footnote.
• Upstream drift: onelogin/php-saml has moved to a new maintainer (SAML-Toolkit/php-saml). Pinning to an old transitive version is a liability; the bundle's version constraints may block patched releases.
• Adoption signal is weak: 147 stars, 0 dependents. Low usage means few eyes on edge cases and a thin community for troubleshooting. Opportunity score of 31 reinforces that this is not a strategically strong bet.
• Framework coupling: Symfony major-version and PHP-version constraints will dictate your platform ceiling if you host the broker service.

Key questions for the team:

1. Does the target IdP require SP-initiated, IdP-initiated, or both? Is Single Logout in scope, and is that a hard requirement?
2. Is multi-tenant SAML needed (per-customer IdP metadata)? The bundle is essentially single-IdP-config oriented.
3. What is the attribute contract — which claims drive identity, roles, and provisioning? Is JIT user creation acceptable, or does HR/SCIM own the lifecycle?
4. Are we willing to own a fork? Who is the named maintainer, and what is the patch SLA if a SAML CVE lands?
5. Can we keep SAML out of the Laravel request path entirely via a broker, or is that infrastructure we don't want to run?
6. What does the security review require — signed assertions only, encrypted assertions, SHA-256, strict audience/recipient/inResponseTo validation?

Integration Approach

Stack fit: Poor for a Laravel monolith as-is; good for a Symfony service. The bundle's value is its reference implementation of SP-side flows, config-driven IdP metadata, and attribute-to-user mapping hooks — all portable concepts, not portable code. If the organization already runs Symfony anywhere, the broker option is the cleanest use of this package. If the stack is Laravel-only, treat this bundle as documentation and build or buy a Laravel-native SP.

Migration path:

1. Treat the bundle as an evaluation artifact: run it in a throwaway Symfony container against a test IdP (Keycloak/SimpleSAMLphp) to validate metadata exchange, attribute mapping, and logout behavior end-to-end.
2. If validated and a broker is acceptable, harden the Symfony broker (pinned patched php-saml, cert rotation, structured logging on ACS) and expose a token endpoint to Laravel.
3. If a broker is not acceptable, use the validated attribute contract and flow behavior to spec a Laravel-native implementation; do not hand-port Symfony security internals.

Compatibility: Verify PHP and Symfony constraints against the runtime you'd deploy the broker on. Confirm the transitive onelogin/php-saml version supports the signature algorithms and XML hardening your IdP and security review demand. Check that libxml settings (LIBXML_NOENT/entity loading) are disabled in the deployed config — this is a class of bug that historically bites SAML SPs.

Sequencing:

1. Spike (1–2 weeks): IdP sandbox, metadata exchange, attribute mapping, SP- and IdP-initiated login, logout behavior. Output: go/no-go on broker vs. rebuild.
2. Decision gate: security review of dependency tree and fork ownership commitment. If either fails, pivot to the Laravel-native option before writing production code.
3. Broker build + Laravel token exchange (or native SP build), with staging integration against the real IdP's test tenant.
4. Production rollout: canary a single low-risk app or user cohort; retain password/SSO fallback until a full auth cycle (including cert rollover) has been observed.
5. Decommission fallback only after a successful certificate rotation cycle and a logout/revocation drill.

Operational Impact

Maintenance: This is the dominant cost. Expect to own the dependency: monitor php-saml advisories, patch or fork the bundle when upstream moves, and re-validate IdP metadata on the IdP's schedule (certificate and endpoint changes are routine, not exceptional). Budget roughly 10–20% of an engineer's time in steady state for an auth-critical integration of this age, spiking during security reviews.

Support: Low external support surface — no active community, no vendor. Internal runbooks are mandatory: cert rotation procedure, metadata refresh, ACS troubleshooting, and a documented break-glass local login path for when the IdP is unavailable.

Scaling: SAML SP scaling is not the hard part — stateless ACS handling scales horizontally; the constraints are the IdP's session limits and your user/attribute sync. Multi-tenant SAML is the real scaling ceiling: per-customer metadata, per-tenant certs, and per-tenant attribute maps are not first-class in this bundle and would require meaningful extension work.

Failure modes to instrument explicitly:

• Expired or mismatched IdP signing certificate → mass login failure with opaque errors. Alert on ACS error rate, not just 500s.
• Metadata drift after an IdP-side change → signature validation failures for a subset of users.
• Clock skew between SP and IdP → NotBefore/NotOnOrAfter rejections; enforce NTP.
• Replay and unsolicited-response handling: confirm inResponseTo and audience/recipient validation are enforced, and that the replay cache is viable if multiple app instances serve ACS.
• Session/logout semantics: SLO is frequently partial; users may remain logged in at the IdP or in Laravel after local logout. Document the actual behavior rather than assuming.
• Silent partial failures: SAML libraries tend to surface generic "invalid response" errors. Without structured logging of the reason code, on-call triage is slow.

Ramp-up: SAML is a specialized skill. Expect 1–2 weeks for a competent engineer to become productive on the flow and the failure taxonomy, longer to be confident in the security review. The TPM should sequence a named owner and a documented runbook as deliverables of the integration itself, not as follow-up work — otherwise the knowledge leaves with the contractor.

TPM recommendation: Use this package as a validation harness and reference implementation, not as a production dependency in a Laravel system. Commit to either a hardened Symfony broker (if cross-framework SSO is a genuine requirement) or a maintained Laravel-native SP (if the stack is Laravel-only). Make fork ownership and security-patch SLA explicit go/no-go criteria before any production code is written.