Saml Bundle Laravel Package

Product Decisions This Supports

• Enterprise SSO as a revenue gate. SAML 2.0 Service Provider support is the single most common blocker in enterprise security reviews. This package is evidence of the requirement, not a recommendation for the implementation — it demonstrates the SP-side scope (assertion consumption, metadata exchange, attribute mapping) that your roadmap item needs to cover.
• Build vs. buy, resolved toward buy. A 16-star, zero-dependent, last-released-2019 bundle is exactly the kind of dependency that looks free and costs a quarter of engineering time. Use it as a data point in the buy-vs-build analysis: SAML is a commodity, so the correct answer is a managed IdP/SSO vendor (WorkOS, Auth0, Okta, FusionAuth) or a maintained library (onelogin/php-saml, lightsaml) — not a bespoke bundle.
• Roadmap and packaging. Informs whether SSO lands in the Enterprise tier, whether it's gated per-seat or flat-fee, and whether SCIM/JIT provisioning ships as a fast-follow (they almost always are requested together).
• Framework fit is a hard filter. The description explicitly targets Symfony, not Laravel. If your product is Laravel, this package is not a candidate at all — it should be logged as "reference only" and removed from any shortlist before it reaches an engineering spike.
• Risk register input. Zero dependents plus a stale release means no upstream security patching. That is a standing liability for anything touching authentication, which is the highest-blast-radius surface in the product.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony, on a version contemporary with the 2019 release (Symfony 3.x/4.x era). A Laravel codebase should look elsewhere immediately.
• You need SP-only SAML — not IdP, not OIDC, not SCIM.
• Your team is prepared to fork and own it: vendor the code, patch it internally, and accept that no upstream fixes are coming.
• It is being used as a reference implementation to understand the SP handshake, not as a production dependency.

Look elsewhere when:

• You are on Laravel — there is no integration path here; use onelogin/php-saml or a vendor SDK.
• You need PHP 8+ support or any modern maintenance guarantee. A 2019 release predates PHP 8 and will not have been validated against it.
• You need a maintained dependency for an auth-critical path. Authentication is the wrong place to accept abandonware.
• You want community validation. Sixteen stars and zero dependents means no one has stress-tested this in production at scale, and you will be the first to find the edge cases.

How to Pitch It (Stakeholders)

To executives: Enterprise deals are being lost or delayed at the security review stage because we cannot offer SAML-based single sign-on. This is a revenue blocker, not a nice-to-have — it typically sits in the top three requirements on enterprise RFPs alongside SOC 2. The good news is that the market has solved it: managed SSO providers let us ship in weeks rather than quarters, at a predictable per-connection cost that is trivially covered by a single enterprise contract.

To engineering: We evaluated pdias/saml-bundle and are not adopting it. It is a Symfony bundle, not Laravel; its last release was October 2019; it has 16 stars and no dependents; and it will not receive security patches. We are treating it as a scope reference — it confirms the SP-side surface area we need — and recommending either a managed SSO vendor or a maintained SAML library on top of our existing framework. Budget expectation: a few weeks of integration work plus an ongoing vendor line item, versus an open-ended internal maintenance tax if we forked this.

The one-line recommendation: the requirement is real and strategically important; this specific package is not the vehicle. Fund the capability, buy the implementation, and keep the auth surface on code someone else is contractually obligated to patch.